Zookeeper简介
角色、选举机制、节点类型
Zookeeper 是一个分布式服务框架（即：为其它分布式程序提供服务），主要是用来解决分布式应用中遇到的一些数据管理问题如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Zookeeper是一个类似hdfs的树形文件结构，zookeeper可以用来保证数据在(zk)集 群之间的数据的事务性一致.
Zookeeper基本功能
Zookeeper底层只提供两个功能：
- 管理（存储、读取）数据
- 保持全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
- 监听数据节点
zookeeper角色
zookeeper有三个角色：Leader、Follower、Observer
- Leader、Follower通过选举产生【详见：zookeeper的选举机制】
- Observer需要在配置文件(zoo.cfg)中指定
server.1=172.23.34.13:2001:3001
server.2=172.23.34.13:2002:3002
server.3=172.23.34.13:2003:3002
server.4=172.23.34.13:2004:3003:observer
zookeeper的选举机制
Zookeeper 无需配置主从节点，会自己通过选举选出主节点（(zk服务器集群规模应不小于3个节点， 只要有半数以上节点存活，zk就能正常服务）
- 全新集群
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的. 1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态 2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态. 3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader. 4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能当Follower. 5) 服务器5启动,同4一样,当Follower.
- 非全新集群(数据恢复)
当zookeeper运行了一段时间之后，有机器down掉，重新选举时，需要考虑数据id、leader id和逻辑时钟。 数据id：数据新的id就大，数据每次更新都会更新id。 Leader id：就是我们配置的myid中的值，每个机器一个。 逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新. 选举的标准就变成： 1、逻辑时钟小的选举结果被忽略，重新投票 2、统一逻辑时钟后，数据id大的胜出 3、数据id相同的情况下，leader id大的胜出
ZNode类型
- 持久（PERSISTENT）: 断开Zookeeper连接不会被清除
- 持久序列（PERSISTENT_SEQUENTIAL）：
- 临时（EPHEMERAL）：断开Zookeeper连接后，该类型节点会自动删除
- 临时序列（EPHEMERAL_SEQUENTIAL）
注意：
- 临时、临时序列类型的节点不能有子节点
- 持久序列、临时序列的znode名称后会附加一个序列值
版权声明：本文为BlueStarWei原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。