简述ZAP和Raft

ZAP（zookeeper）：
选举:
先去比较zxid zxid谁大谁就是领导角色，zxid相等就比较myid，谁的大谁就可能是领导角色，只要满足过半的机制就可以成为领导角色，后来启动的节点不参与选举的。
如何保持数据的一致性问题:
所有写的请求统一交给领导角色实现，领导角色写完数据之后，领导角色将每一个数据同步给每一个节点。
注意:
数据之间同步采用2pc两阶段提交协议。
Raft：
角色:

1. 状态: 来源于生活(台湾选举)------ 跟随者,竞选者,领导角色
2. 大多数: >n/2+1
3. 任期: 每次选举一个新的领导角色 任期都会去实现增加
4. 竞选者谁的票数最多，谁就是为领导角色
5. 问题：票数相同，谁是领导？------ 服务器数量避免是偶数
   选举:
6. 默认情况下，所有节点都是跟随着
7. 每个节点会随机的生成一个选举的超时时间，例如，大概是100-300ms，在超时的时间范围内必须要等待。
8. 超时时间过后，这个节点的状态可能有跟随着变为竞选者状态，会给其他的节点发出选举通知，只要该竞选者有超过半数以上即可选为领导角色，
9. 核心原理: 谁的超时时间最短，谁就越可能成为领导角色
10. 如果所有的节点的超时时间相同，当前投票全部作废，重新进入随机生成随机数阶段
11. 若果有多个节点生成的随机数相同，比较票数谁的多，谁就是领导，票数完全一样，重新进入随机生成随机数阶段(建议不要偶数个服务器,可能无线死循环)
12. 故障重新选举:
    a) 如果跟随着节点不能及时收到领导角色的消息时，那么这个跟随着的状态就会变为竞选者状态，发给其他的节点发出选举投票通知，只要该竞选者有超过半数以上，即可选举为领导角色
    数据一致性：
    类似于ZAP的两阶段提交协议
13. 所有的写的请求都是统一交给领导角色完成的，写入该对应的日志，标记该状态是未提交。
14. 为了提交日志，领导角色就会将该日志以心跳的形式发送给其他的更随着，只要有过半的跟随着可以写入该数据，则为通知其他节点同步该数据，这个称作为日志的复制。