业务请求量膨胀的扩容技术实践

项目早期无论是从成本考虑，或者是业务模型考虑，往往难以估量长期的业务变化发展，尤其是数据库的扩容，项目的设计成员往往会单纯得以为，等到数据量膨胀以后，直接扩容数据库的规格，通过堆硬件的方式来解决数据库负载的问题。

在笔者的从业经验来看，这样的思想几乎是行业的“主流思想”，这也无可厚非，从业务角度，底层做得越透明，往往是越成功的。但从数据库的角度来看，单纯的堆硬件扩容依然存在非常大的性能隐患。

如果早期的时候，使用了8C 16G的RDS规格，以支撑1w QPS的数据库吞吐还算合情合理，等到业务发展到一定规模，业务请求成倍数增长，通过扩容规格，却发现难以支撑更高的请求量。这当中有多个原因：

并发带来的锁的问题，影响了吞吐的提升。

1w QPS提高到2w QPS不是简单的2倍概念，如果有热点问题，虽然请求量提高1倍，但在数据库中，QPS却提高不到1倍，这就是因为锁会阻塞并发的请求。

请求并不是平均的，而是有峰谷的。

峰值的请求往往伴随热点的争抢，针对热点的优化，我们在《云数据库架构》一书的2.3节中将详细阐述优化的方案。

这当中有多种思路。

01
使用分布式削峰

如《云数据库架构》第一章节介绍的，share nothing模式的分布式，就是一个典型的解决方案。因为sharding的方式，可以相对随机的切割分表，热点有概率会被切割到不同的分表上，这等价于把一把大锁，分拆到多把小锁里，锁的等待队列会变短。

这里举一个新零售行业的例子，来看看分布式削峰如何破局。我们知道，零售行业的业务请求量，除了搞活动的时间窗口以外，主要是和线下门店、线上网店的数量和规模有关。同时，除了订单系统外，容易忽略的是，订单背后的复杂采购、库存、划拨等一系列操作，都要落账，都是数据库的行为。

因此，当规模达到一定程度，不仅数据量剧增，更棘手的是，促销的常态化，流量请求变得更加集中，多点写入导致冲突更加频繁，等待时间冗长；同时，报表系统不堪重负，负载的SQL难以跑出，甚至要等待二十分钟。

围绕这个特点，我们通过改造成PolarDB-X的分布式集群，可以支持客户15-25TB的数据容量，同时支撑1.5W TPS, 20W QPS，解决峰值压力的问题。

第一步，我们要梳理业务，把相对独立的业务，做资源隔离。比如订单系统，和库存系统的数据，就分开存放，方便管理，也能保证系统之间尽可能解耦，避免相互资源竞争。

第二步，就是做水平拆分。通过PolarDB-X的水平拓展能力，把核心业务库表进行平拆，分散到不同的底层物理RDS。因为第一步已经从业务上隔离了，所以即使分散到不同的物理节点，但业务在物理节点上也等于上隔离的。

水平拆分的重要性，就是为了支撑前面谈到的容量和请求量，用更多的分布式节点，来支撑更多的业务请求。之前的热表，比如库存表，因为被打细以后，及时多个门店来提交信息，也能够从容应对并发。

水平拆分的另外一个重要性，是给系统留有弹性。比如当前的规模只需要128Core的集群，但如果规模需要提高，水平拆分的系统具备更好的拓展性，可以很快的提升规模。

第三步，解决了实时性要求高的并发请求后，就要着手解决报表的问题。

PolarDB-X 支持两种解决方案。

一种是传统的，读写分离方案。

本例中，当时客户也是选择使用PolarDB-X的只读集群，抗住常规只读请求，特别复杂的计算，通过DTS，同步到ADB for MySQL里，通过ADB 来解决。ADB的强大计算能力，原本十几分钟的报表，现在30秒内就能计算完成。

这个方式比较主流，TP 业务使用TP分布式系统解决，AP业务使用AP数据库解决，中间链路使用DTS搭起桥梁。

另一种方案，是使用PolarDB-X的HTAP 能力来支持。

TP流量依然使用TP引擎来支撑，同时一套MPP架构的只读集群，可以支持相关的业务请求。这就去除了DTS的中间链路，把数据分布方式、计算器全部做在了存储引擎层面解决。

通过以上三步，再稍微做一些精修，比如增加一组全局Redis来扛起请求量，部分冷数据可以直接归档到OSS里，就得到了我们最后的结构。

通过这个例子，我们可以看到削峰的思想非常重要，在解决TP峰值的同时，还可以顺手分流AP的流量，通过合适的引擎来解决。

02
用缓存技术，代替单一的关系型强一致请求题

并不是所有数据库请求都是强一致，需要同步返回的。

理解这点，在代码层面的意义就是，并不是所有数据库请求，都需要使用事务。

举一个具体的场景来说明业务请求量的膨胀，比如秒杀场景，秒杀的时候，业务请求是远超平时的量，单纯的堆硬件往往无法还是会被热点锁，把系统打死。

