[TOC] # 简介 paxos目标是构建一个去中心化的,通用的分布式一致性算法.而且**paxos算法只在乎数据的一致性而并不关心事务请求的顺序**,这一点不能满足zk的要求 因为zk的命名空间是一个树形结构,对执行的顺序有严格要求.于是zk借助了paxos过半提交的思想将两阶段提交进行优化改造,ZAB就这样诞生了. # 角色 zab协议中有三种角色 * leader:所有写的请求首先都会转发到leader节点上,leader节点上的数据变更会同步到集群的follower节点上 * follower:负责同步leader节点的数据,并提供数据的查询功能.当leader节点失效的时候有权利参与投票选举 * observer:同步leader节点的数据,并提供数据的查询功能.没有投票选举.observer的设计目的是提高集群的查询性能 # 和paxos不同 zab并不是一个无中心化的架构,在任意时刻zab都保持有且仅有一个leader节点,所有的更新事务都只能由这个leader发起. 并且当一个leader失效后,**新的leader只有在之前leader事务都被处理之后才能发起行的事务** 通过这种机制,zab协议保证了全局的事务顺序.在更新阶段ZAB使用的就是一个优化过的两阶段提交,这里借助了paxos的思想,只要过半的节点prepare成功,就会发起commit请求. # 使用场景 ## 统一命名服务 zk的命名空间是一个类似于linux文件系统的树形结构,它的每个znode都拥有唯一的路径标识符. 利用这个特性分布式文件系统,可以将zk当做统一命名服务来使用,类型java中的JNDI ## 心跳感知 利用zk的znode临时节点类型的特性,可以实现心跳感知功能. 例如可以在zk上创建一个根目录,如`/cluster1`.利用znode临时阶段类型的特性,当某个集群服务进程启动的时候,可以在/cluster1上创建代表自己服务的临时节点,用以表示其会话状态.由于临时节点是会话绑定的,所以当节点存在的时候即代表正常,当进程失效的时候,节点客户端会话也失效,这时临时节点会被剔除. 这样只要查看临时节点,就能看到集群状态了 ## 选举 zk能够保证当**多个客户端同时创建一个相同路径节点的时候,只会有一个客户端成功.** 借用这个机制我们可以实现选举功能,因为在同一时刻,有且仅有一个客户端会成功创建节点,这个创建成功的客户端就是选举的胜者