免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 57160 | 回复: 1

[其他] 一场完美的“秒杀”:API加速的业务逻辑 [复制链接]

论坛徽章:
0
发表于 2017-03-24 20:46 |显示全部楼层
作者简介:丛磊
白山合伙人兼工程副总裁
丛磊先生2016年加入白山,主要负责云链体系的设计与落实等工作。
丛磊先生2006年至2015年就职于新浪,原SAE(SinaAppEngine)创始人,曾任总负责人兼首席架构师,2010年起,带领新浪云计算团队从事云相关领域的技术研发工作。(注:SAE是国内最大的公有云PaaS平台,拥有70万用户。)
丛磊先生拥有两项发明专利,现任工信部可信云服务认证评委。


一天清晨,我被一个客户电话惊醒,客户异常焦急,寻问CDN能不能帮助他们解决秒杀的问题,他们昨天刚刚进行了整点秒杀活动,结果并发量过大,导致服务宕机,用户投诉。
为了理清思路,我问了对方三个问题:
1)服务宕机的表现是什么?
2)业务的基本架构什么样?
3)秒杀的峰值并发到多少?
顺着这些线索,我们先一起还原了应用场景:

某电商业务架构图

某电商业务架构图
该公司是一家P2P理财网站,常有用户在整点抢购高利率理财产品的整点秒杀活动。如上图所示,终端用户请求先通过前端负载均衡,然后到达运行实际电商逻辑的Web Server;再下层是运行在VM上的8台Redis,负责存储与业务相关的Cache数据,如用户Profile、理财产品信息、用户账单信息等。实际落地数据存储在MySQL,该MySQL进行了简单的分库分表及读写分离。
进行秒杀时,先由风控和运营人员选好理财产品,然后标记到数据库中;活动开始由产品人员放开,终端用户抢购。
该公司的业务主要来自移动端,平时流量较少,但秒杀活动时会瞬间产生大量流量,峰值并发达到10万以上(其中可能包括bot),如此大的并发主要是集中在以下两类接口:
- 对于理财产品的刷新接口类似GET /get_fprod.php?uid={$1}&pid={$2}&sid={$3}此类接口的请求量最多占比90%
- 对于理财产品的下单接口类似 GET /order_fprod?uid={$1}&pid={$2}&oid={$3}&sid={$4}此类接口的请求量较少占比不到1%,但存在大量504超时。
其中uid是用户IDpid是理财产品IDoid是订单号,sid是随着客户端用户变化的随机token标识。
场景解读
根据与客户沟通得到的场景,初步得到了以下结论:

1)客户以移动业务为主,产品通过API在客户端渲染UI,产品中几乎没有静态资源,带宽流量不高,传统CDN无法达到卸载压力的作用;
2)秒杀时,产生大量502/504超时请求,说明此时用户请求已超过服务端的业务承载能力,急需扩容。
基于以上两点,我没有建议该公司采购CDN服务,而是推荐服务扩容,但随着我方对于业务更深层次的分析,逐渐发现了一些诡异的事情。
“诡异”现象
1)数据库主从负载极不均衡,通过MySQL管理工具,发现主库的Query量高达80%
2)Redis Cache节点负载极不均衡通过查看redis info发现秒杀时其中一台Redis请求量极大占比达90%以上,其他Redis请求量却很低。
上述反常现象激起了双方技术人员的兴趣,这也许就是问题的关键!随着分析深入,第一个现象的原因浮出水面:该公司在使用数据库时,并未如某些大型电商平台一样使用数据库中间件层进行MySQL请求的路由分发,而是在业务代码端,使用语言层面的框架完成读写分离工作。这带来了个弊端:
- 程序员绕过语言层框架开发,并未真正实施读写分离
- 产品人员要求展现效果实时,倒逼开发人员修改业务逻辑,会牺牲读写分离,使数据都在主库读写
2.png
接着,第二个现象的原因也逐渐清晰:秒杀时,大量用户访问极少数理财产品,当这几个产品的pid恰好hash到同一个Redis,就会导致Cache节点热点失衡,所有请求最终集中在一个Redis,而这个Redis就是业务的瓶颈!
对症下药
1. 使用数据库中间件进行读写分离以及横向扩展控制
使用数据库中间件可以带来诸多好处,其中最重要的是可对业务层隐藏部分数据库细节,更好地控制业务。当然,引入数据库中间层也存在明显缺点,在业务整体架构中增加一层组件,违反了简单有效的设计原则。对于很多互联网公司,在早期甚至中期没有数据库中间层也很正常。 但当业务发展到一定阶段,引入数据库中间层是利大于弊的。
基于经验,我方推荐客户使用MySQL Route,基本可以满足简单需求,如:连接复用负载均衡读写分离。
3.png
上图是MySQL Router官方架构图可以看到MySQL Router优势在于插件化设计官方提供了一系列插件供使用。
MySQL Router国内还有很多开源数据库中间件可以采用如阿里、美团等。

使用数据库中间层,不仅可以解决性能问题,还能在安全方面起到作用,如审计、流量限制等,甚至拦截SQL注入、劣质SQL语句等。
2、使用API加速服务缓解服务端压力
Cache服务失衡是比较棘手的问题。秒杀时,用户高频访问少数几个理财产品信息,当其Cache数据恰巧分配在同一节点,大量请求会瞬间集中到台或少数几台节点,这就是Cache服务失衡的本质原因。不仅在电商“秒杀”场景中,其他有瞬间热点访问的业务类型也会存在这个问题。以微博为例,曾因明星热点事件导致接口缓慢甚至服务宕机,归根到底也是这个原因。“爆料”的瞬间,个微博会在短时间内海量传播,该微博ID被同时打开,所有流量会集中到一个Redis节点。
这个问题如何解决?首先,Cache通常以某个数据结构的key为维度进行hash存储,大量用户只访问个或几个key时,将导致Redis Cache节点负载不均衡,这是否一定对服务产生影响,则视并发情况而定,但这是一个巨大隐患。针对这个问题,客户提出了一种解决方案:把一个理财产品的Cache数据再拆散,1key变成多个,降低key被分配到同一Cache节点的概率。但这种存在很大弊端:
1)需要修改代码,原本一get请求就可以完成的逻辑,要换成多条才能拼成;

