基于本地消息表的事务补偿中间件 tx-queue

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1386 天前的主题，其中的信息可能已经有所发展或是发生改变。

目前支持 Oracle 、MySQL
https://github.com/yxz1025/tx-queue

6 条回复 • 2021-02-07 13:18:10 +08:00

mmdsun

2021-02-06 13:26:54 +08:00 via Android

404 ？

lewis89

2021-02-06 21:55:04 +08:00

本地消息表？之前用这个方案被面试官吐槽了..
因为用消息队列本身就是因为本地事务太大，可能导入写入压力大，而把写入压力交个消息中间件，
然后通过消息来维护数据的最终一致性

Caesar123

2021-02-07 08:48:44 +08:00

@lewis89 本地事务尽量需要精简，而且加了这个整个事务不会拉太长，实际生产环境你可以压测试试看

Caesar123

2021-02-07 08:49:08 +08:00

@mmdsun 打不开？

lewis89

2021-02-07 09:03:51 +08:00

@Caesar123 #3 是的，我有测试过，本地消息表可靠性好，加一个消息的写入并不会增加太大的事务压力，而且可靠性比使用预提交的消息队列要简单的多，麻烦的是如果你做了水平拆分，消息如果是落地对应的分库那么本地事务就好说，如果消息统一落地一个统一的库那么就是 XA 事务做起来更复杂，如果消息有全局顺序依赖提取多个分库的本地消息表就不太好做.. 当然一般不会有业务有全局消息依赖，都是局部顺序依赖

如果只是提交给消息队列，通过预提交由消息队列中间件来询问你本地事务是否提交是一个比较简易的方案，消息顺序性其实是消息中间件来保证了.. 应用层只要考虑分布式锁来保证消息的投递顺序..

Caesar123

2021-02-07 13:18:10 +08:00

@lewis89 消息队列这种方案就是对于第三方依赖性太强了，比如消息丢失，消息是否投递成功等等，tx-queue 这种就是先将消息写入本地表，然后通过线程分发进行进行消息投递，这种消息的存储是和你本地事务绑定在一起的，这种就属于轻量级的侵入了，不过要看场景，强事务的一致性不太适合，比如库存扣减等等