数据库分库分表平滑扩容方案

背景

参考博客1给出了一种所谓的平滑帅气的秒级扩容的架构方案，但我个人却认为，这个看似没有什么问题的方案在实际中几乎没什么用处，业界也几乎不会用这种方案来进行扩容（分库分表）。为了便于说明这一点，本文先简单回顾下该方案，然后分析该方案为什么没有用，最后给出三种业界广泛使用的分库分表的平滑扩容方案。

双主扩容方案回顾

如图所示，假设当前用户库user分布在两个实例上，ip0和ip1，服务层通过用户标识uid取模的方式进行寻库路由，模2余0的访问ip0上的user库，模2余1的访问ip1上的user库。

而一方面，互联网架构需要保证数据库高可用，常见的一种方式是，使用双主同步+keepalived+虚ip的方式保证数据库的可用性：

如上图所示，两个相互同步的主库使用相同的虚ip（vip），当前的主库挂掉之后，虚ip自动漂移到另一个主库，整个过程对调用方透明：

由此可知，在实际的架构中，既有水平切分，又有高可用保证，所以实际的数据库架构是这样的：

现在假设每个库1亿数据量，如何平滑扩容，增加实例数，降低单库数据量呢？三个简单步骤搞定。

第一步，修改配置

主要修改两处：

a）数据库实例所在的机器做双虚ip，原来%2=0的库是虚ip0，现在增加一个虚ip00，%2=1的另一个库同理

b）修改服务的配置（不管是在配置文件里，还是在配置中心），将2个库的数据库配置，改为4个库的数据库配置，修改的时候要注意旧库与辛苦的映射关系：

%2=0的库，会变为%4=0与%4=2；

%2=1的部分，会变为%4=1与%4=3；

这样修改是为了保证，拆分后依然能够路由到正确的数据。

第二步，