社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等

JackJiang · 4 年前

本文来自腾讯云技术社区的分享，原作者：吴逸翔，原题《从技术角度谈一谈，我参与设计开发的手Q春节红包项目》，收录时有改动。

一、引言

春节期间，QQ以AR技术为支撑、娱乐体验为导向在春节期间推出了系列红包。

系列红包包括三大玩法+年初一彩蛋，分别是“LBS+AR天降红包”、刷一刷红包和“面对面”红包，加上“娱乐红包”(明星刷脸红包)。以2017年为例，共计在春节期间派发了2.5亿现金红包和价值30亿的卡券礼包。根据企鹅智酷提供的数据，手机QQ的用户渗透率在全平台排名第二，为52.9%（第一是微信）。

本文将会详细介绍手Q春节红包项目的功能设计/逻辑、容灾、运维、架构以及实践总结。

补充说明：QQ团队的另一篇分享《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》，讲述了更多技术方面的细节，有兴趣也可以一读。

二、系列文章

❶ 系列文章目录：

❷ 其它相关文章：

三、产品功能需求

3.1、红包类别

以2017 年的手 Q 春节游戏红包为例，共有刷一刷/ AR 地图/扫福三种。

如下图所示：
社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_1.jpg

3.2、体验流程

虽然红包分三种，但在游戏业务侧这边的体验都是一样：

1）用户得到一个红包卡券，打开后展示一个（刷一刷红包）或者多个（ AR 地图红包）游戏的礼包列表；
2）用户选择一个礼包后弹出区服组件；
3）用户确认对应的区服角色信息后会礼包会在 48 个小时内发放到账。

体验如下：

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_2.png

3.3、后台需求

游戏红包的设计容量为入口卡券页流量 80k/s，以上体验流程一共涉及三个后台接口：
社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_3.jpg

三个后台接口分别是：

1）礼包列表：用户界面的礼包内容需要根据后台接口返回礼包列表进行排序和过滤展示；
2）区服选择：用户界面弹出的区服组件需要后台接口返回用户区服角色信息；
3）领取礼包：用户点击“确认”按钮领取礼包，后台进行游戏道具发货。

四、需求拆解和分析

4.1、礼包列表

这个功能使用现有能力比较容易解决。活动共有十种游戏，每个游戏有两种礼包：拉新（面向非注册用户，价值 80 元）/拉活跃（面向注册用户，价值 20 元），一个用户只能获得这两种礼包中的一种，产品策略允许拉新的用户获得价值较低的拉活跃礼包，反之则不允许。页面展示按用户偏好排序十个游戏，每个游戏展示一个拉新礼包或者一个拉活跃礼包。

出于降低除夕当前流量负载和柔性考虑，在红包活动前，十种游戏的礼包内容作为前端静态数据已经预先通过离线包 /CDN 下发；红包活动时，后台接口根据用户偏好返回的游戏礼包列表，只是提供前端礼包内容进行过滤和排序，失败了也有前端默认的游戏礼包列表，保障用户体验。

过滤：读取存储，用户有注册的游戏返回活跃礼包，用户没有注册的游戏返回拉新礼包。

排序：一个两层排序，第一层排序读取存储（key 为用户，value 为用户所注册的游戏列表），用户注册的游戏（拉活跃）排在用户没有注册的游戏（拉新）前面；第二层排序，对于拉新游戏列表和拉活跃游戏列表内部，使用神盾算法对用户这10款游戏的偏好再进行二次排序。对于外部接口的依赖只有 CMEM 存储和神盾算法接口，这两个接口以及合并这两种数据给出最终的个性化推荐礼包列表接口都可以平行扩容以支持 100k 级别的 QPS。

4.2、区服信息

这个功能是现有能力。这个角色信息的来源是 IDIP ，但由于该接口较缓慢（2s 左右）且容量较低（低于 10k/s），故后台做了一层缓存，将 IDIP 的区服信息永久性缓存到 CMEM 中，前台也有本地缓存，在实践中，前台缓存命中率为 60%，后台为 35%，多级缓存后走到 IDIP 的请求量只有5%，对 IDIP 影响不大，只需要扩容现有的区服 server 和 CMEM 即可。

4.3、领取礼包

