浅谈数据库扩容方案

起因

每一个项目都是由小项目发展而来，从最初的一台数据库，到后面的几千上万台数据库，这发展的过程，我们都要涉及到一个技术问题：当数据量太大的时候，如何进行扩容？

 

案例

小明现在负责一个站点，用户数据库有2个，网站用户数据通过ID取模，分别存在两台用户数据库中，现在数据增大，两台数据库已经不够用了，现在需要增加数据库进行扩容，小明应该如何进行扩容？

方案

1. 停机扩容
2. 平滑扩容

 

停机扩容

我们先来了解下停机扩容方案，这是一种很多人初期都会使用的方案（几台数据库的时候），具体步骤：

1. 小明先挂公告，告诉大家明天的凌晨02：00 - 06：00，站点将停机升级；
2. 时间到了，小明停止了所有对外服务；
3. 小明新增了2个数据库，然后写了一个程序，将原先的2个库的数据迁移到现有的4个库（2+2）上；
4. 数据迁移完成，修改数据库服务配置；
5. 重启服务，并重新开启对外服务。

 

回滚方案：

数据迁移失败，或者迁移后测试失败，则将服务配置修改回原先的两个库，改天再升级。

 

优点：

• 简单

 

缺点：

1. 不高可用
2. 开启升级到升级完成，时间短，项目组压力大，易出错
3. 升级时间基本是半夜人流量最少的时候，项目组疲累，容易出错
4. 运行一段时间后，发现问题，难以回滚，只能回到扩容前，会丢失部分数据

 

适用：

1. 小型网站；
2. 大部分游戏；
3. 对高可用要求不高的服务。

 

平滑扩容

现在我们来聊一下本文的重点：平滑扩容中最好的方案就是扩容的数据库是原先数据库的倍数，如：2个数据库扩容到4个数据库，是原先的2倍。步骤：

（1）新增2个数据库

（2）配置双主进行数据同步（先测试，后线上，重启服务时间是秒级）

 

（3）数据同步完成之后，配置主主双写（因为同步有延迟，如果每时每刻都有数据写入/更新的话，就不能准确的保证数据已经同步完成）

 

（4）数据同步完成后（时间比较长），删除双主同步，修改数据库配置，并重启（秒级）；

 

（5）此时已经扩容完成，但此时的数据并没有减少，新增的数据库跟旧的数据库一样多的数据，此时还需要写一个程序，清空数据库中多余的数据，如：

1. User1去除 uid % 4 = 2的数据；
2. User3去除 uid % 4 = 0的数据；
3. User2去除 uid % 4 = 3的数据；
4. User4去除 uid % 4 = 1的数据。

现在，我们就已经完成了数据库的平滑扩容了。

 

优点

1. 扩容期间，服务照常进行，保证高可用；
2. 时间长，项目组压力没有这么大，出错率低；
3. 扩容期间，遇到什么问题，都可以随时调试，不怕影响线上服务；
4. 每个数据库少了一半的数据量。

 

缺点

1. 程序复杂，需要配置双主、主主双写、检测数据同步等额外技术；
2. 但后期数据库成千上万台的时候，扩容复杂（情况非常少，除非将很多业务数据放在同一个数据库）。

 

适用：

1. 大型网站；
2. 对高可用要求高的服务。

 

总结

本文主要简单讲解了数据库扩容的两种方案，并对这两种方案的优缺点、适用场景进行了说明：

• 停机扩容：简单，不高可用，易出错，扩容后不能回滚，只能回档，会丢失一部分数据。
• 平滑扩容：复杂，高可用，出错调试容易，易回滚，不会造成数据丢失，

 

结语

1. 每一种方案都有适合它的场景，适合自己的，才是最好的；
2. 小编经验有限，希望此文章对大家有帮助；
3. 每天进步一点点。

 

参考文献

58沈剑老师架构师之路的：数据库秒级平滑扩容架构方案