逆虚拟机拷贝是怎么解决以上问题的呢。简单来说，就是不给主机直接发网络包，而是发给备机做转发：
1）请求包并不是直接发给主机，而是发给备机；
2）备机并不处理请求包，而是缓存后直接转发给主机；
3）主机的虚拟机接到请求包，执行业务逻辑，并执行正常的虚拟机拷贝到备机。
这样达成的结果是，传统虚拟机拷贝里的主机承担的网络活动和业务活动被解偶了。在逆拷贝里，主机只承担业务活动职责，而网络活动的职责则有备机承担。这样，在主机失败后，备机由于保存了最新的网络包（新于主机），即使备机保存的状态并不是最新（旧于主机），备机仍然能用存储的网络包回放来更新备机状态。
那问题来了，由于备机被加入到关键路径，备机如果失败，整个系统也瘫痪了，所以失败切换也需要考虑到备机。其实很简单，这个时候直接把主机的业务端口打开，直接监听业务网络包即可。这个时候，所有由于备机失败无法成功传到主机的网络包，会作为简单的丢包处理。然后由TCP来进行网络重传。
这样来做，由于去掉了传统虚拟机拷贝的阻塞缓存，这块回包的延时就去掉了。同时，拷贝也不需要高频率进行，进一步改善了性能。
本文由于篇幅限制，没有办法更加详细的对可行性和细节进行讨论，有兴趣可以读一下原文。这里贴一张原文的对比图。
http://ieeexplore.ieee.org/do...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。