共计 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 未同步，但已切换至新库的申请（比方下单，批改了资金，但还未同步），能够通过定制程序，读取检测异样日志，做主动修复或人工解决。
针对此种状况，最好是在凌晨用户量小的时候，或专门进行外网拜访，进行切换，缩小异样数据的产生。
- 数据校验：为保障数据的完全一致，有必要的数据的数量完整性做校验。
问题：
该计划须要有双倍的应用服务器和数据库服务器，消耗较多的硬件资源老本，且减少保护部署工作量；数据库全量同步消耗工夫周期较长，且须要增量同步组件来保障数据一致性。
六、平滑 2N 计划（大数据量）
- 线上数据库，为了保障其高可用，个别每台主库会配置一台从库，主库负责读写，从库负责读取。下图所示，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 的数据），所以须要对冗余数据做一次清理。
这个清理，并不会影响线上数据的一致性，能够随时随地进行。
- 解决实现之，为保证数据的高可用，以及未来下一步的扩容需要。
能够为现有的主库再次调配一个从库。
本文由 mirson 创作分享，如需进一步交换，请加 vx 号：soft_art 或拜访 www.softart.cn
