请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 3
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等
微信扫一扫关注!

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


一、引言


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

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

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

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

二、系列文章


❶ 系列文章目录:


❷ 其它相关文章:

三、产品功能需求


3.1、红包类别


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

如下图所示:
1.jpg

3.2、体验流程


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

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

体验如下:
2.png

3.3、后台需求


游戏红包的设计容量为入口卡券页流量 80k/s,以上体验流程一共涉及三个后台接口:
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 异步发货功能的开发,在春节红包中应用,再将这个功能交接给平台侧的同学维护,达到双赢的效果。

五、整体方案与项目分解


4.png
注意:因本图较大,清晰大图请从此附件下载 整体方案图(清晰大图).zip (769.6 KB , 下载次数: 4 )

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:社交软件红包技术解密(八):全面解密微博红包技术方案下一篇:即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

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

推荐方案
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部