设计一个分布式事务的场景，假如说你开一个qq会员，然后你发起交易，支付，扣款，发邮件。
猜想一：这四个步骤是否可以利用分布式事务去实现，彼此之间通过一个接口去进行认可和否认，保证原子性，因为彼此还是同步操作的，所以嵌套一个TCC的行为，全局保证同步操作，完成一个支付订单的流程。
但是既然是同步操作，必然在性能上会慢一些，那么换一种架构的思路。
猜想二：我们中间不用接口去完成彼此之间的confirm和cancel操作，我们用消息队列，不同的微服务之间去从消息队列中消费信息，当信息显示为cancel，则立刻显示一条message，除非是一路都为confirm操作，才可以完成这项流程，但是这个又会产生一个问题，如果是异步操作，就必然会导致无法最终一致性，比如说，我开一个qq会员，我已经开通了几分钟了，然后最后显示我开通成功的消息才发过来。
所以由此可见，猜想二只能用作对最终一致性要求不高的场景
但不管是猜想一还是猜想二，都是在分布式事务的场景内，那么，我们就都会有主从业务，一般来说，都是一开始会访问的当做我们的主要业务，只有的都是从业务，这个开会员，发起交易就是所说的主业务。
猜想三：假如说，我们开会员的某个步骤，例如说是扣款，这个操作很费时间，当然，我也只是随便去说，如果很费时间导致阻塞的话，我们是否可以进行一个回滚的操作。比如说，我们当身份认证等等信息，账户余额也查过了都ok了，然后我们先去给他开会员，然后再去扣款，但是假如说，会员可以去取消服务，那么我们就直接进行假回滚，写一个接口，在取消的时候，自动调用回滚的操作，让全部的行为进行回滚。
当然，qq会员肯定不会用猜想3的，这个大家也知道，不过我个人感觉，猜想3也可以利用一些在其他的业务场景上。
标签：qq,回滚,猜想,问题,同步操作,会员,扣款 来源： https://blog.csdn.net/qq_41936805/article/details/104858144
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。