QQ会员2018春节红包抵扣券项目背后的故事

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

1. 活动数据

截止3月1日手Q运动红包会员礼包发放核销数据
参与红包活动用户数：2亿+
发券峰值:52w/min

2. 需求背景

2.1 红包类型

2018年手Q春节红包主打“走运红包“，活动规则为除夕为参与用户随机派发4个业务礼包，大年初一、初二、初三用户每走100步即可抽取一个红包，会员这边是按礼包给用户发放抵扣券，其中一个礼包内有三种不同面额的抵扣券，同时上线对接了米大师IOS抵扣券平台支持了IOS终端下领券、用券、核销券功能。

会员春节礼包活动页面：

2.2 活动目标

整个春节期间活动产品配置发放3亿个红包

2.3 活动预估请求峰值

钱包侧评估红包领取峰值预计 5w/s

2.4 后台需求

支持礼包券类型发货（3亿）后台在当前抵扣券基础上新增礼包券类型，对外只暴露礼包ID，外部发货传入礼包ID和对应的终端系统平台，内部自动映射礼包内多张抵扣券，并将多张抵扣券发放到用户卡包账户下。
支持android \ ios双平台发券（之前只支持android平台），ios平台支持发券、用券、核销全流程
在当前物品系统基础上接入米大师IOS抵扣券平台，完善ios发券、支付、核销、查券全流程，通过接入ios平台券
支持对跨平台使用券用户补发对应平台券（不限制领券平台和用券平台的唯一性）
用户抽中红包的平台和真正用券的平台可能不一致，但是我们给用户发什么类型的抵扣券是在用户抽到红包的那一刻就已经决定，这样当用户切换平台去支付用券就会得到“无适用抵扣券”的提示，为了不影响用户体验，经过团队内部讨论决定给这类需求的用户后台静默补发一套对应平台的券，让用户领到红包在任意平台皆可支付使用。
支持按礼包核销钱包侧数据
用户刷到红包在钱包侧状态为“未领取”状态，用户点击领取即可进入“已领取”状态，进入引导用户“去使用”，在用户未全部使用礼包内部抵扣券之前，状态都会停了在“未使用”的状态，直到全部核销使用为止
支持IAP冻结券回滚
主要用于支付挽留业务，在用户放弃支付场景下对抵扣券静默回滚操作

3. 系统架构

整体系统是在2017年架构的基础上进行改造扩展，TGW + QZHTTP + RocketMQ + SPP逻辑服务架构 , 逻辑服务主要包括CGI代理、红包代理（MQ生产）、红包派发（MQ消费）、后端发货为物品系统。存储主要为CMEM、RocketMQ。其中红包入口机器均为多机房接入。

4. 系统容灾、高可用策略

为应对大流量高并发场景下的故障突发不确定性，我们主要从多节点接入、限流保护、熔断降级、快速失败、缓存加速、业务防重等几个方面设计思考

4.1多机房部署

红包入口集群、CMEM多机房部署
由于红包流量入口大，对CGI层和红包接入代理层的可用性要求极高，避免因机房网络等物理故障导致集群整体不可用，在接入代理层多机房部署

4.2 限流保护&流量清洗

接入层流量清洗
春节红包活动中流量大并且集中，接入代理处于系统前置逻辑，为保护后端发货系统，有必要避免用户重复领取请求和其他无效请求对后端系统的冲击影响正常红包的发放，除了基础的请求安全校验逻辑外在红包接入层增加用户红包领取状态存储，春节期间削减 4kw无效请求。
限速保护
业务压测评估后端发货性能在1w/s左右，而请求峰值评估会在5w/s，在增加MQ缓冲队列的同时还需要通过接入限速组件（限流服务优先、本地限速备用），控制消息消费速度来保护后端发货系统，增加后端故障降级的可控性。

4.3多重防重机制

春节红包系统中无法避免重复领取请求，并且RocketMQ也不保证不会重复消费消息，在业务层消息去重保证冥等性、尽快拒绝重复请求对于红包系统来说显得尤为重要。由于系统去重依赖存在柔性策略，不能完全依赖单一机制来实现完全去重，系统通过红包接入代理层领券状态机、限量服务、卡包记录三种机制依次对请求进行校验去重。

4.4 熔断降级

在红包发货过程中存在多点依赖，并且这些依赖存在故障不确定性，需要考虑在这些故障点触发的时候做到最大化的无损，系统在可柔性处理的三个模块位置增加熔断降级开关，在故障失败出现时熔断切换备用策略或者直接降级放弃依赖

领取状态CMEM存储熔断开关
“红包状态存储”虽对整个系统至关重要，但在出现故障时也不能影响用户领红包业务，通过在该模块依赖链路上增加熔断开关，当出现超时、不可用故障时，解除对该模块的依赖，避免非关键路径对整体活动的致命影响。
Rocket MQ 降级开关
MQ生产为本地agent代理方式，除了本地共享内存缓冲外，为避免RocketMQ长时间故障影响消息生产，支持手动熔断消息生产，切到klog系统记录红包领取消息，并通过对账补发脚本对用户领取请求进行补发重做。
计平查券接口自动降级
用户在拉起支付的时候会触发拉取当前可用券信息，这个拉取动作默认会打到计平的查券接口，在容量评估期间，计平大部分资源都腾挪到抵扣券发货上，对查券和支付只保证支持1.5k/s能力，为了增加对计平系统的保护，同时让用户能正常支付用券，物品系统增加对查券接口设定降级机制，如果在周期内故障达到事先设定的阈值时自动降级，将请求切换内部本地卡包服务，并通过核销对账来保证与计平的数据一致性。

4.5 快速失败

