一次给女朋友转账引发我对分布式事务的思考

这个流水表需要怎么用呢?我们在“第1步”进行扣款时，同时往流水表写入一条操作流水，状态为“待处理”，并且这两个操作必须是原子的，也就是说必须通 过本地事务保证 这两个操作要么同时成功，要么同时失败!这就保证了只要转账扣款成功，必定会记录一条状态为“待处理”的转账流水。如果在这一步失败了，那自然就是转账失败，没有后续操作了。如果这步操作后系统宕机了导致没有将消息成功写入消息队列(也就是“第2步”)也没关系，因为我们的流水数据已经持久化了!这时候我们只需要加入一个后台线程进行补偿，定期的从转账流水表中读取状态为“待处理”且最后更新的时间距当前时间大于某个阈值的数据，重新放入消息队列进行补偿。这样，就保证了消息即使丢失，也会有补偿机制!B银行在处理完转账请求后会回调A银行的接口通知转账的状态，从而更新A银行流水表中的状态字段!这样就完美解决了上一个方案中的两个不足点。系统设计图如下：

到目前为止，我们很好的解决了消息丢失的问题，保证了只要A银行转账操作成功，转账的请求就一定能发送到B银行!但是该方案又引入了一个问题，通过后台线程轮询将消息放入消息队列处理，同一次转账请求可能会出现多次放入消息队列而多次消费的情况，这样B银行会对同一转账多次处理导致数据出现不一致!那怎么保证B银行转账接口的幂等性呢?

同样的，我们可以在B银行系统中需要增加一个转账日志表，或者叫转账流水表，B银行每次接收到转账请求，在对账户进行操作的时候同时往转账日志表中插入一条转账日志记录，同样这两个操作也必须是原子的!在接收到转账请求后，首先根据唯一转账流水Id在日志表中查找判断该转账是否已经处理过，如果未处理过则进行处理，否则直接回调返回! 最终的架构图如下：

（编辑：衢州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!