优点：解决方案、处理问题能力、架构优化/拓展能力
零、Zookeeper事务
事务id(主从同步Id-每次ack递增+1,64位存储（32位纪元号-leader号，32位自增号）)
每一个操作都将使节点接收到一个Zxid格式的时间戳
ZooKeeper的每个节点维护者两个Zxid值，为别为：cZxid、mZxid。
（1）cZxid：是节点的创建时间所对应的Zxid格式时间戳。
（2）mZxid：是节点的修改时间所对应的Zxid格式时间戳。
一个客户端发起的写请求打到follower时的整个流程。
1.follower将请求转发给leader。
2。leader发起Proposal原子广播事务提议，把消息广播给所有follower。
3.leader等待过半follower写log并返回ack后,将请求提交。
4.将这条日志广播给所有follower。
5.follower提交并给客户端返回。
假如此时发送写请求的follwer写失败了（失败的那小半数），客户端请求读的时候如果又正好请求到这个follwer，读写不一致问题出现，解决：
zookeeper 的读写一致不是在 server 做的，而是 server & client 配合的；client 会记录它见过的最大的 zxid （写成功的zkid），读取的时候，如果 server 发现 这条 zxid 比 server 端的最大 zxid 大，则此follwer抛出异常决绝请求，client 会自动重连到其他server（还在同一个 session） —— 最终会落到有新数据的 server 上，因为半数已经同意；
Zookeeper集群机器数为什么是奇数（选举出来的zkid不是最大值：1、leader死亡复活2、leader脑裂后占少数（3个节点1:2））
①、集群脑裂时（leader通信部分不可达）导致leader选举：3台机：2>2/3=1.5(脑裂A1台机，脑裂B2台机)
②、集群脑裂时（leader通信部分不可达）导致leader选举：4台机：2不大于2/4=2(脑裂A2台机，脑裂B2台机)
③、情况①允许1个节点宕机，情况②也是允许一台机子宕机（1:3时集群可用），故性价比一样且情况②出错几率更高
一、Zookeeper同步机制
一、(Eureka（AP可用性容错性）-各节点平等，
且有自我保护机制，15分钟内85%的节点没有正常心跳：1、不再移除异常心跳服务2、仍能接收新服务注册和查询3、恢复网络后同步新注册信息到其他节点
二、Zookeeper（CP一致性容错性）-master选举整个集群不可用，选举时长30-120s)
当各个节点已经自我恢复并选举出leader后(根据事务ID和服务器ID，大值当选)，leader就开始和follows进行数据同步了，具体的逻辑可以见{org.apache.zookeeper.server.quorum.LearnerHandler}中：
leader构建NEWLEADER包，内含leader最大数据的zxid, 广播给follows，然后leader根据follower数量为每个follower创建一个LearnerHandler线程来处理同步请求（FIFO数据队列，更新数据时往队列中添加）：leader主线程阻塞，等待超过半数follower同步完数据之后成为正式leader。
follower接收到NEWLEADER包后响应FOLLOWERINFO给leader，告知本方数据最大的zxid值； leader接收到回馈后开始判断：
如果follower和leader数据一致，则直接发送DIFF告知已经同步；
判断这一阶段内有无已经北提交的决议值，如果有，那么
a) 如果follower数据比leader少，leader发送DIFF包将有差异的数据同步过去，同时将follower没有的数据逐个发送commit包给follower要求记录下来；
b) 如果follower数据zxid更大（oldLeader挂了,newLeader当选之后,oldLeader复活作为follower），此时oldLeader取出当前最新的txid，去leader上查找，没有此txid，则丢弃本地的txid，再递归查找上一个txid，不一致就一直丢弃，直到找到与newLeader上txid一致，并且数据一致；从该txid往后开始同步数据
如果这一阶段没有提交的决议，直接发送SNAP包将快照同步给follower
以上消息完毕后，LEADER发送UPTODATE包告知follower当前数据已同步，等待follower的ACK完成同步过程。
Zookeeper leader 选举
半数通过(服务器为奇数的原因)
– 3台机器 挂一台 2>3/2
– 4台机器 挂2台 2！>4/2
