本文转载自微信公众号《sowhat1412》，作者sowhat1412。转载本文请联系sowhat1412公众号。Introduction第一版如果我们的在线服务不是很重要，一般可以使用单一的数据库DB来存储数据。单一申请的优点：简单、轻松、方便。缺点：数据的并发性和稳定性存在问题。进阶随着数据量的不断增加，一般我们需要对数据进行水平拆分。按照水平拆分的规则，可以简单的按照用户id或者用户IP对数据进行建模，实现路由功能。当然也可以加入Slave和KeepAlived来实现高可用。主从+路由但是问题来了，如果随着业务的发展，我们两个库的性能目前无法应付，还需要继续横向拆分，创建更多的库？你通常如何实现丝滑扩展？什么？扩容第一版：宕机扩容一种简单、直接、暴力的宕机扩容方法。APP通知用户在一定时间内关机维护升级。创建几个高度可用的库。停止当前服务，然后编写数据迁移程序，将旧数据库中的所有数据迁移到新数据库中。修改代码路由规则后重新对外提供服务。优点：简单缺点：中途停止服务，无法保证高可用。确保数据切换之前和期间没有错误。SecondEdition:OnlineDoubleWritingOnlineDoubleWriting创建一个新的数据库，然后用户在写原数据库的同时，将数据的副本写入到我们的新数据库中。编写数据迁移程序，将历史数据从旧数据库迁移到新数据库。在迁移过程中，每次插入数据时，都需要检测数据的更新。比如新表中没有当前数据，直接添加；如果新表有数据，并且不比我们要迁移的数据新，我们就更新为当前数据，只允许新数据覆盖旧数据。推荐使用Canal作为中间件。一段时间后，需要验证新旧数据库两边的数据是否相同。如果发现相同，直接切换即可。优点：可用性高。缺点：不够流畅，来回移动数据比较大。第三版：如丝般顺滑扩容目标：打算将原来的两个数据库扩容为四个。第一步：修改配置修改配置修改配置信息，注意旧库和新库的映射关系。确保扩容后数据能够正确路由到服务器。Id%2=0的库变成id%4=0orid%4=2Id%2=1的库变成id%4=1orid%4=3第二步：reloadconfiguration服务层reloadconfiguration，可以重启服务，也可以配置中心发送类似CLoud的信号重新读取配置文件。至此，数据库的2-->4扩容完成。原来是2个数据库实例提供服务，现在是4个数据库实例提供服务。第三步：收缩数据，平滑扩容。此时id为%4=0和id为%4=2的两个DB还在同步数据。id%4=1和id%4=3的两个DB还在同步数据。需要一些收尾工作。触摸上面的两个同步操作。为新库创建高可用性。删除冗余数据，例如从id%4=0的机器上删除id%4=2的冗余数据，只为id%4=0的数据提供服务，其他三者操作类似。至此，实现了双扩，避免了数据迁移。
