亿级流量架构之分布式事务思路及方法( 三 ) _流量架构

分布式事务解决思路讲这个之前需要先简单回顾CAP原则和Base理论,因为分布式事务不同于 ACID 的刚性事务，在分布式场景下基于 BASE 理论，提出了柔性事务的概念。要想通过柔性事务来达到最终的一致性，就需要依赖于一些特性，这些特性在具体的方案中不一定都要满足，因为不同的方案要求不一样；但是都不满足的话，是不可能做柔性事务的。
CAP原则CAP一般人可能听了不下一百遍了,很多人都说CAP是"三选二"的关系,让人误以为有AC这种情况,但是实际CAP是二选一的关系,这个在2012年已经有一篇论文进行解释: CAP Twelve Years Later: How the "Rules" Have Changed
相当于是对之前三选二说法进行修正,CAP中P(分区容错性)是必须具备的,在满足P的前提下,很难同时满足A(可用性)和C(一致性),但是在之后,又有一篇文章: Harvest, yield, and scalable tolerant systems ,这篇论文是基于上面那篇“CAP 12年后”的论文写的，它主要提出了 Harvest 和 Yield 概念，并把上面那篇论文中所讨论的东西讲得更为仔细了一些。简单来说就是满足P之后,C和A在放宽约束后可以得到兼顾,并不是非此即彼的关系,说远了。
为什么P是必须的?为什么CAP原则中分区容错性是必须的呢,首先要理解什么是分区容错性,分区,这儿说的是网络,网络集群设计到很多的服务器,某一瞬间网络不稳定,那么相当于将网络分成了不同的区,假设分成了两个区,这时候如果有一笔交易:
对分区一发出消息:A给B转账100元,对分区二发出消息:A给B转账200元
那么对于两个分区而言,有两种情况:
a）无可用性，即这两笔交易至少会有一笔交易不会被接受；
b）无一致性，一半看到的是 A给B转账100元而另一半则看到 A给B转账200元。
所以,分区容忍性必须要满足,解决策略是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。
Base理论在很多时候，我们并不需要强一致性的系统，所以后来，人们争论关于数据一致性和可用性时，主要是集中在强一致性的 ACID 或最终一致性的 BASE中, BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。
BASE理论是Basically Available(基本可用) ， Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。
基本可用假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：

响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

这就叫基本可用
软状态相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态” 。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
Base其核心思想是：既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。有了Base理论就可以开始讲述分布式事务的处理思路了。
二阶段提交协议二阶段提交(2PC：Two-Phase Commit),顾名思义，该协议将一个分布式的事务过程拆分成两个阶段：投票和事务提交。为了让整个数据库集群能够正常的运行，该协议指定了一个协调者单点，用于协调整个数据库集群各节点的运行。为了简化描述，我们将数据库集群中的各个节点称为参与者，三阶段提交协议中同样包含协调者和参与者这两个角色定义,后面再说。