读书笔记《从Paxos到zookeeper分布式一致性原理与实践》

读完后有种感觉想写点什么，写个老套的读书笔记吧。
不久前看了《大型网站技术架构：核心原理与案例分析》一书恍然大悟，网上流传的各种架构演化图原来取之于此。零碎的知识点容易让人一叶遮目，不如安安心心静下来看一本书来的实在。

整本书从理论讲解到实用细节面面俱到，对全面认识zookeeper很有帮助。下面我就简单写下自己整理的笔记，错了就喷吧，反正我脸皮厚。哈哈

集群角色：

Leader：领导者，处理事务请求并保证事务请求的顺序性（事务指能够改变Zookeeper服务状态的操作，一般包括数据节点的创建删除与内容更新、客户端会话创建与失效。每一个事务有全局唯一的ZXID）；集群内部各服务器的调度

Follower:跟随者，处理客户端非事务请求、转发事务请求给Leader、参与事务请求Proposal投票、参与Leader选举投票

Observer：观察者，只处理非事务服务，不参与任何形式的投票

全部存储在内存中的树形数据节点ZNode，分为持久（顺序）型与临时（顺序）节点（生命周期与客户端会话绑定），每个ZNode只能由一台服务器创建，且节点的sequential自增数字保障兄弟节点按顺序无重复
客户端与服务端TCP长连接的会话Session管理，分桶管理策略通过设定固定周期的超时检查，批量清理超时会话。客户端利用API可对数据节点进行如下操作：创建会话、创建节点、删除节点、读取数据、更新数据、检测节点是否存在、权限控制。常用开源的两款zookeeper客户端：ZkClient、Curator。
Zookeeper将所有节点的路径、数据内容、ACL等信息组成DataTree全部存储在内存中，其底层数据结构是ConcurrentHashMap,其key是数据节点的path，而value则是真正的数据内容DataNode。通过ZKDatabase管理所有会话、DataTree存储和事务日志，并定时dump快照到磁盘，同时也方便在启动时从磁盘上的事务日志和快照数据文件恢复成一个完整的内存数据库

ZAB协议

与Paxos算法的异同？
相同点：都有Leader、Follower
不同点：

Paxos在新选举的主进程中会进行两阶段的工作，第一阶段读阶段主进程通过和其他进程的通信来收集上一个主进程的提案并提交；第二阶段为写阶段即新主进程开始提出自己的提案；
ZAB协议在读阶段之后额外引入一个同步阶段，在此阶段中新的Leader会确保存在过半的Follower已经提交了之前Leader周期中所有的事务proposal，从而保证在新Leader提交proposal之前，所有的Follower都完成了对之前所有事务proposal的提交。同步阶段完成后再进入写阶段

数据发布订阅：对统一配置信息等数据可以通过在Zookeeper创建一个数据节点并让客户端进行监听，主要利用了Zookeeper的Watcher监听特性；
负载均衡：创建一个节点，负载应用把自己的服务地址写到此节点下，如果此应用挂掉，则此子节点消失
命名服务：利用Zookeeper创建顺序无重复子节点的特性；
分布式协调/通知：不同客户端都对Zookeeper上的同一个数据节点进行watcher注册，监听数据节点的变化，当发生变化所有订阅的客户端接收到通知并进行处理；
集群管理：利用了watcher监听与临时节点在会话失效自动清除的特性。同时，各服务器可以讲运行状态信息写入到临时节点中进而有助于Leader收集负载信息；
Master选举：所有客户端创建同一个path的数据节点，只有一个能成功，即为Master；
分布式锁：创建临时节点，谁成功即获得锁。另外，根据创建时不同的类型-序号，根据一定的规则可以模拟出共享锁、读写锁等；
分布式队列：每个客户端在指定节点下创建临时节点，然后获取该指定节点下的所有子节点并判断自己是否是序号最小的节点，如果是则可以进行处理，如果不是则进入等待并监听比自己序号小的最后一个节点，待接到watcher通知后，重复检查。

一个简短的笔记，免不了还有许多遗漏的，有时间在补充。当然建议大家自己阅读理解