解密微博红包：架构、防刷、监控和资源调度
编者按
与传统意义上的红包相比，近两年火起来的“红包”，似乎才是如今春节的一大重头戏。历经上千年时代传承与变迁，春节发红包早已成为历史沉淀的文化习俗，融入了民族的血脉。按照各家公布的数据，除夕全天 微信用户 红包总发送量达到10.1亿次，摇一摇互动量达到110亿次，红包峰值发送量为8.1亿次/分钟。而 支付宝的红包 收发总量达到2.4亿次，参与人数达到6.83亿人次，红包总金额40亿元，峰值为8.83亿次/分钟。春晚直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过8亿次。
为此，InfoQ策划了“春节红包”系列文章，以期为读者剖析各大平台的红包活动背后的技术细节。本文为微博篇。
随着互联网的发展，打破了以往传统的发红包，带给了红包全新的玩法。微博红包已经成为用户给粉丝拜年的一种途径，土豪版成为土豪刷存在感的方式。每年的红包大战都是用户的现金盛宴，对于整个系统却是残酷的考验。
微博有8亿注册用户，单日活跃用户数1.34亿的社交平台。红包在微博平台上运行，针对所有的微博用户开放，微博所有用户都可参与红包活动。微博红包有如下特点：
- 红包价值高、种类多、覆盖用户广，亿级别用户参与。
- 半点准时开抢，高并发访问、瞬间峰值高，每分钟带来上亿次的抢红包峰值。
- 请求快速响应，更新亿级用户中奖状态及红包状态。
- 单个红包数额大。
春晚当天红包总价值超过10亿，有1.34亿用户参与，产生了8亿多次的抢红包行为，其中并发量为平时峰值的10倍左右。在服务器数量一定的情况下，如何构建高并发操作、瞬间峰值高的稳定服务？对于团队和架构师都是一个极大的挑战。这时候系统的架构尤为重要！
红包架构
微博红包支持每秒几十万次的操作，应对突发性的热点事件，快速响应，高内聚低耦合的服务成了架构首先要考虑的因素。
(点击放大图像)
微博是社交型应用，红包在用户数据、关系、抢红包等结构上存在着各种各样复杂的依赖，这些依赖相比其它应用来说，调用频率更高，性能要求也更高。
如上图所示，有多个应用模块接入红包的服务层，服务层由多个节点组成，每个节点对应相应的功能并且相对独立。代码模块的使用和组织上相对独立，保证主功能的快速和稳定，将附属的新功能分离在独立模块中。其中红色虚线框内为核心的功能模块，是重点需要保护的功能。
微博红包提供获取红包属性（红包金额、红包设置、红包状态、获取抽取结果列表、拆包，抽奖等）接口。服务层调用红包SDK相应的API，会根据应用层逻辑需求提供数据和定制化得数据，完成前端完成交互，达到应用层需要展现的效果。
防刷策略
微博红包有别于微信用户发出的红包，微信用户发出的红包是针对自己所认识的朋友或者已存在于微信群的用户；微博红包是针对于微博所有用户的红包，通过分析参与红包的用户数据每年都会产生一些囤积大量账号准备在春晚大发横财的公司和个人。如何防止微博红包被自动注册或者通过转卖账号来领取红包？这成为面对我们需要解决的一大问题。
(点击放大图像)
微博通过基于用户在微博上的行为分析，通过登录，发微博，身份验证等方面来进行分析。主要有：
- 用户注册：通过用户行为分析来识别机器注册的用户，则注册环节进行拦截。
- 用户登录：分析用户登录的行为，通过验证码，身份验证以及手机号验证等措施来提高机器自动登录的门槛。
- 账号质量：通过实名认证，微博的动态等方面来计算出用户的质量。
- 参与红包：红包战场一贯是刷奖账号的获利主战场， 通过用户平时在微博的行为、属性以及实时的登录状态和常用设备来进行分析，判断是否是正常账号来确定是否可以中奖。
完善的监控
红包系统是一个大而规则复杂的系统，系统越大，依赖的资源越多，也就越容易出现各种各样的问题。为了给提供稳定运行的服务，必须要能时刻知晓各个资源当前的运行状态。并且在系统出现异常之前或者出现异常的时候，对问题进行排查和定位。
(点击放大图像)
如上图所示，完善的监控系统，为微博红包顺利度过春晚提供了很好的保障。主要涉及的监控如下：
1、应用层接口响应时间监控
通过实时的分析access log日志，以HTTP code和响应时间维度实时统计出接口的状态和性能，根据占比来查看接口的健康程度。
2、服务层各模块性能监控
在模块中记录开始时间和结束时间，每次处理完计算出模块的耗时，通过这种方式很好的发现各个模块是否正常。
3、网络层监控
微博红包的出口网络是一个单独的app池，出口带宽使用到80%的时候网络稳定性就可能受到影响。通过计算后端服务器输出计算出带宽，以便能够做到及时响应扩容。
4、资源层的监控
对各种资源的监控，比如Redis、MySQL、MC等资源的连接时间、状态和操作的实时统计分析，快速定位是否存在资源瓶颈。
5、服务器的性能监控
通过运维监控系统，对服务器的CPU、内存使用情况，做到了能够观察每台服务器具体的运行情况。
6、系统错误日志的监控
系统错误监控包括服务器负载，服务进程状态，资源连接，网络连接出现的问题，实时通过手机，邮件和私信知道。为快速响应创造了条件。
弹性资源管理和调度
1、故障的秒级切换
微博红包服务部署在了三个机房（包括云服务），任何一个机房如果出现网络或者其它不可预测的问题可以在几秒钟之内将服务切换到其它机房。
2、资源的相互独立
资源的相互独立，让资源的可扩展性变得容易。而且使得各个服务之间交叉影响达到了最小。
3、引入阿里云做为第三机房，使用Docker快速部署服务
红包的核心服务主要分布在 2 个机房，两者互相做为灾难备份用途，为应对超预期的峰值，引入阿里云做为第三机房。使用定制化的红包Docker快速部署服务来实现弹性调度架构。通过Docker自动化操作大规模集群，进行弹性调度资源的任务，实现快速部署服务来应付超预期的峰值。
系统的挑战和性能优化
为了保证用户体验，微博红包需要解决以下几个问题：
- 系统性能的可靠性
- 关键节点的可用性
- 如何应对突发热点
- 业务频繁迭代的处理
1、系统架构的升级
模块的独立化，避免出现模块间的相互影响。
nginx+lua的使用，使得服务器的QPS有了数量级的提升，同时服务器集群做到了秒级重启。
2、修枝剪页
减少对于系统外部的依赖，梳理完整的调用关系图。非核心功能使用异步调用，合并相关的调用，去掉重复的调用。保证核心调用逻辑，避免非核心业务影响核心业务。
3、多级缓存
服务端本地缓存，使用nginx本身缓存和服务器的L0缓存，来提升模块的响应速度，做到了90%以上核心接口的响应时间在50ms以内，减少了进程等待时间，提升了服务器的处理速度。
一年一度的各大平台抢红包还会延续下去，这是一个斗智斗勇的过程，在服务器有限的情况下每一次与峰值的对抗都是对技术一次极大的挑战，每次挑战都是带来技术上的成长和收获。
感谢郭蕾对本文的策划和审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
