几年的架构师生涯，掏心掏肺分享在分布式“刚性事务和柔性事务”中思维逻辑！

Posted 2021-05-01 架构之美

前期回顾:

-     刚性事务总结     -

在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等等。但是没有说分布式事务的现象或者场景，我总结了分布式事务的触发场景大约有以下几种：

1、跨数据库分布式事务：数据库的物理分割下保障跨库操作的ACID。

2、跨服务分布式事务：服务的网络分割下保障多服务的事务完整性。

3、混合式分布式事务：跨数据库分布式事务 + 跨服务分布式事务。

最根本的原因就是事务参与者出现在不同的网络中，需要网络通讯进行交互，因此不可避免的出现失败、超时等情况，所以需要分布式事务来处理。

前面也大体说了下事务的解决方案，接下来咱们先来个完整的结论：业务规避 > BASE柔性事务 > CP刚性事务。刚性事务已经介绍过了，因为追求CP，通常使用在金融等强一致性场景的行业。刚性事务首先有XA规范，这个XA规范的实现方案是2PC，业界开源框架有Atomikos、Bitronix、Seata XA模型及各大数据库厂商对XA的落地。

目前国内对刚性事务使用最广泛的是蚂蚁金服的2PC，但是并不开源。不够我们可以从Seata XA模型去看到一部分蚂蚁2PC的影子。Seata XA模型是1.2版本推出的新功能，目前并不是很成熟，建议可以先观望下。

-     XA规范     -

XA规范定义将事务参与者分成了TM、AP、RM三个角色。XA规范要求事务资源(如数据库) 本身提供对规范和协议的支持，这样的好处是如下：

1、可以从任何角度保证数据的隔离。

2、实现数据的全局一致性。

3、对业务无侵入。

XA规范将事务机制落地到事务资源上,在落地上使用的是XAConnection和 XADataSource。XA开源框架都是从这入手的，但是从职责上去区分，XAConnection 和 XADataSource属于数据库的驱动范围内，如果框架自己去实现，无法保证数据库的兼容完整性。最佳的实践需要事务资源(如数据库) 本身提供对规范和协议的支持。Seata XA模型也是如此，不够Seata 官方承诺保证 提供的驱动程序是经过充分测试的；再加上一个场外因素-阿里多年的实践经验，因此还是可以期待。

XA 框架通过connection通讯层面去处置事务机制，避免了SQL的相关处理、也利用了数据库内部XA实现，因此最能保障 数据全局一致性。但是XA规范在1994年就出现了，至今没有大规模流行起来，必然有他一定的缺陷：

1、数据锁定：数据在事务未结束前，为了保障一致性，根据数据隔离级别进行锁定。

2、协议阻塞：本地事务在全局事务 没 commit 或 callback前都是阻塞等待的。

3、性能损耗高：主要体现在事务协调增加的RT成本，并发事务数据使用锁进行竞争阻塞。

-     柔性事务     -

刚性事务都是CP的，所以不可避免的面临性能有上限，无法满足超高量级的互联网场景。因此出现了柔性事务，相比较与数据库事务中的ACID这种刚性事务来说，柔性事务本质是对XA协议的妥协，它通过降低强一致性要求，从而降低数据库资源锁定时间，提升可用性。这其实就是基于BASE理论，保证数据的最终一致性。

• Basically Available-基本可用

• Soft state-柔性状态

• Eventual consistency-最终一致性

基本可用指分布式系统出现不可知故障时，允许损失部分可用性。具体表现为，一响应时间的损失：出现故障后，通过延长响应(服务重试其他提供者)来保障可用性；二功能上的损失：流量高峰时，通过服务降级、限流等治理手段提供有损服务。

柔性状态指允许系统的数据存在中间状态，并认为中间状态的存在不影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

柔性事务主要分为补偿型和通知型。补偿型事务又分TCC、Saga，通知型事务分MQ事务消息、最大努力通知型。补偿型事务都是同步的，通知型事务都是异步的，所以有时可以听到另外一种划分。

-   关注“架构之美”   -