这个功能使用现有能力解决存在困难。游戏中心日常发货的道具和平台比较多，平台分为 IEG-AMS/MP 两种， MP 发货对于发游戏道具和发 Q 币又是两种接口，故我们在架构上使用 Facade 模式，使用 AMS 作为发货 proxy，屏蔽了底层发货的复杂性，向游戏中心提供统一的发货接口，但比较遗憾的是从 AMS 到游戏的发货接口都是同步接口，发货能力较低，发货能力最高的王者荣耀也只承诺了 3k/s 的发货速度，明显不足以直接承受 100k/s 级别的红包发货，故这里的核心问题是需要有一个队列来解决生产/消费速度不对等的问题。

去年的红包是后台收到发货请求后落地到本地文件返回用户成功，再由一个本机的 daemon 跑落地文件按游戏方所能提供的发货速度进行实际发货，相当于使用本地队列缓冲。但这个方案存在某台机器挂掉后如果不能恢复会丢失一部分本地的发货数据造成漏发，以及每个高并发业务都要重新做这一套东西不方便通用的问题。

从架构上思考，其实最合理的方案是作为发货 proxy 的 AMS 提供异步发货的能力，将用来解决生成/消费速度不匹配的 MQ 做在 AMS 内部，为业务提供通用的异步发货能力，业务侧就不需要考虑发货超过游戏方能力的问题，新业务有类似的场景也不需要重新开发。

游戏中心是业务侧， AMS 是平台侧的能力，属于另一个中心的业务，于是一开始我们准备推动 AMS 做异步发货的能力，这样业务就只要调用发货接口就可以了，很是方便。

但事情并没有想象中顺利，与 AMS 的开发和 PM 开会沟通了几次，异步发货的能力他们也有做技术规划，但年前他们有其它需求要做，没有时间支持。和 leader 讨论了一下这个能力最好还是放在 AMS 做成通用以便以后有同样场景的业务使用，前台也有同学开发过 AMS 功能，可以由游戏中心业务侧的前后台同学合作完成 AMS 异步发货功能的开发，在春节红包中应用，再将这个功能交接给平台侧的同学维护，达到双赢的效果。

五、整体方案与项目分解

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_4.png

（注意：因本图较大，清晰大图请从此附件下载►

整体方案图(清晰大图).zip (769.6 KB , 下载次数: 4 ) ）

整体方案图如上图所示，由于整个项目涉及多方开发，而且模块较多，整个模块的开发周期较长，作为一期开发的话无法跟上基础侧卡券的验收和安排的几次演习/压测，故按「大系统小做」的原则，根据模块的重要和紧急程度分为几期迭代完成，每一期有独立的里程碑目标并达到对应的验收/演习/压测要求：

第一期（方案图左侧部分）为功能需求：在 12 月 9 号上线通过卡券方面功能验收，先使用当前的同步发货接口，对性能无特别要求。

第二期（方案图右侧偏左部分）为性能需求：在 12 月 20 号上线参加第一次演习，对发货进行异步化改造，要求直接面向用户的外网发货接口能支持 100k QPS 的峰值流量。

第三期（方案图右侧偏右部分）为容错需求：在 12 月 27 号上线参加第二次演习，对发货进行对账补送改造，保证发货的可靠性。

第四期为监控需求：在 1 月 6 号上线参加第三次演习，确认各项关键数据的采集，并将采集到的数据展现到一个统一视图上，以便除夕期间值班人员实时了解红包系统的整体运行情况和出数据报表。

六、实际需求开发

6.1、功能需求开发

➊ 核心问题：不同场景的数据一致性

{3.1 后台礼包推荐接口}为用户推荐礼包，用户领取时需要经过{4.1 AMS 外网发货新 OP}校验领取资格，后台的推荐数据必须能和 AMS 的资格校验数据能够对上，否则会出现后台推荐的礼包用户领取时却通不过 AMS 的资格校验导致领取不了的问题。

{4.1 AMS 外网发货新 OP}接口处理的是单个游戏的领取礼包的请求，资格校验操作判断一个用户是否注册了某个游戏。这个是 AMS 现有的通用功能，数据存储在 AMS 的 CMEM 中，简化描述就是一个 key-value 模型，key 为 uin+appid，value 如果有注册则为 1，没有则为 0（实际为了节省存储空间，使用 bitmap 桶实现，具体参见号码包系统使用文档)，导入的数据源是产品在除夕前一周提供 10 款游戏的全量注册号码包，每个游戏一个文件，文件内容是注册用户的 QQ 号。

