• 微服务--数据一致性


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

    一、案例

    在使用微服务时,存在跨多个服务更新数据库数据的情况。那么这就会出现一个问题,比如我们有三个服务(如下图),正常情况下,当一个请求进来时,服务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服务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

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

    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. 在异步任务阶段,将批量相应的回滚记录。
    小结

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

  • 相关阅读:
    使用华为eNSP组网试验⑸-访问控制
    Codeforces Round 895 (Div. 3) C. Non-coprime Split
    java计算机毕业设计健康医疗预约系统MyBatis+系统+LW文档+源码+调试部署
    怎么才能写好宣传软文?媒介盒子为你揭秘
    前端入门学习笔记四十五
    【面试】IO多路复用
    pkl文件与打开(使用numpy和pickle)
    Vue3+Ts+Vite项目(第十二篇)——echarts安装与使用,vue3项目echarts组件封装
    pandas读取文件
    第9章 Apache-Dbutils实现CRUD操作
  • 原文地址:https://blog.csdn.net/gangzhucoll/article/details/126817202