浅谈分布式事务

简单来说，分布式事务就是一个业务操作包含多个子操作，并且子操作分属不同服务器上(也可以说操作不同数据库)，这时候需要保证这些子操作要么全部成功，要么全部失败，进而达到一致性。

基本理论

ACID

参考上一篇文章

CAP理论

• 一致性（Consistency）：在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。这里指的是强一致性
• 可用性（Availability）：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限时间内返回结果
• 分区容错性（Partition tolerance）：分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要根据业务场景做出选择。这里要强调的是：CAP定律的前提是P，当P决定后才有CA的抉择。

BASE理论

BASE理论是对CAP中一致性和可用性权衡的结果，来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：牺牲强一致性，根据自身业务特点，采用适当的方式来使系统达到最终一致性，从而提高可用性。BASE中的三要素：

• 基本可用Basically Available：指分布式系统在出现不可预知故障的时候，允许损失部分可用性，这绝不等价于系统不可用，比如服务降级、页面降级等等。
• 软状态Soft state：是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步存在延时。
• 最终一致性Eventually consistent：强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，其本质是需要系统保证数据最终能够达到一致，而不需要保证系统数据的实时强一致性。

分布式事务解决方案

事务消息最终一致性

前提条件是MQ必须支持事务消息，比如RocketMQ

优点

1. 实现了最终一致性，不需要依赖本地数据库事务；
2. 不占用业务DB资源；
3. 没有耦合其它非业务代码。

缺点：

1. 主流开源MQ基本都不支持，自身实现难度大

本地消息（事务）表

核心设计思想：将分布式事务拆分成一系列的本地事务进行处理

优点

1. 是一种非常经典且较简单的实现，避免了分布式事务，实现了最终一致性。

缺点

1. 与具体的业务场景绑定，耦合性强，不可复用；
2. 消息数据与业务数据同库，占用业务系统资源。

TCC补偿性事务

核心思想：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作

优点

1. 解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用；
2. 实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。

缺点

1. Try、Confirm和Cancel操作功能需业务提供，开发成本高；
2. Cancle要考虑部分cancle成功的场景，保证数据最终一致性。

最大努力通知型

本质上就是通过定期校对，实现数据一致性。典型的使用场景有：银行通知、商户通知

优点
实现简单。

缺点
无补偿机制，不保证能够送达。