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

3次阅读

共计 2595 个字符，预计需要花费 7 分钟才能阅读完成。

假如目前有 3 个库，基于 UID 进去取模分片，数据能够平衡的调配到 3 个数据库中，具体布局如下：

如果要减少新的节点，该如何扩容？须要对数据库进行程度扩容，新库退出之后，数据由原来的 3 个库就拆分至 4 个库外面。

此时因为分片规定产生了变动（uid%3 变为 uid%4），导致大部分的数据，无奈命中原有的数据，须要从新进行调配，要做大量的数据迁徙解决。

比方之前 uid 如果是 uid7 取模 1，是调配在 B 库上，新退出 D 库后，uid7 取模 4，是调配在 D 库上；

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

发布公告
进行服务
离线数据迁徙（拆分，重新分配数据）
数据校验
更改配置
复原服务
回滚预案

问题：

停服之后，可能保障迁徙工作的失常进行，然而服务进行，挫伤用户体验，并造成了工夫压力，必须在指定的工夫内实现迁徙。

反对读写拆散
降级布告
中断写操作，隔离写数据源（或拦挡返回对立提醒）
数据同步解决
数据校验
更改配置
复原写操作
数据清理
回滚预案

问题：

尽管比停机计划有所改进，可能提供读取服务，然而不能保障外围业务数据的失常写入，同样会挫伤用户体验，也会存在工夫压力。

外围是通过日志进行数据库的同步迁徙，次要操作步骤如下：

数据迁徙之前，业务利用拜访旧的数据库节点。
日志记录

在降级之前，记录“对旧数据库上的数据批改”的日志（这里批改包含增、删、改），这个日志不须要记录具体的数据信息，次要记录：

（1）批改的库；

（2）批改的表；

（3）批改的惟一主键；

（4）批改操作类型。

日志记录不必关注新增了哪些信息，批改的数据格式，只须要记录以上数据信息，这样日志格局是固定的，这样能保障计划的通用性。

服务降级日志记录性能危险较小：

写和批改接口是多数，改变点少；

降级只是减少了一些日志，采纳异步形式实现，对业务性能没有太多影响。
数据迁徙：

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

整个过程依然采纳旧库进行对外服务。

数据同步工具实现复杂度不高。

只对旧库进行读取操作，如果同步呈现问题，都能够对新库进行回滚操作。

能够限速或分批迁徙执行，不会有工夫压力。

数据迁徙实现之后，并不能切换至新库提供服务。

因为旧库仍然对线上提供服务，库中的数据随时会发生变化，但这些变动的数据并没有同步到新库中，旧库和新库数据不统一，所以不能间接进行切换，须要将数据同步残缺。
日志增量迁徙

研发一个日志迁徙工具，把下面迁徙数据过程中的差别数据追平，解决步骤：

读取 log 日志，获取具体是哪个库、表和主键产生了变动批改；

把旧库中的主键记录读取进去

依据主键 ID，把新库中的记录替换掉

这样能够最大水平的保障数据的一致性。危险剖析：

整个过程，依然是旧库对线上提供服务；

日志迁徙工具实现的复杂度较低；

任何工夫发现问题，能够从新再来，有充沛的容错空间；

能够限速重放解决日志，处理过程不会因为对线上影响造成工夫压力。

然而，日志增量同步实现之后，还不能切换到新的数据库。

因为日志增量同步过程中，旧库中可能有数据发生变化，导致数据不统一，所以须要进一步读取日志，追平数据记录；日志增量同步过程随时可能会产生新的数据，新库与旧库的数据追平也会是一个有限迫近的过程。
数据校验
筹备好数据校验工具，将旧库和新库中的数据进行比对，直到数据完全一致。
切换新库

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

然而在极限状况下，即使通过下面的数据校验解决，也有可能呈现 99.99% 数据统一，不能保障完全一致，这个时候能够在旧库做一个 readonly 只读性能，或者将流量屏蔽降级，期待日志增量同步工具齐全追平后，再进行新库的切换。

至此，实现日志计划的迁徙扩容解决，整个过程可能继续对线上提供服务，只会短暂的影响服务的可用性。

问题：

这种计划的弊病，是操作繁琐，须要适配多个同步解决工具，老本较高，须要制订个性化业务的同步解决，不具备普遍性，消耗的工夫周期也较长。

双写计划可通过 canal 或 mq 做实现。

减少新库，依照现有节点，减少对应的数量。
数据迁徙：防止增量影响，先断开主从，再导入（耗时较长），同步实现并做校验
增量同步：开启 Canal 同步服务，监听从节点数据库，再开启主从同步，从节点收到数据后会通过 Canal 服务，传递至新的 DB 节点。
切换新库：通过 Nginx，切换拜访流量至新的服务。
修复切换异样数据：在切换过程中，如果呈现，Canal 未同步，但已切换至新库的申请（比方下单，批改了资金，但还未同步），能够通过定制程序，读取检测异样日志，做主动修复或人工解决。
针对此种状况，最好是在凌晨用户量小的时候，或专门进行外网拜访，进行切换，缩小异样数据的产生。
数据校验：为保障数据的完全一致，有必要的数据的数量完整性做校验。

问题：

该计划须要有双倍的应用服务器和数据库服务器，消耗较多的硬件资源老本，且减少保护部署工作量；数据库全量同步消耗工夫周期较长，且须要增量同步组件来保障数据一致性。

线上数据库，为了保障其高可用，个别每台主库会配置一台从库，主库负责读写，从库负责读取。下图所示，A，B 是主库，A0 和 B0 是从库。
当须要扩容的时候，咱们把 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。
因为 A 和 A0 库的数据雷同，B 和 B0 数据雷同，此时无需做数据迁徙。只需调整变更一下分片配置即可，通过配置核心更新，不须要重启。

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

这个清理，并不会影响线上数据的一致性，能够随时随地进行。
解决实现之，为保证数据的高可用，以及未来下一步的扩容需要。
能够为现有的主库再次调配一个从库。