转自：https://blog.csdn.net/dowslake/article/details/73864922
拿到这本书时，花了一周时间看完，当时项目里有用到zk，就迫不及待的从jd下单。虽然目前工作中几乎用不到，但是对未知技术的好奇，迫使我没敲过代码一口气看完了。
这本书写的非常的好，从原理到代码级的剖析，看后大为赞叹，推荐大家看一看。
分布式一致性，zk是如何做到的？我简单总结下 （zk的各部件就是为了实现ZAB协议而存在的）：
ZAB协议：三种服务器角色：leader，follower，observer。leader服务器通过过半的选票选出，将负责事务的调度和处理并保证事务处理的顺序，而follower则向leader转发事务请求，leader收到请求后，将事务请求分发给所有的follower，等待过半数follower正确反馈后，leader再次向follower分发commit消息。
ZAB协议不同于2PC协议，在于对follower服务器可能中断的处理，如果follower 有未提交的事务请求而中断了呢？ZAB只要过半数的服务器同意就可以了，而且采用崩溃恢复的方式来解决可能由于中断带来的不致性。
崩溃恢复：在启动或leader发生中断时就会启动崩溃恢复，也就是重新选举leader，而且系统会保证事务的顺序性不被破坏。zk采用了ZXID(事务递增id)算法来处理，由于每次leader的当选服务器都是ZXID最高者，所以可以保证事务的顺序。
ZXID设计思路：64位，低32位（leader服务器对其加1），高32位做为leader周期编号。
数据同步：对于后加入的服务器自动成为follower，然后开始从leader同步数据，当两者一致时，leader就会把该服务器加入当前可用follower列表中。
leader选举算法：投票信息(myid,zxid)，服务器之间两两建立连接，进行投票，zxid（一般是数据最新的）大者为leader服务器，如果相同者比较myid,myid大者为leader服务器(还很有意思的投票过程，读者可以自行去看)。而且，有专门的线程负责选举过程的通信，也有专门的消息队列来处理接收和发送投票信息，并且有专门的TCP连接算法：只允许myid大的主动连接来避免重复连接。
Version保证了分布式数据原子性操作：每次数据改动都会进行version加1 ，并且在改动之前进行version比较。
Watcher(数据变更的通知)：客户端向服务器注册，如果有数据更新就会触发，服务器会查看Watcher列表，并进行简单的通知（不做其他内容，只是简单的通知你，有东西变啦），客户端watcherManager收到后进行回调处理，如果需要数据，则再次向服务器进行获取。
Session（会话管理）:有意思的sessionID生成算法（可以自行去看，不展开了）简单讲：高8位确定所在机器Id,后56位当前时间。采用分桶策略进行管理会话，服务器会定时的发心跳，对每隔一段时间没有回应，将会把这个会话移到旧的桶中，然后只要定时去检查相应的桶就可以了，这样高效的进行过时会话删除。
ACL：通常使用“username:password”
数据模型：Znode，树型。
服务器，客户端之间的通信：NIO和netty还可以自定义。不得不说netty很重要，dubbo中也用到了，基本上两个设备间的通信都会采用netty。
序列化协议：Jute
通信协议：定义了自己的通信协议（len+请求头+请求体）
不得不说ZooKeeper很重要，非常多的分布式框架都用到了。