分布式事物--本地消息表

桃扇骨 2022-01-26 01:47 142阅读 0赞

## 本地消息表 ##

这种实现方式的思路，其实是源于 ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。

举个经典的跨行转账的例子来描述。

第一步伪代码如下，扣款 1W，通过本地事务保证了凭证消息插入到消息表中。

![61337ee75b0c2a66c06e99fc2ba2505c.png][]

第二步，通知对方银行账户上加 1W 了。那问题来了，如何通知到对方呢？

通常采用两种方式：

1.  采用时效性高的 MQ，由对方订阅消息并监听，有消息时自动触发事件
2.  采用定时轮询扫描的方式，去检查消息表的数据。（此方式实现：[https://blog.csdn.net/wwd0501/article/details/90611203][https_blog.csdn.net_wwd0501_article_details_90611203]）

两种方式其实各有利弊，仅仅依靠 MQ，可能会出现通知失败的问题。而过于频繁的定时轮询，效率也不是最佳的（90% 是无用功）。所以，我们一般会把两种方式结合起来使用。

解决了通知的问题，又有新的问题了。万一这消息有重复被消费，往用户帐号上多加了钱，那岂不是后果很严重？

仔细思考，其实我们可以消息消费方，也通过一个“消费状态表”来记录消费状态。在执行“加款”操作之前，检测下该消息（提供标识）是否已经消费过，消费完成后，通过本地事务控制来更新这个“消费状态表”。这样子就避免重复消费的问题。

总结：上诉的方式是一种非常经典的实现，基本避免了分布式事务，实现了“最终一致性”。但是，关系型数据库的吞吐量和性能方面存在瓶颈，频繁的读写消息会给数据库造成压力。所以，在真正的高并发场景下，该方案也会有瓶颈和限制的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d3ZDA1MDE_size_16_color_FFFFFF_t_70][]

文章来源：[https://www.infoq.cn/article/solution-of-distributed-system-transaction-consistency][https_www.infoq.cn_article_solution-of-distributed-system-transaction-consistency]

[61337ee75b0c2a66c06e99fc2ba2505c.png]: /images/20220126/66fcf484d3124b1696bc5b37907d700b.png
[https_blog.csdn.net_wwd0501_article_details_90611203]: https://blog.csdn.net/wwd0501/article/details/90611203
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d3ZDA1MDE_size_16_color_FFFFFF_t_70]: /images/20220126/f29f738c8661421aac33b8ae1d733b50.png
[https_www.infoq.cn_article_solution-of-distributed-system-transaction-consistency]: https://www.infoq.cn/article/solution-of-distributed-system-transaction-consistency