分布式技术详解

CAP理论

CAP理论

一致性（Consistency）
可用性（Availability）
分区容错性（网络分区）Partition tolerance
CAP（Consistency一致性、Availability可用性、Partition-tolerance分区可容忍性）理论普遍被当作是大数据技术的理论基础。同时，根据该理论，业界有一种非常流行、非常“专业”的认识，那就是：关系型数据库设计选择了C（一致性）与A（可用性），NoSQL数据库设计则不同。其中，HBase选择了C（一致性）与P（分区可容忍性），Cassandra选择了A（可用性）与P（分区可容忍性）。
CAP理论的特点，就是CAP只能满足其中2条。

ACID

为了保证事务的ACID（原子性、一致性、隔离性、持久性）
Two-phase Commit 二段提交（RDBMS经常就这种机制，保证强一致性）
Three-phase commit 三段提交

二段提交

1. 请求阶段（commit-request phase，或称表决阶段，voting phase）
   在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。
   在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

   
   
   

   提交事务请求

2. 提交阶段（commit phase）
   在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。
   当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。
   参与者在接收到协调者发来的消息后将执行响应的操作。

   
   
   

   提交事务请求
   
   
   

   取消事务请求

缺点

1. 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。
   当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2. 单点故障。由于协调者的重要性，一旦协调者发生故障。
   参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3. 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。
   而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

三段提交

三段提交

针对两阶段提交存在的问题，三阶段提交协议通过引入一个“预询盘”阶段，以及超时策略来减少整个集群的阻塞时间，提升系统性能。三阶段提交的三个阶段分别为：can_commit，pre_commit，do_commit。
1.CanCommit阶段
3PC的CanCommit阶段其实和2PC的准备阶段很像。
协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
2.PreCommit阶段
Coordinator根据Cohort的反应情况来决定是否可以继续事务的PreCommit操作。
根据响应情况，有以下两种可能。
A.假如Coordinator从所有的Cohort获得的反馈都是Yes响应，那么就会进行事务的预执行：
发送预提交请求。Coordinator向Cohort发送PreCommit请求，并进入Prepared阶段。
事务预提交。Cohort接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
响应反馈。如果Cohort成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
B.假如有任何一个Cohort向Coordinator发送了No响应，或者等待超时之后，Coordinator都没有接到Cohort的响应，那么就中断事务：
发送中断请求。Coordinator向所有Cohort发送abort请求。
中断事务。Cohort收到来自Coordinator的abort请求之后（或超时之后，仍未收到Cohort的请求），执行事务的中断。
3.DoCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况:
执行提交
A.发送提交请求。Coordinator接收到Cohort发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有Cohort发送doCommit请求。
B.事务提交。Cohort接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
C.响应反馈。事务提交完之后，向Coordinator发送ACK响应。
D.完成事务。Coordinator接收到所有Cohort的ACK响应之后，完成事务。
中断事务
Coordinator没有接收到Cohort发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
2P，3P文字内容引用

Paxos算法

拜占庭将军问题

拜占庭帝国就是5~15世纪的东罗马帝国，拜占庭即现在土耳其的伊斯坦布尔。我们可以想象，拜占庭军队有许多分支，驻扎在敌人城外，每一分支由各自的将军指挥。将军们智能靠通讯员进行通讯。在观察敌人以后，忠诚的将军们必须制订一个统一的行动计划——进攻或者撤退。然而，这些将军冢有叛徒，他们不希望忠诚的将军们能达成一致，因而影响统一行动计划的制订与传播。
问题是：将军们必须有一个协议，使所有忠诚的将军们能够达成一致，而且少数几个叛徒不能使忠诚的将军们作出错误的计划——使有些将军进攻而另一些将军撤退。
如果这11位将军中有间谍呢? 假设有9位忠诚的将军，5位判断进攻，4位判断撤退，还有2个间谍恶意判断撤退，虽然结果是错误的撤退，但这种情况完全是允许的。因为这11位将军依然保持着状态一致性。

1.11位将军进攻城池
2.同时进攻（议案、决议）、同时撤退（议案、决议）
3.不管撤退还是进攻，必须半数的将军统一意见才可以执行
4.将军里面有叛徒，会干扰决议生成

在Paxos算法面前，其他（包括2P、3P）都是渣渣，都是残次品。Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。

Paxos：多数派决议（最终解决一致性问题）

三种角色：
Proposer：提交者（议案提交者）
提交议案(判断是否过半)，提交批准议案(判断是否过半)
Acceptor：接收者（议案接收者）
接受议案或者驳回议案，给proposer回应(promise)
Learner：学习者（打酱油的）
如果议案产生，学习议案。
设定1：如果Acceptor没有接受议案，那么他必须接受第一个议案
设定2：每个议案比必须有一个编号，并且编号只能增长，不能重复。越往后越大。
设定3：接受编号大的议案，如果小于之前接受议案编号，那么不接受
设定4：议案有2种(提交的议案，批准的议案)

演示图片

1. Prepare阶段（决议提交）
   a）Proposer希望议案V。首先发出Prepare请求至大多数Acceptor。Prepare请求内容为序列号K
   b）Acceptor收到Prepare请求为编号K后，检查自己手里是否有处理过Prepare请求。
   c）如果Acceptor没有接受过任何Prepare请求，那么用OK来回复Proposer，代表Acceptor必须接受收到的第一个议案（设定1）
   d）否则，如果Acceptor之前接受过任何Prepare请求（如：MaxN），那么比较议案编号，如果K e）如果K>=MaxN，那么检查之前是否有批准的议案，如果没有则用OK来回复Proposer，并记录K
   f）如果K>=MaxN，那么检查之前是否有批准的议案，如果有则回复批准的议案编号和议案内容（如：， AcceptN为批准的议案编号，AcceptV为批准的议案内容）
