zookeeper系列（一）——简介和原理
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/luo4105/article/details/70304930
Zookeeper简介和工作原理
简介
Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等 Zookeeper工作流程是首先选举一个服务器作为leader，leader会更新服务器状态、数据交互。当集群中其他服务器learner会更新服务器状态、数据交换。当前leader失联时，其他服务器会选举投票产生一个新的learner。 Zookeeper的角色分为以下三种
角色 | 功能 | ||
|---|---|---|---|
Leader | 更新服务器状态、数据 | ||
Learner | Follower | 接收client请求并处理返回、投票选举leader 、同步leader | |
Observer | 接收client请求，但把写的请求给leader。不能投票选举leader，同步leader。扩展只读服务器，提高读取速度。 | ||
工作原理
Zookeeper采用原子消息广播协议(ZAB)作为数据一致性算法。Zookeeper采用单一主线程leader来处理客户端的所有事务处理，将服务器数、状态以事务的形式广播到所有Follower；由于事务之间有依赖关系，leader保证事务顺序广播，即被依赖的先广播；ZAB支持崩溃恢复，即leader崩溃后选举新的leader并保证数据的完整。 Leader接收client的事务请求后，会将事务请求转成事务Proposal，并且将事务Proposal分发给集群下所有的follower，然后leader等待follower的反馈信息。当有一半以上的follower反馈信息后，leader再次向follower广播事务commit信息，follower将之前的Proposal提交。 ZAB协议有三种状态，所有的节点(服务器)，都属于这三种状态中一种 looking：在服务器启动时或leader崩溃时，处于的选举状态。 following：follower所处的状态，同步leader。 leading：leader所处的状态，当前有一个leader是主进程。 Zookeeper启动时所有节点处于looking状态，选举出leader节点，该节点状态切换为leading；looking节点发现集群中存在leader节点时状态切换为followering，与leader保持同步；follower节点与leader失联时，状态切换为looking，并开始选举。 选举出leader后ZAB进入原子广播状态，leader会为每个follower生成一个操作序列，一个leader在同一时间只能和一个follower保持同步，leader和follower通过心跳检测来感知对方存在；当leader节点在超时时间类接收到来自follower节点的心跳检测，follower节点会保持与该leader节点的连接；当leader节点在超时时间外未接受到过半follower节点的心跳检测或TCP断开连接，该leader节点结束当前领导状态切换为looking，所有follower节点也会放弃该leader节点状态切换looking，开始新一轮选举。