但{3.1 后台礼包推荐接口}接口返回的是多个游戏的礼包列表，需要获取十个游戏的用户注册状态。

如果读取 AMS 现有的接口/存储，会有两个问题：

1）AMS 号码包服务也要承受等同于推荐列表接口 48k/s 的流量，需要进行扩容；
2）AMS 号码包服务调用 CMEM 虽然可以一次请求合并 10 个 key 进行批量读取，但请求到了 CMEM 的 Access 机还是要读取多个 Cache 块，性能并不如单请求单 key 读取。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_5.jpg

➋ 解决方案：同质异构的数据冗余

后台将号码包数据进行重新组织存储到后台申请的另外一个 CMEM 中，key 为 uin，value 为用户已注册的 appid 列表，已注册的游戏推荐拉活跃礼包，没注册的游戏推荐拉新礼包，这样只需要查询一次 CMEM 就可以得到十个游戏每个游戏的礼包推荐类型是拉新还是拉活跃。

由于 AMS 和后台使用的是同一份号码包数据，只是应用场景不同，数据组织形式不同，两份 CMEM 数据同质异构，故后台推荐的礼包可以通过 AMS 的资格校验。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_6.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_6.jpg

6.2、性能需求开发

➊ 核心问题：用户领取礼包流量远超游戏发货能力

红包活动具有时间短（单场 5~30 分钟）、大用户量参与（1.5 亿+）参与的特性，请求并发高，游戏红包入口流量设计为 80k/s，流经各个模块有衰减也有增幅，最终用户领取礼包请求预估为 96k/s，而游戏方提供的十款游戏总发货能力只有 5k/s（单款游戏最大为王者荣耀 3k/s），请求峰值接近处理能力的 20 倍，同步调用会导致游戏方发货接口过载，造成大面积发货失败，这个问题如何处理？

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_7.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_7.jpg

➋ 解决方案：发货异步化

使用一个缓冲队列来解决生产消费能力不对等的问题。用户领取请求到达 AMS 进行基础的资格校验后将请求放入 MQ 中，返回用户成功并告知会在 48 小时内到账。再由后台发货 Daemon 从 MQ 中读取请求，通过限速组件控制保证以不超过游戏方发货能力的速率进行发货操作。使用的 MQ 是部门近来建设的 RocketMQ，具体参见会员消息队列( RocketMQ )接入指南。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_8.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_8.jpg

6.3、容错需求开发

➊ 核心问题：安全发货

三场活动发放的礼包总数预计将近 4 亿，如何保障这些礼包对于合法用户能都发货到账，不少发也不多发？如何防范高价值道具被恶意用户刷走？有没有可能内部开发人员自己调用接口给自己发礼包？

➋ 解决方案：对账补送/订单号/安全打击/权限控制

a. 订单号解决不多发的问题：

用户领取礼包的接口{4.1 AMS 外网发货新 OP}调用成功，会为这个请求附带一个 UUID 生成的一个全局唯一的订单号，再放进 MQ 中，{4.3 AMS 内网发货 OP}从 MQ 中取出消息，调用游戏方发货接口前都会先校验这个订单号是否用过，没用过则将订单号以 key 的形式写入 CMEM，再进行发货操作。如果出现对同一个发货消息进行重复发货，则会发现订单号已经用过了不会进行实际的发货操作，保证以订单号为标识的同一个发货请求只会进行一次发货操作。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_9.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_9.jpg

b. 对账补送解决不少发的问题：

发货失败是不可避免的，诸如网络波动/游戏方发货接口故障之类的问题都可能导致调用发货接口失败。在同步领取环境下，用户可以通过重试在一定程度上解决这个问题。但是对于异步发货，用户点击领取后发货请求由{4.1 AMS 外网发货新 OP}放入 MQ 中就算成功了，即使后台调用游戏的实际发货接口失败了没有实际到账，用户对此也无感知不能进行重试但是会投诉，后台发货系统必须通过自身的容错保证即使游戏方的发货接口不稳定偶尔会失败，用户所领的礼包能最终到。这里我们使用了对账补送方案。