2. Accept阶段（批准阶段）
   a）Proposer收到过半Acceptor发来的回复，回复都是OK，且没有附带任何批准过的议案编号和议案内容。那么Proposer继续提交批准请求，不过此时会连议案编号K和议案内容V一起提交（这种数据形式）
   b）Proposer收到过半Acceptor发来的回复，回复都是OK，且附带批准过的议案编号和议案内容（）。那么Proposer找到所有回复中超过半数的那个（假设为）作为提交批准请求（请求为）发送给Acceptor。
   c）Proposer没有收到过半Acceptor发来的回复，则修改议案编号K为Kx，并将编号重新发送给Acceptors（重复Prepare阶段的过程）
   d）Acceptor收到Proposer发来的Accept请求，如果编号K e）Acceptor收到Proposer发来的Accept请求，如果编号K>=MaxN则批准该议案，并设置手里批准的议案为，回复Proposer。
   f）经过一段时间Proposer对比手里收到的Accept回复，如果超过半数，则结束流程（代表议案被批准），同时通知Leaner可以学习议案。
   g）经过一段时间Proposer对比手里收到的Accept回复，如果未超过半数，则修改议案编号重新进入Prepare阶段。

先后提议的场景

先后提议的场景

角色：
proposer：参谋1，参谋2
acceptor：将军1，将军2，将军3（决策者）

1.参谋1发起提议，派通信兵带信给3个将军，内容为（编号1）；
2.3个将军收到参谋1的提议，由于之前还没有保存任何编号，因此把（编号1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（ok）；
3.参谋1收到至少2个将军的回复，再次派通信兵带信给3个将军，内容为（编号1，进攻时间1）；
4.3个将军收到参谋1的时间，把（编号1，进攻时间1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（Accepted）；
5.参谋1收到至少2个将军的（Accepted）内容，确认进攻时间已经被大家接收；

6.参谋2发起提议，派通信兵带信给3个将军，内容为（编号2）；
7.3个将军收到参谋2的提议，由于（编号2）比（编号1）大，因此把（编号2）保存下来，避免遗忘；又由于之前已经接受参谋1的提议，因此让通信兵带信回去，内容为（编号1，进攻时间1）；
参谋2收到至少2个将军的回复，由于回复中带来了已接受的参谋1的提议内容，参谋2因此不再提出新的进攻时间，接受参谋1提出的时间；

交叉场景

交叉场景

proposer：参谋1，参谋2
acceptor：将军1，将军2，将军3（决策者）

1.参谋1发起提议，派通信兵带信给3个将军，内容为（编号1）；
2.3个将军的情况如下
a）将军1和将军2收到参谋1的提议，将军1和将军2把（编号1）记录下来，如果有其他参谋提出更小的编号，将被拒绝；同时让通信兵带信回去，内容为（ok）；
b）负责通知将军3的通信兵被抓，因此将军3没收到参谋1的提议；

3.参谋2在同一时间也发起了提议，派通信兵带信给3个将军，内容为（编号2）；
4.3个将军的情况如下
a）将军2和将军3收到参谋2的提议，将军2和将军3把（编号2）记录下来，如果有其他参谋提出更小的编号，将被拒绝；同时让通信兵带信回去，内容为（ok）；
b）负责通知将军1的通信兵被抓，因此将军1没收到参谋2的提议；

5.参谋1收到至少2个将军的回复，再次派通信兵带信给有答复的2个将军，内容为（编号1，进攻时间1）；
6.2个将军的情况如下
a）将军1收到了（编号1，进攻时间1），和自己保存的编号相同，因此把（编号1，进攻时间1）保存下来；同时让通信兵带信回去，内容为（Accepted）；
b）将军2收到了（编号1，进攻时间1），由于（编号1）小于已经保存的（编号2），因此让通信兵带信回去，内容为（Rejected，编号2）；

7.参谋2收到至少2个将军的回复，再次派通信兵带信给有答复的2个将军，内容为（编号2，进攻时间2）；
8.将军2和将军3收到了（编号2，进攻时间2），和自己保存的编号相同，因此把（编号2，进攻时间2）保存下来，同时让通信兵带信回去，内容为（Accepted）；
9.参谋2收到至少2个将军的（Accepted）内容，确认进攻时间已经被多数派接受；

10.参谋1只收到了1个将军的（Accepted）内容，同时收到一个（Rejected，编号2）；参谋1重新发起提议，派通信兵带信给3个将军，内容为（编号3）；
11.3个将军的情况如下
a）将军1收到参谋1的提议，由于（编号3）大于之前保存的（编号1），因此把（编号3）保存下来；由于将军1已经接受参谋1前一次的提议，因此让通信兵带信回去，内容为（编号1，进攻时间1）；
b）将军2收到参谋1的提议，由于（编号3）大于之前保存的（编号2），因此把（编号3）保存下来；由于将军2已经接受参谋2的提议，因此让通信兵带信回去，内容为（编号2，进攻时间2）；
c）负责通知将军3的通信兵被抓，因此将军3没收到参谋1的提议；

12.参谋1收到了至少2个将军的回复，比较两个回复的编号大小，选择大编号对应的进攻时间作为最新的提议；参谋1再次派通信兵带信给有答复的2个将军，内容为（编号3，进攻时间2）；
13.将军1和将军2收到了（编号3，进攻时间2），和自己保存的编号相同，因此保存（编号3，进攻时间2），同时让通信兵带信回去，内容为（Accepted）；
14.参谋1收到了至少2个将军的（accepted）内容，确认进攻时间已经被多数派接受。