VMware FT容错机制拆解：从虚拟化层到输出规则的高可用设计

最近重读MIT 6.824的重点论文，VMware FT（容错）这篇给我的触动比第一次读时深了很多。它讲的是如何在分布式世界里用两台虚拟机做到“看起来只有一台机器在工作”，核心就是主备同步和一套严格的输出规则。坦白说，这篇论文初读有点绕，因为它不像Raft那样跟你聊共识和选举，而是从虚拟化层切入，把“容错”这个老问题换了个赛道重新解了一遍。但一旦你把它的主备同步机制和输出规则吃透，再看很多高可用系统，眼睛会毒很多。

我会按论文的核心逻辑往下拆，不按章节顺序走，而是从“它到底解决了什么问题”开始，一路讲到日志协议、输出规则、故障检测，最后聊聊性能代价和适用边界。这条路走完，你应该能直接跟人讲清楚VMware FT为什么敢说自己能提供“无缝容错”，以及它付出了什么代价。

1. 为什么传统高可用方案总是差那么一点：从“切换窗口”说起

1.1 传统双机HA：心跳、漂移IP和恢复这个老三样

在虚拟化还没那么普及的年代，做高可用最主流的套路是什么？两台物理机，一台主一台备，中间拉一根心跳线，备机定时问主机“你还活着吗”。主机不回心跳，备机就开始接管：把虚拟IP漂移过来，把共享存储挂载上，拉起应用，对外恢复服务。

这套方案解决了“单点故障”的问题吗？解决了。但它有一个绕不开的硬伤——切换窗口。从主机真正故障，到备机能把服务完整拉起来，中间隔着少则几十秒、多则几分钟的空窗期。数据库要恢复redo日志，应用要重新加载内存状态，会话要重建。对很多在线业务来说，这几分钟可能就意味着大量超时、重试、甚至数据不一致。

那能不能让备机提前把状态都准备好，故障时直接切换？可以，这就引出了两种常见思路：一种是做存储层面的同步复制，让备库时刻保持和主库一致；另一种是应用层做主从复制，让备节点尽量跟上主节点的状态。但无论哪一种，底层逻辑都是“把主节点的状态复制到备节点”。

问题来了：状态复制有延迟窗口。主备之间总有那么一个瞬间，主已经处理了某个请求，但备还没来得及复制过去。这个瞬间主机死了，那个请求就丢了。再说得直白一点——只要靠复制状态，你就不可能做到真正的无损切换，你只能把丢失窗口尽量缩小。

1.2 FT论文的“换赛道”：与其同步状态，不如同步输入

VMware FT论文（全称是《The Design of a Practical System for Fault-Tolerant Virtual Machines》）给出的回答很反直觉：我不复制状态，我复制输入。

怎么理解？你想象两个厨师做同一道菜。一个厨师先做，另一个厨师看着他的动作，试图跟上他的每一步——这是状态复制，后一个厨师永远在追赶，永远有延迟。但如果你给两个厨师同样的食材、同样的菜谱，让他们在同样的时间点执行同一条指令，那么他们做出来的菜会是一样的，不需要谁去追赶谁。

计算机本质上就是那个“看菜谱做菜的厨师”。给定相同的初始内存状态、相同的寄存器内容、相同的输入事件序列，同一套指令流执行出来的结果必然是确定性的。VMware FT要做的，就是让备份VM每一天都跟主VM吃着同一份“输入事件流”，从而保证两台虚拟机的内部状态——内存、寄存器、甚至CPU的微架构可观察状态——实时保持一致。

一旦备份VM的内部状态和主VM一模一样，故障切换的逻辑就变得非常简单：主VM死了，备份VM直接顶上去接着执行。不需要恢复日志，不需要重建内存，不需要拉起应用，因为备份VM本来就相当于主VM的一个“影子”，一直在同一部电影里演同一个角色。

1.3 为什么这事落在虚拟化层恰好合适

你要是想在物理机上做这件事，几乎不可能。一台物理机上有网卡中断、磁盘中断、定时器中断、CPU的时钟计数器，这些统统是硬件直接喂给操作系统的，你没办法在中间插一手，把输入事件都记录下来。但虚拟化改变了这一切。

