Content #
ZAB 和 Raft 从核心原理上做对比。
- 领导者选举
ZAB 采用的“见贤思齐、相互推荐”的快速领导者选举（Fast Leader Election）。 Raft 采用的是“一张选票、先到先得”的自定义算法。 Raft 的领导者选举，需要通讯的消息数更少，选举也更快。
- 日志复制
Raft 和 ZAB 相同，都是以领导者的日志为准来实现日志一致，而且日志必须是连续的，也必须按照顺序提交。
- 读操作和一致性
ZAB 的设计目标是操作的顺序性，在 ZooKeeper 中默认实现的是最终一致性，读操作可以在任何节点上执行；而 Raft 的设计目标是强一致性（也就是线性一致性），所以 Raft 更灵活， Raft 系统既可以提供强一致性，也可以提供最终一致性。
- 写操作
Raft 和 ZAB 相同，写操作都必须在领导者节点上处理。
- 成员变更
Raft 和 ZAB 都支持成员变更，其中 ZAB 以动态配置（dynamic configuration）的方式实现的。那么当你在节点变更时，不需要重启机器，集群是一直运行的，服务也不会中断。
- 设计
相比 ZAB，Raft 的设计更为简洁，比如 Raft 没有引入类似 ZAB 的成员发现和数据同步阶段，而是当节点发起选举时，递增任期编号，在选举结束后，广播心跳，直接建立领导者关系，然后向各节点同步日志，来实现数据副本的一致性。 ZAB 的成员发现，可以和领导者选举合到一起，类似 Raft，在领导者选举结束后，直接建立领导者关系，而不是再引入一个新的阶段；数据同步阶段，是一个冗余的设计，可以去除的，因为 ZAB 不是必须要先实现数据副本的一致性，才可以处理写请求，而且这个设计是没有额外的意义和价值的。
另外，ZAB 和 ZooKeeper 强耦合，你无法在实际系统中独立使用；而 Raft 的实现（比如 Hashicorp Raft）是可以独立使用的，编程友好。