真的需要分布式事务?
因为我们需要各个资源数据一致性。对,看起来合情合理,我们需要,而分布式事务恰好解决这个问题,但是分布式事务提供的是强一致性。试问下,我们真的需要强一致性吗?大多数业务场景都能容忍短暂的不一致,只是不同的业务对不一致的时间窗口要求不同罢了,现实生活中的餐馆买面条,他给你的是单号,而不是面条。
爱因斯坦说过:我们无法用我们制造问题的思维方式去解决我们的制造的问题。
本地消息表(业务耦合)
这种实现方式的思路,其实是源于 ebay,后来通过支付宝等公司的布道,在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅,借助关系型数据库中的表即可实现。
以跨行转账为例。

第一步:扣款 1万,通过本地事务保证了凭证消息插入到消息表中。(图中写业务即理解为扣除1万)
第二步,通知对方银行账户上加 1万了。那问题来了,如何通知到对方呢?
常采用两种方式:
采用时效性高的 MQ,由对方订阅消息并监听,有消息时自动触发事件
采用定时轮询扫描的方式,去检查消息表的数据。
两种方式其实各有利弊,仅仅依靠 MQ,可能会出现通知失败的问题。而过于频繁的定时轮询,效率也不是最佳的(90% 是无用功)。

本文深入探讨分布式事务,分析了本地消息表、MQ的非事务消息和事务消息、外部消息事件以及业务补偿模式。本地消息表通过数据库确保最终一致性,但可能带来性能瓶颈;MQ在确保一致性的同时,需要处理消息重复消费和丢失问题;外部消息事件通过独立事件系统降低耦合,但需额外操作;事务消息如RocketMQ提供保证,确保消息与本地事务同步;业务补偿模式则通过协调服务实现事务一致性。
最低0.47元/天 解锁文章
1872

被折叠的 条评论
为什么被折叠?



