怎么进行分库分表以及数据迁移

有一个未分库分表的系统，未来要分库分表，如何设计才可以让系统从未分库分表动态切换到分库分表上？

已经明白为啥要分库分表了，你也知道常用的分库分表中间件了，你也设计好你们如何分库分表的方案了（水平拆分、垂直拆分、分表），那问题来了，你接下来该怎么把你那个单库单表的系统给迁移到分库分表上去？

友情提示

假设，你现有有一个单库单表的系统，在线上在跑，假设单表有600万数据

3个库，每个库里分了4个表，每个表要放50万的数据量

假设你已经选择了一个分库分表的数据库中间件，sharding-jdbc，mycat，都可以

你怎么把线上系统平滑地迁移到分库分表上面去

sharding-jdbc：自己上官网，找一个官网最基本的例子，自己写一下，试一下，跑跑看，是非常简单的

mycat：自己上官网，找一个官网最基本的例子，自己写一下，试一下看看

 

从low到高大上有好几种方案，都给你说一下

 

（1）停机迁移方案

我先给你说一个最low的方案，就是很简单，大家伙儿凌晨12点开始运维，网站或者app挂个公告，说0点到早上6点进行运维，无法访问。。。。。。

接着到0点，停机，系统挺掉，没有流量写入了，此时老的单库单表数据库静止了。然后你之前得写好一个导数的一次性工具，此时直接跑起来，然后将单库单表的数据哗哗哗读出来，写到分库分表里面去。

导数完了之后，就ok了，修改系统的数据库连接配置啥的，包括可能代码和SQL也许有修改，那你就用最新的代码，然后直接启动连到新的分库分表上去。

验证一下，ok了，完美，大家伸个懒腰，看看看凌晨4点钟的北京夜景，打个滴滴回家吧

但是这个方案比较low，谁都能干，我们来看看高大上一点的方案

 

（2）双写迁移方案

常用的一种迁移方案，比较靠谱一些，不用停机，不用看北京凌晨4点的风景

简单来说，就是在线上系统里面，之前所有写库的地方，增删改操作，都除了对老库增删改，都加上对新库的增删改，这就是所谓双写，同时写俩库，老库和新库。

然后系统部署之后，新库数据差太远，用之前说的导数工具，跑起来读老库数据写新库，写的时候要根据gmt_modified这类字段判断这条数据最后修改的时间，除非是读出来的数据在新库里没有，或者是比新库的数据新才会写。

接着导完一轮之后，有可能数据还是存在不一致，那么就程序自动做一轮校验，比对新老库每个表的每条数据，接着如果有不一样的，就针对那些不一样的，从老库读数据再次写。反复循环，直到两个库每个表的数据都完全一致为止。

接着当数据完全一致了，就ok了，基于仅仅使用分库分表的最新代码，重新部署一次，不就仅仅基于分库分表在操作了么，还没有几个小时的停机时间，很稳。所以现在基本玩儿数据迁移之类的，都是这么干了。

 

双写部署法(一)
这个就是不停机部署法，这里我需要先引进两个概念:历史数据和增量数据。
假设，我们是对一张叫做test_tb的表进行拆分，因为你要进行双写，系统里头和test_tb表有关的业务之前必定会加入一段双写代码，同时往老库和新库中写，然后进行部署，那么
历史数据:在该次部署前，数据库表test_tb的有关数据，我们称之为历史数据。
增量数据:在该次部署后，数据库表test_tb的新产生的数据，我们称之为增量数据。
然后迁移流程如下
(1)先计算你要迁移的那张表的max(主键)。在迁移过程中，只迁移db-old中test_tb表里，主键小等于该max(主键)的值，也就是所谓的历史数据。
这里有特殊情况，如果你的表用的是uuid，没法求出max(主键)，那就以创建时间作为划分历史数据和增量数据的依据。如果你的表用的是uuid,又没有创建时间这个字段，我相信机智的你，一定有办法区分出历史数据和增量数据。
(2)在代码中，与test_tb有关的业务，多加一条往消息队列中发消息的代码，将操作的sql发送到消息队列中，至于消息体如何组装，大家自行考虑。需要注意的是，只发写请求的sql，只发写请求的sql，只发写请求的sql。重要的事情说三遍！
原因有二:

