分库分表后，数据库数据一致性问题如何解决？

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

• 原创 | Java 2021 超神之路，很肝~
• 中文详细注释的开源项目
• RPC 框架 Dubbo 源码解析
• 网络应用框架 Netty 源码解析
• 消息中间件 RocketMQ 源码解析
• 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析
• 作业调度中间件 Elastic-Job 源码解析
• 分布式事务中间件 TCC-Transaction 源码解析
• Eureka 和 Hystrix 源码解析
• Java 并发源码

来源：juejin.cn/post/

6933003178661462023

• 前言
• 数据迁移
• 分布式事务
• 总结

前言

通过对数据的垂直拆分或水平拆分后，我们解决了数据库容量、性能等问题，但是将会面临数据迁移和数据一致性的问题。 在数据迁移方面，需要考虑如何快速迁移、平滑迁移、不停机的迁移等。待数据迁移完毕后，还需要校验数据的完整性。 数据一致性方面，要根据的业务来判断是否要必要引入分布式事务，如果需要引入分布式事务，需要斟酌是采用XA，还是基于BASE的柔性事务。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

数据迁移

数据迁移是很容易出故障的一个环节，需要考虑怎么更加平滑的迁移旧数据到新的数据库和系统，以及达到数据准确、快速迁移、减少停机、对业务的影响小等，特别是异构的数据结构情况下，难度更大。

全量

全量迁移的过程如下：

• 业务系统停机。
• 数据库迁移，校验数据一致性。
• 然后业务系统升级，接入新的数据库。

缺点：

• 需要业务系统停机
• 迁移时间较长，对业务影响较大。如果是异构数据的话，需要使用程序来处理，迁移时间更长。

全量+增量

全量+增量迁移的方式，需要依赖数据本身的创建时间，步骤如下：

• 先同步数据到最近的某个时间戳（创建时间）。
• 然后发布系统升级维护的通知。
• 然后同步最近一段时间变化的数据。
• 最后升级系统，接入新的数据库。

全量+增量的同步相比全量同步的方式，大大的减少了系统停机的时间，对业务影响较小。

binlog+全量+增量

binlog+全量+增量是通过从数据库的主库或者从库解析和重新构造数据，实现复制。

通常情况下都需要中间件等工具的支持，一般需要中间件等工具的支持。可以实现多线程、断点续传、全量和增量数据的同步，还可以实现自动扩容和缩容。

常见的工具有：Canal、ShardingSphere-scaling等

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://gitee.com/zhijiantianya/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

分布式事务

XA分布式事务

XA分布式事务，是数据库本身支持的协议，具备强一致性。

XA分布式事务的组件：

• 应用程序(Application Program, 简称AP): 用于定义事务边界，即事务的开始和结束，并且在事务边界内对资源进行操作。
• 资源管理器(Resource Manager, 简称RM): 如数据库、文件系统，并且提供访问资源的方式。
• 事务管理器(Transaction Manager, 简称TM): 负责分配事务唯一标识，监控事务的执行进度，并且负责事务的提交、回滚等。

XA接口:

• xa_start 负责开启或者恢复一个事务分支
• xa_end 负责取消当前线程与事务分支的关联
• xa_prepare 询问RM是否准备好提交事务分支
• xa_commit 通知RM提交事务分支
• xa_rollback 通知RM回滚事务分支
• xa_recover 需要恢复的XA事务

MySQL从5.0.3开始支持InnoDB引擎的XA分布式事务。

完整的XA事务处理流程如下:

主流的XA框架有：Atomikos、Narayana、Seata

XA分布式事务存在的问题：

• 同步阻塞：全局事务包含了多个独立的事务分支，这一组事务分支要么都不成功，要不都失败，各个分支的ACID特性共同构成了全局事务的ACID特性。如果对读操作很敏感，需要将数据库的隔离级别设置为SERIALIZABLE，性能特别的差。
• 单点故障：TM存在单点故障，需要考虑TM高可用性。
• 数据不一致：极端情况下，会出现事务失败问题，需要监控和人工处理。即二阶段commit请求后，发送网络故障，只有一部分RM收到请求，其他节点没有收到Commit请求的情况。

柔性事务

BASE的核心在于，保证系统基本可用的前提下，通过利用柔性状态(支付操作后不是支付成功，而是支付中状态)，实现数据的最终一致性，如下：

• 基本可用(Basically available)，分布式事务参与方不一定同时在线。
• 柔性状态(Soft state), 允许系统状态更新有一定的延迟，出现一些中间状态，这个延迟对客户来说不一定能够察觉。
• 最终一致性(Eventually consistent)，通常是通过消息传递的方式保证系统的最终一致性。

柔性事务核心理念是通过业务逻辑将互斥锁操作从RM层上升到业务层，通过放宽对强一致性的要求，来换取系统吞吐量的提升。

BASE柔性事务常见模式

• TCC: 通过手动补偿处理
• AT: 通过自动补偿处理

TCC介绍

TCC模式即将每个服务业务操作分成两个阶段，第一个阶段检查并预留相关资源，第二个阶段根据所有服务业务的try状态来操作，如果都成功，则进行Confirm操作，如果任意一个Try发送错误，则全部Cancel。

• Try：准备操作，完成所有的业务检查，预留业务资源。
• Confirm：真正执行的业务逻辑，不做任意的业务检查，只使用Try阶段预留的业务资源。因此Try操作成功，Confirm必须能成功。同时，Confirm操作必须保证冥等性，保证一笔分布式事务能切只能成功一次。
• Cancel：释放Try阶段预留的业务资源，同样Cancel操作也必须满足冥等性。

TCC模型实际是通过业务分解来实现分布式事务，对业务有较强的侵入性。

TCC模型需要注意的地方:

• 允许空回滚，即try没有完成资源预留，允许短路操作。
• 防悬挂控制，即需要保证，cancel必须在try之后才执行。
• 冥等性设计，即需要保证confirm和cancel需要保证冥等性，防止网络因素导致数据混乱。

AT

AT模式就是两阶段提交，自动生成反向SQL，当发生异常的时候，通过反向SQL回滚数据。

Seata框架对AT的支持如下:

• 第一阶段，业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 第二阶段，提交异步化，非常快速的完成，回滚的话通过一阶段的回滚日志进行反向补偿。

柔性事务下的事务特性

• 原子性：正常情况下保证
• 一致性：某个时间点，数据存在不一致，但是最终是一致的。
• 隔离性：某个时间点，A能读到B事务未提交的结果，即会脏读现象。
• 持久性：和本地事务一样，只要commit则数据就会被持久化。

总结

分布式事务主要目的是解决数据一致性问题，XA强一致，但是吞吐量太低，不利于高并发场景。柔性事务不保证强一致性，但是通过补偿实现最终一致性，常见的补偿有重试补偿、调度补偿、人工补偿等。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。谢谢支持哟 (*^__^*）