七种分布式事务的解决方案，一次讲给你听

今天看到一篇分布式事务的推文，介绍了7种分布式事务的解决方案，适合简单了解

微信公众号：moon聊技术
七种分布式事务的解决方案，一次讲给你听

什么是分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器「分别位于不同的分布式系统的不同节点之上」。

一个大的操作由N多的小的操作共同完成。而这些小的操作又分布在不同的服务上。针对这些操作，要么全部成功执行，要么全部不执行。

为什么会有分布式事务？

举个例子：

转账是最经典的分布式事务场景，假设用户 A 使用银行 app 发起一笔跨行转账给用户 B，银行系统首先扣掉用户 A 的钱，然后增加用户 B 账户中的余额。

如果其中某个步骤失败，此时就有可能会出现 2 种「异常」情况：

• 用户 A 的账户扣款成功，用户 B 账户余额增加失败
• 用户 A 账户扣款失败，用户 B 账户余额增加成功。

对于银行系统来说，以上 2 种情况都是「不允许发生」，此时就需要事务来保证转账操作的成功。

在「单体应用」中，我们只需要贴上@Transactional注解就可以开启事务来保证整个操作的「原子性」。

但是看似以上简单的操作，在实际的应用架构中，不可能是单体的服务，我们会把这一系列操作交给「N个服务」去完成，也就是拆分成为「分布式微服务架构」。假设订单服务，库存服务分别是不同的服务，不是用同一个数据库。

比如下订单服务，扣库存服务等等，必须要「保证不同服务状态结果的一致性」，于是就出现了分布式事务。

分布式理论

一、CAP定理

在一个分布式系统中，以下三点特性无法同时满足，「鱼与熊掌不可兼得」

一致性（C）：
在分布式系统中的所有数据备份，「在同一时刻是否拥有同样的值」。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：
在集群中一部分节点「故障」后，集群整体「是否还能响应」客户端的读写请求。（对数据更新具备高可用性）

分区容错性（P）：
即使出现「单个组件无法可用,操作依然可以完成」。

具体地讲在分布式系统中，在任何数据库设计中，一个Web应用「至多只能同时支持上面的两个属性」。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。

二、BASE理论

在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？

前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：

• 「Basically Available（基本可用）」
• 「Soft state（软状态）」
• 「Eventually consistent（最终一致性）」

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

分布式事务解决方案

• 两阶段提交（2PC）
• 三阶段提交（3PC）
• 补偿事务（TCC）
• 本地消息表
• 消息事务
• 最大努力通知
• Sagas 事务模型

具体请看原文