主题
数据库扩容
面试题 数据库扩容
引言
初版
如果线上服务不重要，一般来个单体的数据库 DB 来存储数据即可来。
单体应用
优点：简单，省事，方便。
缺点：数据并发性，稳定性都有问题。但问题是，如果随着业务发展，目前 2 个库的性能扛不住了，还要继续水平拆分，造出更多库咋办？一般是如何实现丝滑扩容的呢？简单直接暴力的方法。
进阶
随着数据量的不断增大，一般要对数据进行水平切分，水平切分的规则可以简单根据用户 id 或者用户 IP 对数据进行取模，实现路由功能。当然也可以增加 Slave 跟 KeepAlived 来实现高可用。
主从 + 路由
扩容
第一版：停机扩容
停机扩容
- APP 通知用户在某个时间段停机维护升级。
- 新建若干个具有高可用的库。
- 停止当前服务，然后写个数据迁移程序，实现把老库数据全部迁移到新库中。
- 修改代码路由规则后重新对外提供服务。
此时 id % 4 = 0 跟 id % 4 = 2 的两个 DB 还在同步数据。id % 4 = 1 跟 id % 4 = 3 的两个 DB 还在同步数据。需做一些收尾操作。
优点：简单
缺点：中间停服务了，无法保证高可用。数据切换前跟切换过程中需确保无任何出错。
第二版：在线双写
在线双写
- 建立好新到数据库，然后接下来用户在写原有数据库到同时也写一份数据到新库中。
- 写个数据迁移程序，实现旧库中的历史数据迁移到新库中。
- 迁移过程中，每次插入数据时，需检测数据的更新情况。比如，如果新的表中没有当前的数据，则直接新增；如果新表有数据并没有要迁移的数据新的话，就更新为当前数据，只能允许新的数据覆盖旧的数据，推荐使用 Canal 这样到中间件。
- 经过一段时间后需要校验新库跟旧库两边数据是否一样。如果检查到一样了，则直接切换即可。
**优点：**高可用了。
**缺点：**不够丝滑，来回挪动数据较大。
第三版：丝滑般扩容
目标：打算将原来到两个数据库扩容到 4 个。
第一步：修改配置
修改配置
- 修改配置信息，注意旧库跟新库之间到映射关系。确保扩容后数据可以正确路由到服务器。
- Id % 2 = 0 的库变为了 id % 4 = 0 或 id % 4 = 2
- Id % 2 = 1 的库变为了 id % 4 = 1 或 id % 4 = 3
第二步：reload 配置
服务层 reload 配置，可以重启服务，也可以 CLoud 那样配置中心发送信号来实现重读配置文件。
至此，数据库的 2 --> 4 扩容完成，原来是 2 个数据库实例提供服务，现在变为 4 个数据库实例提供服务。
第三步：收缩数据
丝滑扩容
- 接触上面的两个同步操作。
- 对新库新建高可用。
- 删除冗余数据，比如 id % 4 = 0 的机器中删除 id % 4 = 2 的冗余数据，只为 id % 4 = 0 的数据提供服务，其余三个类似操作。
- 至此实现成倍扩容，还避免来数据迁移。
更新: 2021-05-10 21:10:00
原文: <https://www.yuque.com/fcant/notes/lpbl90>