CAP定理

CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。

Consistency（一致性）: 多个副本节点保持数据的一致性。
Availability（可用性）：指系统一直处于可用的状态。
Partition Tolerance（分区容错性）：遇到任何网络分区故障，仍然能够保证对外提供满足一致性和可用性的服务。

ZK为什么不能满足可用性呢？

集群中网络出现分割的故障，ZK将他们从自己的管理范围内踢出去，外界就不能访问这个节点.

ZK在什么情况下是不能保证可用呢？

ZK在进行leade选举时，集群都是不可用的状态。选举leader的期间，持续的时间短的话是数百毫秒，长的话持续数秒。客户端加入重试机制来做补偿。

ZAB协议解析

概述

ZAB （Atomic Broadcast Protocol）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。

ZAB与PAXOS的联系与区别

Paxos算法的目的在于设计分布式的一致性状态机系统。
ZAB协议的设计目的在于分布式的高可用数据主备系统。
ZAB借鉴了Paxos算法，做了相应的改进，ZAB协议除了遵从Paxos算法中的读阶段和写阶段，还有加入了同步阶段。

ZAB协议两个过程

ZAB 协议主要包括两个过程: 消息广播和崩溃恢复。和三个阶段: 分为Discovery 发现，Synchronization 同步，Broadcast 广播。

消息广播过程：Leader 节点接受事务提交，并且将新的 Proposal 请求广播给 Follower 节点，收集各个节点的反馈，决定是否进行 Commit。
崩溃恢复过程如果在同步过程中出现 Leader 节点宕机，会进入崩溃恢复阶段，重新进行 Leader选举，崩溃恢复阶段还包含数据同步操作，同步集群中最新的数据，保持集群的数据一致性。

ZAB协议三个阶段

ZAB存在三个阶段：发现阶段、同步阶段和广播阶段。其中发现阶段等同于Paxos的读阶段，广播阶段等同于Paxos的写阶段。
涉及专业术语：

CEpoch：Follower 发送自己处理过的最后一个事务 Proposal 的 epoch 值。
NewEpoch：Leader根据接收 Follower 的 epoch，来生成新一轮 epoch 值。
Ack-E：Follower 确认接收 Leader 的新epoch。
NewLeader：确立领导地位，向其他 Follower 发送 NewLeader 消息。
Ack-LD：Follower确认接收 Leader 的 NewLeader 消息。 Commit-LD：提交新 Leader 的 proposal。
Propose：Leader 开启一个新的事务。
Ack：Follower 确认接收 Leader 的 Proposal。
Commit：Leader 发送给 Follower，要求所有 Follower 提交事务 Proposal。

Discovery（发现阶段）

处理过程：

    1. Follower 将自己最后处理的事务 Proposal 的 epoch 值发送给 Leader，消息 CEpoch(F.p) ， F.p 可以提取出 zxid。 
    2. 当 Leader 接收到过半的 Follower 的 CEpoch 消息后，Leader 生成 NewEpoch(e') 发送给这些 过半的 Follower， e' 是比任何从 CEpoch 消息中收到的 epoch 值都要大。 
    3. Follower 一旦从 Leader 处收到 NewEpoch(e') 消息，会先做判断，如果 e'<F.acceptedEpoch ，并且F.state = election 也就是Looking状态，那么会重新回到Leader选举 阶段。 
    4. Leader 一旦收到了过半的 Follower 的确认消息。它会从这些过半的 Follower 中选取一个 F，并 使用它作为初始化事务的集合（用于同步集群数据），然后结束发现阶段。既然要选择需要同步 的事务集合，必然要选择事务最全的，所以，须满足epoch 是最大的且 zxid 也是最大的条件。

Synchronization（同步阶段）

第一个过程 NewLeader：Leader 将新 epoch 和 S’ 以 NewLeader(e’, S’) 的消息形式发送给所有过半 (Quorum) 的 Follower。在上一阶段 L.history = F.history ，所以 S’ 就是流程图中的
L.history 。
第二过程ACK：当 Follower 接收到NewLeader(e’, S’) 消息后，做相应判断：
1. 如果 Follower 的 epoch 等于 e’ ，也就是确认是不是该Follower的信息，因为前一阶段已经存储了最新的 e’ 。Follower 将会执行事务应用操作，将接收 S’ 中的所有事务 Proposal，只是接收不作其他处理。
2. 如果 Follower 的 epoch 不等于 e’ ，即不是这一轮的 Follower信息，直接回退至选举阶段。
3. Leader 在接收到过半的 Follower 的 Ack 消息后，发送 Commit 消息至所有的 Follower进行同步，之后进入下一阶段即 Broadcast（消息广播）。
第三个过程 Commit：在收到 Leader 的 Commit 消息后，按顺序依次调用 abdeliver() 处理 S’ 的每一个事务，随后结束这一阶段的处理。

Broadcast（广播阶段）

第一个过程 Propose：Leader 收到来自客户端新的事务请求后，会生成对应的事务 Proposal，并根据 zxid 的顺序（递增）向追随自己的所有 Follower 发送 P<e’, <v, z>> ，其中 epoch(z) == e’ 。
第二个过程 Ack：Follower 根据收到消息的次序来处理这些 Proposal，并追加到 H 中去，然后通知给 Leader。
第三个过程 Commit：一旦 Follower 收到来自 Leader 的 Commit 消息，将调用 abdeliver() 提交事务。这里是按照zxid的顺序来提交事务。
广播请求处理流程：
Leader（主）服务器接收 Client（客户端）的请求，为其生成 Proposal（提案）。
然后将 Proposal 发送给所有 Follower （从）。主会为每一个从分配一个单独的队列，以保证消息的有序性。
主节点等待所有从服务器反馈 Ack，当有过半的从服务器 Ack 之后，主节点会提交本地事务。然后广播 Commit 给所有，从节点接收到 Commit 之后完成提交。