虚拟机跑在VMM（虚拟机监视器）之上，VMM本身就要接管所有敏感指令、中断、I/O、时钟。也就是说，外部世界对一台虚拟机的所有“输入”，本来就必然经过VMM这个关卡。你在关卡处安一个记录仪，把输入事件全部录下来，再通过一条日志通道发给另一台物理机上的VMM，由它把这些事件注入到备份VM里，备份VM就能精确复刻主VM的执行路径。

这就是FT的整个立论根基。它不需要改动客户操作系统（guest OS），不需要应用配合，对所有跑在虚拟机里的软件完全透明。这也是为什么VMware能在一套虚拟化产品里直接提供这种“特种部队”级别的容错能力——它不是在应用层做文章，而是在“上帝视角”的虚拟化层动手。

2. 确定性重放：VMware FT的技术基石

2.1 计算机世界的确定性假设

要让备份VM跟主VM执行出同样的结果，前提条件是：给定同样的初始状态和同样的输入序列，处理器执行的结果是唯一的。

这个前提在绝大多数时候是成立的。一条普通的mov指令、add指令、跳转指令，输入相同，输出必然相同。CPU不像人脑，它没有“灵机一动”。只要外部中断、异常、I/O完成这些随机事件都在完全相同的指令边界上重放，两台虚拟机的执行路径就会像复印一样一致。

这里我要强调一个词：指令边界。假设主VM执行到第100000条指令时，网卡中断来了，处理完中断后继续执行。要重放这个过程，备份VM不仅要收到“网卡中断来了”这个消息，还必须知道这个中断是在第100000条指令和第100001条指令之间到达的，这不是说记录n条、10000条指令，而是一条都不能差。如果备份VM在第99999条指令之后就把中断注入进去，后续执行路径就会跟主VM分叉，整个同步就毁了。

2.2 破坏确定性的“定时炸弹”清单

那什么样的输入会破坏确定性？论文里实际上给出了一个清单，普通指令不用记，需要记录的非确定性事件主要有几类：

这张表就是FT日志通道里“日志条目”的候选素材。你可以这样理解：日志里装的不是备份VM需要执行的指令，而是备份VM自己无法凭空产生的“外部输入”。指令流是两台VM各自执行的，外部输入是主VM单独经历、然后通过日志分享给备份VM的。

2.3 VMM如何捕捉与重放这些事件

理论说完了，落地才是重点。VMM要把这些非确定性事件记录下来，需要的是x86虚拟化中原有的机制——所有外部中断、异常、I/O访问，本来就会触发VM Exit（从客户模式切换到VMM模式）。VMM在处理这些VM Exit的瞬间，本身就是天然的“记录点”。

让我用网络中断举个例子。物理网卡收到一个数据包，VMM把它交给主VM的虚拟网卡，虚拟网卡向客户OS触发中断。在这一套流程里，VMM做了什么额外动作？很简单：在把包交给客户OS之前，VMM把包的内容、以及当前客户OS执行到哪条指令（也就是精确的IP位置），一并打包成一条日志，塞进日志通道。备份VM那边的VMM收到这条日志后，会在同样的一条指令位置上，把包内容注入到备份VM的虚拟网卡，并触发一个中断。备份VM的客户OS完全感知不到有什么不同——它看到的只是“哦，网卡收了个包，触发了中断”，它不会知道远方有一台兄弟VM也在经历一模一样的事情。

这个“精确到指令位置”的要求，恰恰是虚拟化技术本身能提供的。硬件虚拟化（Intel VT-x / AMD SVM）在执行VM entry和VM exit时，本来就可以精确保存客户机的指令指针和处理器状态。FT要做的只是在保存下来的状态里额外加上“填写日志”和“从日志恢复”这两步。我一度觉得这个设计很取巧：它几乎没有新增任何底层机制，而是把一个早已存在的VM Exit流程复用成了容错协议的“记账本”。

3. 主备同步管线拆解：日志通道里装了什么，同步点在哪里

3.1 一条日志的完整旅程

理解了事件记录的原理，我们来看整条同步管线怎么运转。论文把这条管线称为FT Logging Channel，主VM和备份VM之间的所有同步信息都通过这条TCP连接传输。

我按时间顺序把一次完整的事件同步走一遍：

