微服务--数据一致性

本篇文章讲解微服务数据一致性相关的知识

一、案例
在使用微服务时，存在跨多个服务更新数据库数据的情况。那么这就会出现一个问题，比如我们有三个服务（如下图），正常情况下，当一个请求进来时，服务1到服务3会分别改变其数据库中存储的数据，但是如果出现部分服务网络不通或者部分服务失效的情况，那么整个服务调用链就会失效，进而出现部分服务更新数据库成功，而剩余服务更新数据库失败的情况，这就出现了所谓了数据不一致。

在我们实际项目中只要涉及数据一致性的问题，就可以分为两种情况：

可实时数据不一致，但最终数据必须一致（最终一致性）
实时数据必须一致
针对这两种情况我们分别来看一下如何解决。

二、最终一致性
要解决这个问题，最好的办法是引入MQ，思路如下：

每个步骤完成后，就生成一条消息发送到MQ中，告知开始进行下一步处理；
消费者收到消息后，开始进行处理，处理完成后同样生成一条消息发送给MQ；
如果消费者处理失败，那么这条消息就保留，直到下次重试成功为止；
一图胜千言，简要图示如下：

客户端调用服务1，服务1修改数据库，然后生成消息1发送给MQ，服务1向客户端返回成功信息；
服务2监听到消息1后，修改数据库，然后生成消息2发送给MQ，最后将消息1设置为已消费；
服务3监听到消息2后，修改数据库，然后将消息2设置为已消费。
上面这三个步骤是在理想情况下才会出现的，但是在实际情况中可能会出现部分服务不可用的情况，那么该怎么解决呢？我们来说一下。

编号    问题    解决方法
1    服务1不可用    直接返回失败信息给客户端
2    服务1可用，但修改修改数据库失败    利用本地事务回滚数据，并向客户端返回失败信息
3    服务1可用，数据库也修改成功了，但是给MQ发送消息失败    利用本地事务将数据回滚，并向客户端返回失败信息
4    服务1返回客户端信息失败    不处理
5    服务2监听消息1失败    利用MQ机制，不需要特意处理
6    服务2修改数据库失败    利用本地事务回滚数据在利用消息重试的特性重新从第5步开始
7    服务2将生成的消息2发送给MQ失败    MQ有生成消息失败的重试机制，不需要特意处理，即是说服务其崩溃了也没问题，因为消息1还没被标记为已消费，因此可以由其他消费者重新从第5步骤开始执行
8    服务2将消息1标记为已消费失败    MQ有重试机制，会找另一个消费者重新从第5步骤开始
9    服务3监听消息2失败    同步骤5
10    服务3修改数据库失败    同步骤6
11    服务3将消息2标记为已消费失败    同步骤8
上面的解决方案看似完美，其实存在两个问题：

方案利用了MQ的重试机制，因此在步骤6和步骤10重复执行的情况下， 有可能出现重复数据，因此在下游步骤执行时需要保业务代码的幂等性‘
存在大量的重复代码，因此需要将MQ相关的业务代码抽出来做成一个公共代码。
三、实时一致性
实时一致性，就是所谓的分布式事务，常用的方案有TCC模式和AT模式

3.1 TCC模式
TCC模式会把一个接口拆分成三个接口：

Try接口：检查数据、预留业务资源（）；
Confirm接口：确认实际业务操作、更新业务资源；
Cancel接口：释放Try接口中预留的资源（回滚数据）。
这个解决方案核心就是如果在执行业务代码的过程中出现了异常/错误，需要手动调用回退方法。它将原本只需要在一个接口里写的回退方法，分布到了三个阶段，因此需要注意以下问题：

要保证每个服务的Try接口执行成功后，Confirm接口在业务逻辑上也能执行成功；
如果Try接口执行失败，一定要保证Cancel接口执行成功，正确回滚；
如果因为网络堵塞导致Try接口执行超时并触发了Cancel接口的功能，那么在后续Try接口执行到服务时应该予以拒绝；
三个接口必须保证幂等性；
因为在整个事务期间数据库一致处于临界状态，因此其他请求数据时要考虑如何正确返回数据。
3.2 AT模式
AT模式，就是所谓的自动回滚，他就比较简单的，对于支持该模式的框架来说只需在代码上引入注解即可。AT模式的执行步骤大致如下：

解析并记录每个服务执行的SQL和SQL类型，修改表并更新SQL条件等；
根据上一步的条件信息生成查询语句，并记录修改前的数据镜像；
执行业务SQL；
记录修改后的数据镜像；
插入回滚日志，将前后镜像数据和业务SQL组合成日志插入到回滚日志中；
提交前向TC注册分支，并申请修改数据行的全局锁；
将业务数据的更新和第五步生成的回滚日志一起向本地事务提交；
本地事务将提交结果上报事务管理器；
如果需要回滚，事务管理器回发送发出分支回滚请求，并开启一个本地事务；
查找回滚日志记录；
数据校验，对比回滚日志记录中后镜像数据是否和当前数据一致，如果不一致就说明数据已被修改，这时具体该怎么做就由配置的策略来决定了；
根据回滚日志中的前镜像数据和业务SQL等相关信息生成回滚语句并执行；
把执行结果提交给事务管理器；
事务管理器发出分支提交请求，将请求放入异步任务队列里；
在异步任务阶段，将批量相应的回滚记录。
小结
解决数据一致性，就是这么简单。