分布式的事务该怎么做？

比眉伴天荒 2024-04-18 17:06 54阅读 0赞

#### 分布式八大坑 ####

分布式就是魔鬼啊！

张大胖最近十分感慨，他所在的公司原来有个电商系统，后来随着用户量越来越大，对系统的可用性要求越来越高。 CTO要求把系统进行拆分， 从一个单体的应用，拆分成微服务组成的应用。

微服务听起来很美好，但是其中的苦只有做过的人才知道。

在原来的单体应用中，订单模块想要调用库存和支付，只要调用相关的类或者接口就可以了，只有一个数据库，`轻轻松松就可以把所有操作放到一个事务当中，保证不会出现扣了库存但是支付失败的情况`。

![单体应用][20190909232839748.png]  
（单体应用）

现在好了，系统成了分布式，原来的进程间调用变成了跨越网络的HTTP调用，这数据库也从单个数据库变成了多个独立的数据库，原来的事务肯定是不起作用了！

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9zaGFuaHkuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]

大神Bill告诉张大胖分布式有八个大坑， 千万别跳到坑里去：

当你在构建一个分布式系统的时候，可能会不由自主地做一些假设，这些假设从长期来看，都是错误的，都会导致大麻烦：

1.  网络是可靠的
2.  (调用)没有延迟
3.  无限的带宽
4.  网络是安全的
5.  (系统)拓扑结构不会改变
6.  有个管理员在管理这个系统
7.  (数据)传输代价为零
8.  网络是同质的（同类的）

这第一条就很要命，网络是不可靠的， 网络调用失败的可能性是非常高的，很有可能出现扣减了库存，但是没有支付的情况。

#### 分布式的事务 ####

怎么样让扣减库存和支付服务能在一个类似数据库事务中完成，要么都做，要么都不做呢？ 张大胖觉得十分头疼。

张大胖首先想到了两阶段的提交（2PC），但是2PC是针对底层的数据资源层实现的，现在要做的是业务层的事情， 况且这2PC也很不好用啊。

（码农翻身注： 2PC的故事参见《Java帝国之宫廷内斗》）

他觉得必须要有一个协调人居中协调各个微服务，让他们处于一个“事务”中， 可是这协调者该如何实现？

Bill 递给他一篇文章：“你要实现的就是分布式事务了！看看这篇文章吧！”

张大胖接过打印的文章，标题是：《Distributed Atomic Transactions over RESTful Services》 ，他的头嗡地一声就变大了，哀叹道：“英文的啊，你还是给我讲讲吧！”

“英文很重要啊，大胖同学！” Bill说道，“其实这个分布式事务的原理很简单，它的精华就是冻结资源和幂等性。”

（此处应该插入一个英语广告，哈哈。）

张大胖说：“这幂等性我知道，就是一个操作不管是执行一千次，一万次，效果和执行一次是一样的。 这冻结资源是怎么回事？”

“拿咱们的系统举个例子吧，订单服务要调用库存服务扣减库存（假设数量为2），还要调用支付服务从用户余额扣钱（假设为100）， 那订单服务第一步就告诉库存服务，给我冻结2个库存； 告诉支付服务，给我冻结100块钱。在这一步，两个服务要做业务检查，看看库存余额够不够，如果足够，就冻结他们，防止其他调用也进行了扣减操作，导致本次调用余额不足。 这一步，我们称之为尝试(`Try`)。 ”

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9zaGFuaHkuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1]  
（注： 这里也可以对库存数量和用户余额做扣减）

库存服务和支付服务操作的都是自己的表，冻结操作可以放到一个本地事务中，保证原子性。

“明白， 接下来呢？” 张大胖问道。

“这一步如果成功完成，订单服务就可以进入第二步，告诉这两个服务真正地执行扣减操作，这一步叫做`Confirm`。”

![在这里插入图片描述][20190909233020866.png]

