知识卡片
增量同步保现实可用
内容
设计版 Zab 会传输完整 history，正确但不现实；Zab 1.0 选最新历史节点做 leader，并用 SNAP/TRUNC/DIFF 增量同步 follower。发散：工程协议常在证明模型外加优化，但优化必须保持同样的不变量。
参考来源
- 位置：《分布式系统与一致性》第12章《原子广播算法Zab》设计版与实现版差异一节（源文件：_epub-src/OEBPS/Text/chapter16.xhtml）
- 结论依据：原文明确设计版要求"leader会要求follower把其全部的history发送给自己……选中的history全部发送给其他所有的follower……这种做法在history非常大的情况下是极其耗时的"，因此实现版"在选举阶段会选举具有最新history的节点作为leader……在实际的实现中会根据具体情况进行增量传输"，Zab 1.0具体用SNAP/TRUNC/DIFF请求实现。
- 原始内容：这种做法在history非常大的情况下是极其耗时的。如果集群运行了一段时间，积累了大量的事务，那么这个过程就变得不切实际了……在实际的实现中会根据具体情况进行增量传输……如果follower落后太多，则将SNAP请求加入队列中……将TRUN（zxid）请求加入队列中……把大于F.lastZxid的所有提议放入DIFF请求中。