浅谈数据库扩容方案
起因
每一个项目都是由小项目发展而来，从最初的一台数据库，到后面的几千上万台数据库，这发展的过程，我们都要涉及到一个技术问题：当数据量太大的时候，如何进行扩容？
案例
小明现在负责一个站点，用户数据库有2个，网站用户数据通过ID取模，分别存在两台用户数据库中，现在数据增大，两台数据库已经不够用了，现在需要增加数据库进行扩容，小明应该如何进行扩容？
方案
- 停机扩容
- 平滑扩容
停机扩容
我们先来了解下停机扩容方案，这是一种很多人初期都会使用的方案（几台数据库的时候），具体步骤：
- 小明先挂公告，告诉大家明天的凌晨02：00 - 06：00，站点将停机升级；
- 时间到了，小明停止了所有对外服务；
- 小明新增了2个数据库，然后写了一个程序，将原先的2个库的数据迁移到现有的4个库（2+2）上；
- 数据迁移完成，修改数据库服务配置；
- 重启服务，并重新开启对外服务。
回滚方案：
数据迁移失败，或者迁移后测试失败，则将服务配置修改回原先的两个库，改天再升级。
优点：
- 简单
缺点：
- 不高可用
- 开启升级到升级完成，时间短，项目组压力大，易出错
- 升级时间基本是半夜人流量最少的时候，项目组疲累，容易出错
- 运行一段时间后，发现问题，难以回滚，只能回到扩容前，会丢失部分数据
适用：
- 小型网站；
- 大部分游戏；
- 对高可用要求不高的服务。
平滑扩容
现在我们来聊一下本文的重点：平滑扩容中最好的方案就是扩容的数据库是原先数据库的倍数，如：2个数据库扩容到4个数据库，是原先的2倍。步骤：
（1）新增2个数据库
（2）配置双主进行数据同步（先测试，后线上，重启服务时间是秒级）
（3）数据同步完成之后，配置主主双写（因为同步有延迟，如果每时每刻都有数据写入/更新的话，就不能准确的保证数据已经同步完成）
（4）数据同步完成后（时间比较长），删除双主同步，修改数据库配置，并重启（秒级）；
（5）此时已经扩容完成，但此时的数据并没有减少，新增的数据库跟旧的数据库一样多的数据，此时还需要写一个程序，清空数据库中多余的数据，如：
- User1去除 uid % 4 = 2的数据；
- User3去除 uid % 4 = 0的数据；
- User2去除 uid % 4 = 3的数据；
- User4去除 uid % 4 = 1的数据。
现在，我们就已经完成了数据库的平滑扩容了。
优点
- 扩容期间，服务照常进行，保证高可用；
- 时间长，项目组压力没有这么大，出错率低；
- 扩容期间，遇到什么问题，都可以随时调试，不怕影响线上服务；
- 每个数据库少了一半的数据量。
缺点
- 程序复杂，需要配置双主、主主双写、检测数据同步等额外技术；
- 但后期数据库成千上万台的时候，扩容复杂（情况非常少，除非将很多业务数据放在同一个数据库）。
适用：
- 大型网站；
- 对高可用要求高的服务。
总结
本文主要简单讲解了数据库扩容的两种方案，并对这两种方案的优缺点、适用场景进行了说明：
- 停机扩容：简单，不高可用，易出错，扩容后不能回滚，只能回档，会丢失一部分数据。
- 平滑扩容：复杂，高可用，出错调试容易，易回滚，不会造成数据丢失，
结语
- 每一种方案都有适合它的场景，适合自己的，才是最好的；
- 小编经验有限，希望此文章对大家有帮助；
- 每天进步一点点。
参考文献
58沈剑老师架构师之路的：数据库秒级平滑扩容架构方案
