1808亿次,16倍的超越!谈支付宝红包的高并发挑战

  • 时间:
  • 浏览:0

为了更好地控制客户端的行为,参数化、配置化就成了必不可少的利器。但参数化、配置化带来了那我问题报告 :

与传统意义上的红包相比,近两年火起来的“红包”,似乎才是如今春节的一大重头戏。历经上千年时代传承与变迁,春节发红包早已成为历史沉淀的文化习俗,融入了民族的血脉。按照各家公布的数据,除夕全天微信用户红包总发送量达到200.8亿个,红包峰值收发量为40.9万个/秒。春晚直播期间讨论春晚的微博达到5191万条,网友互动量达到1.15亿,网友抢微博红包的总次数超过8亿次。

  • 接入层时要具备足够富裕的容量支撑,即使机会评估不准浪费主次机器也是能不都还可以 容忍的。接入层一旦出问题报告 ,所有业务将全军覆没。机会接入层足够健壮,当某个业务抗不住时,删改能不都还可以 通过限流来隔离有些业务,而有些业务不受任何影响。
  • 用户时不都还可以进得来。也太少太少我要保证用户能顺利登陆进来,机会用户连登陆都受限制,体验肯定好不都还可以不都还可以哪儿去。
  • 用户不都还可以玩起来。这是核心业务逻辑,机会咻都没哟咻,机会咻了半天红包机会福卡发没哟去,那也是致命的。
  • 不都还可以保证用户能传播和互动起来,包括分享、加好友、聊天。
  • 非核心业务时要进行合理分级。我们大致分了4档。第一档那我tab,非核心链路中的最高优先级,时要力保。第二档1级入口,容量时也不我平时的几十倍。第三档2级入口,容量是平时的十几倍。第四档,一、二、三档外的有些业务,要保证系统具备自我保护能力,底线是不都还可以不都还可以被压跨。
3)大规模生产系统全链路压测。核心链路和非核心链路梳理清楚了,进行了性能优化和系统扩容后,能不都还可以 达到我们预测的目标值,要靠线上全链路压测来验证。全链路压测相应的原则:核心链路时要删改覆盖,包括单独压测和混合压测,非核心链路要尽最大机会覆盖。经过项目组的努力,全链路压测基本覆盖了所有的核心链路和非核心链路,覆盖率接近200%。单系统或接口压测问题报告 不大,但混合压测就比较头痛,主要还是用户行为预测的问题报告 ,为了确保万无一失,在混合压测时组合出多个模型进行压测,尽最大机会暴露出系统的性能和容量问题报告 。

6) 实时数据计算能力:红包剩余个数尽机会实时准确显示。这里有那我细节,当咻咻的很久,红包剩余个数随着你咻咻在不停的递减,否则递减的个数比较平滑,不像有些App,老出长时间不动,动一次太少太少我断崖式变化。嘴笨 这是那我不起眼的细节,但我们为了给用户更好的体验,让没抢到红包的用户能在最短的时间内知道尽量准确的红包剩余个数,我们处理了有些技术问题报告 。

这里有有几个关键点,gateway的处理能力是千万级别,集中咻咻大概用掉了200万,剩下900万是给有些业务的。当少量咻咻请求没到gateway时,lvs和spanner不都还可以处理,给用户比较好的体验,不都还可以不都还可以老出任何限流问题报告 ,这也符合用户没哟中奖预期。我们的处理方案是,机会咻咻请求没到后端,给用户随机显示彩蛋(包括文案、图片、视频等)。对于spanner嘴笨 所处网络更外层,但也时要理解主次业务逻辑。比如不都还可以识别出不同的rpc请求,尤其是不都还可以区分出咻咻接口。机会spanner不做任何识别,只管向网关转发2000万请求,那肯定将导致 着转发的咻咻请求超过200万,而挤占了有些业务的配额,导致 着有些业务被spanner限流无法正常处理。

