Zookeeper结构

zk的服务器模式

仲裁模式：zk复制集群中所有服务器的数据；大多数服务器保存数据成功后才返回客户端成功
独立模式：一个单独的服务器，zk的状态无法复制

会话

1.客户端设置的监视点和会话相关联，会话到期后等待中的监视点会移除
2.在对zk集合进行任何操作之前，必须先与服务器创建会话
3.当会话因为某种原因终止时，这个会话建立的临时节点也会消失
4.zk客户端可以透明的将会话从一个服务器转移到另一个服务器
5.会话提供了顺序保证，保证一个会话中的请求按FIFO的顺序执行，但当一个客户端打开了多个会话不能保证FIFO

zk的架构设计

节点角色

1.leader：
    领导者负责投票的发起和决议，状态的维护
2.learner：
  follower：接受客户端的请求，返回数据；参与投票；
  observer：接受客户端的读请求，返回数据，如果是写请求会转发给leader；不影响提议，不参与投票；只同步leader的状态（数据）
  observer和follower的区别是observer不参与选举和投票；数据不同不到磁盘，每次重启后需要全量同步数据；引入observer的目的是在不牺牲写的性能下，提高读的性能

集群中唯一的leader节点，唯一对外负责写请求，集群中的节点都可以接受读请求,learner节点接收到写请求后会转发给leader

数据一致性zab协议

zk通过zab原子广播协议来保证每个节点的数据一致性；

zk对数据一直性的特点

- 顺序一致性：严格按照事物发起的顺序执行操作
- 原子性：所有事物的请求结果在集群中所有节点上的应用情况是一样的
- 单一视图：客户端访问任何一个节点获取到的数据模型是一样的
- 实时性：包含在极小的一段时间内，客户端可以读取到服务器最新的数据状态，如果需要实时需要客户端调用sync方法

写的示例图

1.leader节点接收到写请求后会分配一个全局的事物ID（zxid），并发起提议，广播给每个follower；
2.follower接收到事物 请求后，写入到本地事物日志，根据事物的执行结果，和zxid的有效性来返回是否接受这个提议；
3.leader接收到超过半数的节点（包括自己）的ack请求，则执行事物提交请求，自己执行提交并且广播给follower和同步状态给observer；
4.follower接受到事物提交请求后，进行事物的提交

leader选举

选举触发的条件

当集群初始化（崩溃恢复）或者follower没办法联系上leader时，每个follower会进入选举模式

选举的原则

谁的数据最新，谁就具有优先选举为leader的资格；

选举的步骤

1.发起选票、每个节点都投自己 一票并提议别的节点也投自己一票
2.选票重投阶段、根据第一阶段的投票决定投哪一个节点
3.选票统计、哪个节点收到了超过半数的投票，则变更状态为leader节点其余的节点变更为learner；

选举完后，会进行数据的同步，只有数据同步完成后这个节点才会对外提供服务
####数据的持久化
服务器只有强制冲刷事务到事务日志中，才会确认对应的提议

数据的类型

• 内存数据库：全部数据存储在内存中默认为1M
• 事务日志：每次写操作完成后保存到内存中的同时会写入到事务日志
• 快照日志：当事务日志的写入次数超过一定数量后（默认10W），会将内存数据库中的数据进行一次备份，存储到磁盘上，这个文件是快照文件
  快照文件是一个若一致性的文件，因为在进行快照的时候服务器不会阻塞
  通过快照日志和事务日志可以把任意zk节点还原到任意时间点的数据

写操作的流程

• 接受写操作：集群中的任意节点都可以接受写操作，但是当非leader节点接收到写请求后，会把当前的请求转发给leader节点
• 协调写操作：leader接收到写操作请求后，会为这次的写分配一个唯一的事务ID（ZXID）然后把这次事务广播出去
• 记录数据：当大多数节点响应这次事务提议后，进行事务的提交和内存数据库的应用
• 记录快照：当事务日志记录的次数达到一定数量后(默认10W)，将内存数据库进行一次备份，持久化保存到磁盘上