公众号消息服务快速失败
用户每成功领取一个红包都需要收到公众号消息，发送公众号消息成为领红包路径的必要事件点，在公众号消息系统部分机器故障时如果不快速失败将会降低红包整体发货性能

4.6 缓存

缓存加速
1. 对红包抵扣券基础信息本地cache加速，减少cmem访问和发货时延。
2. 采用钱包侧领取码，节约动态生成领取码的资源耗时
Rocket MQ缓冲屏蔽后端发货故障后端发货系统内部依赖多，计平发货能力有限，通过MQ一方面缓冲红包领取消息，同时屏蔽了后端逻辑系统故障对整体春节红包活动的影响，实现故障无感知

5. 活动紧急预案

虽有容灾策略，依然无法保证万无一失，我们需要梳理整个系统所有关键节点，并对关键节点设计故障演练修复方案

关键点1：后端物品发货大面积失败
后端物品发货依赖复杂，从逻辑校验到限量再到midas发货，任何环节故障都可能触发发货故障干预策略:在故障出现时第一时间降速（对切换了本地限速服务的消费机，需要暂时停止消费机），之后再排查具体的发货故障

关键点2：RocketMQ生产失败
RocketMQ为红包单独部署了红包集群，虽无法生产的可能性比较低干预策略:

采用本地agent生产机制，利用本地共享内存对MQ进行容灾
若出现生产失败情况使用klog对失败消息记录并统一进行对账重做

关键点3：领券公众号通知长时间无法修复 干预策略:

公众号消息如果遇到故障短时间能恢复可以通过重试处理即可
若公众号消息故障长时间无法恢复（超过10分钟），可直接关掉公众号通知机制，在通道恢复正常后恢复公众号通知，保证故障期间礼包正常到账，牺牲无消息通知的体验。

6. 数据采集监控

系统在接入TNM2特性告警、米格告警、模调同时监控系统运行状态

7. 分段压测、全链路压测

与钱包后台侧压测性能达到预估要求5w/s 米大师抵扣券发货性能峰值通过几轮压测最终可达1.3w/s 查券接口可达3.5k/s

项目上线之后除了参与多轮红包演练外还执行了分段压测，之所以需要分段压测是因为在服务上线之后，依赖的链路中存在部分系统完成扩容、部分系统未升级，所以前期很可能不具备全链路压测的条件，如果贸然执行全链路压测，很可能会导致部分依赖服务过载无法提供正常的业务服务；
在压测过程中提前申请测试帐号，因为部分系统如果帐号空间有限的话可能无法反映真实流量情况，如果条件允许的话建议按照预估的QPS来申请，本次为配合压测申请2w个测试账号；
在所有系统扩容结束并完成分段压测后，需要对全链路进行压测；
对压测相关服务保证与当前线上提供的服务环境隔离，避免因为压测影响正常业务，
对有依赖CMEM服务，单独申请临时CMEM用于压测，构建压测环境;

8. 故障处理

介绍了这些准备工作和预案，那么在除夕大流量来临时我们是否有遇到现网故障呢，怎么修复现场？

CMEM故障第一时间联系数据运维现场值班同事定位问题，之后对消费速度降低避免过多的消息进入“重试队列”，同时降低对CMEM的冲击在CMEM负载修复之后，逐步放量
消息队列消息堆积在除夕当天出现因CMEM告警导致了请求无法走正常发货渠道到账，从而堆积在消息队列里面，为了保证在零点前全部礼包到账，在数据运维同事处理的同时，业务侧首先停止部分消费机并将速度降低到500/s，以控制较少的请求到达重试队列。在CMEM故障恢复之后逐步放量，并扩大进程消费线程数来提高重试队列的消费速度，最终在23:20将所有消息消费完毕

9.经验总结

处理失败消息执行再生产
在大流量依赖MQ消费消息过程中，如果遇到消息处理失败，最好执行再生产，否则将会进入“重试队列”，影响消费速度，从而会导致部分用户物品无法在产品预定时间到账。
确认依赖的CMEM是否已经关闭数据下沉
部分大容量CMEM很可能在过往开启了tssd关联，在大流量进来很可能会导致tssd过载，影响cmem整体可用性。
不断完善红包项目checklist
从红包项目需求启动时，创建并不断完善check项，方便除夕活动开始前依次检查。
普通活动与春节红包服务独立部署或者错峰推广
在春节期间，除了春节红包项目外，可能有其他活动推广，如果无法对普通活动做到错峰推广，需要为春节红包项目独立隔离部署服务，避免相关资源竞争影响。
压测环境与正常业务环境隔离
由于在压测过程中很可能出现故障，同时我们红包项目的大部分服务都是在现有业务服务的基础上实现，所以我们需要保证压测的系统与当前业务服务环境隔离。
MQ消费队列数与消费进程配置合理，保证最好的消费并行度
在配置消费队列数和进程数与MQ集群节点数匹配，保证最好的多机并行消费状态，单机消费进程数在机器条件允许的情况下不要配置过高，尽量让队列负载到不同的机器上去。
确定值班联系人
在活动开始前确认各个依赖模块的值班联系人，方便在模块出行问题时第一时间知会相关同事，节约沟通成本，缩短故障持续时间
提前保存相关服务配置信息
在checklist里加上需要重点关注的配置信息，如CMEM bid地址、服务L5、开关配置，在需要定位时快速执行，减少查找信息的时间

问答

针对移动web的PayPal自适应支付如何实现？

相关阅读

10亿红包背后的数据中心

浅谈数据中心应急冷源

如何搭建一个红包架构?

此文已由作者授权腾讯云+社区发布，原文链接：https://cloud.tencent.com/developer/article/1145740?fromSource=waitui

欢迎大家前往腾讯云+社区或关注云加社区微信公众号（QcloudCommunity），第一时间获取更多海量技术实践干货哦~