这是一个创建于 1585 天前的主题，其中的信息可能已经有所发展或是发生改变。
有时会遇到业务逻辑太长涉及的东西比较多。
比如库存 账户余额增减 订单修改 消息通知，对 N 多个表进行删除 更新 添加，为了保证事务的一致性都是套在一个事务里进行操作。
这样做会非法耗时感觉也不好。
如果是微服务架构做业务拆分比较合理。
如果是单体架构为了业务解耦拆分，引用事件或者队列进行业务异步处理。
但是这样就导致了事务拆分成了 N 个事物，不能保证一致性。为了保证一致性加入重试机制，这样也会导致单体架构的臃肿。
遇到这情况大家技术上如何处理比较好呢
 |
1
sivacohan 2020-08-26 17:49:19 +08:00 via iPhone
单体能解决的问题不要瞎搞。
拆解之后还想要和单体一样的事务级别，你至少要付出十倍的开发成本。 |
 |
2
Leigg 2020-08-26 18:18:06 +08:00 via Android
你遇到的就是分布式事务问题，一般常用的是对列，定时任务，最后是人工补偿，做好流水记录就行，不要思维固化就想着实现一个 [分布式事务] ，大部分场景只需要最终一致性。
|
 |
3
QZFCANBA 2020-08-26 18:42:38 +08:00
rocketmq 事务消息
|
 |
4
jones2000 2020-08-27 02:10:50 +08:00
目前最好的方法就是花钱提升数据库服务器性能， 投 10W-20W 硬件基本就完事了， 钱到位机器上线就可以搞定的，成本最低。
|
 |
5
CoderGeek 2020-08-27 10:34:40 +08:00
必须要拆分的话 异步肯定就消息队列 保证发送与重试 还有
事务强一致不现实 保证有正向反向接口 要看业务来 前提业务接收你最终一致 |
Select Language