炸！亿级数据DB秒级平滑扩容

一步一步，娓娓道来。

通常来讲，并发量大，吞吐量大的互联网分层架构是怎么样的？

数据库上层都有一个微服务，服务层记录“业务库”与“数据库实例配置”的映射关系，经过数据库链接池向数据库路由sql语句。

 

 

如上图所示，服务层配置用户库user对应的数据库实例ip。

画外音：实际上是一个内网域名。

该分层架构，如何应对数据库的高可用？

数据库高可用，很常见的一种方式，使用双主同步+keepalived+虚ip的方式进行。

 

 

如上图所示，两个相互同步的主库使用相同的虚ip。

 

 

当主库挂掉的时候，虚ip自动漂移到另外一个主库，整个过程对调用方透明，经过这种方式保证数据库的高可用。

画外音：关于高可用，《互联网分层架构如何保证“高可用“？》专题介绍过，本文再也不展开。

该分层架构，如何应对数据量的暴增？

随着数据量的增大，数据库要进行水平切分，分库后将数据分布到不一样的数据库实例（甚至物理机器）上，以达到下降数据量，加强性能的扩容目的。

 

 

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

画外音：此时，水平切分集群的读写实例加倍，单个实例的数据量减半，性能增加可不止一倍。

 

综上三点所述，大数据量，高可用的互联网微服务分层的架构以下：

 

 

既有水平切分，又保证高可用。

若是数据量持续增大，2个库性能扛不住了，该怎么办呢？

此时，须要继续水平拆分，拆成更多的库，下降单库数据量，增长库主库实例（机器）数量，提升性能。

新的问题来了，分红n个库后，随着数据量的增长，要增长到2*n个库，数据库如何扩容，数据可否平滑迁移，可以持续对外提供服务，保证服务的可用性？

画外音：你遇到过相似的问题么？

 

停服扩容，是最容易想到的方案？

在讨论秒级平滑扩容方案以前，先简要说明下停服务扩容的方案的步骤：

（1）站点挂一个公告“为了为广大用户提供更好的服务，本站点/游戏将在今晚00:00-2:00之间升级，届时将不能登陆，用户周知”；

画外音：见过这样的公告么，实际上在迁移数据。

（2）微服务中止服务，数据库再也不有流量写入；

（3）新建2*n个新库，并作好高可用；

（4）写一个小脚本进行数据迁移，把数据从n个库里select出来，insert到2*n个库里；

（5）修改微服务的数据库路由配置，模n变为模2*n；

（6）微服务重启，链接新库从新对外提供服务；

整个过程当中，最耗时的是第四步数据迁移。

 

若是出现问题，如何进行回滚？

若是数据迁移失败，或者迁移后测试失败，则将配置改回旧库，恢复服务便可。

 

停服方案有什么优劣？

优势：简单。

 

缺点：

（1）须要中止服务，方案不高可用；

（2）技术同窗压力大，全部工做要在规定时间内完成，根据经验，压力越大约容易出错；

画外音：这一点很致命。

（3）若是有问题第一时间没检查出来，启动了服务，运行一段时间后再发现有问题，则难以回滚，若是回档会丢失一部分数据；

有没有秒级实施、更平滑、更帅气的方案呢？

 

 

再次看一眼扩容前的架构，分两个库，假设每一个库1亿数据量，如何平滑扩容，增长实例数，下降单库数据量呢？三个简单步骤搞定。

 

步骤一：修改配置。

 

 

主要修改两处：

• 数据库实例所在的机器作双虚ip：

（1）原%2=0的库是虚ip0，现增长一个虚ip00；

（2）原%2=1的库是虚ip1，现增长一个虚ip11；

• 修改服务的配置，将2个库的数据库配置，改成4个库的数据库配置，修改的时候要注意旧库与新库的映射关系：

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

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

画外音：这样可以保证，依然路由到正确的数据。

 

步骤二：reload配置，实例扩容。

 

 

服务层reload配置，reload多是这么几种方式：

（a）比较原始的，重启服务，读新的配置文件；

（b）高级一点的，配置中心给服务发信号，重读配置文件，从新初始化数据库链接池；

无论哪一种方式，reload以后，数据库的实例扩容就完成了，原来是2个数据库实例提供服务，如今变为4个数据库实例提供服务，这个过程通常能够在秒级完成。

 

 

整个过程能够逐步重启，对服务的正确性和可用性彻底没有影响：

（a）即便%2寻库和%4寻库同时存在，也不影响数据的正确性，由于此时仍然是双主数据同步的；

（b）即便%4=0与%4=2的寻库落到同一个数据库实例上，也不影响数据的正确性，由于此时仍然是双主数据同步的；

 

完成了实例的扩展，会发现每一个数据库的数据量依然没有降低，因此第三个步骤还要作一些收尾工做。

画外音：这一步，数据库实例个数加倍了。

 

步骤三：收尾工做，数据收缩。

 

 

有这些一些收尾工做：

（a）把双虚ip修改回单虚ip；

（b）解除旧的双主同步，让成对库的数据再也不同步增长；

（c）增长新的双主同步，保证高可用；

（d）删除掉冗余数据，例如：ip0里%4=2的数据所有删除，只为%4=0的数据提供服务；

画外音：这一步，数据库单实例数据量减半了。

 

总结

 

 

互联网大数据量，高吞吐量，高可用微服务分层架构，数据库实现秒级平滑扩容的三个步骤为：

（1）修改配置（双虚ip，微服务数据库路由）；

（2）reload配置，实例增倍完成；

（3）删除冗余数据等收尾工做，数据量减半完成；

 

思路比结论重要

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：787707172，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。