(1)只有写请求的sql对恢复数据才有用。

(2)系统中，绝大部分的业务需求是读请求，写请求比较少。

注意了，在这个阶段，我们不消费消息队列里的数据。我们只发写请求，消息队列的消息堆积情况不会太严重！
(3)系统上线。另外，写一段迁移程序，迁移db-old中test_tb表里，主键小于该max(主键)的数据，也就是所谓的历史数据。
上面步骤(1)～步骤(3)的过程如下

等到db-old中的历史数据迁移完毕，则开始迁移增量数据，也就是在消息队列里的数据。
(4)将迁移程序下线，写一段订阅程序订阅消息队列中的数据
(5)订阅程序将订阅到到数据，通过中间件写入新库
(6)新老库一致性验证，去除代码中的双写代码，将涉及到test_tb表的读写操作，指向新库。
上面步骤(4)～步骤(6)的过程如下

这里大家可能会有一个问题，在步骤(1)～步骤(3),系统对历史数据进行操作，会造成不一致的问题么？
OK，不会。这里我们对delete操作和update操作做分析，因为只有这两个操作才会造成历史数据变动，insert进去的数据都是属于增量数据。
(1)对db-old中test_tb表的历史数据发出delete操作，数据还未删除，就被迁移程序给迁走了。此时delete操作在消息队列里还有记录，后期订阅程序订阅到该delete操作，可以进行删除。
(2)对db-old中test_tb表的历史数据发出delete操作，数据已经删除，迁移程序迁不走该行数据。此时delete操作在消息队列里还有记录，后期订阅程序订阅到该delete操作，再执行一次delete，并不会对一致性有影响。
对update的操作类似，不赘述。

双写部署法(二)
上面的方法有一个硬伤，注意我有一句话

(2)在代码中，与test_tb有关的业务，多加一条往消息队列中发消息的代码，将操作的sql发送到消息队列中，至于消息体如何组装，大家自行考虑。

大家想一下，这么做，是不是造成了严重的代码入侵。将非业务代码嵌入业务代码，这么做，后期删代码的时候特别累。
有没什么方法，可以避免这个问题的?
有的，订阅binlog日志。关于binlog日志，我尽量下周写一篇《研发应该掌握的binlog知识》，这边我就介绍一下作用

记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。binlog不会记录SELECT和SHOW这类操作，因为这类操作对据本身并没有修改。

还记得我们在双写部署法(一)里介绍的，往消息队列里发的消息，都是写操作的消息。而binlog日志记录的也是写操作。所以订阅该日志，也能满足我们的需求。
于是步骤如下
(1)打开binlog日志，系统正常上线就好
(2)还是写一个迁移程序，迁移历史数据。步骤和上面类似，不啰嗦了。
步骤(1)~步骤(2)流程图如下

(3)写一个订阅程序，订阅binlog(mysql中有canal。至于oracle中，大家就随缘自己写吧)。然后将订阅到的数据通过中间件，写入新库。
(4)检验一致性，没问题就切库。
步骤(3)~步骤(4)流程图如下

怎么验数据一致性
这里大概介绍一下吧，这篇的篇幅太长了，大家心里有底就行。
(1)先验数量是否一致，因为验数量比较快。
至于验具体的字段，有两种方法:
(2.1)有一种方法是，只验关键性的几个字段是否一致。
(2.2)还有一种是 ，一次取50条(不一定50条，具体自己定，我只是举例),然后像拼字符串一样，拼在一起。用md5进行加密，得到一串数值。新库一样如法炮制，也得到一串数值，比较两串数值是否一致。如果一致，继续比较下50条数据。如果发现不一致，用二分法确定不一致的数据在0-25条，还是26条-50条。以此类推，找出不一致的数据，进行记录即可。