千亿级数据平滑扩容之方案全面剖析

一、为什么需要扩容

假设目前有3个库， 基于UID进去取模分片，数据可以均衡的分配到3个数据库中，具体规划如下：

如果要增加新的节点， 该如何扩容？需要对数据库进行水平扩容， 新库加入之后，数据由原来的3个库就拆分至4个库里面。

此时由于分片规则发生了变化（uid%3 变为uid%4），导致大部分的数据，无法命中原有的数据，需要重新进行分配，要做大量的数据迁移处理。

> 比如之前uid如果是uid7取模1， 是分配在B库上，新加入D库后， uid7取模4，是分配在D库上；

新增一个节点， 大概会有90%的数据需要迁移， 这样会面临大量的数据压力，并且对服务造成极大的不稳定性。

二、停机方案

1. 发布公告
2. 停止服务
3. 离线数据迁移（拆分，重新分配数据）
4. 数据校验
5. 更改配置
6. 恢复服务
7. 回滚预案

问题：

> 停服之后， 能够保证迁移工作的正常进行， 但是服务停止，伤害用户体验， 并造成了时间压力， 必须在指定的时间内完成迁移。

三、停写方案

1. 支持读写分离
2. 升级公告
3. 中断写操作，隔离写数据源（或拦截返回统一提示）
4. 数据同步处理
5. 数据校验
6. 更改配置
7. 恢复写操作
8. 数据清理
9. 回滚预案

问题：

> 虽然比停机方案有所改进，能够提供读取服务， 但是不能保障核心业务数据的正常写入，同样会伤害用户体验， 也会存在时间压力。

四、日志方案

核心是通过日志进行数据库的同步迁移， 主要操作步骤如下：

1. 数据迁移之前， 业务应用访问旧的数据库节点。

   

2. 日志记录

   在升级之前， 记录“对旧数据库上的数据修改”的日志（这里修改包括增、删、改），这个日志不需要记录详细的数据信息，主要记录：

   （1）修改的库；

   （2）修改的表；

   （3）修改的唯一主键；

   （4）修改操作类型。

   日志记录不用关注新增了哪些信息，修改的数据格式，只需要记录以上数据信息，这样日志格式是固定的， 这样能保证方案的通用性。

   服务升级日志记录功能风险较小：

   > 写和修改接口是少数， 改动点少；
   >
   > 升级只是增加了一些日志，采用异步方式实现， 对业务功能没有太多影响。

3. 数据迁移：

   研发定制数据迁移工具， 作用是把旧库中的数据迁移至新库中。

   

   > 整个过程仍然采用旧库进行对外服务。
   >
   > 数据同步工具实现复杂度不高。
   >
   > 只对旧库进行读取操作， 如果同步出现问题， 都可以对新库进行回滚操作。
   >
   > 可以限速或分批迁移执行， 不会有时间压力。

   数据迁移完成之后， 并不能切换至新库提供服务。

   因为旧库依然对线上提供服务， 库中的数据随时会发生变化， 但这些变化的数据并没有同步到新库中， 旧库和新库数据不一致， 所以不能直接进行切换， 需要将数据同步完整。

4. 日志增量迁移

   

   研发一个日志迁移工具，把上面迁移数据过程中的差异数据追平，处理步骤：

   > 读取log日志，获取具体是哪个库、表和主键发生了变化修改；
   >
   > 把旧库中的主键记录读取出来
   >
   > 根据主键ID，把新库中的记录替换掉

   这样可以最大程度的保障数据的一致性。风险分析：

   > 整个过程， 仍然是旧库对线上提供服务；
   >
   > 日志迁移工具实现的复杂度较低；
   >
   > 任何时间发现问题， 可以重新再来，有充分的容错空间；
   >
   > 可以限速重放处理日志， 处理过程不会因为对线上影响造成时间压力。

   但是， 日志增量同步完成之后， 还不能切换到新的数据库。

   因为日志增量同步过程中，旧库中可能有数据发生变化， 导致数据不一致，所以需要进一步读取日志， 追平数据记录； 日志增量同步过程随时可能会产生新的数据， 新库与旧库的数据追平也会是一个无限逼近的过程。

5. 数据校验

   准备好数据校验工具，将旧库和新库中的数据进行比对，直到数据完全一致。

   

6. 切换新库

   数据比对完成之后， 将流量转移切换至新库， 至此新库提供服务， 完成迁移。

   但是在极限情况下， 即便通过上面的数据校验处理， 也有可能出现99.99%数据一致， 不能保障完全一致，这个时候可以在旧库做一个readonly只读功能， 或者将流量屏蔽降级，等待日志增量同步工具完全追平后， 再进行新库的切换。

   至此，完成日志方案的迁移扩容处理， 整个过程能够持续对线上提供服务， 只会短暂的影响服务的可用性。

   问题：

   > 这种方案的弊端，是操作繁琐，需要适配多个同步处理工具，成本较高， 需要制定个性化业务的同步处理， 不具备普遍性，耗费的时间周期也较长。

五、双写方案（中小型数据）

双写方案可通过canal或mq做实现。

1. 增加新库，按照现有节点， 增加对应的数量。

2. 数据迁移：避免增量影响， 先断开主从，再导入（耗时较长）， 同步完成并做校验

3. 增量同步：开启Canal同步服务， 监听从节点数据库， 再开启主从同步，从节点收到数据后会通过Canal服务， 传递至新的DB节点。

4. 切换新库：通过Nginx，切换访问流量至新的服务。

5. 修复切换异常数据：在切换过程中， 如果出现，Canal未同步，但已切换至新库的请求（比如下单，修改了资金， 但还未同步 ）， 可以通过定制程序， 读取检测异常日志，做自动修复或人工处理。

   针对此种情况， 最好是在凌晨用户量小的时候， 或专门停止外网访问，进行切换，减少异常数据的产生。

6. 数据校验：为保障数据的完全一致， 有必要的数据的数量完整性做校验。

问题：

> 该方案需要有双倍的应用服务器和数据库服务器， 耗费较多的硬件资源成本，且增加维护部署工作量；数据库全量同步耗费时间周期较长，且需要增量同步组件来保障数据一致性。

六、平滑2N方案（大数据量）

1. 线上数据库，为了保障其高可用，一般每台主库会配置一台从库，主库负责读写，从库负责读取。下图所示，A，B是主库，A0和B0是从库。

   

2. 当需要扩容的时候，我们把A0和B0升级为新的主库节点，如此由2个分库变为4个分库。同时在上层的分片配置，做好映射，规则如下:

   > uid%4=0和uid%4=2的分别指向A和A0，之前指向uid%2=0的数据，重新调整为uid%4=0和uid%4=2；
   >
   > uid%4=1和uid%4=3的指向B和B0，之前指向uid%2=1的数据，重新调整为uid%4=1和uid%4=3。

3. 因为A和A0库的数据相同，B和B0数据相同，此时无需做数据迁移。只需调整变更一下分片配置即可，通过配置中心更新，不需要重启。

   

   由于之前uid%2的数据是分配在2个库里面，扩容之后需要分布到4个库中，但由于旧数据仍存在（uid%4=0的节点,还有一半uid%4=2的数据），所以需要对冗余数据做一次清理。

   这个清理，并不会影响线上数据的一致性，可以随时随地进行。

4. 处理完成之，为保证数据的高可用，以及将来下一步的扩容需求。

   可以为现有的主库再次分配一个从库。

   

---