高并发低成本场景“喊红包”系统的设计与实施

朱建勇，王乐，傅雷，代文章

(中央广播电视总台，北京 100866)

1 引 言

微信红包自从在2015年春晚上大放异彩之后，让人们传统思维中的“红包”产生了一个巨大的转型，同时也为传统广播电视与新媒体平台进行融合发展提出了一个新思路。很多媒体节目也都在尝试使用这种模式来增加节目效果及关注度，但想完成一次用户参与度高、体验效果好、投入成本低的中大型直播“喊红包”活动却并非那么容易。首先面临的问题就是技术平台如何才能处理瞬时爆发的巨大数据流量，往往抗住此类流量所要付出的代价是巨大的。2019年百度为央视春晚发红包活动调动了全球的供应链体系、全国的网络带宽，使用了10万台服务器才完成这项任务。可想要达到预期的效果花费是十分高昂的，很少有企业能够承担得起这么高的开销，因此，节目效果与投入成本成为了两难问题。

本文研究了如何利用公有云资源结合微信平台，设计与构建针对全国用户的低投入、高并发、低延迟的“喊红包”系统。

2 需求分析

2.1 企业需求分析

融媒体时代，传统媒体与互联网媒体融合，互相协作利用“红包”元素创造出很多成功案例，但也暴露出了一些问题。通常此类项目都会委托第三方新媒体技术服务提供商去完成发放红包的环节，但受限于预算以及合作方的规模、产品力等问题，发放红包的实际效果往往不尽如人意。例如，合作方计算资源处理能力不足，当并发数增大时会导致红包发送卡顿甚至是业务崩溃无法使用，而面对这种情况合作方通常束手无策，无法做出及时有效的应急响应，因为他们的资源和能力确实有限。再比如合作方产品较为固定，在短时间内很难满足用户的多变定制化需求。如果是跨地域、大用户量并发的场景，为了满足用户体验效果，就要选择规模更大的合作商，但这样又远超活动预算。

因此，委托第三方很多时候并不是最佳解决方案。利用互联网架构下的技术思路，使用成熟的互联网产品去解决高并发、弹性扩展、安全防护等问题，再配合自主研发的业务系统去处理多变的定制化需求，才是既节约成本又满足使用效果的可行方案。

下文将以2019年中央广播电视总台央广《中国声音中国年》直播节目为例，分析探讨如何设计并实现这一技术思路。

2.2 业务需求分析

该直播节目分六个时段，每时段由主持人公布“喊红包”口令，用户则通过央广新闻公众号发送对应的语音口令参与活动。口令正确有机会获得现金红包、优惠券、会员卡等福利，口令不正确或未中奖则接收明星主持人新春祝福语或央广商城推广页。

中奖流程如下图1所示：

图1 获得红包流程图

①用户通过手机微信发送正确红包口令到央广新闻公众号；

②微信平台将语音转换成文字后发送到网关系统；

③网关系统判断口令正确且业务系统运行正常，将信息发送给业务系统处理；

④业务系统判断是否满足中奖概率，判断结果为成功获得红包奖励；

⑤订单系统发送红包指令给微信红包模块；

⑥微信红包模块将中奖通知发送给用户；

⑦用户点击领取红包；

⑧用户收到现金红包。

活动前央广新闻公众号关注用户数为67万，要求用户必须关注该公众号才能参与本次活动，从而达到推广、宣传增加关注度的目的。各奖品发放需求如下：

•红包发放需求

①现金红包累计总金额100万，最终剩余红包现金额需低于2万元；

②所有奖品需可配置优先级；

③要求总时段红包数量大于60万个，红包每人限制领50个；

④每个时段可视发放情况及节目效果随时调整红包额度及中奖概率，发送红包金额最大可调整为58元；

•优惠券及会员发放需求

①央广商城优惠券和中国广播会员卡每个微信号限领一次；

②央广商城会员卡曝光率需高于50%。

整个活动的奖品发放逻辑既要满足用户体验，同时要兼顾自有业务的推广，根据需求合理设计红包和各类奖品的发放顺序。页面总浏览量需高于1700万次。

2.3 非功能需求分析

2.3.1 性能需求

响应时间：微信语音接口从发送请求数据到接收响应数据所需要的RT时间不得超过200毫秒。平均响应RT时间不超过100毫秒，高峰时段不超过500毫秒。系统容量：要求系统最大可承载每秒40W万次QPS(Query Per Second，每秒查询率)并发处理能力。资源使用率：活动中服务器CPU平均占用率≤80%，内存占用率≤80%。“喊红包”整体响应时长不得超过3秒。

2.3.2 安全需求

