分布式架构的事务怎么管控
大家好，我们最近在弄一个项目，采用的是dubbo交互，前后端分离，现在问题是，有可能一个业务需要调用多个后端，怎么样才能做到下一个后端异常了，把上一个后端的回滚呢。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
大家好，我们最近在弄一个项目，采用的是dubbo交互，前后端分离，现在问题是，有可能一个业务需要调用多个后端，怎么样才能做到下一个后端异常了，把上一个后端的回滚呢。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（10）
感谢，我也感觉是我用的方法不对
对你来说是误解的。
阿里巴巴是最终一致性，
一些公司会把，这些业务，合拼到一个事务中，或者 调节控制流程
Dubbo分布式事务处理教程，有兴趣可关注：
http://www.roncoo.com/course/view/7ae3d7eddc4742f78b0548aa8bd9ccdb
嗯，你说的第二点我能理解，就是有一个中间状态，所有完成之后再把数据置为生效状态。
1. 如果是需要事务处理的请求，就把多个后端封装成一个后端供前端调用，事务在这一个后端中处理就可以了。
2. 使用redis，把状态写在redis中
但是是不同的JVM，每个JVM的事务时独立的啊
用mqtt，每个后端都订阅业务处理处理，监听到所有都处理完了再放回，否则不返回
JTA是针对不同的数据库，我的是不同的应用
你说的这个就是楼上说的方案。不错，我研究一下，谢谢
目前比较多的解决方案有几个：
一、结合MQ消息中间件实现的可靠消息最终一致性
二、TCC补偿性事务解决方案
三、最大努力通知型方案
第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态
第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。
TRYING阶段主要是对业务系统进行检测及资源预留
CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。
CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。
第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不再通知。
具体的案例你也可以参考下这篇博客，它上面有完整的电商系统分布式事务实现案例：http://www.roncoo.com/article/detail/124243