对账：用户领取礼包调用的接口{4.1 AMS 外网发货新 OP}成功写应发流水，{4.3 AMS 内网发货 OP}调用游戏方发货接口的写实发流水，由于部分消息会堆积在消息队列中，这部分称为队列堆积流水。故实际要进行补发操作的流水由以下公式可得：
失败补发流水= 应发流水 - 实发流水 - 队列堆积流水。

由于订单号的存在，可以保证同一个发货请求重复发送也不会多发，对队列中堆积的消息提前进行补发操作也不会导致多发。故当队列中堆积的流水较少的时候，采用应发流水与实发流水的差集作为失败补发流水是合理，只是每个对账周期会对队列中堆积的消息进行两次发货操作，对性能略有损耗。

后台每个小时运行一次增量对账功能，检测 MQ 消息堆积量量低于某个阈值，则进行对账操作，截取上次对账到此时的应发流水/实发流水，两者相减得到补发流水。

补送：对对账操作得到的补发流水调用游戏方发货接口进行发货补送操作。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_10.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_10.jpg

c. 安全打击解决高价值道具防刷的问题：

对于领奖的请求，都要求都要求带上登录态，对用户进行身份验证，同时对于高价值的道具开启安全打击，上报安全中心进行恶意用户校验，防止被恶意用户刷走。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_11.jpg

d. 权限控制解决内部人员监守自盗的问题：

对于发货的机器都要安装铁将军，用户需要使用 RTX 名和 token 才能登录机器，审计用户在机器上的操作行为；
发货模块对于调用方是需要严格授权，调用方需要申请 key，包含程序路径、程序 MD5、部署模块等信息，保证发货功能不被随意调用。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_12.jpg

6.4、监控需求开发

➊ 核心问题：红包涉及多个系统的自有监控，数据收集困难

在监控方面有两个主要诉求：

1）我们对外提供的服务是否正常？如果有问题，如何快速地发现问题、分析问题？
2）实时知道用户在整个系统的行为漏斗模型，每一步的转化率是多少？

游戏红包涉及红包基础侧/业务前台/业务后台/AMS/MQ 平台等多个合作方，各个系统有自己的监控系统，数据来源不一致，活动当天一个系统一个系统地收集的话效率太低。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_13.jpg

（注意：因本图较大，清晰大图请从此附件下载►

13(清晰大图).zip (855.33 KB , 下载次数: 3 ) ）

➋ 解决方案：汇总各个系统的关键数据到一个视图

红包作为一个涉及多个子系统的聚合系统，我们需要一个汇总了各个子系统关键数据的整体视图，才能够较全面地监控业务核心指标，对系统和业务有较全面把控，避免在监控系统中跳转检索而耗费有限的时间，为迅速响应解决问题提供保证。

接口封装：虽然红包涉及的多个子系统，各自有各自的上报方式和监控系统，但是对于关键数据大都有提供 HTTP 形式的查询接口，我们通过封装，将接口的定义统一为 key-value 形式，以（监控项 id，开始时间，结束时间）为 key，value 为（开始时间，结束时间）段内监控id的值之和。

配置化：一场红包活动的监控，可以由一个时间段加若干个监控项定义。比如刷一刷红包，时间段为除夕当天 20:00~20:30，监控项为若干页面的点击量，若干礼包的发放量，若干后台接口的请求量，若干 MQ 的堆积量等等。

通过对接口的封装和配置化，新增一场红包活动，只需要增加一个时间段和若干个监控项的配置文件，比如下图的 AR/刷一刷混场/刷一刷专场就是通过 3 个配置文件定义 3 场活动，新增一场活动也只需要增加一个配置文件，并可以在一个视图上灵活切换，相当方便。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_14.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_14.jpg

从上图中我们就可以实时看到实发和应发是大致相等的，队列没有出现堆积，用户在各级页面的转化率，可以很方便地判断系统的健康状态和分析定位问题。

七、系统保障

第六部分讲述了业务需求的开发，但是否功能开发完成后我们就这样就可放到线上安心睡大觉了呢？

如果出现一部分机器乃至整个机房挂了，服务是否可用？