（注：如果在第一步已经做了扣减，这里只需要修改相关状态即可，大家可自行脑补。 ）

“慢着，如果调用支付服务进行Confirm时出错怎么办？ ” 张大胖问道。

“很简单，那就告诉库存服务和订单服务，都进行`Cancel`操作， 把冻结的数量进行恢复。”

Bill说道。 “我们把这套机制叫做 `Try - Confirm -Cancel`，简称TCC。对于每个每个微服务来讲，都要提供try , confirm , cancel这三个接口。” Bill接着说，“另外每个微服务也得有一个专门用来管理TCC的组件。”

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9zaGFuaHkuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 2]

#### 异常场景 ####

张大胖心想，你说得简单，这都是所谓`Happy Path`， 在分布式环境中出错是必然的，他很快找到了第一个场景：

**场景1** ： 库存服务的Try操作完成， 支付服务的Try操作没有完成， 怎么办？

Bill说：“这很好处理，订单服务可以尝试去调用库存的Cancel操作（这应该是个`幂等操作`，可以多次调用），把冻结的库存释放。”

张大胖说：“那如果出现网络问题，订单服务无法联系库存服务了呢？”

“不用担心，库存服务的TCC组件能够发现冻结的时间已经超时，会自动把冻结的库存给释放。”

**场景2** ： 两个微服务的Try操作都完成， 然后发生网络故障，导致两个Confirm都无法进行

Bill说： “和第一种情况一下，TCC组件会发现超时，释放冻结的资源， 当然，冻结的这部分资源在释放前的一段时间内不可以被使用。”

“可是，如果库存服务所在的机器已经挂掉了呢？怎么计算超时？” 张大胖问道。

“这是个好问题，所以TCC系统必须得`记录日志`，把那些没有完成的事情记录下来，持久化到硬盘上。这样下次重启就可以接着执行了。”

**场景3** ： Try操作都已完成，资源已经冻结，在第三步中库存服务Confirm成功，库存做了扣减， 但是支付服务挂掉了，余额还处于冻结状态， 怎么办？

Bill 说道：“那可以多尝试几次， 让支付服务做Confirm操作（很明显，这个`Confirm操作必须得是一个幂等操作才行`）。如果实在是无法成功，那就可以让库存服务做Cancel操作。 如果还是不行，只有让人工介入了。”

怪不得Bill一直在强调幂等性，原来真正的作用是这样啊。

#### 转向BASE? ####

张大胖想了想，似乎各种情况都能覆盖了， 但是还有实现层面的大问题：

(1) 就是对于try (冻结资源)， confrim , cancel(恢复资源)这样的操作都需要程序员去写代码实现。

比如对于支付服务， 至少的实现三个方法：

tryPayment(…)

confirmPayment(…)

cancelPayment(…)

这样TCC框架才可以去调用。

(2) 还得自己搞个TCC框架。

Bill 笑道： “那没办法，分布式就是这么烦人。TCC框架倒是有一些现成的，比如Atomikos，tcc-transaction,Hmily等， 但是那些try,confrim, cancel是业务方法，程序员必须得写， 跑不掉的。”

“就没有别的办法了吗？”

“有啊，也可以尝试下另外一个最终一致性的模型，叫做BASE。” Bill随手又递过来一篇论文，名字是《BASE: An Acid Alternative》

“有没有搞错 ！ 又是英文的！”

“你要是不想看英文的，就去看看老刘写的《Java帝国之宫廷内斗》吧！”

--------------------

（END）

[20190909232839748.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f32bd39917404cf18766a5e033fd0755.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9zaGFuaHkuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9389f0593eb24d63924df73c08702240.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9zaGFuaHkuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/91635413e0214f9ca5375db1c27a088a.png
[20190909233020866.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/299a7b5d0a4b4c8c810354bc7e3c9cec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9zaGFuaHkuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/fc53d618f93840c3b9dfa20fe9fe7e95.png