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

数据一致性

前面总结了微服务的9个痛点，有些痛点没有好的解决方案，而有些痛点是有对策的，从本章开始，就来讲解某些痛点对应的解决方案。

这一章先解决数据一致性的问题，先来看一个实际的业务场景。

业务场景：下游服务失败后上游服务如何独善其身

前面讲过，使用微服务时，很多时候需要跨多个服务去更新多个数据库的数据，架构如图13-1所示。

• 图13-1 微服务上下游示意图

如图13-1所示，如果业务正常运转，3个服务的数据应该分别变为a2、b2、c2，此时数据才一致。但是如果出现网络抖动、服务超负荷或者数据库超负荷等情况，整个处理链条有可能在步骤2失败，这时数据就会变成a2、b1、c1；当然也有可能在步骤3失败，最终数据就会变成a2、b2、c1。这样数据就出错了，即数据不一致。

在本章所讨论的项目开始之前，因为之前的改造项目时间很紧，所以开发人员完全没有精力处理系统数据一致性的问题，最终业务系统出现了很多错误数据，业务部门发工单告知IT部门数据有问题，经过一番检查后，IT部门发现是因为分布式更新的原因导致了数据不一致。

此时，IT部门不得不抽出时间针对数据一致性问题给出一个可靠的解决方案。通过讨论，IT部门把数据一致性的问题归类为以下两种情况。

1.实时数据不一致可以接受，但要保证数据的最终一致性

因为一些服务出现错误，导致图13-1中的步骤3失败，此时处理完请求后，数据就变成了a2、b2、c1，不过没关系，只需保证最终数据是a2、b2、c2即可。

在以往的一个项目中，业务场景是这样的（示例有所简化）：零售下单时，一般需要实现在商品服务中扣除商品的库存、在订单服务中生成一个订单、在交易服务中生成一个交易单这3个步骤。假设交易单生成失败，就会出现库存扣除、订单生成，但交易单没有生成的情况，此时只需保证最终交易单成功生成即可，这就是最终一致性。

2.必须保证实时一致性

如果图13-1中的步骤2和步骤3成功了，数据就会变成b2、c2，但是如果步骤3失败，那么步骤1和步骤2会立即回滚，保证数据变回a1、b1。

在以往的一个项目中，业务场景类似这样：用户使用积分兑换折扣券时，需要实现扣除用户积分、生成一张折扣券给用户这两个步骤。如果还是使用最终一致性方案的话，有可能出现用户积分扣除而折扣券还未生成的情况，此时用户进入账户发现积分没有了，也没有折扣券，就会马上投诉。

那怎么办呢？直接将前面的步骤回滚，并告知用户处理失败请继续重试即可，这就是实时一致性。

针对以上两种情况，具体解决方案是什么呢？下面一起来看看。

最终一致性方案

对于数据要求最终一致性的场景，实现思路是这样的。

1）每个步骤完成后，生产一条消息给MQ，告知下一步处理接下来的数据。

2）消费者收到这条消息，将数据处理完成后，与步骤1）一样触发下一步。

3）消费者收到这条消息后，如果数据处理失败，这条消息应该保留，直到消费者下次重试。

将3个服务的整个调用流程走下来，逻辑还是比较复杂的，整体流程如图13-2所示。

• 图13-2 服务调用流程

详细的实现逻辑如下。

1）调用端调用Service A。

2）Service A将数据库中的a1改为a2。

3）Service A生成一条步骤2（暂且命名为Step2）的消息给MQ。

4）Service A返回成功信息给调用端。

5）Service B监听Step2的消息，获得一条消息。

6）Service B将数据库中的b1改为b2。

7）Service B生成一条步骤3（暂且命名为Step3）的消息给MQ。

8）Service B将Step2的消息设置为已消费。

9）Service C监听Step3的消息，获得一条消息。

10）Service C将数据库中的c1改为c2。

11）Service C将Step3的消息设置为已消费。

接下来要考虑，如果每个步骤失败了该怎么办？

1）调用端调用Service A。

解决方案：直接返回失败信息给用户，用户数据不受影响。

2）Service A将数据库中的a1改为a2。

解决方案：如果这一步失败，就利用本地事务数据直接回滚，用户数据不受影响。

3）Service A生成一条步骤2）（Step2）的消息给MQ。

解决方案：如果这一步失败，就利用本地事务数据将步骤2）直接回滚，用户数据不受影响。

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包装好分布式事务中相关服务的相关方法即可。

对于Seata的内在机制，AT模式的自动回滚往往需要执行以下步骤（分为3个阶段）。

阶段1

1）解析每个服务方法执行的SQL，记录SQL的类型（Update、Insert或Delete），修改表并更新SQL条件等信息。

2）根据前面的条件信息生成查询语句，并记录修改前的数据镜像。

3）执行业务的SQL。4）记录修改后的数据镜像。

5）插入回滚日志：把前后镜像数据及业务SQL相关的信息组成一条回滚日志记录，插入UNDOLOG表中。

6）提交前，向TC注册分支，并申请相关修改数据行的全局锁。

7）本地事务提交：业务数据的更新与前面步骤生成的UNDOLOG一并提交。

8）将本地事务提交的结果上报给事务控制器。

阶段2

收到事务控制器的分支回滚请求后，开启一个本地事务，执行如下操作。

1）查找相应的UNDOLOG记录。

2）数据校验：将UNDOLOG中的后镜像数据与当前数据进行对比，如果存在不同，说明数据被当前全局事务之外的动作做了修改，此时需要根据配置策略进行处理。

3）根据UNDOLOG中的前镜像数据和业务SQL的相关信息生成回滚语句并执行。

4）提交本地事务，并把本地事务的执行结果（即分支事务回滚的结果）上报事务控制器。

阶段3

1）收到事务控制器的分支提交请求后，将请求放入一个异步任务队列

中，并马上返回提交成功的结果给事务控制器。

2）异步任务阶段的分支提交请求将异步、批量地删除相应的UNDOLOG记录。

以上就是Seata AT模式的简单介绍。

尝试Seata

当时，虽然Seata还没有更新到1.0，且官方也不推荐线上使用，但是项目组最终还是使用了它，原因如下。

1）因为实时一致性的场景很少，而且发生频率低，所以并不会大规模使用，影响面在可控范围内。如果实时一致性的场景发生频率高，并发量就高，业务人员对性能的要求也高，此时就会与业务沟通，采用最终一致性的方案。

2）Seata AT模式与TCC模式相比，只有增加一个@GlobalTransactional的工作量，因此两者的工作量相差很多，也就是说，对项目组来说，投入产出比更高，值得冒险。这可能也是Seata发展很快的原因之一。

虽然Seata AT模式有些小缺陷，但是瑕不掩瑜。

小结

最终一致性与实时一致性的解决方案设计完成后，不仅没有给业务开发人员带来额外工作量，也没有影响业务项目进度的日常推进，还大大减少了数据不一致的出现概率，因此数据不一致的痛点得到了较大缓解。