外部的服务突然故障了，比如 MQ 突然挂了，不能写入消息了，服务是否可用？

说是红包入口流量 8W/s，万一来了 20W/s 呢？系统会不会挂掉？服务是否可用？

以下从系统容灾/过载保护/柔性可用/立体监控来讲我们这方面做的一些工作，我们对于除夕当天出现各种问题系统还能正常运行，用户能正常体验服务的信心从何而来？

7.1、系统容灾

容灾就是在整体服务一部分出现异常时，另一部分能顶上，不影响整体服务的使用，保障业务可用、数据安全。但容灾设计会使得系统复杂度增加，成本和代价也增加，需要额外的开销和资源，应该在合理的范围内考虑容灾。

容灾级别一般划分为多机容灾、多机房容灾，多地容灾，红包的后台服务主要使用公用组件的均衡负载和系统容灾能力，服务无单点问题，采用同地多机房部署，按多机房容灾标准设计。

7.1.1 接入层：

典型的 GSLB+TGW+QZHTTP 接入，GSLB 解析域名把请求带到离用户最近的 IDC 的 TGW 接入机，TGW 再通过内网专线，把请求转发到实际提供 WEB 服务的 QZHTTP 服务器上。

GSLB：Global Server Load Balance 的首字母缩写，意为全局负载均衡，主要提供提供域名解析的就近接入和流量调度。实现在广域网（包括互联网）上不同地域的服务器间的流量调配，保证使用最佳的离自己最近的客户服务器服务，从而确保访问质量；它对服务器和链路进行综合判断来决定由哪个地点的服务器来提供服务，实现异地服务器群服务质量的保证。红包使用独立的 sh.vip.hongbao.qq.com 域名。
TGW：Tencent Gateway，是一套实现多网统一接入，支持自动负载均衡的系统，TGW 把外网不同运营商的请求，通过内网隧道转发给 server，server 返回数据时，再把数据通过内网隧道返回给 TGW，再由 TGW 发送给不同的运营商。红包 TGW 外网部署了上海电信联通双 VIP+香港 CAP VIP。
QZHTTP：Web 服务器，负责将 HTTP 请求转成逻辑层使用的 WUP 协议，采用同地多机房部署部署。QZHTTP 作为 TGW 的 RS，TGW 会周期性的探测 RS 的状态，在 1 分钟内自动把故障 RS 从可服务列表中踢除，当 TGW 检测到 RS 恢复正常后，自动把它加回可服务列表中。由 TGW 提供负载均衡和容灾。

7.1.2 逻辑层：

逻辑层使用 SPP 容器开发，礼包列表/区服选择/礼包发货三个功能均是无状态服务，多个服务器在服务容量足够的情况下任意踢掉一部分都不会影响正常服务，使用 L5 进行负载均衡/容灾/过载保护。

L5：机器级别容灾，业务程序调用 L5 API 从 L5 Agent 获取后台服务器的(IP, Port)，使用该(IP, Port)对应的后台服务器进行通信，访问结束时调用 L5 API 上报访问接口和处理时延，L5 Agent 对 L5 API 上报的访问结果和处理时延进行统计和上报，当服务器出现故障，L5 一般在 1 到 2 分钟内就会自动剔除故障服务器。

7.1.3 数据层：

数据层主要使用了作为 K-V 存储的 CMEM 和作为分布式消息队列的 RocketMQ，这两种服务都采用接入层-存储层划分，逻辑层访问数据层的接入层使用 L5 进行负载均衡/容灾，数据层的存储层都采用一主一备双机热备容灾，并落地磁盘支持掉电重启后重建内存数据，支持多机容灾但是不支持多机房多地容灾。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_1.jpg

7.2、过载保护

红包入口流量说是 8W/s，万一基础侧有问题发到了 20W/s 怎么办？

每个模块的容量都是从入口流量按照用户行为漏斗模型推算转化率设计的，万一评估有误转化率偏高超过了设计容量怎么办？

对于可能出现的超过了设计容量的流量尖峰，就要应用过载保护方法，保障系统能拒绝超过容量的部分请求，保障设计容量内的请求还能正常响应。

实施的时候有四个要注意的地方：

1）从源头上减少无效请求；
2）从接入层开始拒绝；
3）各层互相不信任；
4）要照顾用户的情绪。