2)日常所有get/set操作的时间消耗都将成倍增加,因为1%热点事件增加99%常规操作的时间,严重违背二八法则
基于以上问题,我们推荐客户使用白山云聚合CLN-X的“API加速”来解决这个问题
API加速
API加速完全不同于传统CDN的链路加速,通过缓存API返回内容并结合TCP广域网优化技术,对API请求进行优化。白山API加速将每个APIresponse数据毫秒级缓存在全网边缘节点,节点内存中的response数据以LRULeast Recently Used)算法交换。在热点事件时,最热的信息持续保存在边缘节点,当客户端访问该API时,边缘节点可直接返回结果,不必返回源站。整个架构如下:
4(2).png
API加速服务在网络边缘节点提供对API的加速能力,包括:API返回结果缓存能力API请求回源网络加速能力。
传统观点认为,动态资源(API)无法缓存,但白山提出任何资源都可以被缓存,只是过期时间不同。对于常见的静态资源,缓存过期时间较长;而API并非不能被缓存,只是过期时间很短。如一个查询股价的API,可设定过期时间为50毫秒;百米运动员起跑反应时间为100-200毫秒,50毫秒对于PC端或移动端的用户体验并不会造成影响。
没有缓存时1秒内如有10000个用户同时访问,后端承受10000个并发;如果设置50毫秒的缓存时间,理论上可将后端并发降低到20个(1秒/50毫秒=20),后端负载降低至五百分之一,其他请求由缓存服务器直接返回给用户。
综上所述,白山API加速为客户提供毫秒级缓存,在不影响用户体验的前提下提高终端用户响应速度,同时降低服务端的业务负载压力。
API加速还支持自定义缓存规则,使其更贴近业务包括QueryStringHeaderPath三种类型针对场景设定如下规则
GET /get_fprod.php?uid={$1}&pid={$2}&sid={$3}每个理财产品都有独立ID产品信息不随用户ID和客户端随机信息变化因此Cache key忽略URI参数的{$1}{$3}/get_fprod.php?pid={$2}就是在边缘节点存储毫秒级的Cache key
缓存的过期时间如何确定呢?与业务相关,这需要对客户提供的脱敏日志进行分析,可初步设定过期时间为500毫秒,最后还需考虑RTT修正值,以适应广域网环境;RTTAPI加速服务自动捕捉并实时更新。
实际效果
通过为客户主要的瓶颈接口配置API加速服务,并在峰值时间,从以下两个维度对比API加速服务开启与关闭时的效果:
- 终端用户请求平均响应时间和响应码200比例
- 服务集群平均负载
最终效果如下:
5.png

6.png

7.png
如图A所示,峰值期间终端用户请求平均响应时间,从3秒左右压缩至40毫秒以内;如图B所示,峰值期间所有请求响应码200的比例从70%左右提升至100%;图C表示,峰值期间,后端CPU Idle10%左右提高至97%左右实测对比数据表明,API加速对降低平均响应时间、提升用户体验效果十分显著,在降低后端服务器负载方面效果更加明显,使用API加速的后端CPU Idle可保持在91%以上。
后续建议
数据库失衡和缓存Redis失衡问题已经解决,但除上述问题,还有很多环节可以改善:
1、队列服务异步化请求
目前客户最终落地数据库请求直接请求到MySQL,未经队列缓冲,建议使用队列服务排队处理峰值请求,其好处在于能在大访问量时对请求进行调度,并可控制实际到达数据库的并发,从而有效保护数据库后端。
2、API防火墙屏蔽恶意Bot
用户日志中含有大量明显且规律的扫描软件痕迹,如sqlmapfimap等,虽然尚未对业务造成较大影响,但却使服务端资源被占用。建议在负载均衡最前端对扫描行为予以屏蔽,以提高安全性,同时提升服务效率。除恶意Bot,抢单、刷单等行为也会对服务产生影响,建议使用API防护服务识别与拦截。
3、产品层考虑服务降级设计
该客户在整体业务上,没有服务降级设计,产品功能优先级未做划分,导致重要的数据库、Cache众多基础服务混杂。一旦秒杀导致数据库穿透等严重问题时,整体服务将不可用。这种情况应重新梳理业务单元,按照优先级切分基础服务,首屏、产品列表、购买、订单等信息优先级最高;其次是非重要功能,如评论、账单等;如果后端负载较大,必要时可直接舍弃次要功能,从而降低后端负载,保证服务稳定。
总结
解决类似整点秒杀活动的情景,是一个系统复杂的工程,就文中客户暴露出来的数据库负载不均匀、Cache缓存负载不均匀等问题,可通过采用数据库中间层和API加速等技术解决,最终可取得理想效果。
上述“秒杀”案例,只是API加速的一个典型应用场景,接下来我还会撰文对API加速问题进行更为系统的剖析。也欢迎业界同仁通过微信后台(baishancloud)与我们取得联系,一起探讨API相关话题。

论坛徽章:
0
发表于 2017-12-14 14:44 |显示全部楼层
We tend to forget that happiness doesn't come as aresult of getting sth. we don't have,but rather ofrecognizing and appreciating what we do have.
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP