分布式协调服务zookeeper

zookeeper是一个开源的分布式协调服务，可以用来解决分布式数据一致性的问题。

zookeeper能做什么

数据的发布/订阅（配置中心:disconf）

负载均衡（dubbo利用了zookeeper机制实现负载均衡）

统一命名服务、ID生成器

master选举(kafka、hadoop、hbase)

分布式队列、分布式锁

zookeeper的特性

顺序一致性 ：从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中

原子性：所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、要么全都不应用

可靠性：一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的

实时性：一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态（zookeeper仅仅保证在一定时间内，近实时）

zookeeper集群

zookeeper集群中有三种角色：leader，follower，observer

半数以上投票通过：可以这样理解。客户端的增删改操作无论访问到了哪台zookeeper服务器，最终都会被转发给leader服务器，再由leader服务器分给zookeeper集群中所有follower服务器去投票（投票指的是在内存中做增删改操作），半数投票通过就被认为操作可执行（commit），否则不可执行。

leader:  接受follower和observer的提案请求并统一发起投票，与所有follower，observer进行数据交互，更新系统状态。

follwer: 处理客户端读请求，将写请求转发给leader。参与选举，处理leader的提议，在leader提交提议时，在本地也进行提交。

observer: 处理客户端读请求，将写请求转发给leader。不参与选举（降低投票的成本），只同步leader的状态。目的是提高扩展性和读取速度。

zoo.cfg配置文件分析

tickTime=2000  zookeeper中的时间单位长度 （ms）

initLimit=10  follower节点启动后与leader节点完成数据同步的时间

syncLimit=5 leader节点和follower节点进行心跳检测的最大延时时间

dataDir=/tmp/zookeeper  表示zookeeper服务器存储快照文件的目录

dataLogDir 表示配置 zookeeper事务日志的存储路径，默认指定在dataDir目录下

clientPort 表示客户端和服务端建立连接的端口号： 2181

zookeep Java Api

连接状态：

KeeperStat.Expired  在一定时间内客户端没有收到服务器的通知， 则认为当前的会话已经过期了。

KeeperStat.Disconnected  断开连接的状态

KeeperStat.SyncConnected  客户端和服务器端在某一个节点上建立连接，并且完成一次version、zxid同步

KeeperStat.authFailed  授权失败

事件类型：

NodeCreated  当节点被创建的时候，触发

NodeChildrenChanged  表示子节点被创建、被删除、子节点数据发生变化

NodeDataChanged    节点数据发生变化

NodeDeleted        节点被删除

None   客户端和服务器端连接状态发生变化的时候，事件类型就是None

节点类型：

PERSISTENT  持久性节点：生命周期和session无关, 只能显式删除

PERSISTENT_SEQUENTIAL  持久有序节点

EPHEMERAL    临时性节点：不能有子节点，在客户端session结束或超时后自动删除

EPHEMERAL_SEQUENTIAL     临时有序节点

zookeper Session：

客户端和 server 间采用长连接

连接建立后, server生成 session id(64位)返还给客户端

客户端定期发送 ping 包来检查和保存和 server 的连接

一旦 session 结束或超时,所有 ephemeral节点会被删除

客户端可根据情况设置合适的 session 超时时间

zookeper Watch：

Watch 是客户端安装在 server 的事件监听方法

当监听的节点发生变化, server 将通知所有注册的客户端

客户端使用单线程对所有时间按顺序同步回调

触发回调条件：客户端连接,断开连接，节点数据发生变化，节点本身发生变化

curator 开源的zk客户端

curator提供了各种应用场景的实现封装

curator-framework  提供了fluent风格api

curator-replice     提供了实现封装

zab协议的原理

paxos协议主要就是保证如何在分布式环网络环境下，各个服务器达成一致最终保证数据的一致性问题（拜占庭问题）

zookeeper并没有完全采用paxos算法， 而是采用Zookeeper atomic broadcast（zab原子广播协议）。

• 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
• zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，把数据的状态变更以事务请求的形式广播到其他的节点
• zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
• 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower
• leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点，再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息