1. 主VM的客户OS正在愉快地执行指令。
2. 外部事件到来（比如网卡收到包），触发VM Exit，控制权从客户OS跑到主VMM。
3. 主VMM记录事件内容（包数据、中断号、指令位置等），编码成日志条目，写入日志通道的发送缓冲。
4. 日志通过网络传递到备份物理机上的VMM。
5. 备份VMM解码日志条目，在备份VM上构造相同的事件注入（同样在对应的指令位置）。
6. 备份VM的客户OS被中断唤醒，处理这个包，处理完之后继续执行。
7. 备份VMM在处理完这条日志对应的执行点后，向主VMM返回一个确认（ACK）。

这个循环看起来很简单，但有一个微妙的问题：日志的“应用”不是瞬时的。主VM可能已经处理完这个包、又执行了十万条指令、又收到了新的包，而备份VM才刚处理完第一条日志。也就是说，备份VM天然是落后于主VM的。

这个落后的量级必须被控制住。如果备份VM落后太远，主VM突然崩溃，那就意味着备份VM跳过了主VM执行的很大一段“历史”，切换过去的状态就缺少了这段时间内的所有内存修改和后续的输入处理。为了不让这种“失控的落后”发生，FT在协议里加了一个强制同步点——这就是论文里最出名的那条规则：输出规则（Output Rule）。下一章细说。

3.2 日志语义：记录的是“输入”，不是“状态”

这里值得再停下来划一下重点：日志通道里传输的从来不是内存页、不是寄存器快照、更不是整机状态。如果在读论文的时候你以为FT是靠“定期同步内存镜像”来保持一致，那就完全理解反了。

FT的同步单位是“事件”。一条典型日志的可能是一个网络包的内容，可能是磁盘读返回的数据块，可能是时钟中断到达的指令位置。备份VM接收到这条日志后，把它当成“自己本来就该经历的输入”，在自己的执行引擎里重放一遍。因为所有重放指令本身是由备份VM自己的CPU执行的，所以内存状态、寄存器内容会自己趋向于一致——不需要显式地去“复制状态”。

这件事用一句粗糙的话总结就是：主VM负责“经历”，备份VM负责“重演经历”。经历的输入通过日志分享，重演的结果自然对齐。这比任何一种“定期快照+增量同步”的状态机方案都更彻底，因为它同步的不是状态变化的“结果”，而是状态变化的“原因”。

3.3 备份VM落后的边界：什么算“太远”

如果日志通道一直畅通，备份VM只是“稍微慢半拍”，主VM完全不用管它。但一旦主VM真的发生故障，这个“半拍”就成了需要考虑的核心问题。假设主VM在崩溃前已经对外发送了10个网络包，但备份VM只重放到第8个包的位置，那么接管后，备份VM这台机器对外呈现的状态，就比真实世界少了后两个包对应的内部状态和后续影响。这在某些场景下可能是致命的数据丢失。

所以FT必须做出一个硬性保证：当主VM的任意输出被外部世界观察到时，备份VM必须已经处理到了那个输出点。否则无法保证切换后备份VM能够无缝接续主VM已经对外承诺的工作。

这就是引入“输出确认”机制的直接动机。主VM对外发送数据包的时候，不能直接把包丢出去，而要先通过日志通道告诉备份VM“我要在这个执行点对外输出一个包”，等备份VM确认“我已经重放到了这个执行点”，主VM才真正把数据交给物理网卡。这样，外部能看到的所有输出，都发生在主备双方都已确认执行到位之后。主VM崩溃时，备份VM不会落后于任何已经对外可见的输出点。

说到这你可能已经意识到，日志通道不但承担着“事件同步”的职责，还肩负着“输出屏障”的功能。前者保证两台VM内部状态一致，后者保证这种一致性在外部观察者眼里也是成立的。这两个功能交织在一起，构成了FT主备同步管线的完整语义。

4. 输出规则详解：全世界只允许一个VM开口说话

4.1 如果两个VM都往外发包，会发生什么

先把一个最简单的道理摆到桌面上：FT架构里有两台虚拟机，它们各自有虚拟网卡，各自有完整的TCP/IP协议栈，各自能执行网络发送指令。那么问题来了——备份VM在处理网络发送指令时，它真的要把包发出去吗？

