版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/luo4105/article/details/70304930
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,开始新一轮选举。