共同点

1. 都是基于 状态机+ 操作日志 +快照的机制实现存储
2. 都是Master负责写，而且写的过程都类似，都是两阶段提交

区别

1. 请求的处理方式不同

• Zk集群中的client和任意一个Node建立TCP的长连接，完成所有的交互动作，而Raft第一次随机的获取到一个节点，然后找到Leader后，后续直接和leader交互
• Zk中的读请求，直接由连接的Node处理，不需要和leader汇报，也就是Consul中的stale模式。这种模式可能导致读取到的数据是过时的，但是可以保证一定是半数节点之前确认过的数据
• 为了避免Follower的数据过时，Zk有sync()方法，可以保证读取到最新的数据。可以调用sync()之后，再查询，确保所有的数据一致后再返回结果

2. 角色Zk引入了 Observer的角色来大幅提升读取的性能，也可以不影响写的速度和选举的速度。
3. 写的时候，zk是统计过半proposal就广播commit，再apply数据，响应客户端。而raft是master先commit，响应客户端，下一个心跳再通知小弟们commit（因为默认的raft模式，读写请求都转发给leader，所以对小弟们数据的即时性要求没那么高，而zk是每个Node都直接响应读请求，所以Follower对数据的即时性要求高）

选主投票的区别：

1. Zk集群之间投票消息是单向、网状的，类似于广播，比如A广播A投票给自己，广播出去，然后B接收到A的这个消息之后，会PK A的数据，如果B更适合当leader（数据更新或者myid更大），B会归档A的这个投票，但是不会更新自己的数据，也不会广播任何消息。除非发现A的数据比B当前存储的数据更适合当leader，就更新自己的数据，且广播自己的最新的投票消息。
   而Raft集群之间的所有消息都是双向的，发起一个RPC，会有个回复结果。比如A向B发起投票，B要么反馈投票成功，要么反馈投票不成功。

2. ZK集群中，一个节点在一个epoch下是可以发起多次投票的，当节点发现有比之前更新的数据更适合的leader时，就会广播自己的最新投票消息，结合recvset这个Set的结构，来更新某个结点最新的投票结果。而Raft的follower在一个term里只能投票一次。

3. ZK集群中，因为引入了myid的概念，系统倾向让数据最新和myid最大的节点当leader，所以即使有半数节点都投票给同一个Node当leader，这个Node也不一定能成为leader，需要等待200ms，看是不是有更适合的leader产生，当然如果可能因为网络原因 数据最新 myid最大的节点也不一定能当选为leader。但是在Raft系统中，只要某个candidate发现自己投票过半了，就一定能成为leader

4. ZK集群中，每一轮的选举一定会选出一个leader，因为每个节点允许多次投票，而且会广播自己的最新投票结果。而Raft系统可能涉及选票瓜分，需要重新发起一轮选举才能选出leader，是通过选举超时时间的随机来降低选票瓜分的概率。所以ZK的选举理论上一般需要花费更多的时间，但是只需要一轮。Raft每一轮选举的时间是大致固定的，但是不一定一轮就能选出leader。

5. ZK集群中，成为公认的leader条件更苛刻，raft模式下，只要新leader发一个命令为空的Log出来，大家就会认同这个节点为leader，但是在ZK集群中，追随leader的2种条件都很苛刻

• 要么recvset中半数节点的选举following投票给A，才会认可A为自己的leader
• 要么outofelection中半数节点都认可A为leader，自己才会认可A为自己的leader