有人可能会想：都发出去也没关系吧，反正内容一样，大不了接收方收到重复包？这个想法完全错了。网络协议栈不是这么工作的。TCP层面，同样的数据如果被发送两次，接收方的序列号就乱了，重传机制会陷入混乱；应用层面，如果这个包是一个“转账请求”，那么重复投递可能导致一笔交易被执行两次。更麻烦的是，如果两台VM走的物理路径不同，包的到达顺序、时延都不同，接收方会看到come from两个不同来源的相同数据。为了不制造这些混乱，最简单的规则就是：备份VM的所有输出都必须被抑制。

FT论文里的做法很干脆：备份VM收到一条“输出事件”类型的日志时，会正常重放这个输出指令的内部执行（比如更新发送队列、更新协议栈状态），但虚拟网卡真正的数据发送动作会被VMM拦截并丢弃。它模拟了“发送成功”的结果，但没有真正把数据送到物理网络。在主VM那个方向，VMM才会真正执行网卡发送操作。

这样一来，对外部世界而言，只有一个VM在“开口说话”——那就是主VM。备份VM是一个忠实的哑巴观众，它能看到听到一切，但它永远不出声。

4.2 输出规则的完整动作序列：等待ACK的那个关键窗口

但“只有主VM能输出”只是输出规则的半边。另一半是前面提到的“输出必须等备份确认”。我们把一次网络发送拆开看：

1. 主VM的客户OS执行网络发送指令（比如写网卡发送队列）。
2. 主VMM拦截到这次发送，知道这会产生一个外部可见的输出。
3. 主VMM不立刻把包交给物理网卡，而是记一条“output entry”进日志，通过日志通道发给备份VM。
4. 备份VMM收到这条entry后，在备份VM里重放到对应的发送指令位置，模拟发送成功，然后向主VM返回ACK。
5. 主VMM收到ACK后，确认“备份已经追到了这个输出点”，这时才把真正的数据包交给物理网卡发送。

你可能会问：主VM要等到ACK才能发送，那网络时延不是增加了整整一个往返RTT吗？是的，这就是FT在输出路径上的代价。论文之所以愿意付这个代价，是因为这个等待把一个核心性质变成了铁律：任何被外部观察到的输出，都必然发生在主备双方都已就绪之后。主VM在发出包之后立刻崩溃，备份VM也已经重放到了这个输出点之后，它接管过去，世界看起来就像“同一台机器刚刚发了这个包，然后继续运行”，外部完全感知不到切换。

反过来想一下：如果主VM不等备份确认就直接把包发出去，然后主VM崩溃，备份VM还没重放到那个发送点。于是外部世界已经看到了一个输出，但新接管的那台机器还没有经历这个输出——它的内部状态会比外部世界观察到的状态落后一拍。那才是真正的数据混乱，而且是无法补救的混乱。所以这个等待是值得的。

4.3 输出规则在论文中的技术表述与两个边界细节

论文里对输出规则有一个非常精确的表述：当且仅当备份VM已经确认处理到某一点（称为“同步点”），主VM才允许执行对应的外部输出。这个“同步点”的语义，说白了就是让输出事件本身变成主备执行进度对齐的强制屏障。

有两个边界细节很容易被忽略，我说一下。

第一，这条输出屏障只阻塞“输出相关”的指令，不回压普通指令。主VM平时执行内部计算、内存读写、CPU运算时，完全不需要等备份VM确认，可以放开跑。只要执行到会产生输出的指令，才会停下来等一次ACK。所以FT不是全流程的“强同步”，而是“事件触发的选择性同步”。

第二，不是所有输出都要等ACK，而是所有“外部可见”的输出都要等ACK。什么东西算外部可见？往虚拟网卡发送队列里写数据算，往虚拟磁盘控制器提交写请求也算——因为这些操作最终会影响外部观察者的状态。而一些客户OS内部的写操作、寄存器的修改、内存的变化，对FT来说是“内部事件”，不需要走输出规则。这个区分非常关键，它决定了备份VM不会被主VM的每一个动作阻塞到窒息，只是在外露的边界上守住一致性。

5. 故障检测与裂脑防线：心跳、日志通道和原子锁

5.1 谁是主，谁说了算：故障检测的天然不对称

