CAP定理
2000年7月加州大学伯克利分校 Eric Brewer教授提出CAP猜想，两年后被证明。
CAP理论告诉我们，一个分布式系统不可能同时满足一致性（C，Consistency），可用性（A，Availability）和分区容错性（P，Partition tolerance）三个基本要求，最多只能同时满足其中两个。
一致性：分布式系统中，能够做到针对一个数据的更新成功后，其他所有的用户都可以读取到［最新的值］，那么这样子的系统就是强一致性的。
可用性：［有限时间内］［返回结果］
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够抱枕固堤外提供满足一致性和可用性的服务。
其实CAP定理是理论，现实系统场景中的CAP也不一定会真的会放弃其中一个不做，而是我们可以着重性的保证其他两个，而剩下的一个尽量保证。
在一些面试中，面试官是比较喜欢提问到如果保证分布式事务的。比较出名的解决办法就是二段式提交协议、三段式提交协议和Paxos算法了。
［二段式提交协议］是将事务的提交过程分成了两个阶段来进行处理，其执行过程如下：
阶段一：提交事务请求：
1、事务询问。协调者向所有参与者发送事务内容，询问是否可以进行事务提交操作，然后就开始等待参与者的响应。
2、执行事务。各参与者节点执行事务奥做，并将Undo和Redo信息记入事务日志中。
3、各参与者向协调者反馈事务询问的响应。
阶段二：执行事务提交：
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。
1、发送提交请求。
2、事务提交。
3、反馈事务提交结果。参与者在完成事务提交之后，会向协调者发送Ack消息。
4、完成事务。
中断事务：
1、发送回滚请求。协调者向参与者发出rollback请求。
2、事务回滚。参与者接收到Roolback请求利用阶段一种记录的Undo信息来执行事务回滚动作。
3、反馈事务回滚结果。
4、中断事务。
二段式提交协议的优缺点：
优点：原理简单，实现方便；
缺点：同步阻塞、单点问题、脑裂（比如协调者的消息在网络异常情况下只给一部分参与者发送了）、太过保守。
［三段式提交协议］其实是在二段式基础上面针对二段式的缺点进行了改进。
阶段一：CanCommit
1、事务询问。
2、各参与者向协调这反馈事务询问的响应。
阶段二：PreCommit
假设协调者从所有的参与者获得的都是Yes响应，那么将执行事务预提交。
1、发送预提交请求。协调者向所有参与者节点发出preCommit请求，进入prepared阶段。
2、事务预提交。参与者接收到preCommt请求，执行事务擦偶走，将Undo和Redo信息记录到事务日志中。
3、各参与者向协调者反馈事务提交的响应。
假设任何一个参与者向协调者反馈了No反应，活着在等待超时之后，协调者无法获得所有参与者的响应，那么将执行事务的中断。
1、发送终端请求。协调者向所有参与者发出abort请求。
2、中断事务。无论接到abort请求还是等待协调者请求过程出现超时情况，参与者都会中断事务。
阶段三：doCommit
该阶段将进行真正的事务提交：
执行提交
1、发送提交请求。进入这一阶段，假设协调者从正常的工作状态，并且接收到所有的参与者的ack响应，它将从预提交状态转换到提交状态，向所有参与者发送doCommit请求。
2、事务提交。参与者接收到doCommit请求后，正式执行事务提交操作。并在提交后释放在整个事务执行期间占用的事务资源。
3、反馈事务提交结果。参与者完成事务提交之后，向协调者发送Ack消息。
4、完成事务。协调者接收到所有参与者的Ack消息，完成事务。
中断事务
中断事务的4步操作与提交事务完全一致，只不过从提交事务变成了事务回滚。
三段式提交协议的优缺点：
最大优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点就是在去除阻塞的情况下引入了新的问题，那就是参与者接收到了PreCommit消息，然后网络出现问题，参与者和协调者无法通信，这种情况下，参与者依然会执行事务的提交。
－－－－
该文内容出自倪超的《从Paxos到zookeeper》