一步一步,炸亿娓娓道来。数据D级平 一般来说,滑扩并发量大,炸亿吞吐量大的数据D级平互联网分层架构是怎么样的? 数据库上层都有一个微服务,服务层记录“业务库”与“数据库实例配置”的滑扩映射关系,通过数据库连接池向数据库路由sql语句。炸亿 如上图所示,数据D级平服务层配置用户库user对应的滑扩数据库实例ip。 画外音:其实是炸亿一个内网域名。 该分层架构,数据D级平如何应对数据库的滑扩高可用? 数据库高可用,很常见的炸亿一种方式,使用双主同步+keepalived+虚ip的数据D级平方式进行。 如上图所示,滑扩两个相互同步的主库使用相同的虚ip。 当主库挂掉的时候,虚ip自动漂移到另一个主库,整个过程对调用方透明,通过这种方式保证数据库的高可用。 画外音:关于高可用,云南idc服务商《互联网分层架构如何保证“高可用“?》专题介绍过,本文不再展开。 该分层架构,如何应对数据量的暴增? 随着数据量的增大,数据库要进行水平切分,分库后将数据分布到不同的数据库实例(甚至物理机器)上,以达到降低数据量,增强性能的扩容目的。 如上图所示,用户库user分布在两个实例上,ip0和ip1,服务层通过用户标识uid取模的方式进行寻库路由,模2余0的访问ip0上的user库,模2余1的访问ip1上的user库。 画外音:此时,水平切分集群的读写实例加倍,单个实例的数据量减半,性能增长可不止一倍。 综上三点所述,大数据量,高可用的亿华云互联网微服务分层的架构如下: 既有水平切分,又保证高可用。 如果数据量持续增大,2个库性能扛不住了,该怎么办呢? 此时,需要继续水平拆分,拆成更多的库,降低单库数据量,增加库主库实例(机器)数量,提高性能。 新的问题来了,分成n个库后,随着数据量的增加,要增加到2*n个库,数据库如何扩容,数据能否平滑迁移,能够持续对外提供服务,保证服务的可用性? 画外音:你遇到过类似的问题么? 停服扩容,是最容易想到的方案? 在讨论秒级平滑扩容方案之前,先简要说明下停服务扩容的方案的步骤: 整个过程中,最耗时的是第四步数据迁移。 如果出现问题,如何进行回滚? 如果数据迁移失败,或者迁移后测试失败,则将配置改回旧库,恢复服务即可。 停服方案有什么优劣? 优点:简单。 缺点: 画外音:这一点很致命。 有没有秒级实施、更平滑、更帅气的方案呢? 再次看一眼扩容前的架构,分两个库,假设每个库1亿数据量,如何平滑扩容,增加实例数,降低单库数据量呢?三个简单步骤搞定。 步骤一:修改配置。 主要修改两处: 数据库实例所在的机器做双虚ip: 修改服务的配置,将2个库的数据库配置,改为4个库的数据库配置,修改的时候要注意旧库与新库的映射关系: 画外音:这样能够保证,依然路由到正确的数据。 步骤二:reload配置,实例扩容。 服务层reload配置,reload可能是这么几种方式: 不管哪种方式,reload之后,数据库的实例扩容就完成了,原来是2个数据库实例提供服务,现在变为4个数据库实例提供服务,这个过程一般可以在秒级完成。 整个过程可以逐步重启,对服务的正确性和可用性完全没有影响: 完成了实例的扩展,会发现每个数据库的数据量依然没有下降,所以第三个步骤还要做一些收尾工作。 画外音:这一步,数据库实例个数加倍了。 步骤三:收尾工作,数据收缩。 有这些一些收尾工作: 画外音:这一步,数据库单实例数据量减半了。 总结 互联网大数据量,高吞吐量,高可用微服务分层架构,数据库实现秒级平滑扩容的三个步骤为: 思路比结论重要,希望大家有收获。 【本文为专栏作者“58沈剑”原创稿件,转载请联系原作者】 戳这里,看该作者更多好文