一：理论
CAP理论：分布式系统不可能同时满足三点：一致性，可用性，分区容错性
- 一致性Consistency：所有节点访问时都是同一份最新的数据副本，即强一致性。
- 可用性Availability：每次访问（任一节点）都能获得响应，不保证数据正确。
- 分区容错性Partition tolerance：在遇到任何网络分区故障的时候，即节点之间不能同步数据了（或者会丢失部分数据），分式系统需要容忍这种情况，还能继续提供服务。
为什么不能同时满足呢？
假如在分区容错性的情况下，节点之间已经不同步了，这时候就算各节点还可用，也没法保证一致性； 假如要保证一致性，那就得等网络修复且数据完全同步后，才能提供服务，此期间，也就丢失可用性了； 而最终网络好了，真的能完全同步时，分区容错也就不存在了。
既然不能同时满足，如何选择？
1、选择CA，所有节点都可用且能完全同步，不能容忍网络错误或节点错误。 如果发生了，那只能将节点变成可读 不可写。
2、选择CP，在发生网络或节点错误情况下，还要保证一致性，那就只能满足大部分节点的一致性了，将那些少部分有问题的节点停用，牺牲可用性。
3、选择AP，网络或节点有问题时，还要提供对外服务，没法保证数据一致性。
至于如何选择以上情况，要根据实际业务场景。 比如银行，一定离不开一致性，就只能选择CA或CP。 而另一些系统中，对于一些不重要的数据，那可能就可选择AP。
BASE理论：
在大多数公司来看（不是银行这种），服务可用是要尽量满足的，分区问题也避免不了，如果不能同时满足CAP，那是不是可以对C做一些妥协，不要强一致性，不管采取什么措施达到最终一致性即可。 这就是由CAP演化而来的BASE理论。
1、基本可用：系统出现问题后还是能提供服务，只不过可能响应时间变慢，或者定位到降级页面等等方式。
2、软状态：各节点数据允许不一致，存在一个中间状态，但不会影响整体可用性。
3、最终一致性：将上面软状态的不一致，在一定时间后变成一致。
二：分布式一致性协议
上面说了分布式系统的设计理念，下面看看数据的一致性问题。
两阶段提交：
正常提交事务的情况：
回滚的情况：
如上面提交或回滚的情况，在阶段一各参与者会进入prepare阶段，先写Undo和Redo日志，阶段二收到协调者通知后，执行commit或rollback。
优点：原理简单。
缺点：1、在整个过程中所有参与者都同步阻塞等待。 2、如果协调者发生问题，或者因为其他原因，参与者没有收到通知，会一直等待无法释放资源（参与者是没有超时机制的）。 3、协调者发出阶段二的命令后，可能有些参与者成功，而有的又失败了。
三阶段提交：
相对于二阶段提交，主要有两点改进：
1、在参与者也增加了超时机制，如果超时则会提交事务，不会一直阻塞等待。
2、把二阶段提交中的准备阶段，拆分成了Can-Commit阶段（询问阶段，类似二阶段提交的第一步，只是这里还不执行本地事务）和Pre-Commit阶段（执行本地事务，写Undo和Redo）。增加Pre-Commit而不是直接执行commit，也就是推迟了commit的执行，确保各参与者都知道下一步就要commit了，做好commit准备，更大程度保证了在最后提交阶段之前各参与节点的状态是一致的。
两阶段和三阶段都是一种协议（或者叫做理念），虽然三阶段提交看起来更优，实则也没有完全解决数据一致性问题。比如最后一步，参与者中有的提交成功了有的失败了，或者有的收到了协调者回滚命令，但是有的没收到 并在超时后提交了事务。 此外，三阶段实现难度复杂，所以，在实际的实现技术、框架等，基本都是采用二阶段提交的方式。 如何在分布式中实现分布式事务，有什么技术，框架等，后面专门拿一章来讲分布式事务。