数据库扩容

面试题 数据库扩容

引言

初版

如果线上服务不重要，一般来个单体的数据库DB来存储数据即可来。

单体应用
优点：简单，省事，方便。
缺点：数据并发性，稳定性都有问题。但问题是，如果随着业务发展，目前2个库的性能扛不住了，还要继续水平拆分，造出更多库咋办？一般是如何实现丝滑扩容的呢？简单直接暴力的方法。

进阶

随着数据量的不断增大，一般要对数据进行水平切分，水平切分的规则可以简单根据用户id或者用户IP对数据进行取模，实现路由功能。当然也可以增加Slave跟KeepAlived来实现高可用。

主从+路由

扩容

第一版：停机扩容

停机扩容

1. APP通知用户在某个时间段停机维护升级。
2. 新建若干个具有高可用的库。
3. 停止当前服务，然后写个数据迁移程序，实现把老库数据全部迁移到新库中。
4. 修改代码路由规则后重新对外提供服务。

此时 id % 4 = 0 跟 id % 4 = 2 的两个DB 还在同步数据。id % 4 = 1 跟 id % 4 = 3的两个DB还在同步数据。需做一些收尾操作。
优点：简单
缺点：中间停服务了，无法保证高可用。数据切换前跟切换过程中需确保无任何出错。

第二版：在线双写

在线双写

1. 建立好新到数据库，然后接下来用户在写原有数据库到同时也写一份数据到新库中。
2. 写个数据迁移程序，实现旧库中的历史数据迁移到新库中。
3. 迁移过程中，每次插入数据时，需检测数据的更新情况。比如，如果新的表中没有当前的数据，则直接新增；如果新表有数据并没有要迁移的数据新的话，就更新为当前数据，只能允许新的数据覆盖旧的数据，推荐使用Canal这样到中间件。
4. 经过一段时间后需要校验新库跟旧库两边数据是否一样。如果检查到一样了，则直接切换即可。

优点：高可用了。
缺点：不够丝滑，来回挪动数据较大。

第三版：丝滑般扩容

目标：打算将原来到两个数据库扩容到4个。

第一步：修改配置

修改配置

1. 修改配置信息，注意旧库跟新库之间到映射关系。确保扩容后数据可以正确路由到服务器。

• 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个数据库实例提供服务。

  第三步：收缩数据

  
  丝滑扩容

1. 接触上面的两个同步操作。
2. 对新库新建高可用。
3. 删除冗余数据，比如id % 4 = 0的机器中删除id % 4 = 2的冗余数据，只为id % 4 = 0的数据提供服务，其余三个类似操作。
4. 至此实现成倍扩容，还避免来数据迁移。