任何一个分布式系统，只要涉及两个节点互相检查对方死活，就会遇到经典的“我联系不上你，不代表你死了，也许只是我们之间的网络断了”问题。FT的架构里有两台物理机，一台跑主VM，一台跑备份VM，它们之间靠网络进行日志同步和心跳同步。如果这条网络断了，或者某一台物理机真的宕机了，剩下的那台VM要怎么判断对方的命运？

更要命的是，这两台VM的角色不是固定不变的。正常时主VM对外服务；一旦主VM故障，备份VM会升级成新的主VM。但如果两边同时认为对方已经死了、自己才是那个应该继续服务的主呢？那就产生了分布式系统里臭名昭著的裂脑（split-brain）。

裂脑有多恐怖？你可以想象两台“主VM”同时对外提供服务，各写各的数据，然后网络恢复后再试图合并状态——那个混乱场景会直接摧毁任何一个数据一致性保证。所以FT必须有一套机制，确保任何一个时刻，最多只有一个VM认为自己是主。

5.2 FT的三道防线：UDP心跳、TCP日志通道、共享存储上的原子锁

论文里设计了三层不同的机制来应对故障检测和裂脑问题。

第一层是UDP心跳。主备两台物理机上的VMM之间定时互发心跳包。心跳的作用很单纯：告诉对方“我还活着”。但心跳本身不可靠——UDP可能丢包，网络可能抖动，物理机可能负载过高导致心跳发送延迟。所以FT不会因为一两个心跳丢失就立刻判定对方死亡。

第二层是前面的TCP日志通道。日志通道本身就是一条持续的TCP流，它的存在本身就是一个活性证明：只要还在正常同步日志，说明对方还活着且在正常工作。TCP的可靠传输特性还能暴露网络中断的真实情况——连接断开会触发明确的错误通知。

第三层是共享存储上的原子CAS锁。这层是裂脑的最终裁决机制。在FT的设计里，两台物理机必须同时连接到一个共享存储。当某台VM决定要接管成为主VM时，它不能仅凭“对方心跳超时”就擅自升级，而是在共享存储上执行一个原子Compare-And-Swap操作：如果锁处于被主VM持有的状态，且锁的所有者标记是可以被夺走的，那么接管者成功夺取锁；CAS成功才代表它获得了“合法主VM”的身份。

这个锁的意义在于：如果旧主VM真的死了，没人会在CAS时跟新主VM争抢，锁会被轻松拿到；但如果旧主VM还活着，它不可能把自己持有的锁交出去——因为要释放锁它也得自己操作。两台VM在同一个共享存储上通过一个原子操作PK，赢的那个才被允许继续对外输出。这就把“谁死了谁活着”这种网络层面的模糊判断，变成了一个存储层面的原子事实。

5.3 主VM故障与备份VM故障的处置差异

故障检测的另一个重要装配点是：主VM和备份VM“死亡”之后，幸存方要做的事情完全不同。

如果是备份VM故障，主VM发现自己收不到心跳、日志通道也断了，它会怎么做？答案是：它停止容错，直接继续运行。对，你没看错，主VM不需要故障切换，因为它本来就是对外服务的那个。它只是失去了一只“眼睛”——不再有备份VM跟它保持同步。这时候系统从FT容错模式降级为普通非容错模式，管理员需要人工介入，重新拉一台备份VM起来，重新建立FT session。

如果是主VM故障，备份VM在确认（通过心跳超时+日志通道中断+CAS拿锁成功）之后，会立刻接管成为新的主VM。关键是，它的内存状态、应用状态、网络协议栈状态都和旧主VM在故障瞬间是一致的——因为FT一直保持着这种同步。所以接管后它可以直接继续执行，继续对外发送。外部观察者看到的现象是什么？可能只是一次短暂的网络抖动或者一个小停顿（心跳超时窗口的代价），然后流量又从同一个IP恢复。

这里有个细节容易被人问住：接管之后，新的主VM还要不要继续为别人提供容错？答案是，FT协议会要求新主VM尝试重新启动一个新的备份VM，重新建立FT session。如果新备份拉不起来，那系统还是降级到无保护状态。

5.4 双主问题：为什么CAS必须建立在共享存储上

我再展开一下共享存储这个前提。为什么FT一定要共享存储？最根本的原因是，两台VM要操作同一份数据。主VM往共享存储写数据，备份VM也得看得见这次写操作产生的结果，这样才能保证后续读操作的一致性。没有共享存储，主备看到的磁盘数据各自为政，那还谈什么容错。