为了能有效地扛住瞬间峰值对CDN的压力,我们对资源进行了有效的管理和控制。首先在客户端预埋了有几个缺省资源,万一真不行了,这有几个资源能不都还可以 用。其次尽量提前打开入口,当用户浏览很久,就将资源下载到本地。再次浏览时不再时要远程访问CDN。最后,做了应急预案,高峰期一旦发现流量告警,紧急从视频切换到图片,降低传输速率压力,确保不老出传输速率欠缺而所处限流导致 着的黑屏等体验不好的问题报告 。

原文链接:http://www.infoq.com/cn/articles/alipay-high-concurrency-challenge

2)从钱包9.0开始,我们机会开始布局生活服务平台,有些版本搭建起社交和口碑那我平台的雏形,架构上从移动互联网金融架构扩展出能支撑生活互动型的架构,形成了支付+互联网金融+生活互动的混合架构,有些架构体系既能支持移动互联网金融的高可用、资金安全、高弹性伸缩,又能支持生活互动型架构的轻巧、灵便、弹性十足的特点。架构示意图如图2所示。

为此,InfoQ策划了“春节红包”系列文章,以期为读者剖析各大平台的红包活动背后的技术细节。本文为支付宝篇。

没哟超大规模的活动,肯定所处太少太少技术难点,平时看不起眼的那我问题报告 ,在超大规模情形下,就机会被放大。接下来简短总结哪些技术难点。

  • 应用架构时不都还可以不都还可以 大规模扩容。机会架构不合理,即使有服务器也没哟扩容,刚好在架构演进的过程中,支付宝App服务端进行了LDC单元化改造,扩容对我们来说so easy。
  • 模型要尽量准确。模型不准确的后果是用户的行为习惯和预期不同,导致 着主次业务压力一阵一阵大,无法正常提供服务,而另外主次服务器十分空闲,占着机器资源不干活。
2)核心链路和非核心链路彻底梳理。核心链路梳理和非核心链路梳理相对比较容易,注意以下5点。

5) 资源管理:在这次春晚活动中,涉及到少量的资源,包括图片、拜年视频等。图片和视频都比较大,十几b到几百kb不等。当在高峰期时,机会瞬间有海量的请求到CDN上,没哟大的请求传输速率根本扛不住。我们当时预估了大概有几T的传输速率需求。

                                                                            图2 总体架构示意图

为了保证整个春晚顺利进行,我们在以下一三个小方面做足了功课。

感谢郭蕾对本文的策划,感谢陈兴璐对本文的审校。

7) 全链路压测:支付宝有一套非常强大的线上环境压测的利器,不不都还可以模拟出你所很久的任何请求场景。对于参与用户量非常大的活动,前期再完备的准备,太少太少我能 确保一定没哟问题报告 ,时要对线上环境进行性能压测。在全链路压测机制下你不仅仅能不都还可以 知道各个应用系统的容量水位和目标之间的差距,还不不都还可以知道整个基础设施层,比如数据库、网络、存储等的瓶颈,我能 不不都还可以根据压测数据进行快速决策。

我们充分利用了那我方面的能力。一是实时的流式计算处理能力,能不都还可以 在秒级架构设计 各个服务器处理的红包个数,否则进行汇总计算,并把有些计算结果写在缓存中。此人 面我们充分利用每个请求头的控制信息,在用户每次请求的同時 带回剩余个数。客户端收到应答后,机会发现本次请求没哟中奖,从头部控制信息中解凝固红包剩余个数并正确显示。

编者按

2015年12月份,我们在第一时间得知支付宝中标央视消息后,既兴奋又担心!兴奋的是,这是一次千载难逢的机会,我们终于能不都还可以 一展身手。担心的是,支付宝和央视联合搞活动,是我们有史以来最大规模的活动,到底规模多大,我们没哟任何概念。唯一能得到的信息是,历年观看春晚的人数大概在7亿多,支付宝的年度活跃用户4亿多,至于用户的行为习惯,没哟任何参考模型。

                                                         图1 架构演进示意图

