【分库分表】企业级分库分表实战方案与详解（MySQL专栏启动）

📫作者简介：小明java问道之路，2022年度博客之星全国TOP3，专注于后端、中间件、计算机底层、架构设计演进与稳定性建设优化，文章内容兼具广度、深度、大厂技术方案，对待技术喜欢推理加验证，就职于知名金融公司后端高级工程师。

        

📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。

        

🏆 2022博客之星TOP3 | CSDN博客专家 | 后端领域优质创作者 | CSDN内容合伙人

🏆 InfoQ(极客邦)签约作者、阿里云专家 | 签约博主、51CTO专家 | TOP红人、华为云享专家

        

🔥如果此文还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主~ 

---

🍅 文末获取联系 🍅  👇🏻 精彩专栏推荐订阅收藏 👇🏻

专栏系列（点击解锁）	学习路线（点击解锁）	知识定位
🔥Redis从入门到精通与实战🔥	Redis从入门到精通与实战	围绕原理源码讲解Redis面试知识点与实战
🔥MySQL从入门到精通🔥	MySQL从入门到精通	全面讲解MySQL知识与企业级MySQL实战
🔥计算机底层原理🔥	深入理解计算机系统CSAPP	以深入理解计算机系统为基石，构件计算机体系和计算机思维
	Linux内核源码解析	围绕Linux内核讲解计算机底层原理与并发
🔥数据结构与企业题库精讲🔥	数据结构与企业题库精讲	结合工作经验深入浅出，适合各层次，笔试面试算法题精讲
🔥互联网架构分析与实战🔥	企业系统架构分析实践与落地	行业最前沿视角，专注于技术架构升级路线、架构实践
	互联网企业防资损实践	互联网金融公司的防资损方法论、代码与实践
🔥Java全栈白宝书🔥	精通Java8与函数式编程	本专栏以实战为基础，逐步深入Java8以及未来的编程模式
	深入理解JVM	详细介绍内存区域、字节码、方法底层，类加载和GC等知识
	深入理解高并发编程	深入Liunx内核、汇编、C++全方位理解并发编程
	Spring源码分析	Spring核心七IOC/AOP等源码分析
	MyBatis源码分析	MyBatis核心源码分析
	Java核心技术	只讲Java核心技术

本文目录

本文目录

本文导读

一、企业级分库分表生产实践方案

1、分库分表重难点分析

2、架构设计图

二、分库分表架构分析

1、数据库源迁移配置

1.1、数据路由

1.2、数据源配置

2、全量+增量同步复制方案

3、校验数据定时任务方案

三、分库分表技术方案

1、Client模式（客户端直连）

2、Proxy模式（中间层）

总结

---

本文导读

本文是真实百亿级数据分库分表生产实践方案脱敏后的详解，第一部分分析分库分表重难点，给出总架构设计图，第二部分是分库分表架构分析，暴扣数据库源迁移配置、数据路由、数据源配置、全量+增量同步复制及重试方案、校验数据定时任务方案，最后一部分是介绍分库分表技术方案客户端直连和MyCat中间层。

一、企业级分库分表生产实践方案

1、分库分表重难点分析

通常，生产环境数据库的架构是经过时间和业务迭代之后形成的，当从一组单数据库和表迭代到分库分表时，需要注意许多因素。

1、如果跑的是如果是单库单表的数据库，代码对应的也是单库单表，部署一套分库分表的数据库环境，就需要每台服务器上装一个 mysql 实例，每个 mysql 实例里创建一个库，每个库建一堆的表。

2、分库分表的数据库是空的，以及如何迁移历史中的所有数据的问题，如果十亿级表中有大量历史数据，并且仍在更新，那么如何将单个数据库和单个表中的全部历史数据完全复制到子数据库和子表环境中（完全同步+增量同步）。数据在复制过程中仍在变化。有必要将完整复制过程中发生变化的数据与增量复制同步。为了确保完全一致性，还需要进行完整的数据验证

3、如何将单库单表老数据库下线掉，每个迁库的需求，经常会有新老数据库一起使用的情况。

4、如何把已有的数据分散到分库里去呢，分库分表数据扩容这个过程应该怎么来做。

2、架构设计图

针对以上问题这里给出架构设计图，如下：

二、分库分表架构分析

1、数据库源迁移配置

1.1、数据路由

原数据库单库单表不需要进行数据库分片路由，目标数据库（分库分表）需要根据一定的字段，决定如何路由到那个分库的表里，一般情况下10-100个库的方案会根据 用户ID、订单ID已经某些业务ID的后1~2位进行路由。

1.2、数据源配置

请参考：【MySQL】MyCat分库分表分片规则配置详解与实战（MySQL专栏启动）、【MySQL】MyCAT三大配置文件详解（MySQL专栏启动）、【MySQL】高性能高可用表设计实战-表设计篇（MySQL专栏启动）

2、全量+增量同步复制方案

一般数据同步使用全量同步+增量同步的方式，JOB调度系统（ElasticJob）发起一个数据同步任务，把历史数据同步和写入到分库分表环境里去，在这个过程中，单库单表中的数据还会不断的增删改操作，同步的执行增量数据复制，全量数据复制的过程中，还得把数据变更增量复制，等某个时间点，单库单表数据和分库分表的数据，是保持一致和同步，将老库下线。

1、存量数据，这种方案需要后续删除非对应分片的数据，风险较大。

2、业务双写，是存量数据全量导入分库，增量数据通过业务系统双写到原库和分库中从而达到一致，由业务系统实现双写。

业务双写分为3步：一同步写老库，异步写分库（查询查单库，以老库为准校对新库中的老数据），二、同步写老库，同步写新库（查询查分库），三、此时如果没问题，二、同步写新库、下线分库（查询查分库）

3、等某个时间单库单表数据和分库分表的数据保持一致和同步，将老库下线。

3、校验数据定时任务方案

对批次内（迁移任务表）的内先获取老库的一批数据，再获取新库的一批数据，对数据进行核对校验，对数据进行归正处理，完成数据核对校验更改状态（迁库明细表校验位），如果数据核对失败，记录数据核对错误信息。

三、分库分表技术方案

建议是选择 Proxy模式 中间层集中管理监控，并且无代码侵入，推荐中间件MyCAT。

1、Client模式（客户端直连）

Client模式，客户端直连方案，无需中间层相对轻便、无额外成本、性能相对较好，但是支持的语言相对单一且代码侵入强，例如TDDL、sharding-jdbc、Cobar-Client

2、Proxy模式（中间层）

Proxy模式，在应用程序和MySQL之间搭建一层Proxy。中间层介于应用程序与数据库间，需要做一次转发，直接由应用程序连接数据库，性能上有些许优势，这里并非中间层一定不如客户端直连，除了性能，需要考虑的因素还有很多，中间层更便于实现监控、数据迁移、连接管理等功能。例如阿里cobar、MyCAT、MySQL-Proxy、Amoeba for MySQL、Atlas（360）。

总结

本文是真实百亿级数据分库分表生产实践方案脱敏后的详解，第一部分分析分库分表重难点，给出总架构设计图，第二部分是分库分表架构分析，暴扣数据库源迁移配置、数据路由、数据源配置、全量+增量同步复制及重试方案、校验数据定时任务方案，最后一部分是介绍分库分表技术方案客户端直连和MyCat中间层。