高并发Zookeeper（心得）

1. 概述：Zookeeper是Apache提供的一套于用进行分布式管理和协调的框架
2. 分布式存在的问题：
   1. 分布式容易存在死锁以及活锁问题
   2. 分布式中，需要引入管理节点
   3. 如果只有一个管理节点，容易存在单点故障，所以需要引入管理集群
   4. 管理集群中需要选举出一个主节点
   5. 管理节点之间需要进行信息的共享
3. 安装：
   1. 单机模式：只用一个节点来安装，往往只能提供这个框架的部分功能
   2. 伪分布式：只用一个节点来安装，但是模拟集群环境，能够提供框架的所有功能
   3. 完全分布式：在集群中安装，提供这个框架的所有功能
4. 特点：
   1. Zookeeper本身是一个树状结构
   2. 根节点是/
   3. 将Zookeeper中称之为znode节点
   4. 每一个节点都要求携带数据
   5. Zookeeper不支持相对路径
   6. 将数据存储在磁盘以及内存中
   7. 数据在磁盘上的存储位置由dataDir来决定
   8. 理论上Zookeeper可以作为缓存机制使用，但是如果使用Zookeeper作为缓存机制，则会导致内存被大量占用，则致使Zookeeper的协调能力减弱
   9. Zookeeper会对每一次的写操作（create/set/delete/rmr）分配一个全局递增的编号，这个编号称之为事务id - Zxid
   10. 临时节点不能挂载子节点
5. 命令：

   命令	解释
   ls /	查看根节点的所有子节点
   create /news 'news server'	创建节点
   delete /log	删除节点。要求这个节点没有子节点
   rmr /news	递归删除
   set /log 'log servers'	更新数据
   get /log	查看数据

6. 节点信息

   属性	解释
   cZxid	创建事务id - create
   ctime	创建时间
   mZxid	修改事务id - set
   mtime	修改时间
   pZxid	子节点个数变化事务id
   cversion	子节点个数变化次数
   dataVersion	数据变化次数
   aclVersion	权限变化次数
   ephemeralOwner	用于标记当前节点是否是一个临时节点 如果是持久节点，此项为0 如果是临时节点，此项的值是sessionid
   dataLength	数据的字节个数
   numChildren	子节点个数

7. 节点类型

   	持久节点	临时节点
   顺序节点	Persistant_Sequencial	Ephemeral_Sequencial
   非顺序节点	Persistant	Ephemeral

8. 选举机制
   1. 概述：
      1. 当Zookeeper在启动的时候，会先去恢复当前服务器上的最大事务id
      2. 在选举开始的时候，每一个节点都会选举自己成为leader
      3. 每一个Zookeeper服务器会将自己的选举信息发送给其他节点然后进行选举
   2. 细节：
      1. 选举信息：
         1. 最大事务id
         2. 选举编号 - myid
         3. 逻辑时钟值 - 控制所有的节点处在同一轮选举上
      2. 比较原则：
         1. 先比较两个节点之间的最大事务id，谁大谁赢
         2. 如果最大事务id一致，则比较myid，myid谁大谁赢
      3. 如果一个节点比一半及以上的节点都大，则这个节点会成为leader - 过半性
      4. 在Zookeeper中，只要一个集群中选举出来了leader，那么后续新添节点的事务id和myid无论是多少，都只能成为follower
      5. 如果leader丢失，会自动重新选举出一个新的leader
      6. 因为集群分裂导致子集群产生了leader致使整个集群中产生了多个leader，这个现象称之为脑裂
      7. 如果存活的节点个数不足一半的时候，这个Zookeeper集群就不再选举也不再对外提供服务
      8. Zookeeper集群的节点个数一般是奇数个
      9. Zookeeper中会对每一次选举的leader分配一个全局递增的编号，编号称之为epochid，每一个节点在被选为leader之后，会将当前的epochid分发给每一个follower
      10. 如果因为分裂而产生脑裂，恢复之后，Zookeeper会自动kill掉epochid小的那个节点
      11. 集群节点状态变化：
          1. voting/looking - 选举状态
          2. follower - 追随者
          3. leader - 领导者
          4. observer - 观察者
9. ZAB协议：
   1. 概述
      1. ZAB(Zookeeper Atomic Broadcast) - Zookeeper原子广播协议，是针对Zookeeper专门设计的一套进行原子广播和崩溃恢复的协议
      2. 基于2PC算法进行了改进，2PC - 2 Phase Commit - 二阶段提交
         1. 将提交过程拆分为两个阶段：
            1. 准备阶段：当协调者收到请求之后，将请求分发给每一个参与者，并且等待参与者的返回信息
            2. 提交阶段：如果协调者收到了参与者的返回信息，并且所有的参与者都返回了yes，那么协调者发布指令要求执行这个操作
            3. 中止阶段：如果协调者没有收到所有参与者的yes，那么协调者会认为这个操作不能执行，要求所有的参与者删除这个操作
         2. 核心思想是"一票否决"
   2. 原子广播：
      1. 保证数据一致性-访问任意一个节点，获取到的数据都是一样的
      2. 基于2PC算法进行了改进

      3. leader 在 收 到 请 求 之后，
         
         先 将 这 个 请 求 记 录 到 日 志 
         
         中 ， 如 果 记 录 成 功 ， 则 
         
         leader 会 认 为 这 个 请 求 可 以 执行，
         
         然 后 leader 会 将 请 求 放 入 队 列 
         
         中 发 送 给 每 一 个 follower ， 等 
         
         待 的follower 的 返 回 信 息 
         
         follower 在 收 到 队 列 之后 ， 将 队 列 中 的 请 求 一 
         
         一 取 出 来 写 到 本 地 的 日 志 文件 中 
         
         如 果 记 录 成 功 ， 则 
         
         follower 会 给 leader 返 回 
         
         yes 信 号 ， 认 为 这 个 请 求 
         
         可 以 执 行 
         
         如 果 有 半 数 及 以 上 的 follower 返 
         
         回 了 yes ， 则 leader 会 认 为 这 个 
         
         请 求 可 以 执 行 ， 会 给 follower 发 
         
         送 信 息 要 求 执 行 这 个 请 求 
         
         如 果 记 录 失 败 ， 则 
         
         follower 会 给 leader 返 回 
         
         no 信 号 ， 认 为 这 个 请 求 
         
         不 能 执 行 
         
         如 果 leader 没 有 收 到 半 数 
         
         的 yes ， 会 认 为 这 个 请 求 不 
         
         能 执 行 ， 会 给 follower 发 
         
         送 指 令 要 求 删 除 这 个 请 求 

   3. 崩溃修复：
      1. leader从集群中脱离之后，集群会自动选举出一个新的leader
      2. 用于避免单点故障
      3. 在Zookeeper中，每当产生一个新的leader，会自动分配一个全局递增的epochid，这个epochid同样会体现在Zxid上。在集群中，事务id实际上由64位二进制组成，其中高32位是epochid，低32位是真正的事务id
      4. epochid能够有效的保证操作的提交顺序
   4. 观察者：observer
      1. 特点：不投票不选举，但是会监听投票结果，然后根据投票结果执行操作
      2. 观察者适合于节点数量较多或者网络情况不好的场景。在实际开发中，因为参与选举的节点的数量越多选举的效率会越低，所以实际过程中，会将90%的节点设置为observer

      3. 因为observer不参与投票，所以observer不影响过半，即observer的存活与否都不会影响集群的服务