不知不觉距离五五开黑节又近了一天，不仅有非卖免费的新皮肤面世，接下来每天都有跨界重！磅！福！利！来袭，相信许多玩家都已经摩拳擦掌组好队，准备抢夺好礼啦！

这不，守能极限救队友，攻能一技能夺两个人头的妲己宝宝，凭借这华丽的实力操作，虏获一众好友的开黑邀请……

但是！这酷炫有逼格的红包妲己宝宝怎么没有？这是从哪来的！

原来，五五开黑节期间，QQ红包将祭出王者专属主题红包封皮、王者专属礼包等多重壕礼犒赏，为王者峡谷的召唤师们开黑团战呐喊助威：

【五五开黑，解锁王者专属红包封皮】

QQ红包为《王者荣耀》定制专属酷炫红包封皮

谁用谁酷炫！王者气息妥妥的~ 

据说！QQ红包过去的封皮都是和法拉利、Burberry等奢侈品大牌才合作的

一个红包就让你秀翻群友！

召唤师仅需呼朋唤友开黑一局

即可免费获得王者荣耀专属的QQ红包主题封皮

峡谷里的实力carry，发起红包来也要与众不同才可以！

据说此次解锁后，可使用一年哦！

满满一年的逼格，王者气息展现无遗了。

【发酷炫主题红包，尽显开黑王者风范】

五五开黑节的挑战，还差一个队友？

让王者专属红包成为你的召唤师标识，

发酷炫红包邀请大神一起开黑，助力团战稳赢，hold住全场！

领取王者荣耀红包封皮，让召唤师们在峡谷之外也能相遇，成为最炫的MVP！

【专属红包发不停，英雄/皮肤等你来拿！】

三五好友开黑团战，没有多几个英雄，怎能炫出实力操作？

活动期间，只要召唤师发炫酷主题红包

就能免费领取孙尚香、铠等强力英雄的体验卡

操作不够?那就外观来凑！

有了英雄怎能少了华丽丽的英雄皮肤？

快来领取【孙尚香-水果甜心】皮肤体验卡

成为草丛里最闪亮的香香

换闪亮新肤，享开黑乐趣。

王者荣耀一年一度的招牌节日！排位享勇者积分双倍、五排不掉星、组队享亲密度双倍，拉上你的召唤师好友，简直不要太棒！更有亿万福利！神秘大咖！KPL全明星阵容前来助阵！排位享勇者积分双倍、五排不掉星

不过，开黑节的精彩绝不止于此，此次王者荣耀联袂QQ红包，两大个性社交玩法携手，只为召唤师们开黑更精彩！

爆仓的活动、成吨的好礼，重磅福利拿不停！更有系列召唤师专属定制，英勇的召唤师们，你们准备好了吗？这个假期，让我们相约峡谷吧！

随着1月9日更新，全新的吉星高照相关活动上线。很多朋友都第一时间在游戏中收集吉星高照红包，要知道每天最多可是能收集4个的，那么在吉星高照所有的五个兑换奖励中，哪个是最好的呢，且听小编给大家分析下，保证划得来。吉星高照红包能兑换什么：新的一年，吉星高照！参与活动收集红包，兑换超值好礼！吉星高照红包可以开出哪些永久英雄吉星高照红包分别可以兑换吉，星，高，照，外加小礼包五个奖励。奖励的丰富程度也是至上而下排列。最给力的当然是头像框，其次就是英雄体验卡什么的。吉星高照礼包兑换哪个好：首先要明确自己需要什么，如果是有头像框收集爱好的玩家，那肯定是兑换头像框礼包了。但是如果你只是想要钻石，或是英雄，小编建议16个吉星高照红包，拿下一个30天的英雄体验卡。多的红包，再兑换吉星高照-照礼包。

• 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提供负载均衡和容灾。

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

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

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

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

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

对于可能出现的超过了设计容量的流量尖峰，就要应用过载保护方法，保障系统能拒绝超过容量的部分请求，保障设计容量内的请求还能正常响应，实施的时候有四个要注意的地方：

• 从源头上减少无效请求；

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

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

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

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

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

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

 找准用户的核心诉求

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

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

 保障关键路径的可用

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

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

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

 放弃异常的非关键路径

• 前端页面展示模块化，对于请求数据不成功的非关键模块进行隐藏。

• 红包页面导流到游戏中心，游戏中心展示按红点逻辑展示，只显示第一屏的数据，默认不加载第二屏数据，用户往下滚动时再加载，牺牲用户往下滚动会短暂卡顿的体验减少后台的请求压力。

• 后台读取算法接口返回的推荐排序失败时使用默认的礼包排序。

• 后台读取CMEM接口返回的礼包是拉活跃还是拉新失败的时每款游戏默认返回低价值的拉活跃礼包。

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

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

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

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

1. 模块间的调用监控

监控系统内部各个模块间的调用是否正常，使用的是模调系统。

2. 模块内的状态监控

监控某个业务模块当前的状态是否正常，使用的是各个子系统自建的监控告警系统，春节红包这方面的监控主要有两个：AMS礼包领取剩余数量和消息队列消息堆积数量。春节红包由于准备的礼包数量较为充足，故没有引起告警；队列由于生成速度远超消费速度，设置的告警阈值是100W，但实际最终堆积超过了1200W，引发了告警。

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

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

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

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

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

• 对于系统容量内的合理请求，系统能否正常处理

• 对于系统容量外的超额请求，系统能否成功丢弃

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

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

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

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

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

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

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

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

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

• 后台SPP修改神盾的L5为错误的L5，SPP调用神盾出错，预期后台依旧能按默认排序返回礼包列表

• 后台SPP修改CMEM的L5为错误的L5，SPP调用CMEM出错，预期后台依旧能按全部游戏推荐拉活跃礼包返回礼包列表

• 后台随机停掉一台SPP，CGI调用SPP出错，预期服务短时间内有部分失败，L5能在1~2分钟内踢掉该出错机器，服务恢复正常

• 打开MQ容灾开关，用户领取成功消息不再放入MQ，而是直接走流水对账，预期游戏能够成功到账

• 前台用户操作频率超过了限制（5次/秒），预期前台直接返回领取失败，抓包看到请求不走到后台

• 前台调用后台接口通过设置host指向错误IP，前台调用后台推荐接口出错，预期前端页面依然能正确显示作为关键路径的礼包列表

• 前台调用后台接口通过设置host指向错误IP，前台调用后台非关键信息接口出错，预期前端页面对非关键模块进行隐藏

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