防护多种DDoS类型攻击，包括但不限于以下攻击类型：ICMP Flood、UDP Flood、TCP Flood、SYN Flood、ACK Flood 攻击。防御SQL注入、XSS跨站脚本、常见Web服务器插件漏洞、木马上传、非授权核心资源访问等OWASP常见攻击，并过滤海量恶意CC攻击，避免“喊红包”系统内部数据泄露，保障系统的安全与可用性。

2.3.3 可靠性需求

使用独立的基础设施，配置两个及以上可用区，不同可用区之间基础设施(网络，电力和空调等)相互独立，即一个可用区出现基础设施故障不影响另外一个可用区。所有服务资源(包括但不限于负载均衡SLB、云服务器ECS)，需具备当主可用区的机房故障或不可用时，可切换到另外一个备可用区的机房并恢复服务的能力；当主可用区恢复时，资源同样会自动切换到主可用区的机房提供服务。

2.3.4 高可用需求

系统需部署在电力和网络互相独立的不同物理区域内，将故障隔离在一个可用区中。系统需能够根据应用负载情况进行弹性扩容，做到任意一台设备故障或流量波动都不中断对外服务。

3 系统设计

3.1 系统设计原则

“喊红包”系统设计时，综合考虑了《中国声音中国年》直播节目的影响力及重要性，借鉴了先进的技术路线，采取全面的安全保护措施，保证系统体系的先进性、开放性和实用性。在满足系统功能及性能要求的前提下，尽量降低系统建设成本，采用经济实用的方式，利用互联网资源，综合考虑系统的整体费用。在符合标准化原则，遵循国家标准、行业和相关规范的同时，力争打造出在高并发场景下保证系统稳定性及用户体验的通用型产品，为后期类似业务的开展起到示范作用。

3.2 系统体系架构设计

根据对央广信息化系统的需求分析，提出符合“中国声音中国年”活动要求的“新春喊红包”系统的设计方案。利用微信开发者平台实现用户身份验证及语音转换功能，利用阿里云实现计算资源弹性扩展及安全防护功能。

系统总体架构设计如下图2所示，主要分为：表示层、业务逻辑层和数据层，这种架构确保了责任的明确划分，使系统更加易于维护和扩展。

图2 系统体系架构图

表现层位于最外层，是“喊红包”系统的系统管理、数据统计、用户参与界面，主要完成中奖参数变更、用户交流、参与人数和奖品发放量统计等工作；其中，央广新闻公众号页面由微信平台提供。

业务逻辑层包括网关系统、业务系统和订单系统，位于数据层和表现层之间，其可通过数据层提交的数据为表现层提供良好的数据支撑。

数据层是支撑整个系统的基础，使用阿里云RDS Mysql和RDS Redis存储中奖信息和配置信息，保证系统数据安全、数据流入流出高效。

3.3 系统基础架构设计

整体系统基础架构分为五层：接入层、网关层、业务层、数据库层和支付业务层，图3为系统基础架构图。

图3 系统基础架构图

3.3.1 接入层

接入层主要处理数据流量的接入和安全，中间使用阿里云的高防IP(DDOS)和WAF组件以阻挡网络三层、七层上的流量攻击和业务漏洞攻击。预计在喊红包活动中，可能出现的攻击手段是DDOS泛洪攻击、SQL注入和XSS注入攻击。通过使用阿里云高防产品，将正常的数据流量经过阿里高防集群，对流量进行清洗和梳理，卸载其中的异常流量，达到防治DDOS攻击的目的。针对SQL注入和XSS注入攻击，使用阿里云WAF等安全组件，梳理系统中所有的参数提交关键点，对异常代码、代码注入、恶意代码提交、代码语义篡改等行为进行审计和拦截，确保未经过安全审核的代码无法提交到系统中，保证系统在应用层面是安全可靠的。

3.3.2 网关层

网关层在整个系统基础架构中起到业务数据流量的接入及分发的功能。由标准的SLB负载均衡组件和Nginx服务器组成。其中，单台SLB能承担5万/秒的QPS并发。在SLB后接入的Nginx能承担2万/秒的QPS并发。从整体上看，网关层的接入性能较高，可以满足“喊红包”业务的高并发接入需求。使用Lua语言对Nginx层进行扩展，流量抵达Nginx层后，会根据条件判断返回用户中奖结果或者选择继续抵达业务层。通过代码对用户流量进行限流，实现后端业务层的并发性能可控，确保业务系统的性能安全。

3.3.3 业务层

业务层通过概率计算中奖的结果，并且将中奖信息、相关业务信息，例如用户身份数据等写入后面的数据库。为避免计算成本过高，在此层尽量不处理未中奖的情况。

3.3.4 数据库层

