猜想问题(一)

设计一个分布式事务的场景，假如说你开一个qq会员，然后你发起交易，支付，扣款，发邮件。

猜想一：这四个步骤是否可以利用分布式事务去实现，彼此之间通过一个接口去进行认可和否认，保证原子性，因为彼此还是同步操作的，所以嵌套一个TCC的行为，全局保证同步操作，完成一个支付订单的流程。

但是既然是同步操作，必然在性能上会慢一些，那么换一种架构的思路。

猜想二：我们中间不用接口去完成彼此之间的confirm和cancel操作，我们用消息队列，不同的微服务之间去从消息队列中消费信息，当信息显示为cancel，则立刻显示一条message，除非是一路都为confirm操作，才可以完成这项流程，但是这个又会产生一个问题，如果是异步操作，就必然会导致无法最终一致性，比如说，我开一个qq会员，我已经开通了几分钟了，然后最后显示我开通成功的消息才发过来。

所以由此可见，猜想二只能用作对最终一致性要求不高的场景

但不管是猜想一还是猜想二，都是在分布式事务的场景内，那么，我们就都会有主从业务，一般来说，都是一开始会访问的当做我们的主要业务，只有的都是从业务，这个开会员，发起交易就是所说的主业务。

猜想三：假如说，我们开会员的某个步骤，例如说是扣款，这个操作很费时间，当然，我也只是随便去说，如果很费时间导致阻塞的话，我们是否可以进行一个回滚的操作。比如说，我们当身份认证等等信息，账户余额也查过了都ok了，然后我们先去给他开会员，然后再去扣款，但是假如说，会员可以去取消服务，那么我们就直接进行假回滚，写一个接口，在取消的时候，自动调用回滚的操作，让全部的行为进行回滚。

当然，qq会员肯定不会用猜想3的，这个大家也知道，不过我个人感觉，猜想3也可以利用一些在其他的业务场景上。

标签：qq,回滚,猜想,问题,同步操作,会员,扣款
来源： https://blog.csdn.net/qq_41936805/article/details/104858144