7.2.1 流量预加载：

CDN 做为页面访问的关键路径，前端页面制作离线包，预先下发到客户端，减少除夕当天 CDN 的流量压力。

7.2.2 频率限制：

前台对用户发起请求的频率进行限制，超出频率的请求提示用户失败而不走到后台（每 5 秒只允许请求一次到后台），前台保护后台。

后台接入层根据压测数据配置 CGI 接口的每分钟接受的请求数，超出接口处理能力的请求丢弃并进行告警。接入门神系统，配置 IP/uin/refer 等规则限制恶意用户刷请求，保障服务的正常运行。

7.2.3 降级开关：

前台调用后台的接口，设置开关以一定概率丢弃请求，对于关键路径返回错误提示用户稍后重试，对于非关键路径提供降级体验，结合频率限制功能，可以限制前台的流量传递到后台的比例，当比例设为 0 的时候则关闭该模块，实现前台保护后台。

7.2.4 队列堆积丢弃：

后台逻辑层使用 SPP 框架，worker 处理消息前先检查消息在 SPP 消息队列中等待时间是否超出了预设阈值（500ms），在队列中堆积过久的消息前端已经超时，对于用户已经无意义，服务丢弃请求并进行告警，预防队列式过载雪崩。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_2.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_2.jpg

7.3、柔性可用

柔性可用，柔性是为了保护系统，保证系统整体的稳定性，可用性。可用是为了用户，尽最大努力为用户提供优质的体验（可能是部分服务体验）。一个是从系统本身角度出发，一个是从用户角度看，在真正实施过程中只有将两者分析清，并融合在一起才能真正做到系统的柔性可用。关键问题是找准用户的核心诉求，找出符合求场景的核心诉求作为关键路径，出现异常可以放弃的诉求作为非关键路径。

7.3.1 找准用户的核心诉求：

春节游戏红包用户的核心诉求有三个：

1）看到礼包列表；
2）选择区服角色；
3）领取礼包到账。

其他的都可以作为非关键路径，有可以提高用户体验，没有也不影响用户的核心诉求。

7.3.2 保障关键路径的可用：

看到礼包列表：作为页面关键模块的礼包列表，在红包活动前，十种游戏的礼包内容作为前端静态数据已经预先通过离线包/CDN下发。红包活动时，后台接口根据用户偏好返回的游戏礼包列表，只是提供前端礼包内容进行过滤和排序，失败了也有前端默认的游戏礼包列表，用户依旧能看到礼包列表，只是排序不够智能化。

选择区服角色：除夕前一周游戏中心的主站页面和运营活动增加一个后台接口请求，预先请求用户的区服角色信息缓存到本地，既降低了除夕当天的区服接口请求量又保证了游戏中心核心用户的区服信息是有效的。

领取礼包到账：RocketMQ对于领取操作是关键路径服务，用户领取礼包后需要写入RocketMQ才能算成功。故业务对消息队列做了逻辑层面的容灾，当RocketMQ出现故障时，可以打开容灾开关，领取操作写完应发流水后直接返回成功，不再往RocketMQ写入消息，采用分时段对账的方法替代实时发货，达到消息队列容灾效果，参见6.3.容错需求开发。

7.3.3 放弃异常的非关键路径：

前端页面展示模块化，对于请求数据不成功的非关键模块进行隐藏；
红包页面导流到游戏中心，游戏中心展示按红点逻辑展示，只显示第一屏的数据，默认不加载第二屏数据，用户往下滚动时再加载，牺牲用户往下滚动会短暂卡顿的体验减少后台的请求压力；
后台读取算法接口返回的推荐排序失败时使用默认的礼包排序；
后台读取CMEM接口返回的礼包是拉活跃还是拉新失败的时每款游戏默认返回低价值的拉活跃礼包。

7.4、立体监控

“我们对外提供的服务是否正常的么？怎么证明我们的服务是没有问题的？”，是监控告警首先要回答的根本问题。有效的监控告警需要保证能完备地监测业务指标，当发现问题时能有效通知负责人并帮助分析问题，强调的是“完备性”和“有效通知”，两者缺一不可。春节红包的监控告警从用户、业务和机器三个层面上描述。

7.4.1 用户层面：