综合考虑数据库系统容灾，借助阿里云的一些逻辑复制工具，对数据库层的数据进行逻辑复制，避免数据库物理层面的故障，例如跨可用区实例，数据库实例三副本，以及数据库数据实时备份等等。其中，在高并发下的数据库高可用、容灾方案设计需要考虑的因素较多，因涉及到大量数据，实施起来难度较大。

3.3.5 支付业务层

支付层需要针对业务层产生的红包订单，进行计算和处理。根据微信的需求，在发红包速度上有一定限制，所以支付业务层定时成批处理数据库中的订单数据，调用微信接口对红包进行发送。在满足微信发红包限制的基础之上，需要将红包快速、稳定的发放到用户手中。经过三轮压力测试，最终实现了红包在10分钟之内发到用户账户的目标。

系统基础架构中的各个层次都综合考虑高可用和高并发，所有逻辑层中的计算资源(包括数据库)都实现跨区高可用，一旦发生系统宕机、整个可用区发生故障等灾难，会在第一时间进行无缝切换，将高并发下的活动影响降到最低。另外，在计算资源中除数据库外，均已实现系统资源的动态扩容。系统资源可在3-5分钟扩容翻倍，以应对活动中突发资源需求的挑战。

3.4 系统网络拓扑设计

所有服务器均部署在阿里云中，云下数据中心作为管理区域，对系统进行监控、调整。云上数据中心与云下数据中心使用两根不同运营商的专线连接在一起，并在链路中间部署物理防火墙，启用过滤功能防止未知流量进入，保护业务安全。防火墙开启冗余功能，当主用线路出现问题时，防火墙将自动感知并迅速切换到备链路，阿里云边界路由器同时感知故障，进行联动切换，切换过程会出现1至2个丢包，业务层不受任何影响。

如图4所示，阿里云内部按照业务创建四台虚拟交换机，分别为订单、数据库、业务、网关系统提供服务。每类业务对应的虚拟交换机分别部署于北京的两个不同机房中。可用区之间通过边界路由器VBR相连，为红包业务提供负载冗余能力，当某一可用区出现问题时，另一可用区将直接接管，承担所有业务功能。使用阿里云200M互联网出口并针对支付区配置SNAT，使支付区可与互联网通信，将NAT规则升配至超大型，最大支持200万连接数，保障红包业务平稳运行。

图4 系统网络拓扑结构图

3.5 系统接口设计

“喊红包”系统通过与微信开发者平台的API做集成，实现微信公众号各项功能的对接。外部接口按数据流向可分为上行接口和下行接口。各类接口需满足表1的规则。

3.5.1 上行接口

实现用户身份确认，对接微信语音输入转文字的结果数据，将微信公众号中的语音喊红包的结果输入到网关系统的概率逻辑控制模块，完成语音输入的上行功能。

接收用户语音消息：当用户发送消息给公众号时(或某些特定的用户操作引发的事件推送时)，会产生一个POST请求，“喊红包”系统在响应包(Get)中返回特定XML结构，来对该消息进行响应。严格来说，发送被动响应消息其实并不是一种接口，而是对微信服务器发过来消息的一次回复。接收微信的语音转文字XML内容接口，微信返回语音格式如表2。

表1 微信接口规则表

表2 回复语音消息的XML数据包结构表

3.5.2 下行接口

接收其他各系统返回给微信公众号的反馈信息，使用这些反馈信息调用微信接口，压入下行的队列中，反馈红包中奖状态。

发送用户红包：通过微信平台向微信支付用户发放现金红包。用户领取红包后，资金到达用户微信支付零钱账户，和零钱包的其他资金有一样的使用出口。若用户未领取，资金将会在24小时后退回商户的微信支付账户中。

3.6 系统业务逻辑设计

喊红包业务逻辑场景分为中奖和未中奖两个结果。未中奖的原因不只是口令错误这一种可能，还有可能为网关系统容错机制生效、用户发送空语音、非语音、数据量过大致使网关系统消峰处理、未达到中奖概率等情况。虽然未获得红包奖励，但用户可接收到事先编辑好的明星祝福语或央广商城宣传页页，从而达到宣传自身产品及营造节日气氛的效果。当用户中奖时，除得到红包奖励外还可能得到央广商城购物券、央广商场会员卡和中国广播会员卡，具体奖品发放逻辑如下表3所示。

表3 奖品发放逻辑表

4 系统压力测试

4.1 测试工具及测试环境

测试工具：Locust压力测试工具，python脚本

测试环境：测试中使用的应用服务器配置及说明信息见表4。

4.2 测试流程

具体测试内容如表5所示。

4.3 典型功能测试用例

具体测试用例见表6。

表4 压力测试环境设备配置列表

