从单表到分表实现数据平滑迁移

背景

初到新公司接手支付中心系统，发现支付表单表数据量达到了 7 亿多，震惊之余不由的脊背发凉，这个系统运行犹如走钢丝，稍微有点风吹草动就可能造成线上事故，DBA 天天催着要数据迁移，给出大表解决方案，给出排期。

当你担心一件事要出问题，他就一定会出问题，不得不说这墨菲定律真™️准。营销部门搞活动，支付单量激增，客服反应好多用户投诉明明支付成功了，但还是处于支付中状态。打开日志排查原因，就是因为数据库响应慢，支付状态未能更新成功，导致未能及时通知上游系统支付成功结果。（当然支付逻辑也存在问题，这点不在此文讨论范围内）

痛定思痛，分库分表和数据迁移迫在眉睫。

分库？分表？

什么时候需要分库

分库主要是解决并发量大的问题，数据库的连接数是有限的，当读或者写的QPS过高，导致数据库连接数不够时，就需要考虑分库，通过增加数据库实例的方式来增加连接数，从而提升系统的并发性能。

什么时候需要分表

分表主要时应对数据量大的情况，当一个表的数据量过大时，不论是读还是写的性能都会出现明显下降，一张表的数据量最好控制在1000万以内（看硬件性能）。

业务增量分析及容量规划

首先通过计算得到高峰期QPS每秒约50，并发量不算特别高，所以没有必要做分库来分担并发量。

在业务高峰期的月份每日的支付单量约270多万，业务低峰期的月份每日的支付单量约130多万，每年大概的单量为6亿单左右，

按照3到5年的规划，每张表约1000万数据，计划分256张表。

我们目前数据库配置是32C/64G/3T SSD，满足需求。

数据迁移

数据迁移分析及遇到的问题：

使用业务单号的hash值对256取模（hash(业务唯一ID)%256），得到表的索引值。之前单表存在唯一的业务单号，直接使用即可。
需要将旧库新增的实时数据同步到新库，并记录开始数据的ID。
需要将存量数据同步到新库，终止点为1中开始数据的ID。
考虑切流量过程中的稳定性和可回滚能力，需要将实时数据双向同步，即新库新增的数据也需要同步到旧库。
迁移完成，需要做新旧库数据的比对工作。

整体迁移方案

下面按照迁移步骤来逐一讲解：

1. 增量数据同步

将实时新增的数据同步到新库的表中。这阶段利用的 Canal、RocketMQ 中间件实现，Canal 获取 MySQL BinLog 日志，发送到 RocketMQ 指定的 Topic，消费者对数据做处理后插入到新的库表。

增量数据同步问题

需要记录一下增量数据同步的开始 ID，这个 ID 作为存量数据的终止点。
RocketMQ 消费消息要保证顺序性，需要指定消费模式为顺序消费 consumeMode = ConsumeMode.ORDERLY，顺序消费需要注意，如果消费消息异常，会导致消息阻塞。
在增量数据同步时，需要将 update 语句转为 insert 语句，因为我们先执行增量数据同步，在这个过程中可能会有对存量的数据进行更新的操作，如果不将 update 转为 insert 的话，在迁移存量数据的时候，迁移数据在存入新库前，发生了更新，更新先到的新库，这时会更新 0 条记录，因为存量数据还未插入到新库，就会发生更新丢失的情况。binlog 是全部字段发送的，经过解析可以 insert 全部的字段。