23. 分布式事务的基础？

23. 分布式事务的基础？

数据库的 ACID 满足了数据库本地事务的基础，但是它无法满足分布式事务，这个时候衍生了 CAP 和 BASE 两个经典理论。

? CAP 理论

CAP 定理，又被叫作布鲁尔定理。对于设计分布式系统来说(不仅仅是分布式事务)的架构师来说，CAP 就是你的入门理论。

C (一致性)：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
A (可用性)：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
P (分区容错性)：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。

高可用、数据一致性是很多系统设计的目标，但是分区又是不可避免的事情。我们来看一看分别拥有 CA、CP 和 AP 的情况。

CA without P：如果不要求 P（不允许分区），则 C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此 CA 的系统更多的是允许分区后各子系统依然保持 CA 。
CP without A：如果不要求 A（可用），相当于每个请求都需要在 Server 之间强一致，而 P（分区）会导致同步时间无限延长，如此 CP 也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

可能胖友看完之后，会一脸懵逼，可以看看《分布式系统理论（一）：CAP 定理》文章提供的示例：

MySQL 主从异步复制是 AP 系统。
MySQL 主从半同步复制是 CP 系统。
Zookeeper 是 CP 系统。
Redis 主从同步是 AP 系统。
Eureka 主从同步是 AP 系统。

从上的示例中，“三选二”是一个伪命题。不是为了 P（分区容忍性），要在 A 和 C 之间选择一个。分区很少出现，CAP 在大多数时候允许完美的 C 和 A 。但当分区存在或可感知其影响的情况下，就要预备一种策略去探知分区并显式处理其影响。

艿艿，如果关于**“三选二”是一个伪命题**无法理解，可以回过头在看一眼“CA without P” ，对比下就好理解了。对于单节点，CA 必然是可以保证的。

另外，关于 CAP 的论证过程，也是蛮有趣的一块内容，感兴趣的胖友，可以自己去搜索下。

? BASE 理论

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性) 三个短语的缩写。是对 CAP 中AP 的一个扩展

BA 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
S 软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是 CAP 中的不一致。
E 最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。

BASE 解决了 CAP 中理论没有网络延迟，在 BASE 中用软状态和最终一致，保证了延迟后的一致性。

BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

对于大部分的分布式应用而言，只要数据在规定的时间内达到最终一致性即可。我们可以把符合传统的 ACID 叫做刚性事务，把满足 BASE 理论的最终一致性事务叫做柔性事务。

一味的追求强一致性，并非最佳方案。对于分布式应用来说，刚柔并济是更加合理的设计方案，即在本地服务中采用强一致事务，在跨系统调用中采用最终一致性。如何权衡系统的性能与一致性，是十分考验架构师与开发者的设计功力的。

具体到分布式事务的实现上，业界主要采用了 XA 协议的强一致规范以及柔性事务的最终一致规范。

所以，市面上的分布式事务的解决方案，除了 XA 协议是强一直的，其他都是最终一致的。