Zab系列博客
Raft Vs Zab
https://www.jianshu.com/p/24307e7ca9da
Zab系列1 核心概念
https://www.jianshu.com/p/76e5dba31ea4
Zab系列2 角色和存储
https://www.jianshu.com/p/d80f9250ffd1
Zab系列3 选举
https://www.jianshu.com/p/0d2390c242f6
Zab系列4 zookeeper特性
https://www.jianshu.com/p/08b62ca1fe4e
Zab系列5 选举恢复（源码分析）
https://www.jianshu.com/p/b6acd99921b7
Zab系列6 zk单机版工作原理
https://www.jianshu.com/p/ed45982b18b4
Zab系列7 集群工作原理Leader篇
https://www.jianshu.com/p/59240c36ba1b
Zab系列8 集群工作原理Follower篇
https://www.jianshu.com/p/8d7c7f1b2838
Zab系列9 消息顺序性
https://www.jianshu.com/p/0aa96b6a2070
区别
- 请求的处理方式不同
-
Zk集群中的client和任意一个Node建立TCP的长连接，完成所有的交互动作，而Raft第一次随机的获取到一个节点，然后找到Leader后，后续直接和leader交互
-
Zk中的读请求，直接由连接的Node处理，不需要和leader汇报，也就是Consul中的stale模式。这种模式可能导致读取到的数据是过时的，但是可以保证一定是半数节点之前确认过的数据
-
为了避免Follower的数据过时，Zk有sync()方法，可以保证读取到最新的数据。可以调用sync()之后，再查询，确保所有的数据一致后再返回结果
-
角色Zk引入了 Observer的角色来提升性能，既可以大幅提升读取的性能，也可以不影响写的速度和选举的速度，同时一定程度上增加了容错的能力。
https://www.cnblogs.com/EasonJim/p/7488484.html -
日志和状态机
Zab和Raft都是同时存在 log[]（还有快照技术）和状态机（内存树）的存储结构。
- 日志是以log和快照的形式持久化到磁盘，保存的是数据写的完整过程，为重启加载历史数据提供了便利，避免了服务器宕机造成的数据丢失。
- 状态机（内存树）把数据加载到内存中，避免了查询操作时磁盘读取，读取的是数据的最终值，从而提升读取的性能
Zab中的日志和Raft中的日志模型很像，都是超过半数节点完成复制之后，该命令才会被commit，而结合半数节点confrim之后的节点才有可能成为新leader，这两点保证了集群的一致性。
选主投票的区别：
-
Zk集群之间投票消息是单向、网状的，类似于广播，比如A广播A投票给自己，广播出去，然后B接收到A的这个消息之后，会PK A的数据，如果B更适合当leader（数据更新或者myid更大），B会归档A的这个投票，但是不会更新自己的数据，也不会广播任何消息。除非发现A的数据比B当前存储的数据更适合当leader，就更新自己的数据，且广播自己的最新的投票消息。
而Raft集群之间的所有消息都是双向的，发起一个RPC，会有个回复结果。比如A向B发起投票，B要么反馈投票成功，要么反馈投票不成功。 -
ZK集群中，一个节点在一个epoch下是可以发起多次投票的，当节点发现有比之前更新的数据更适合的leader时，就会广播自己的最新投票消息，结合recvset这个Set的结构，来更新某个结点最新的投票结果。而Raft的follower在一个term里只能投票一次。
-
ZK集群中，因为引入了myid的概念，系统倾向让数据最新和myid最大的节点当leader，所以即使有半数节点都投票给同一个Node当leader，这个Node也不一定能成为leader，需要等待200ms，看是不是有更适合的leader产生，当然如果可能因为网络原因 数据最新 myid最大的节点也不一定能当选为leader。但是在Raft系统中，只要某个candidate发现自己投票过半了，就一定能成为leader
-
ZK集群中，每一轮的选举一定会选出一个leader，因为每个节点允许多次投票，而且会广播自己的最新投票结果。而Raft系统可能涉及选票瓜分，需要重新发起一轮选举才能选出leader，是通过选举超时时间的随机来降低选票瓜分的概率。所以ZK的选举理论上一般需要花费更多的时间，但是只需要一轮。Raft每一轮选举的时间是大致固定的，但是不一定一轮就能选出leader。
-
ZK集群中，成为公认的leader条件更苛刻，raft模式下，只要新leader发一个命令为空的Log出来，大家就会认同这个节点为leader，但是在ZK集群中，追随leader的2种条件都很苛刻
- 要么recvset中半数节点的选举following投票给A，才会认可A为自己的leader
- 要么outofelection中半数节点都认可A为leader，自己才会认可A为自己的leader
事务操作的区别
-
Raft系统中的事务消息是通过双向的RPC来完成的，而Zab中，则是单向的，一来一回两个消息来完成的。明显Zab的性能更加，不需要浪费leader一个线程去等待follower完成业务操作。
Zab中leader发送一个Proposal消息给follower，发送完成。当follower完成proposal过程时，再发送一个消息ACK到leader，发送完成。leader统计ACK数量过半时，触发广播commit。 -
操作流程当中，Zab的即时性做的更好吧。
Raft的集群模式下：
Leader创建日志，广播日志，半数节点复制成功后，自己commit日志，运用到状态机中，反馈客户端，并且在下一个心跳包中，通知小弟们commit
Zab的集群模式下：
leader创建Proposal，广播之后，半数节点复制成功后，广播commit。同时自己也commit，commit完之后再运用到内存树，反馈客户端
网友评论