炸!亿级数据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)删除冗余数据等收尾工作,数据量减半完成;
思路比结论重要,希望大家有收获。
炸!亿级数据DB秒级平滑扩容!!!相关推荐
- clickhouse 在货拉拉的应用实践,千亿级别数据实现秒级查询
作者:扬大平仔 前携程.网易高级工程师,现为货拉拉高级工程师.热爱技术,敢于将新技术用于项目实践. 前言 为了解决线上问题定位慢,相应不及时等问题.所以我们决定开发一套智能问题定位系统.对于我们的一些 ...
- 亿级数据,秒级响应!看Smartbi如何助力经济普查,把脉时代经济!
距离第一次经济普查工作已经整整 15 年,该项工作是我国经济发展进入 21 世纪进行的一项对重大国情国力的全面调查,是党中央国务院为正确认识国情,准确把握国力,科学制定国策而采取的一项重要举措. 然而 ...
- Quick BI产品核心功能大图(四):Quick引擎加速--十亿数据亚秒级分析
简介: 随着数字化进程的深入,数据应用的价值被越来越多的企业所重视.基于数据进行决策分析是应用价值体现的重要场景,不同行业和体量的公司广泛依赖BI产品制作报表.仪表板和数据门户,以此进行决策分析. 在 ...
- Quick引擎加速 - 十亿数据亚秒级分析
随着数字化进程的深入,数据应用的价值被越来越多的企业所重视.基于数据进行决策分析是应用价值体现的重要场景,不同行业和体量的公司广泛依赖BI产品制作报表.仪表板和数据门户,以此进行决策分析. 在利用BI ...
- 亿级流量场景下的平滑扩容:TDSQL的水平扩容方案实践
为帮助开发者更好地了解和学习分布式数据库技术,2020年3月,腾讯云数据库.云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙<你想了解的国产数据库秘密,都在这!&g ...
- destoon7.0对mysql5..7优化,实现单台几百万数据下秒级速度
destoon7.0对mysql5..7优化,实现单台几百万数据下秒级速度,可以缓解吃内存的情况,希望对大家有帮助 记得要备份数据,以防万一,代码附上 ALTER TABLE `destoon_sel ...
- uniapp返回上一页_一例万级写入并发,百亿级数据,毫秒级返回架构分享
肉眼品世界导读: 在互联网环境里,很多时候常常会有海量级别的订单,高并发,低延迟,不同的业务场景有不同的做法.更多优质内容请关注微信公众号"肉眼品世界"(ID:find_world ...
- 知乎1.3万亿条数据查询毫秒级响应,如何做到的?
点击"开发者技术前线",选择"星标????" 在看|星标|留言, 真爱 来自:孙晓光 | 责编:乐乐 链接:dzone.com/articles/lesson ...
- 上亿条数据(GB级)文件去重解决方案
1.准备待处理的文件 2.随便一个文件都有100000000条数据库,如果直接去重非常麻烦 3.一段php代码解决问题 define('FileIn', $argv[1]); $time_start ...
最新文章
- JavaScript基本知识
- Python matplotlib 绘制等高线图
- 网站的线下活动如何组织
- PHP5.4.3,有些插件不是你想用就能用的
- 一个SAP Marketing Cloud和Kyma的集成
- ip_forward
- 有关Botton的用法(二)
- 做一个聪明的前端开发者
- mysql 上级组织参数值_MYSQL组织结构设计构思(快速查上级和下级)
- [20170612]FOR ALL COLUMNS SIZE repeat(11g).txt
- 改善C#程序的建议2:C#中dynamic的正确用法
- 如何判断脸型测试软件,【图】脸型判断 教你非常准确的测试方法_脸型_伊秀美容网|yxlady.com...
- 使用Adobe Acrobat去除PDF文件签名
- 22牛客多校1 J.Serval and Essay (启发式合并)
- Lect1_Intro_RL
- qt学习之旅--MinGW编译FFmpeg(32bit)
- Android studio的ADBWifi使用
- 什么是时序数据?如何治理?
- 最新整理常见互联网公司职级和薪资一览!
- Web开发基础——CSS