从用户的角度监控系统是否有问题，模拟用户行为从系统外部发起请求，判断请求结果和时延是否符合预期，使用的是ATT的自动化用例。

ATT，autotest，是社交、开放平台测试组使用的测试管理工具，它是功能用例、自动化用例管理的平台。通过模拟真实的用户访问并校验返回数据，确认访问延时、功能正确性的用户层的监控手段，从业务侧进行实施监控功能的正常运行状态的工具。

7.4.2 业务层面：

监控红包系统内部的各个子业务模块是否运行正常，分为两种：

a. 模块间的调用监控：监控系统内部各个模块间的调用是否正常，使用的是模调系统。
b. 模块内的状态监控：监控某个业务模块当前的状态是否正常，使用的是各个子系统自建的监控告警系统。

春节红包这方面的监控主要有两个： AMS礼包领取剩余数量和消息队列消息堆积数量。春节红包由于准备的礼包数量较为充足，故没有引起告警；队列由于生成速度远超消费速度，设置的告警阈值是100W，但实际最终堆积超过了1200W，引发了告警。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_44.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_44.jpg

7.4.3 机器层面：

监控机器的CPU/内存/磁盘/网络是否正常，使用的是网管系统。

网管系统(TNM2)是一个功能非常强大的采集服务器CPU、内存、网络、IO等指标的监控系统，同时还能对设备的进程和端口异常、磁盘使用率、硬件故障等进行告警，同时对外部系统提供功能丰富的调用接口，关于网管系统的监控能力，请参考其网站首页的TMP监控能力白皮书。

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_4.jpg

社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等_4.jpg

八、演习验证

演习是一种将被动相应转换为主动服务的手段，在演习前设定演习目标和演习方法，在演习过程中进行验证并收集数据，在演习后进行总结并提出改进方案。通过演习，可以实际验证用户行为与评估预期是否一致（灰度演习），系统各个模块的容量是否符合预期（压测演习），各类容灾和柔性的措施是否生效（异常演习），提前发现架构中存在的问题。

8.1、灰度演习

➊ 核心问题：实际的用户行为与评估预期是否一致

已知游戏红包的入口流量设定是最大80k/s，红包系统内的各个模块需要支持的流量是多少？每个模块要部署多少机器以支持多大的流量？这个就要涉及到对用户行为和各个模块的转化率的评估？

➋ 解决方案：现网灰度用户收集数据进行验证

在现网灰度一部分用户对游戏红包进行验证，收集数据修正评估模型。

结果如下：

a. 入口卡券也到游戏礼包列表页的转化率评估为60%，实际为59%，评估与实际相当接近；
b. 区服组件数据前端有缓存，评估请求缓存命中率为60%，请求到后台的比例为40%，实际为45%，评估与实际相当接近；
c. 游戏礼包列表页有10款游戏，评估每个用户平均会领取2个礼包，实际为0.23个礼包，评估与实际有很大出入。

从以上三个接口的流量评估来看，我们的开发和产品根据以往经验评估的用户行为数据大部分还是比较接近实际情况，但也有不太好评估的接口的灰度数据跟评估预期相差很大。根据灰度数据我们重新修正了评估模型和模块容量设计，极大地节约了领取接口的机器。活动当天的数据与灰度得到的数据相差无几，也证明了灰度验证手段是确切可靠的。

8.2、压测演习

➊ 核心问题：系统能否抗住压力

细分又可以划为两个问题：

a. 对于系统容量内的合理请求，系统能否正常处理；
b. 对于系统容量外的超额请求，系统能否成功丢弃。

]➋ 解决方案：全链路压测和单模块压测

最理想的情况是先红包各个模块的进行压测后评估没有问题，再灰度用户使用现网流量进入红包系统进行全链路压测，但由于使用现网流量进行演习需要实际地发送红包，成本较高，灰度 500 万用户红包入口峰值仅为 5k/s，远低于设计的 80k/s。故对系统的压力测试验证主要以单模块压测结合灰度演习得到的用户行为数据评估系统的整体能力。

a. 对于未上线的接口的 CGI Server 和 SPP Server，采用 ApachBenchmark 模拟请求压测；
b. 对于已经上线的接口，除了隔离现网机器用 ApachBenchmark 模拟请求压测外，还使用了小组自研的压测系统，通过调整 L5 权重把现网流量逐步导到一台机器上来进行压测。

