在项目初期，我们部署了三个数据库 A、B、C，此时数据库的规模可以满足我们的业务需求。为了将数据做到平均分配，我们在 Service 服务层使用 uid%3 进行取模分片，从而将数据平均分配到三个数据库中。
如图所示
后期随着用户量的增加，用户产生的数据信息被源源不断的添加到数据库中，最终达到数据库的最佳存储容量。如果此时继续向数据库中新增数据，会导致数据库的 CRUD 等基本操作变慢，进而影响整个服务的响应速度。
这时，我们需要增加新的节点，对数据库进行水平扩容，那么加入新的数据库 D 后，数据库的规模由原来的 3 个变为 4 个。
如图所示：
此时由于分片规则发生了变化（uid%3 变为 uid%4），导致大部分的数据，无法命中原有的数据，需要重新进行分配，要做大量的数据迁移处理。
比如之前 uid 如果是 uid=3 取模 3%3=0， 是分配在 A 库上，新加入 D 库后， uid=3 取模 3%4=3，分配在 D 库上；
新增一个节点， 大概会有 90% 的数据需要迁移， 这样会面临大量的数据压力，并且对服务造成极大的不稳定性。
五个方案
1.1 停机方案
1、发布公告：为了进行数据的重新拆分，在停止服务之前，我们需要提前通知用户，比如：我们的服务会在 yyyy-MM-dd 进行升级，给您带来的不便敬请谅解。
2、停止服务：关闭 Service
3、离线数据迁移（拆分，重新分配数据）：将旧库中的数据按照Service 层的算法，将数据拆分，重新分配数据
4、数据校验：开发定制一个程序对旧库和新库中的数据进行校验，比对
5、更改配置：修改 Service 层的配置算法，也就是将原来的 uid%3 变为 uid%4
6、恢复服务：重启 Service 服务
7、回滚预案：针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁移，恢复服务等）执行失败，立刻进行回滚，重新再来
1.2 停写方案
1、支持读写分离：数据库支持读写分离，在扩容之前，每个数据库都提供了读写功能，数据重新分配的过程中，将每个数据库设置为只读状态，关闭写的功能
2、升级公告：为了进行数据的重新拆分，在停写之前，我们需要提前通知用户，比如：我们的服务会在 yyyy-MM-dd 进行升级，给您带来的不便敬请谅解
3、中断写操作，隔离写数据源（或拦截返回统一提示）：在 Service 层对所有的写请求进行拦截，统一返回提示信息，如：服务正在升级中，只对外提供读服务
4、数据同步处理：将旧库中的数据按照 Service 层的算法，将数据重新分配，迁移（复制数据）
5、数据校验：开发定制一个程序对旧库中的数据进行备份，使用备份的数据和重新分配后的数据进行校验，比对
6、更改配置：通过配置中心，修改 Service 层的配置算法，也就是将原来的 uid%3 变为 uid%4，这个过程不需要重启服务
6、恢复写操作：设置数据库恢复读写功能，去除 Service 层的拦截提示
7、数据清理：使用delete语句对冗余数据进行删除
8、回滚预案：针对上述的每个步骤都要有数据回滚预案，一旦某个环节（如：数据迁移等）执行失败，立刻进行回滚，重新再来
缺点：在数据的复制过程需要消耗大量的时间，停写时间太长，数据需要先复制，再清理冗余数据
1.3 日志方案
核心是通过日志进行数据库的同步迁移， 主要操作步骤如下：
1、数据迁移之前， 业务应用访问旧的数据库节点
2、日志记录
在升级之前， 记录“对旧数据库上的数据修改”的日志（这里修改包括增、删、改），这个日志不需要记录详细的数据信息，主要记录：
- 修改的库
- 修改的表
- 修改的唯一主键
- 修改操作类型
日志记录不用关注新增了哪些信息，修改的数据格式，只需要记录以上数据信息，这样日志格式是固定的， 这样能保证方案的通用性。
服务升级日志记录功能风险较小：
写和修改接口是少数， 改动点少；升级只是增加了一些日志，采用异步方式实现， 对业务功能没有太多影响。
3、数据迁移
研发定制数据迁移工具， 作用是把旧库中的数据迁移至新库中。
整个过程仍然采用旧库进行对外服务。
数据同步工具实现复杂度不高。
只对旧库进行读取操作， 如果同步出现问题， 都可以对新库进行回滚操作。
可以限速或分批迁移执行， 不会有时间压力。
数据迁移完成之后， 并不能切换至新库提供服务。
因为旧库依然对线上提供服务， 库中的数据随时会发生变化， 但这些变化的数据并没有同步到新库中， 旧库和新库数据不一致， 所以不能直接进行切换， 需要将数据同步完整。
4、日志增量迁移
研发一个日志迁移工具，把上面迁移数据过程中的差异数据追平，处理步骤：
读取 log 日志，获取具体是哪个库、表和主键发生了变化修改；把旧库中的主键记录读取出来; 根据主键 ID，把新库中的记录替换掉
这样可以最大程度的保障数据的一致性。风险分析：
整个过程， 仍然是旧库对线上提供服务；日志迁移工具实现的复杂度较低；任何时间发现问题，可以重新再来，有充分的容错空间；可以限速重放处理日志，处理过程不会因为对线上影响造成时间压力。
但是， 日志增量同步完成之后， 还不能切换到新的数据库。
因为日志增量同步过程中，旧库中可能有数据发生变化，导致数据不一致，所以需要进一步读取日志，追平数据记录；日志增量同步过程随时可能会产生新的数据， 新库与旧库的数据追平也会是一个无限逼近的过程。
5、数据校验
准备好数据校验工具，将旧库和新库中的数据进行比对，直到数据完全一致。
6、切换新库
数据比对完成之后， 将流量转移切换至新库， 至此新库提供服务， 完成迁移。
但是在极限情况下， 即便通过上面的数据校验处理， 也有可能出现 99.99% 数据一致，不能保障完全一致，这个时候可以在旧库做一个 readonly 只读功能， 或者将流量屏蔽降级，等待日志增量同步工具完全追平后，再进行新库的切换。
至此，完成日志方案的迁移扩容处理，整个过程能够持续对线上提供服务，只会短暂的影响服务的可用性。
这种方案的弊端，是操作繁琐，需要适配多个同步处理工具，成本较高，需要制定个性化业务的同步处理， 不具备普遍性，耗费的时间周期也较长。
1.4 双写方案（中小型数据）
双写方案可通过 canal 或 mq 做实现。
- 增加新库，按照现有节点， 增加对应的数量。
- 数据迁移：避免增量影响， 先断开主从，再导入（耗时较长）， 同步完成并做校验
- 增量同步：开启 Canal 同步服务， 监听从节点数据库， 再开启主从同步，从节点收到数据后会通过 Canal 服务， 传递至新的 DB 节点。
- 切换新库：通过 Nginx，切换访问流量至新的服务。
- 修复切换异常数据：在切换过程中， 如果出现，Canal 未同步，但已切换至新库的请求（比如下单，修改了资金， 但还未同步 ），可以通过定制程序，读取检测异常日志，做自动修复或人工处理。
- 针对此种情况，最好是在凌晨用户量小的时候，或专门停止外网访问，进行切换，减少异常数据的产生。
- 数据校验：为保障数据的完全一致，有必要对数据的数量完整性做校验。
1.5 平滑 2N 方案（大数据量）
线上数据库，为了保障其高可用，一般每台主库会配置一台从库，主库负责读写，从库负责读取。下图所示，A，B 是主库，A0 和 B0 是从库。
1、当需要扩容的时候，我们把A0和B0升级为新的主库节点，如此由2个分库变为4个分库。同时在上层的分片配置，做好映射，规则如下:
把 uid%4=0 和 uid%4=2 的数据分别分配到 A 和 A0 主库中
把 uid%4=1 和 uid%4=3 的数据分配到 B 和 B0 主库中
2、因为 A 和 A0 库的数据相同，B 和 B0 数据相同，此时无需做数据迁移。只需调整变更一下分片配置即可，通过配置中心更新，不需要重启。
由于之前 uid%2 的数据是分配在 2 个库里面，扩容之后需要分布到 4 个库中，但由于旧数据仍存在（ uid%4=0 的节点,还有一半 uid%4=2 的数据），所以需要对冗余数据做一次清理。
这个清理，并不会影响线上数据的一致性，可以随时随地进行。
3、处理完成之后，为保证数据的高可用，以及将来下一步的扩容需求。
可以为现有的主库再次分配一个从库。
评论区