而CAS锁放在共享存储上，还有一层额外的价值：它能作为fencing的权威证据。分布式系统的fencing是这样一个概念——旧节点可能还活着，但它必须被物理性/逻辑性地隔离在外，不能让它继续访问共享资源。FT用CAS锁做了逻辑fencing：新主VM拿到锁之后，旧主VM即使还活着，它在下一步执行需要访问该锁的代码时也会发现锁已经被抢走，从而被迫降级或自杀。通过共享存储这个唯一事实源，两个VM的“主身份”之争被收敛成了一个原子问题，而不是网络延迟的赌博。

我读论文时一度认为这个锁的引入是点睛之笔。它在任何网络故障模式下都能提供一个确定性答案：锁在谁手里，谁就是主。不需要复杂的投票协议，不需要quorum，就是存储设备上一个CAS原语。这就是把“不变量”建立在工程上最可靠契约上的聪明做法。

6. 网络与存储的外设屏障：数据包、磁盘块和虚拟时钟如何被FT驯服

6.1 网络输入：在VMM网卡处截获

前面我们已经用网络包做了例子，这里再补一点细节。主VM的网络输入路径是：物理网卡到主VMM到虚拟网卡到客户OS。FT在主VMM收到包、还没把它投递给客户OS之前，先把包内容记录成日志。所以主VM的客户OS看到的网络包，永远是“伴随一条日志已经发出去了”的包。备份VM那边，VMM收到日志后，在对应指令位置把包注入备份VM的虚拟网卡。两边客户OS看到的包内容和到达时机完全一致。

有一个好问题值得提出来：如果主VM收到一个包后还没来得及处理就崩溃了，备份VM会怎么处理？答案很简单：日志已经发出去了，备份VM会正常重放这个包的接收过程，然后继续执行主VM没来得及执行的后继指令。也就是说，这个包被主备双方都“完整经历”了，不会出现“主丢了但备没收到”的问题。

6.2 磁盘I/O：共享存储与日志记录

磁盘I/O比网络包更复杂一点，因为读操作的“输入”是存储里的数据。FT的处理策略是：写操作照常执行，写到共享存储上，同时把它作为一个输出事件——因为写操作对外部存储有副作用，所以会受到输出规则的约束，需要等备份确认。读操作则是一个输入事件：主VMM发起读，等到数据从共享存储返回后，把读到的数据内容记录进日志，然后在备份VM重放时让备份VM“再次读到同一份数据”。

这要求共享存储在物理上必须是两个VM都能访问到的同一份数据视图。论文里明确要求使用类似FC SAN这样的共享存储，而不是各自本地的磁盘。因为主VM写了一块数据，备份VM那边的VMM必须能读到同样内容，否则后续事件的对齐就无从谈起。我补充一句，存储本身仍然可能成为单点，所以在生产环境里，共享存储通常还得自己再做一层冗余。

6.3 时钟问题：RDTSC与定时器中断

最后一个容易被忽略的非确定性来源是时钟。x86架构里有一条RDTSC指令用来读取时间戳计数器，很多时候软件靠它获取精确时间。问题在于，两台物理机的真实时钟芯片不同步，直接往备份VM上跑RDTSC，读出来的数值会和主VM不一样。这会导致客户OS感知到“时间跳跃”，进而影响自旋锁超时、时钟轮询、性能监控等逻辑。

FT的解决办法是虚拟化层的时钟抽象。VMM拦截客户机的RDTSC指令，不把真实物理时间戳暴露给它，而是提供一个虚拟时钟。FT会确保操作主VM时这个虚拟时钟的基准值被记录到日志里，备份VM重放时使用同一个基准值。所以两台VM看到的时间戳是严格一致的。同理，定时器中断也被纳入日志体系，中断何时触发、在哪个指令点触发，都必须重放成一样的节奏。

把这些外设屏障串起来看，你会发现FT处理“外部世界”的方式有一个统一逻辑：所有从外部进入VM的信息，都必须经过日志通道转述一遍；所有从VM发往外部世界的结果，都必须经过输出规则确认一遍。网络包、磁盘块、时钟中断，无一例外。

7. 性能和适用范围：FT不是银弹，但容错思路是通用财富

7.1 开销的三个主要来源

