CAP定理
CAP由[Eric Brewer]在2000年PODC会议上提出，是Eric Brewer在Inktomi期间研发搜索引擎、分布式web缓存时得出的关于数据一致性(consistency)、服务可用性(availability)、分区容错性(partition-tolerance)的猜想：
It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.
该猜想在提出两年后被证明成立，成为我们熟知的CAP定理：
- 数据一致性(consistency)：所有节点在同一时刻能够看到同样的数据，也即“强一致性”；
- 服务可用性(availability)：所有读写请求在一定时间内得到响应，可终止、不会一直等待；
-
分区容错性(partition-tolerance)：因为网络故障导致的系统分区不影响系统正常运行。
q6bmAn6.png
我们把解决一致性问题（Consensus Problem）的算法叫做一致性算法（Consensus Algorithm）或者一致性协议（Consensus Protocol）。CAP定理能够将这些一致性算法的集合进行归类：
C+A ：以2阶段提交(2 phase commit)为代表的严格选举协议。当通信中断时算法不具有终止性（即不具备分区容忍性）;
C+P ：以Paxos、Raft为代表的多数派选举算法。当不可用的执行过程超过半数时，算法无法得到正确结果（即会出现不可用的情况）;
A+P ：以Gossip协议为代表的冲突解决协议。当网络分区存在和执行过程正确时，只能等待分区消失才保持一致性（即不具备强一致性）
基于CAP定理，我们需要根据不同场景的不同业务要求来进行算法上的权衡。对于分布式存储系统来说，网络连接故障是无法避免的。在设计系统时不得不考虑分区容忍性，所以我们实际上只能在一致性和可用性之间进行权衡。
强一致性与可用性的矛盾会导致十分令人头疼的抉择。在实际情况中，对于不是那么重要的数据的存取操作，往往会调低一致性来增加可用性。
工程实践上根据具体的业务场景，或保证强一致(safety)，或在节点宕机、网络分化的时候保证可用(liveness)。2PC、3PC是相对简单的解决一致性问题的协议，下面我们就来了解2PC和3PC。
2PC
2PC(tow phase commit)两阶段提交[5]顾名思义它分成两个阶段，先由一方进行提议(propose)并收集其他节点的反馈(vote)，再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator)，其他参与决议节点称为参与者(participants, 或cohorts)：
2PC, phase one
在阶段1中，coordinator发起一个提议，分别问询各participant是否接受。
2PC, phase two
在阶段2中，coordinator根据participant的反馈，提交或中止事务，如果participant全部同意则提交，只要有一个participant不同意就中止。
3PC
3PC(three phase commit)即三阶段提交，既然2PC可以在异步网络+节点宕机恢复的模型下实现一致性，那还需要3PC做什么，3PC是什么鬼？
在2PC中一个participant的状态只有它自己和coordinator知晓，假如coordinator提议后自身宕机，在watchdog启用前一个participant又宕机，其他participant就会进入既不能回滚、又不能强制commit的阻塞状态，直到
participant宕机恢复。这引出两个疑问：
- 能不能去掉阻塞，使系统可以在commit/abort前回滚(rollback)到决议发起前的初始状态
- 当次决议中，participant间能不能相互知道对方的状态，又或者participant间根本不依赖对方的状态
相比2PC，3PC增加了一个准备提交(prepare to commit)阶段来解决以上问题：
图片截取自wikipedia
coordinator接收完participant的反馈(vote)之后，进入阶段2，给各个participant发送准备提交(prepare to commit)指令。participant接到准备提交指令后可以锁资源，但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort，3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。
participant如果在不同阶段宕机，我们来看看3PC如何应对：
- 阶段1: coordinator或watchdog未收到宕机participant的vote，直接中止事务；宕机的participant恢复后，读取logging发现未发出赞成vote，自行中止该次事务
- 阶段2: coordinator未收到宕机participant的precommit ACK，但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2)，coordinator进行commit；watchdog可以通过问询其他participant获得这些信息，过程同理；宕机的participant恢复后发现收到precommit或已经发出赞成vote，则自行commit该次事务
- 阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK，也结束该次事务；宕机的participant恢复后发现收到commit或者precommit，也将自行commit该次事务
因为有了准备提交(prepare to commit)阶段，3PC的事务处理延时也增加了1个RTT，变为3个RTT(propose+precommit+commit)，但是它防止participant宕机后整个系统进入阻塞态，增强了系统的可用性，对一些现实业务场景是非常值得的。
参考资料
