关于分布式事务的疑问 about eshop-soa HOT 2 OPEN

from eshop-soa.

您好，首先前两个问题我也不能回答，我当时是研究了几天TCC模式，然后尝试用一个开源的实现做一个demo，结果是失败了，用不起来，另外理解起来也挺复杂的，后来就放弃了。第三个问题我不是很明白，TCC中是不依赖消息机制的吧，只需要RPC。 第四个问题答案是是的，事务消息的话，在RocketMQ源码中是Producer发送给Broker消息是重试若干次（可能是3）发送，如果全部失败，那么会抛出异常，Producer端可以另行处理。 关于分布式事务这个问题，这几种解决方案对代码侵入性都很大，设计起来也是非常复杂的。据说阿里有开源一个TXC，底层也是基于消息实现的，但是是非常透明的，用注解就可以搞定，你可以去了解一下，读一下源码啥的。 在 2018-10-26 20:54:45，"zhangyongxin" [email protected] 写道： 首先不是提bug哈，就是探讨下作者的最终一致性的实现。 1.AccountService.rollback并没在cancel阶段调用啊 2.那个阶段是cancel阶段呢？order库存扣减失败后吗？ 3.消息机制的使用不用直接调用远程dubbo接口了吧？（节选 ：扣减和增加需要实现幂等（Dubbo调用远程接口失败的话会重试）） 4.事务消息的使用时确保消息可靠送达吗？ 5.本人刚接触这块，还请不吝赐教 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

是的，TCC要求远程服务都要实现try,commit,cancel方法，对代码的侵入性高；也不需要消息组件。

基于消息的最终一致性也有个问题，虽然网上转账后通知的场景使用rocketmq的事务消息很合适。但是常规业务并非仅仅给下游服务发送消息而已啊。
往往都是向作者写的那样，如付款的业务。但是在下游服务扣减库存时如果库存不足，下游服务执行失败，但是上游扣款成功了啊。这种业务怎么回滚上游操作呢？难道还要调用上游rollback，但是业务链长的话，岂不是还像TCC那样吗？或者只能人工干预吗？
难道在本地事务中先调用下游check方法，保证库存够，才调用下游扣减操作？这样也难以确保并发失败的情况啊。所以业务check还是在下游方法做啊。

阿里的分布式事务中间件又称GTS吧，有商用过吗，开源的TXC好像也没找到官网或者工程github？

from eshop-soa.