表5 系统压力测试内容列表

表6 系统管理子系统功能测试表

续表

测试结果显示：与目标结果一致，达到预定目标。

4.4 压力测试

测试功能项：业务系统压力测试

测试步骤：

业务系统1台php服务器，连接redis和mysql，服务器挂载到SLB下；

locust向业务系统SLB打压，模拟微信端的喊红包请求；

获得红包的订单写入mysql，查询从redis中读取。

预期结果：1台php服务器承受QPS达到1500次/秒，无5XX报错

测试结果：和预期结果基本一致

在压力测试过程中SLB的QPS保持在1400—1600之间，response time维持在20-40ms/个之间，未出现5XX状态码。相关测试指标如下图5-图7。

在压力测试过程中PHP服务器的CPU使用率维持在60%左右，内存基本无消耗，系统平均负载低于CPU核数。在模拟实际微信“喊红包”，微信端向系统POST XML格式数据包的场景下，网络流入流出速率保持在28-38Mbps之间，TCP连接数总数保持在4.8k，无明显波动。具体见图8、图9所示。

图5 业务系统SLB压力测试QPS图

图6 业务系统SLB压力测试response time图

图7 业务系统SLB压力测试5XX状态码图

图8 业务系统PHP压力测试的资源使用情况图

图9 业务系统PHP压力测试的网络数据图

测试功能项：网关系统压力测试。

测试步骤：

网关系统1台nginx服务器，服务器挂载到SLB下；

locust向网关系统SLB打压

预期结果：1台nginx服务器承受QPS达到25000次/秒

测试结果：和预期结果基本一致

在压力测试过程中，SLB上的QPS在24783次/秒左右，最大并发连接数50351个，实际业务场景中共使用了10台SLB，参照此测试结果完全可以满足40W并发量的业务需求，相关压力测试数据如下图10、图11所示。

Nginx服务器网络流入流出速率在140-250Mbps之间，TCP连接数维持在5500个左右，无明显波动，实际业务场景中共使用20台Nginx服务器。单台Nginx相关压力测试数据如下图12所示。

图10 网关系统SLB压力测试QPS图

图11 网关系统SLB最大并发图

图12 网关系统Nginx网络流量图

4.5 测试结果分析

符合新春“喊红包”活动功能及性能的需求。同时，在模拟用户并发使用和持续运行中，系统未出现不良反应，响应时间令人满意，系统稳定性比较可靠。

5 系统实施

5.1 实施环境

具体软硬件环境配置如下表7所示。

5.2 系统上线

准备工作完成后由资源部署组完成系统的实施工作，主要工作内容如下：

梳理出自动化扩容、代码更新、健康检查等应用场景以及操作流程，各场景相关的配置参数整理成配置文件；

网关层限流配置进行最后确认，通过压测进行限流配置的校验；

网关系统、业务系统、订单系统分别创建ECS镜像，为活动当天扩容做准备；

网关系统准备若干台ECS和SLB，用于业务并发过高时的备用；

创建最小灾备环境，在极端情况下上线使用；

使用自动化扩容脚本生成的ECS，在上线前，通过健康检查脚本进行服务可用性检查；

更新微信白名单IP，重新创建WAF规则；

发布最终版代码，上线前三天封版；

上线前一天修改SLB网络模式为按带宽付费；

清空所有日志、数据库的测试数据，数据库导入生产数据；

活动当天前一小时，通过压测进行系统预热。

5.3 实施效果

2019年2月4日(除夕)12点至18点，喊红包互动人次突破3500万，央广新闻公众号粉丝增长15万。当天所有发放红包、优惠券、会员卡等任务均达到预定目标，奖品具体分配情况及实际发放数如下表8所示。

表7 系统实施软硬件配置表

表8 奖品分配表

数据统计页面实时显示奖品发放情况，电台主持人根据数据随时与后台工程师沟通，结合节目进程和节目效果更改红包金额从而达到调动听众情绪的效果。数据统计页面如下图13所示。

用户喊红包过程系统响应积极，未出现卡顿情况，平均响应RT时间未超过100毫秒，高峰时段不超过500毫秒。

图13 数据统计页面图

6 结论

本文针对高并发场景、低成本“喊红包”系统的整体架构设计进行了深入的研究和应用。该系统在实际应用中取得了较好的效果和积极的反响，在2019年中央广播电视总台央广春节特别节目《中国声音中国年》中，使用80台服务器抗住来自全国总计3500万人次的流量海啸，顺利完成高并发场景下的红包发放任务，听众普遍反映良好。同时，该系统设计方案具有比较重要的指导意义，可为传统媒体结合新媒体技术搭建互动平台提供一定参考。