Zookeeper-3 工作机制

Zookeeper架构

ZooKeeper集群是主从架构

• 主角色：leader
• 从角色：follower或observer；统称为learner
  

Zookeeper特点

• 顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
• 原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
• 单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
• 5223可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

Zookeeper集群个数

Zookeeper集群节点一般为奇数个，如3 5 7.

• 发生网络分层时，不会发生两层节点数相同，集群无法服务的现象

假如zookeeper集群有4个节点，同样发生脑裂，脑裂成了A、B两个小集群：
A：2个节点 ， B：2个节点
两个分层都不能满足quorum大于4/2 + 1的要求，ZK无法提供服务

• 与偶数个节点比，容灾能力一样但更节省资源
• quorum小，响应速度快

• 5节点
  可以个挂掉2台：比例2/5
  quorum数，3，比例 3/5
• 6节点
  可以挂掉2台：比例2/6
  quroum数：4，比例4/6

Zookeeper读数据

• 常见的读取操作，如ls /查看目录；get /zktest查询ZNode数据

• 读操作

  • 客户端先与某个ZK服务器建立Session

  • 然后，直接从此ZK服务器读取数据，并返回客户端即可

  • 关闭Session
    

Zookeeper写数据

• Zookeeper写数据是两段式(2PC)提交

2PC：在分布式系统中，每一个机器节点虽然能够明确的知道自己在进行事物操作过程的结果是失败或成功，但却无法直接获取其他分布式节点的操作结果，因此事物操作需要跨越多个分布式节点的时候，需要引入一个协调者统一调度所有节点的执行逻辑。

• 阶段一：提交事物请求

1. 事物询问
   协调者向所有的参与者发送事物内容，询问是否可以执行事物操作，并开始等待各参与者的响应。
2. 执行事物
   各参与者节点执行事物操作，并将Undo和Redo信息记入事物日志中
3. 各参与者向协调者反馈事物询问的响应
   如果参与者成功执行了事物操作，那么就反馈给协调者Yes响应，表示事物可以执行；如果参与者没有成功执行事物，那么就反馈给协调者No响应，表示事物不可以执行。

• 阶段二：执行事物请求