5) 上千个业务、技术预案和完备的应急响应体系支持。业务上主要参数化、配置化,通过服务端来控制客户端的行为,以满足业务多样性需求,降低客户端版本升级困难带来的冲击。技术上预案分为提前预案和应急预案。提前预案主要作用是让服务器轻装上阵,将计算能力节省下来供核心功能使用,比如降级日志、关掉定时任务等。而应急预案更主太少太少我用来保命的,万一系统在有些点老出了意外情形,会通过所谓的大招以牺牲主次非核心业务来保核心业务,也太少太少我丢卒保车。当然春晚机会前期工作做得比较到位,哪些大招都深藏闺阁,没机会施展。

用户“咻一咻”在第二场活动达到高潮,累计互动次数达到12008亿次,是去年的16倍。20点38分,“咻一咻”峰值达到177亿次/分钟。能不都还可以 想象一下,几亿用户同時 拿着手机,以想戳透手机屏幕的传输速率点击咻咻按钮,几亿的请求瞬间从客户端洪水般涌入服务端,对后台将是多大的压力!没哟高并发情形下,机会系统设计不合理机会预测模型不准确,将立即被冲垮,应用系统一旦被冲垮,高压下根本没哟恢复的机会。

对于配置的实时架构设计 ,我们单独做了一套机制,使用推拉结合的法子 ,在最短的时间内架构设计 配置信息。以服务端推送为主,通过sync机制,假若用户在线,尽最大机会将配置数据推送到客户端,万一有少量配置推送失败,还能不都还可以 通过拉的法子 进行补偿,另那我确保了配置数据一定能架构设计 到客户端。

嘴笨 心里否是很有谱,但也没没哟担心,信心来自于两方面。

团队在拿到中标信息后,我们很快了 了 决策,达成了以下指导原则:优先确保核心链路,保证核心链路上用户体验顺畅。万一老出系统容量欠缺,系统时不都还可以扛住洪峰,不被压垮,即使有些情形下也要给用户尽量友好的提示文案。在确保主链路基础上,还时要照顾到支付宝App内几百个非关键链路,对于非关键链路按照业务重要程度分为那我等级,根据等级分配不同的资源配置。

1)经历过没哟多年的双11和去年的除夕,多年经验的沉淀,我们对超大规模的活动沉淀总结出一整套预测模型,否则有些预测模型经过了多次实战检验,相对比较准确。

2016年春晚在轰轰烈烈中过去了,我们收获了太少太少,其中最重要的有些是我们对春晚的用户行为有个初步的了解,机会再搞有些超大规模的活动,预测模型将更加精确。机会2017年央视春晚我们继续中标,我们将做得更加从容,更加顺滑,真正做到喝着咖啡过春晚!

8) 超大规模活动弹性计算能力:没哟大规模的活动,初步计算下来,大概时要几万台机器,包括应用服务器、存储、网络设备等。对于没哟少量的资源调配,机会没哟金融云高弹性能力,短时间内部署完成,这是不可想象的。得益于金融云的高弹性能力,我们基本做到在1周内完成了相关资源的调配部署。

4) 高频次灰度内测和线上小规模活动预热(2月1日和2月4日两次小规模活动)。高频次的内部灰度测试更主太少太少我能 暴露出有些比较隐蔽的功能问题报告 ,能进行充分的业务配置演练。而两次小规模预热则起到了更大的作用,嘴笨 规模没哟春晚大,但用户行为习惯具备一定的参考性,不都还可以相对真实地模拟春晚活动。我们在这两次预热活动中嘴笨 也发现了有些问题报告 ,否则根据相对真实的用户行为习惯对系统容量进行了调整和优化,有效地处理了春晚老出资源分配不均的问题报告 。

3)活动奖品控制系统:春晚一共搞了4场活动,大概发了2.3亿个现金红包和十几亿张福卡。在没哟大规模的活动下,我们做到了0差错0资损,没哟多发机会少发那我红包,严格控制了福卡的发放比例,也合理控制了发奖传输速率。4场活动基本控制在3-5分钟内完成,严格按照我们设定的预期模型执行。所哪些都得益于我们的奖品控制系统,对于有些系统设计上有一三个小基本原则。

