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

一、为什么须要扩容

假如目前有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. 解决实现之，为保证数据的高可用，以及未来下一步的扩容需要。

   能够为现有的主库再次调配一个从库。

本文由mirson创作分享，如需进一步交换，请加vx号：soft_art或拜访www.softart.cn