目录
1 zookeeper简介
zookeeper:动物管理员
zookeeper是分布式应用程序的协调服务框架 是Hadoop的重要组件 zookeeper是Google的chubby一个开源实现 是Hadoop的分布式协调服务
2 zookeeper具体应用场景
1.Hadoop 使用zookeeper的事件处理确保整个集群只有一个NameNode 存储配置信息等
2.Hbase 使用zookeeper的事件处理确保整个集群只有一个HMaster 察觉HRegionServer联机和宕机 存储访问控制列表等
3.分布式环境下的统一命名服务
4.分布式环境下的配置管理
5.数据发布/订阅
6.分布式环境下的分布式锁
7.集群管理问题
3 分布式编程容易出现的问题
分布式编程的思想:人多干活快 即多台机器同时处理一个任务
1.活锁 在程序里 由于某些条件的发生碰撞 导致重新执行 再碰撞 再执行 如此循环重新 就形成了活锁
2.需要考虑集群的管理问题 需要有一套机制来检测到集群节点的状态变化
3.如果用一台机器做集群管理 存在单点故障问题 所以针对集群管理 也需要形成一个集群
4.管理集群里Leader的选举问题(根据一定的算法和规则来选举) 包括要考虑Leader挂掉之后 如何从剩余的follower里选举出Leader
5.分布式锁的实现
4 集群架构剖析
4.1 zookeeper之攘其外
zookeeper服务端有两种不同的运行模式。单机的称为”独立模式“,但是独立模式存在单点故障的问题,所以在实际开发中很少使用;集群的称为仲裁模式,不存在单点故障问题,实际开发中使用较多。
主从架构:Master + Slave
1.客户联系某一个柜员说要存钱
2.柜员告知Leader说客户要存钱
3.Leader发起投票,通知其他四个柜员,现在有人要存钱,允不允许他往里存
4.柜员收到后 允许存钱 反馈给领导
5.领导看到反馈允许存钱 给柜员发通知 进行存钱操作 更新一下客户的账户余额数据
Leader在通知follower执行某条命令时,如何保证每个follower都收到并执行呢
队列结构
CAP:Consistency一致性;Availability可用性;Partition Tolerance分区容错;三选二
对外视图统一 叫攘其外
4.2 zookeeper之安其内
1.leader很重要 如果挂了怎么办
开始选举新的leader
2.zookeeper服务器的四种状态
looking:服务器处于寻找leader群首的状态
leading:服务器作为群首时的状态
following:服务器作为follower跟随者时的状态
observing:服务器作为观察者时的状态
leader选举分为两种情况
集群初启动时:安装后首次启动
集群运行中leader挂了时
3.集群启动时的leader选举
以三台机器组成的zookeeper集群为例
原则:集群中过半server启动后,才能选举出leader
每个server投票信息vote信息结构为(sid,zxid)
server1~3初始投票信息分别为:
server1 -> (1, 0)
server2 -> (2, 0)
server3 -> (3, 0)
leader选举公式:
server1 (sid1, zxid1)
server2 (sid2, zxid2)
zxid大的server胜出;若zxid相等,再根据判断sid判断,sid大的胜出
依次启动ZK1、ZK2、ZK3 选举的流程:
ZK1和ZK2票投给自己;ZK1的投票为(1, 0),ZK2的投票为(2, 0),并各自将投票信息分发给其他机器。
处理投票。每个server将收到的投票和自己的投票对比;ZK1更新自己的投票为(2, 0),并将投票重新发送给ZK2。
统计投票。server统计投票信息,是否有半数server投同一个服务器为leader;
改变服务器状态。确定Leader后,各服务器更新自己的状态,Follower变为FOLLOWING;Leader变为LEADING。
当ZK3启动时,发现已有Leader,不再选举,直接从LOOKING改为FOLLOWING。
同时启动ZK1、ZK2、ZK3 选举的流程:
ZK1-> (1, 0) ZK2-> (2, 0) ZK3 -> (3, 0) -> ZK3被选中为Leader,其他两台节点被选为Follower。
4.集群运行时新leader的选举
4.3 脑裂和服务器数量选取
1.服务器数量选取
ZK集群的服务器的数量通常为奇数台(3,5,7,9)
2.脑裂