1) 登陆:去年除夕,我们登陆上容量做的欠缺,导致 着用户在登陆时就被挡在门外。本次春晚,我们做了硬性规定,时不都还可以顺利登陆进来,坚决不允许老出机会登陆系统处理能力欠缺而导致 着老出限流有些很不好的体验。去年的登陆峰值大概在十几万每秒,今年我们提出实现百万登陆能力,有些量是平时量的200倍左右,也是去年除夕峰值的6、7倍,而我们用户数量也仅仅增长了2,3倍,百万级别应该没哟问题报告 ,而实际上登陆量嘴笨 也在有些数量级。

目标选择好了,接下来比较难的太少太少我要怎样做到有些系统容量目标。性能优化和扩容两手抓,否则更多的是要靠性能优化,作为有追求的工程师扩容不应该是首选。经过那我月左右极致的性能优化,最终机器仅仅扩容到另那我的4倍,大概在几千台,有些的提升删改通过性能优化实现。

                                                                                图3 网络漏斗模型示意图

蚂蚁金服旗下的支付宝经过十几年的发展,从简单的支付工具逐步发展成互联网金融平台。2013年余额宝的崛起太少太少我互联网金融平台升级的标志型事件,有些年支付宝顺利进行了PC向无线的布局,能不都还可以 说架构成功升级到移动互联网金融平台。经过两年的发展,2015年口碑和社交业务的崛起让支付宝架构进一步在原有架构基础上拓展出支持线下市场和社交的生活互动型架构。2015年钱包9.0的发布,有些里程碑式的项目初步奠定了支付+移动互联网金融+生活互动型混合架构。演进示意图如图1所示。

(图3是简单的架构示意图):能不都还可以 想象,几亿用户同時 在线,在几乎同一时刻进行咻咻操作,瞬间洪水般流量直接冲进来,当时秒级峰值达到了2.95亿次。对于没哟大的流量,我们使用了漏斗形的分流、导流方案。客户端请求到我们的网络设备后,从应用视角我们大体分为三层LVS、spanner、gateway。这儿我能 看作那我漏斗,越往里层,能不都还可以 处理的请求越小。嘴笨 没哟设计,还是基于业务和用户体验,对于咻一咻,嘴笨 有2.95亿次请求,但我们的奖品个数是有限的,每场不都还可以不都还可以20000万个现金红包和上亿张福卡。机会发奖能力达到了20000万每秒,那20000万个现金红包瞬间被秒光,这太少太少我是业务和用户看到到的。我们平衡下来,将奖品(现金红包+福卡)发放能力设定在200万每秒,大概能不都还可以 在几分钟内顺利发完这20000万个现金红包。

本文转载自 InfoQ

1)相对合理的超大规模压力预测模型。前提约束条件要说明下,服务器资源是有限的。总共没哟多服务器,要充分利用起来时要那我条件。

:客户端的那我最大的问题报告 太少太少我版本发布,有个成语叫做“覆水难收”,刚好比较形象地说明了有些问题报告 。版本一旦发布,机会有问题报告 时要让用户再次升级,时间机会来不急了。

经过那我月的精心准备,在激动人心的4小时开始后,整个春晚支付宝系统稳稳地扛住了4波洪峰,表现平稳,无论是核心链路还是非核心链路,没哟老出任何问题报告 。那我小时内几乎没哟用户机会系统、功能上的问题报告 而产生投诉,客服同学没哟任何咨询压力。

最后的结果能不都还可以 用完美来形容,机会预热充分,传输速率嘴笨 很高,但没达到我们的告警值,应急预案也没哟使用。

  • 客户端预埋了太少太少逻辑,极大的增加了代码繁杂度,客户端的代码测试难度加大,质量真难保证。
  • 机会参数化、配置化,时要有机制不不都还可以保证配置数据能尽机会实时架构设计 给几亿客户端,否则在最短的时间内生效。
对于客户端繁杂度增大的问题报告 ,主要通太少套机制保障。