微服务--数据一致性

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

一、案例

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

在这里插入图片描述

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

1. 可实时数据不一致，但最终数据必须一致（最终一致性）
2. 实时数据必须一致

针对这两种情况我们分别来看一下如何解决。

二、最终一致性

要解决这个问题，最好的办法是引入MQ，思路如下：

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

一图胜千言，简要图示如下：

在这里插入图片描述

1. 客户端调用服务1，服务1修改数据库，然后生成消息1发送给MQ，服务1向客户端返回成功信息；
2. 服务2监听到消息1后，修改数据库，然后生成消息2发送给MQ，最后将消息1设置为已消费；
3. 服务3监听到消息2后，修改数据库，然后将消息2设置为已消费。

上面这三个步骤是在理想情况下才会出现的，但是在实际情况中可能会出现部分服务不可用的情况，那么该怎么解决呢？我们来说一下。

上面的解决方案看似完美，其实存在两个问题：

1. 方案利用了MQ的重试机制，因此在步骤6和步骤10重复执行的情况下， 有可能出现重复数据，因此在下游步骤执行时需要保业务代码的幂等性‘
2. 存在大量的重复代码，因此需要将MQ相关的业务代码抽出来做成一个公共代码。

三、实时一致性

实时一致性，就是所谓的分布式事务，常用的方案有TCC模式和AT模式

3.1 TCC模式

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

1. Try接口：检查数据、预留业务资源（）；
2. Confirm接口：确认实际业务操作、更新业务资源；
3. Cancel接口：释放Try接口中预留的资源（回滚数据）。

这个解决方案核心就是如果在执行业务代码的过程中出现了异常/错误，需要手动调用回退方法。它将原本只需要在一个接口里写的回退方法，分布到了三个阶段，因此需要注意以下问题：

1. 要保证每个服务的Try接口执行成功后，Confirm接口在业务逻辑上也能执行成功；
2. 如果Try接口执行失败，一定要保证Cancel接口执行成功，正确回滚；
3. 如果因为网络堵塞导致Try接口执行超时并触发了Cancel接口的功能，那么在后续Try接口执行到服务时应该予以拒绝；
4. 三个接口必须保证幂等性；
5. 因为在整个事务期间数据库一致处于临界状态，因此其他请求数据时要考虑如何正确返回数据。

3.2 AT模式

AT模式，就是所谓的自动回滚，他就比较简单的，对于支持该模式的框架来说只需在代码上引入注解即可。AT模式的执行步骤大致如下：

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

小结

解决数据一致性，就是这么简单。