秒杀系统的流量虽然很高，但是实际有效流量是十分有限的。利用系统的层次结构，在每个阶段提前校验，拦截无效流量，可以减少大量无效的流量涌入数据库。

下面是比较通用的分层拦截流量的主要步骤，对每个步骤的具体实现的讲解详见《云数据库架构》书籍内容，在此限于篇幅不再展开。

利用浏览器缓存和CDN抗压静态页面流量。
利用读写分离Redis缓存拦截流量。
利用主从版Redis缓存加速库存扣量。
使用主从版Redis实现简单的消息队列异步下单入库。
数据控制模块管理秒杀数据同步。

本文摘自《云数据库架构》一书，本书全面介绍了主流数据库的技术特点，并结合业务场景讲解了数据库技术选型和数据库架构的最佳实践，欢迎阅读本书了解更多云数据库架构的内容！

▊《云数据库架构》

朱明等著

引领云数据库技术，详解9大云数据库引擎，5大行业技术选型！

阿里云数据库产品事业部总裁、达摩院数据库与存储实验室负责人李飞飞力荐

“阿里云数字新基建系列”包括5本书，涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维（Windows），囊括了领先的云技术知识与阿里云技术团队独到的实践经验，是国内IT技术图书又一重磅作品。

数据库技术，被称为“计算机三驾马车”之一，几十年来，持续支持着全球亿万数字业务的运行，而云计算的出现，赋予了数据库新的能力。云数据库按引擎能力，可以分为关系型数据库、非关系型数据库、数据仓库和分布式新型数据库。本书从技术原理入手，讲解各种数据库的特点，分析不同场景的架构选型和数据库优化，继而展开到云数据库的迁移、云数据库的运维工作，期望能帮助读者了解和掌握云数据库相关知识与技能。

（京东满100减50，快快扫码抢购吧！）

业务请求量膨胀的扩容技术实践相关推荐

日均请求量百亿级数据处理平台的容器云实践
from: http://geek.csdn.net/news/detail/97887 声明:本文为CSDN原创投稿文章,未经许可,禁止任何形式的转载. 作者:袁晓沛,目前在七牛云的主要工作是基于 ...
神策数据实战学堂开课，分享行业最佳业务和技术实践
近来,"数据驱动"概念大热,从精益分析到增长黑客,处处都有神策数据的身影.专题沙龙.数据驱动峰会.分析师培训营.在线公开课等,我们一直走在探索数据驱动的道路前沿,致力于帮助用户实现 ...
vc idispatchimpl 怎么实例化_京东APP订单业务楼层化技术实践解密
用户体验关键影响因素京东订单业务,主要负责为京东用户提供下单后订单的信息全面展现,用户在下单后会不断关注自己的订单状态变化,还有可能在购买后的一段时间内查询历史订单,并进行商品的复购.订单业务承载着 ...
技术分享 | 业务模板的技术实践
源宝导读:"业务模板"作为天际·建模平台3.0推出的重要特性,它将元数据复用发挥到了极致,通过业务模板几乎可以覆盖整个建模元数据开发流程,提供业务场景级别的复用能力.本文将介绍&q ...
亿级流量场景下的平滑扩容：TDSQL的水平扩容方案实践
为帮助开发者更好地了解和学习分布式数据库技术,2020年3月,腾讯云数据库.云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙<你想了解的国产数据库秘密,都在这!&g ...
系统“烂”怎么办？请看资深专家拆分改造实践
上一篇:追根溯源 - 数据中台概念的起源本篇文章作者给大家分享一个复杂系统的拆分改造实践! 图片来自 Pexels 为什么要拆分? 先看一段对话: 从上面对话可以看出拆分的理由: 应用间耦合严重.系 ...
周锦民：腾讯在线教育视频互动直播间技术实践
本文来自腾讯云技术沙龙,本次沙龙主题为在线教育个性化教学技术实践演讲嘉宾:周锦民 | 2011年毕业进入腾讯, 现任在线教育部在线教育后台中心高级工程师,多年linux后台开发工作经验,目前主要负责 ...
1688 复杂业务场景下的 Serverless 提效实践
前言首先为大家简单介绍一下我们的业务场景,1688 隶属于阿里集团的国内贸易事业部(CBU),是阿里最早起家的业务,已有十几年的历史.我们主要负责 PC 端 1688.com 以及手机端阿里巴巴 A ...
亿级用户百TB级数据的 AIOps 技术实践之路（增强版）
作者简介周荣,华为消费者BG云运维部 AIOps 负责人,GOPS 2018 深圳站金牌讲师,07年加入华为,先后分别负责下一代智能网.中间件平台.运维工具等产品的研发与规划,在分布式系统.大数据分 ...
知乎技术分享：知乎千万级并发的高性能长连接网关技术实践
本文来自知乎官方技术团队的"知乎技术专栏",感谢原作者faceair的无私分享. 1.引言实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你 ...

业务请求量膨胀的扩容技术实践

业务请求量膨胀的扩容技术实践相关推荐

最新文章

热门文章