zookeeper基础知识

• 概念

  • 分布式协调服务【命名服务、共享配置、协调锁资源】
  • 数据结构
    • Znode
      • data：Znode存储的数据信息。
      • ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
      • stat：包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。
      • child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。
    • 读多写少：节点存储少量的状态和配置信息，每个节点的数据最大不能超过1MB。
  • 一致性：ZAB协议【zookeeper atomic broadcast】：同Paxos和Raft，解决集群崩溃恢复以及主从同步数据的问题
    • Looking ：选举状态。
    • Following：Follower节点（从节点）所处的状态。
    • Leading：Leader节点（主节点）所处状态。
  • 崩溃恢复：选举->发现->同步
  • 数据写入：1.从节点转发leader 2.leader 二阶段提交，propose给follower 3.follower 接收到Propose消息，写入日志成功后，返回ACK消息给Leader。4.Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower。

• zk选举：

  • myid

    • 集群节点id属性

  • epoch

    • 在每一轮投票递增，记录投票的”朝代“。

  • zxid（事务id）

    • leader节点在每次事务操作后都会递增zxid，follower节点同步leader的zxid，保证节点数据与leader节点数据一致。

（1）Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工作；

（2）在集群正常工作之前，myid小的服务器给myid大的服务器投票，直到集群正常工作，选出Leader；

（3）选出Leader之后，之前的服务器状态由Looking改变为Following，以后的服务器都是Follower。

• 选举时机：

1. 服务器初始化启动。

2. 服务器运行期间无法和Leader保持连接。

• 若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

(1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下

· 优先检查ZXID。ZXID比较大的服务器优先作为Leader。

· 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。