经验证，在 V8 的机器上，礼包列表/区服接口 CGI/Server的QPS 在 5k/s~8k/s 之间，礼包领取接口达到 2k/s 的 QPS。在部署足够的机器后，对于系统 80k/s 的请求量，是可以正常处理的。

在配置了接入层 CGI 的限速选项后，超出限速(8k/s)的超额请求会被 CGI 直接返回错误而不传递到后端处理；在配置了逻辑层 SPP 的超时丢弃后，在队列中堆积超过超时时间(500ms)的堆积请求会被框架丢弃而不进行实际处理。对于超出系统容量的请求，系统是可以成功丢弃的。

8.3、异常演习

➊ 核心问题：系统发生异常时各种柔性逻辑/容灾措施能否生效

系统中的柔性/容灾措施，往往只有系统异常时才会生效，导致在实际现网服务运行中，柔性逻辑经常无法测试到，容灾措施一般也不会启用。这样，当运营环境真正异常时，柔性逻辑/容灾措施是否有效还是个未知数。

➋ 解决方案：验证柔性逻辑和容灾措施

在红包正式上线前，通过模拟故障发生的真实异常场景，列出重点可能发生的故障问题，验证柔性逻辑和容灾错误是否真实有效。

a. 后台 SPP 修改神盾的 L5 为错误的 L5，SPP 调用神盾出错，预期后台依旧能按默认排序返回礼包列表。
b. 后台 SPP 修改 CMEM 的 L5 为错误的 L5，SPP 调用 CMEM 出错，预期后台依旧能按全部游戏推荐拉活跃礼包返回礼包列表。
c. 后台随机停掉一台 SPP，CGI 调用 SPP出错，预期服务短时间内有部分失败，L5 能在 1~2 分钟内踢掉该出错机器，服务恢复正常。
d. 打开 MQ 容灾开关，用户领取成功消息不再放入 MQ，而是直接走流水对账，预期游戏能够成功到账。
e. 前台用户操作频率超过了限制（5 次/秒），预期前台直接返回领取失败，抓包看到请求不走到后台。
f. 前台调用后台接口通过设置 host 指向错误 IP，前台调用后台推荐接口出错，预期前端页面依然能正确显示作为关键路径的礼包列表。
g. 前台调用后台接口通过设置 host 指向错误 IP，前台调用后台非关键信息接口出错，预期前端页面对非关键模块进行隐藏。

经测试同学验证，checklist 中的柔性逻辑和容灾措施确切有效，符合预期。

九、总结

针对本文内容，我们总结一下手Q的红包系统：

三个系统功能：礼包列表/区服选择/礼包发货；
四个开发阶段：功能开发/性能开发/容错开发/监控开发；
四种业务保障：系统容灾/过载保护/柔性可用/立体监控；
三场演习验证：灰度演习/压测演习/异常演习。

附录1：有关微信、QQ的技术文章汇总

附录2：更多架构方面的文章汇总

[1] 有关IM架构设计的文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
>> 更多同类文章 ……

[2] 更多其它架构设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
《通俗易懂：如何设计能支撑百万并发的数据库架构？》
>> 更多同类文章 ……

本文目录

一、引言

二、系列文章

三、产品功能需求

3.1、红包类别

3.2、体验流程

3.3、后台需求

四、需求拆解和分析

4.1、礼包列表

4.2、区服信息

4.3、领取礼包

五、整体方案与项目分解

六、实际需求开发

6.1、功能需求开发

6.2、性能需求开发

6.3、容错需求开发

6.4、监控需求开发

七、系统保障

7.1、系统容灾

7.2、过载保护

7.3、柔性可用

7.4、立体监控

八、演习验证

8.1、灰度演习

8.2、压测演习

8.3、异常演习

九、总结

附录1：有关微信、QQ的技术文章汇总

附录2：更多架构方面的文章汇总

本帖已收录至以下技术专辑

MobileIMSDK(v4.0精编版)

MobileIMSDK-Web(有偿开源)

RainbowAVnew(有偿开源)

RainbowChat(技术转让)

RainbowChat-Web(技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

MobileIMSDK (v4.0精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

即时通讯网　