拜占庭将军问题

拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。

• 问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒。
• 叛徒可以任意行动以达到以下目标：
  • 欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，如当将军们不希望进攻时促成进攻行动；
  • 或者迷惑某些将军，使他们无法做出决定。
  • 如果叛徒达到了这些目的之一，则任何攻击行动的结果都是注定要失败的，只有完全达成一致的努力才能获得胜利。

Paxos算法

• Paxos算法：一种基于消息传递且具有高度容错特性的一致性算法。
• Paxos算法解决的问题：就是如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性
  

Paxos 算法描述：

在一个 Paxos系统中，首先将所有节点划分为 Proposer（提议者），Acceptor（接受者），和Learner（学习者）。（注意：每个节点都可以身兼数职）。

一个完整的 Paxos 算法流程分为三个阶段：

• Prepare准备阶段
  提议者向每个接受者发出 Propose 请求 Promise（承诺），接受者针对收到的 Propose请求进行 Promise（承诺）
• Accept接受阶段
  Proposer收到多数Acceptor承诺的Promise后，向 Acceptor 发出Propose请求，Acceptor针对收到的Propose请求进行 Accept 处理
• Learn学习阶段
  Proposer将形成的决议发送给所有Learners

详细步骤

• （1）Prepare:
  Proposer 生成全局唯一且递增的 Proposal ID，向所有Acceptor发送Propose请求，这里无需携带提案内容，只携带 Proposal ID即可。相当于Proposer 广播propose请求，寻找接收者
• （2）Promise:
  Acceptor 收到 Propose 请求后，做出==“两个承诺，一个应答”==。
  • 不再接受 Proposal ID 小于等于（注意：这里是<= ）当前请求的Propose请求。
  • 不再接受Proposal ID小于（注意：这里是< ）当前请求的 Accept 请求。
  • 不违背以前做出的承诺下，回复已经 Accept 过的提案中 Proposal ID最大的那个提案的 Value和 Proposal ID，没有则返回空值。
• （3）Propose:
  • Propose r收到多数 Acceptor 的 Promise 应答后，从应答中选择Proposal ID 最大的提案的 Value，作为本次要发起的提案。
  • 如果所有应答的提案 Value 均为空值，则可以自己随意决定提案Value。然后携带当前Proposal ID，向所有Acceptor发送 Propose 请求。
• （4）Accept:
  Acceptor收到Propose请求后，在不违背自己之前做出的承诺下，接受并持久化当前Proposal ID和提案Value。
• （5）Learn:
  Proposer 收到多数 Acceptor 的 Accept 后，决议形成，将形成的决议发送给所有Learner。

举例

造成这种情况的原因是系统中有 一个以上的 Proposer，多个 Proposers 相互争夺 Acceptor，造成迟迟无法达成一致的情况。

• 针对这种情况，一种改进的 Paxos 算法被提出：从系统中选出一个节点作为 Leader，只有 Leader 能够发起提案。
• 这样，一次 Paxos 流程中只有一个 Proposer，不会出现活锁的情况，此时只会出现例子中第一种情况。

ZAB 协议

什么是 ZAB 算法

• Zab 借鉴了 Paxos 算法，是特别为 Zookeeper 设计的支持崩溃恢复的原子广播协议。基于该协议，Zookeeper 设计为只有一台客户（Leader）负责处理外部的写事务请求，然后 Leader 客户端将数据同步到其他Follower 节点=。即 Zookeeper 只有一个 Leader 可以发起提案。

Zab 协议内容

Zab 协议包括两种基本的模式：消息广播、崩溃恢复。

具体步骤：

• （1）客户端发起一个写操作请求。
• （2）Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的 ID，即 zxid。
• （3）Leader服务器为每个Follower服务器分配一个单独的队列，然后将需要广播的 Proposal依次放到队列中去，并且根据FIFO策略进行消息发送。
• （4）Follower接收到Proposal后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向Leader反馈一个Ack响应消息。
• （5）Leader接收到超过半数以上Follower的Ack响应消息后，即认为消息发送成功，可以发送commit消息。
• （6）Leader向所有Follower广播commit消息，同时自身也会完成事务提交。Follower 接收到commit消息后，会将上一条事务提交。
• （7）Zookeeper采用Zab协议的核心，就是只要有一台服务器提交了Proposal，就要确保所有的服务器最终都能正确提交Proposal。

ZAB协议针对事务请求的处理过程类似于一个两阶段提交过程

• （1）广播事务阶段
• （2）广播提交操作

这两阶段提交模型，有可能因为 Leader 宕机带来数据不一致，比如

• （ 1 ） Leader 发 起 一 个 事 务 Proposal1 后 就 宕 机 ， Follower 都 没 有 Proposal1
• （2）Leader 收到半数 ACK 宕 机，没来得及向 Follower 发送Commit

崩溃恢复

1、异常假设

假设两种服务器异常情况：

• （1）假设一个事务在 Leader 提出之后，Leader挂了。
• （2）一个事务在Leader上提交了，并且过半的Follower都响应Ack了，但是Leader在Commit消息发出之前挂了。

一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半 Follower的联系，那么就会进入崩溃恢复模式。 Zab协议崩溃恢复要求满足以下两个要求：

• 确保已经被 Leader 提交的提案 Proposal，必须最终被所有的Follower服务器提交。 （已经产生的提案，Follower必须执行）
• 确保丢弃已经被Leader提出的，但是没有被提交的Proposal。（丢弃胎死腹中的提案）

2、Leader选举

崩溃恢复主要包括两部分：Leader选举和数据恢复。

根据上述要求，Zab 协议 需要保证选举出来的 Leader 需要满足以下条件：

• 新选举出来的 Leader 不能包含未提交的 Proposal。即新Leader必须都是已经提交了 Proposal 的 Follower 服务器节点。
• 新选举的 Leader 节点中含有最大的 zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。

3、数据恢复

Zab如何数据同步：

• （1）完成Leader选举后，在正式开始工作之前（接收事务请求，然后提出新的Proposal），Leader服务器会首先确认事务日志中的所有的Proposal 是否已经被集群中过半的服务器Commit。
• （2）Leader服务器需要确保所有的 Follower 服务器能够接收到每一条事务的Proposal，并且能将所有已经提交的事务Proposal应用到内存数据中。 等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过，并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中

CAP

CAP 理论告诉我们，一个分布式系统不可能同时满足以下三种 CAP 理论

• 一致性（C:Consistency）
• 可用性（A:Available）
• 分区容错性（P:Partition Tolerance）

这三个基本需求，最多只能同时满足其中的两项，因为 P 是必须的，因此往往选择就在 CP 或者 AP 中。

1）一致性（C:Consistency）

在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。

2）可用性（A:Available）

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

3）分区容错性（P:Partition Tolerance）

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

ZooKeeper 保证的是 CP

• （1）ZooKeeper 不能保证每次服务请求的可用性。（注：在极端环境下，ZooKeeper 可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，ZooKeeper 不能保证服务可用性。

• （2）进行 Leader 选举时集群都是不可用。