QQ会员2018春节红包抵扣券项目实践与总结

1. 活动数据

截止3月1日手Q运动红包会员礼包发放核销数据 

2. 需求背景

2.1 红包类型

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

会员春节礼包活动页面：

2.2 活动目标

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

2.3 活动预估请求峰值

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

2.4 后台需求

• 支持礼包券类型发货（3亿） 

• 支持android \ ios双平台发券（之前只支持android平台），ios平台支持发券、用券、核销全流程 

• 支持对跨平台使用券用户补发对应平台券（不限制领券平台和用券平台的唯一性 

• 支持按礼包核销钱包侧数据 

• 支持IAP冻结券回滚 

3. 系统架构

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

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

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

4.1多机房部署

• 红包入口集群、CMEM多机房部署 

4.2 限流保护&流量清洗

• 接入层流量清洗 

• 限速保护 

4.3多重防重机制

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

4.4 熔断降级

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

• 领取状态CMEM存储熔断开关 

• Rocket MQ 降级开关 

• 计平查券接口自动降级 

4.5 快速失败

• 公众号消息服务快速失败 

4.6 缓存

• 缓存加速

1. 对红包抵扣券基础信息本地cache加速，减少cmem访问和发货时延。

2. 采用钱包侧领取码，节约动态生成领取码的资源耗时

Rocket MQ缓冲屏蔽后端发货故障 

5. 活动紧急预案

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

关键点1：后端物品发货大面积失败 

关键点2: RocketMQ生产失败 

• 采用本地agent生产机制，利用本地共享内存对MQ进行容灾

• 若出现生产失败情况使用klog对失败消息记录并统一进行对账重做

关键点3:领券公众号通知长时间无法修复 

干预策略: 

• 公众号消息如果遇到故障短时间能恢复可以通过重试处理即可

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

6. 数据采集监控

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

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

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

1. 项目上线之后除了参与多轮红包演练外还执行了分段压测，之所以需要分段压测是因为在服务上线之后，依赖的链路中存在部分系统完成扩容、部分系统未升级，所以前期很可能不具备全链路压测的条件，如果贸然执行全链路压测，很可能会导致部分依赖服务过载无法提供正常的业务服务；

2. 在压测过程中提前申请测试帐号，因为部分系统如果帐号空间有限的话可能无法反映真实流量情况，如果条件允许的话建议按照预估的QPS来申请，本次为配合压测申请2w个测试账号；

3. 在所有系统扩容结束并完成分段压测后，需要对全链路进行压测；

4. 对压测相关服务保证与当前线上提供的服务环境隔离，避免因为压测影响正常业务，

5. 对有依赖CMEM服务，单独申请临时CMEM用于压测，构建压测环境;

8. 故障处理

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

• CMEM故障

第一时间联系数据运维现场值班同事定位问题，之后对消费速度降低避免过多的消息进入“重试队列”，同时降低对CMEM的冲击在CMEM负载修复之后，逐步放量

• 消息队列消息堆积

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

9.经验总结

• 处理失败消息执行再生产 

• 确认依赖的CMEM是否已经关闭数据下沉 

• 不断完善红包项目checklist 

• 普通活动与春节红包服务独立部署或者错峰推广 

• 压测环境与正常业务环境隔离 

• MQ消费队列数与消费进程配置合理，保证最好的消费并行度 

• 确定值班联系人 

• 提前保存相关服务配置信息