FT能把故障切换做得这么顺滑，不可能没有代价。它的性能开销主要压在三块上面。

第一块是日志传输开销。每一个外部事件都要编码、传到另一台物理机、在备份VM里重放。网络包多的负载（比如缓存集群、消息网关），日志流量会非常可观。论文里报告过，在某些I/O密集型的基准测试中，FT的相对吞吐量相比原生虚拟机会有比较明显的下降。

第二块是输出等待ACK的延迟。每发一个网络包，都要等备份VM确认重放成功，这等于在发送路径上插入了一个物理往返时延。对高并发、低延迟的交易系统来说，这个额外延迟可能比日志流量本身更伤。

第三块是同步执行的一致性约束。备份VM虽然落后一点，但必须始终追得上主VM。如果主VM跑得太快，备份VM永远追不上，那整个FT session就可能因为“落后过多”而中断。所以FT通常要求两台物理机的配置尽量一致，主VM不能疯狂冲到备份完全跟不上。

7.2 什么场景适合FT，什么场景别硬上

结合性能和架构限制，FT的适用画像其实很清晰。

适合的场景：对可用性要求极高、但对吞吐量不是极致的在线关键业务，比如核心账务系统、订单状态机、会话保持类服务。这类系统最大的恐惧是切换造成的会话丢失和状态断裂，FT正好能提供“主备状态完全同步”的硬保证。

不太适合的场景：高吞吐网络包转发类业务、大规模批处理计算、CPU密集型的科学计算负载。这些负载要么日志量太大，要么性能开销比例太高，要么完全用不上FT对“状态一致性”的强保。对这类场景，传统主从复制或者分布式计算框架的分片容错往往更划算。

还有一个值得注意的点：FT需要两个物理主机配置高度一致，共享存储，还有网络带宽给日志通道留足余量。这些都是部署前必须盘算清楚的硬件前提。我见过不少团队在架构评审时被“FT”两个字吸引，结果一评估才发现自己的机房连可靠的共享存储波都没有，最后还是得退回非容错方案。所以评估FT之前，先盘硬件。

7.3 读完这篇论文，我做系统设计时多想到的几件事

这篇论文我前前后后读了三遍，每一遍都有不同的收获。谈三点我自己的体会。

第一，“复制什么”比“复制多快”更本质。大多数高可用设计都在拼命优化“状态同步的速度”，而FT告诉我们，如果是同步“输入”，每个输入都要过一遍日志通道，那是几十次、几百次地拉齐状态。复制输入，状态自然对齐。这个思路在后来的很多系统里都能看到影子，只不过换了个外壳——比如有些数据库的CDC（变更数据捕获）在一定程度上也是在重放输入变化，而不是同步最终表状态。当然它们没有FT那么极致，因为FT是在虚拟化指令层面重放，而数据库只是在事务层面重放。

第二，输出规则是所有复制系统都绕不开的语义难题。你可以复制任意多的内部状态，但一旦涉及对外部世界产生可观察影响，就必须回答“输出什么时候算数、备份在哪里确认”。FT用“输出前等ACK”把这个问题解决得非常优雅，但它付出的代价是每个输出多一个RTT。这让我在设计其他系统时，每次看到“双写”“多副本对外服务”都会本能地追问一句：你们的输出规则是什么？如果答不上来，那这个系统的高可用多半只停留在一半。

第三，故障切换的权威性需要存储层的原子性来支撑。FT用共享存储上的CAS锁解决了裂脑问题，这个设计让我意识到，分布式系统在出现网络分区时，往往需要一个“只有物理上排他才能裁决”的底牌。这种底牌不一定是锁，可以是共享盘上的一个文件、数据库中的一行记录，关键在于它具备原子性和互斥性。没有这张底牌，靠心跳投票之类的逻辑，你永远无法百分之百避免双主。

结合我自己的学习路径，我建议每个读这篇论文的人，都先不要急着去啃协议细节，而是先问自己一句：如果我要设计一个“无缝容错”的系统，我最怕的是什么？答案是两个：备份机器跟主不一致，以及主挂了之后备份不知道该不该顶上去。FT的整套设计，日志通道解决第一个问题，输出规则和CAS锁解决第二个问题。想清楚这个，论文的骨架就已经在你心里了，剩下的全是血肉。