分布式系统一致性所涉及的问题及算法

拜占庭将军问题

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

Paxos算法

Paxos算法是一种基于消息传递且具有高度容错特性的一致性算法。

Paxos算法解决的问题：就是如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。

Paxos算法描述：

• 在一个Paxos系统中，首先将所有节点划分为Proposer（提议者），Acceptor（接受者），和Learner（学习者）。（注意每个节点都可以身兼数职）。
• 一个完整的Paxos算法流程分为三个阶段：
  • Prepare准备阶段：（1）Proposer向多个Acceptor发出Propose请求Promise（承诺）。（2）Acceptor针对收到的Propose请求进行Promise。
  • Accept接受阶段：（1）Proposer收到多数Acceptor承诺的Promise后，向Acceptor发出Propose请求。（2）Acceptor针对收到的Propose请求进行Accept处理。
  • Learn学习阶段：（1）Proposer将形成的决议发送给所有Learners。

（1）Prepare：Proposer生产全局唯一且递增的Proposal ID，向所有Acceptor发送Propose请求，这里无需携带提案内容，只携带Proposal ID即可。
（2）Promise：Acceptor收到Propose请求后，做出“两个承诺，一个应答”。

• 不再接受Proposal ID小于等于当前请求的Propose请求。
• 不再接受Proposal ID小于当前请求的Accept请求。
• 不违背以前做出的承诺下，回复已经Accept过的提案中Proposal ID最大的那个提案的value和Proposal ID，没有则返回空值。

（3）Propose：Proposer收到多数Acceptor的Promise应答后，从应答中选择Proposal ID最大的提案的Value，作为本次要发起的提案。如果所有应答的提案Value均为空值，则可以自己随意决定提案Value。然后携带当前Proposal，向所有Acceptor发送Propose请求.
（4）Accept：Acceptor收到Propose请求后，在不违背自己之前做出的承诺下，接受并持久化当前Proposal ID和提案Value。
（5）Learn：Proposer收到多数Acceptor的Accept后，决议形成，将形成的决议发送给所有Learner。

情况一：

情况二：

情况三：

Paxos算法缺陷：在网络复杂的情况下，一个应用Paxos算法的分布式系统可能很久无法收敛，甚至陷入活锁的情况。

造成这种情况的原因是系统中有一个以上的Proposer，多个Proposer相互争夺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发起一个事务Proposal后就宕机，follower都没有Proposal。
（2）leader收到半数ack宕机，没来得及向follower发送commit。

崩溃恢复

一旦leader服务器出现崩溃或者由于网络原因导致leader服务器失去了过半follower的联系，那么就会进入崩溃恢复模式。

崩溃恢复——异常假设

（1）假设两种服务器异常情况：
1）假设一个事务在leader提出之后，leader挂了。
2）一个事务在leader上提交了，并且过半的follower都响应ack了，但是leader在commit消息发出之前挂了。
（2）ZAB协议崩溃恢复要求满足以下两个要求：
1）确保已经被leader提交的提案Proposal，必须最终被所有的follower服务器提交。（已经产生的提案，follower必须执行）
2）确保丢失已经被leader提出的，但是没有被提交的Proposal。（丢弃提案）

崩溃恢复——leader选举

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

leader选举：根据上述要求，ZAB协议需要保证选举出来的leader需要满足以下条件：
（1）新选举出来的leader不能包含未提交的proposal。即新的leader必须都是已经提交了Proposal的follower服务器节点。
（2）新选举的leader节点中含有最大的zxid。这样做的好处是可以避免leader服务器检查Proposal的提交和丢弃工作。

崩溃恢复——数据恢复

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

CAP理论

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

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

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

（１）一致性（Consistency）
在分布式环境下，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保持系统的数据仍然处于一致的状态。
（２）可用性（Available）
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间返回结果。
（３）分区容错性（Partition　Tolerance）
分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

Zookeeper保证的是CP
（１）zookeeper不能保证每次服务请求的可用性。（在极端情况下，zookeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）
（２）进行leader选举时集群都是不可用的。