zookeeper 集群介绍与搭建

zookeeper集群的目的是为了保证系统的性能承受更多的客户端连接而专门提供的机制，通过集群可以实现以下功能：
1.读写分离：提高承载，为更多的客户端提供连接，并保证性能。
2.主从自动切换，提供服务容错性，部分节点故障不会影响整个服务集群。

半数以上运行机制说明：
集群至少需要三台服务器，并且强烈建议使用奇数个服务器，因为zookeeper通过判断大多数节点的存活来判断整个服务是否可用，比如3个节点，挂掉两个表示整个集群挂掉，而偶数4个节点，挂掉2个也表示其并不是大部分存活，因此也会挂掉。

1.集群部署

配置语法 server.<节点ID>=<地址ip>:<数据同步端口号>:<选举端口号>
示例

server.1=192.168.174.128:2888:3888  
server.2=192.168.174.129:2888:3888
server.3=192.168.174.130:2888:3888

节点ID：服务id手动指定1至125之间的数字，并写到对应服务节点的{dataDir}/myid文件中
地址ip ： 节点的远程ip地址，
数据同步端口：主从同时数据复制端口
选举端口：主从节点选举端口号

逐个启动zookeeper服务 集群服务就启动了
查看节点状态

./zkServer.sh status

2.集群角色说明

zookeeper集群中总共由三种角色，分别是leader（主节点）follower（子节点）observer（次级字节点）

角色	描述
leader	主节点，又称领导者，用于写操作，通过选举产生，如果宕机将会选举新的主节点，
follower	字节点，又名追随者，用于读操作，用于实现数据的读取，同时，他也是主节点的备选节点，并且拥有投票权
observer	次级子节点，又名观察者，用于读取数据，与follower区别在于没有投票权，不能选为主节点，并且在计算集群可用状态时不会将observer计算进去

observer配置：只需要在集群配置中加上observer后缀即可

server.3=192.168.174.130:2888:3888：observer

3.选举机制

集群启动时选举机制
第一轮投票.当zk1,zk2,zk3启动时 自己 分别都给给自己投了一票
第二轮投票 myid小的节点会投给大的相邻节点 如果有一个票数超过半数 选举结束

选举触发 ：
1.服务节点初始化
2.半数以上的节点无法与leader建立连接

4.数据提交机制

zookeeper的数据同步是为了保证各节点中数据的一致性，同步时设计到两个流程，一个是正常的客户端数据提交，另一个是集群中某个节点宕机在恢复后的数据同步。

客户端写入请求

实际情况要复杂的多，因为客户端并不知道哪个是leader，可能把请求发送给follower ，由follower再转发给leader进行同步处理

客户端写入流程说明：
1.client向zk中的server发送写请求，如果该server不是leader，则会将该写请求转发给leader，leader将请求事务以proposal形式分发给follower
2.当follower收到leader的proposal时，根据接受的先后顺序处理proposal；
3.当leader收到follower针对某个proposal过半的ack时，则发起事务提交，重新发送一个commit的proposal；
4.Follower收到commit的proposal后，记录事务提交，并把数据更新到内存数据库中
5.当写入成功后返回给client

服务节点初始化同步
当集群中某个follower宕机后有链接上，他会首先找到当前的leader，通过ZXID事务ID来确认同步的数据

ZXID说明
ZXID是一个64位的数字，其中低32位是按照数字递增，任何数据的变更都会导致，低32位的数字加1，高32位是leader的周期编号，每当选举出一个新的leader时，新的leader就从本地事务日志中取出ZXID，然后解析出高32位的周期编号，进行加1，再将低32位全部设置为0，这样就保证每次选举出的leader后，保证ZXID时唯一的