微服务进阶场景实战：最终一致性与实时一致性解决方案如何设计？( 二 ) _微服务

4）Service A返回成功信息给调用端。
解决方案：不用处理。
5）Service B监听Step2的消息，获得一条消息。
解决方案：如果这一步失败，MQ有对应机制，无须担心。
6）Service B将数据库中的b1改为b2 。
解决方案：如果这一步失败，则利用本地事务直接将数据回滚，再利用消息重试的特性重新回到步骤5）。
7）Service B生成一条步骤3）（Step3）的消息给MQ 。
解决方案：如果这一步失败，MQ有生产消息失败重试机制。若出现极端情况，服务器会直接崩溃，因为Step2的消息还没有消费，MQ会有重试机制，然后找另一个消费者重新从步骤5）执行。
8）Service B将Step2的消息设置为已消费。
解决方案：如果这一步失败，MQ会有重试机制，找另一个消费者重新从步骤5）执行。
9）Service C监听Step3的消息，获得一条消息。
解决方案：参考步骤5）的解决方案。
10）Service C将数据库中的c1改为c2 。
解决方案：参考步骤6）的解决方案。
11）Service C将Step3的消息设置为已消费。
解决方案：参考步骤8）的解决方案。
以上就是最终一致性的解决方案，这个方案还有两个问题。
1）因为利用了MQ的重试机制，所以有可能出现步骤6）和步骤10）重复执行的情况，此时该怎么办？比如，上面流程中的步骤8）如果失败了，就会从步骤5）重新执行，这时就会出现步骤6）执行两遍的情况。为此，在下游（步骤6）和步骤10））更新数据时，需要保证业务代码的幂等性（关于幂等性，在第1章提过）。
2）如果每个业务流程都需要这样处理，岂不是需要额外写很多代码？那是否可以将类似流程的重复代码抽取出来？答案是可以，这里使用的MQ相关逻辑在其他业务流程中也通用，这个项目最终就是将这些代码抽取出来并进行了封装。因为重复代码抽取的方法比较简单，这里就不展开了。
实时一致性方案
实时一致性其实就是常说的分布式事务。
MySQL其实有一个两阶段提交的分布式事务方案MySQL XA，但是该方案存在严重的性能问题。比如，一个数据库的事务与多个数据库间的XA事务性能可能相差10倍。另外，XA的事务处理过程会长期占用锁资源，所以项目组一开始就没有考虑这个方案。
而当时比较流行的方案是使用TCC模式，下面简单介绍一下。
TCC模式
在TCC模式中，会把原来的一个接口分为Try接口、Confirm接口、Cancel接口。
1）Try接口：用来检查数据、预留业务资源。
2）Confirm接口：用来确认实际业务操作、更新业务资源。
3）Cancel接口：是指释放Try接口中预留的资源。
比如在积分兑换折扣券的例子中，需要调用账户服务减积分（步骤1）、营销服务加折扣券（步骤2）这两个服务，那么针对账户服务减积分这个接口，需要写3个方法，代码如下所示。

文章插图

同样，针对营销服务加折扣券这个接口，也需要写3个方法，而后调用的大体步骤如图13-3所示。

文章插图
• 图13-3 账户和营销服务TCC处理流程
图13-3中，除Cancel步骤以外的步骤，代表成功的调用路径，如果中间出错，则去调用相关服务的回退（Rollback）方法进行手工回退。该方案原来只需要在每个服务中写一段业务代码，而现在需要分成3段来写，而且还涉及一些注意事项。
1）需要保证每个服务的Try方法执行成功后，Confirm方法在业务逻辑上能够执行成功。
2）可能会出现Try方法执行失败而Cancel被触发的情况，此时需要保证正确回滚。
3）可能因为网络拥堵而出现Try方法调用被堵塞的情况，此时事务控制器判断Try失败并触发了Cancel方法，之后Try方法的调用请求到了服务这里，应该拒绝Try请求逻辑。
4）所有的Try、Confirm、Cancel都需要确保幂等性。
5）整个事务期间的数据库数据处于一个临时的状态，其他请求需要访问这些数据时，需要考虑如何正确被其他请求使用，而这种使用包括读取和并发的修改。
所以，TCC模式是一个实施起来很麻烦的方案，除了每个业务代码的工作量乘3之外，还需要通过相应逻辑应对上面的注意事项，这样出错的概率就太高了。
后来，笔者在一篇介绍Seata的文章中了解到AT模式也能解决这个问题。
Seata中AT模式的自动回滚
自动回滚对于使用Seata的人来说操作比较简单，只需要在触发整个事务的业务发起方的方法中加入@GlobalTransactional标注，并且使用普通的@Transactional包装好分布式事务中相关服务的相关方法即可。