分布式事务探讨系列（三）：本地消息表和MQ等可靠消息解决方案

真的需要分布式事务？

因为我们需要各个资源数据一致性。对，看起来合情合理，我们需要，而分布式事务恰好解决这个问题，但是分布式事务提供的是强一致性。试问下，我们真的需要强一致性吗？大多数业务场景都能容忍短暂的不一致，只是不同的业务对不一致的时间窗口要求不同罢了，现实生活中的餐馆买面条，他给你的是单号，而不是面条。

爱因斯坦说过：我们无法用我们制造问题的思维方式去解决我们的制造的问题。

本地消息表（业务耦合）

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

以跨行转账为例。

第一步：扣款 1万，通过本地事务保证了凭证消息插入到消息表中。(图中写业务即理解为扣除1万)

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

常采用两种方式：

采用时效性高的 MQ，由对方订阅消息并监听，有消息时自动触发事件
采用定时轮询扫描的方式，去检查消息表的数据。
两种方式其实各有利弊，仅仅依靠 MQ，可能会出现通知失败的问题。而过于频繁的定时轮询，效率也不是最佳的（90% 是无用功）。所以，我们一般会把两种方式结合起来使用。

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

仔细思考，其实我们可以消息消费方，也通过一个“消费状态表”来记录消费状态。在执行“加款”操作之前&#