更多深度文章，请关注云计算频道：

https://yq.aliyun.com/cloud

微博红包在春节也是一个比较热门的词汇，经常出现在各种事件流之中，但是微博红包面临的场景比较特殊，比如面临亿级用户的大规模场景，它背后的技术架构和技术结构是怎么样的呢？来自微博红包团队的技术负责人柯立志在云栖社区2017在线技术峰会红包技术分会现场分享了微博红包背后的技术实践。

红包业务场景

今年的场景新增了传送门和粉丝红包。传送门主要是通过用户下拉feed流获得红包，可以连续抢，得到奖品。粉丝红包有口令红包和普通红包，红包的业务规模如下图所示。

红包面临的挑战包括：单个红包数额大；亿级别用户参与，覆盖全微博用户；红包种类多，业务复杂；整点准时抢，高并发访问量、瞬间峰值高；互动时间短，同步更新红包状态；多机房数据一致性保证。

红包系统设计

红包系统的整体架构包括应用层、服务层、资源层。应用层主要是用户的入口，任何一个用户进来之后都需要对其状态进行验证，所以需要进行用户状态验证。服务层包括各个服务模块，资源层则用到了数据库、Redis、MC、消息队列等。

红包塞钱

红包塞钱实现过程是：用户通过向客户端塞钱进红包，然后使用微博支付，经过队列后进行拆包服务，其他用户可以进红包进行抽取。在用户进红包之前，微博已经在队列中做了一些拆包的服务。

红包抽奖

如上图所示，其中更新的红包状态包括用户的状态和红包剩余金额等。在红包的抽取过程中大量使用了异步处理，这样保证了用户前端的可用性。

红包拆包模型

微博拆包的金额在0.5-200元之间。最初采用了通用模型设计，保证了大额的、100左右的金额，导致了0.5的比较多。之后，采用了基于正态分布的模型，对红包进行插值使得整个红包的金额分配更趋于合理。处理大额拆包时，做到了10万以下金额秒级可以拆。对于10万以上金额先拆分成10万以下金额再进行拆分。

特定场景选定合适实现方式

最初的实现是通过Nginx后端PHP服务以及存储资源实现的。经过调研后，采用了Nginx的高并发可用性，基于lua脚本语言实现应用层的服务。这样能够让单台服务器的并发数量能有数量级的提升。其缺点是对于快速业务耗费的人力成本和调试成本更高。

数据一致性保证

在红包分发期间，微博用到的设备包括微博自有机房、阿里云包月机房、阿里云动态扩容（根据峰值实时动态扩容）。同时，各个机房之间MC的缓存需要同步，并且同步机制需要达到毫秒级才能保证所有用户看到的红包状态均一致。缓存资源的实现通过消息队列实现，若消息队列发现缓存积压的资源比较多，可以通过实时的删写来减少（前提是三个部署都存在，如果动态扩容则删写，如果动态扩容收容则不删写）。阿里云的机器都是实时分配的，所以我们需要有快速响应的机制来更快的进行扩容和对MC缓存资源的写。

预热

春晚当天，微博红包当晚从20点开始每个整点的推送。为了减少对应接口的用户信息，提前预热了一批MAU用户，减少可能由于峰值带来用户服务系统压力，在当天预热了MAU用户数据，这样做可以保证在每个整点时间到来之前的红包数据为热数据。

异步化

异步化就是用消息队列来处理一些类似于用户时间比较长或者需要消耗大量资源的处理。比如抽奖，在抽奖的核心逻辑里，运营可配置、用户信息、红包状态的判断均用到了异步化来验证当前的用户是否中现金、卡券或者其他奖品。用户中奖后，奖品将进入队列，进行现金兑账、现金进钱包、发私信，这样就给前端用户的抽奖节省了大量的时间，使得前端的接口响应时间非常快。

红包保障体系

监控

系统保障的前提是监控，监控主要通过五个层面来进行的。网络监控主要是监控专线带宽，微博在春节期间大量使用阿里云的机器，对于专线的监控是有必要的。服务监控主要是自有服务的监控，类似监控feed接口、客户端拆和抽、传送门等服务的响应时间以及服务接口返回的状态。设备监控主要是前端机、服务器的监控，包括CPU、内存、网卡等的监控。资源监控涉及到缓存资源、存储资源，资源也是通过网络协议进行调用的，所以网络层面的问题会导致资源的可用性降低、响应时间变长。所以在应用层或者底层架构上都对资源所涉及的相关端口做了一些监控，比如每一次连接的响应时间、操作的响应时间、每一种响应时间的占比。接口监控主要依赖于其他接口，类似于用户信息的接口、微博钱包支付接口、卡券接口。

预案和干预手段

预案主要做了两类，一类是能够快速扩容，因为在每一个推广的时间段都申请了部分冗余的服务器，如果负载异常则会实时部署上去；一类是快速切换，通过切层的切换快速应对突发情况。

服务降级主要在服务异常或者负载过高时对非核心链路进行降级。

系统性能优化

性能

红包是由各个模块组成的，所以要对各个模块进行性能检测。性能检测的前提是制定性能指标，指标主要通过响应时间、接口输出大小制定。然后进行模块性能压测，分析模块具体消耗（时间及输出大小），根据具体点进行模块优化，直到模块性能达到标准才停止循环。

容量评估

根据目前应用场景用户的DAU和MAU去预估在某个时间点最大的QPS。根据最大的QPS以及单机所承载的QPS预估应用服务器的数量。根据接口依赖程度、接口访问量占比预估每个接口输出的带宽，预算出整体的带宽占用来进行带宽方面的扩容以及预演。资源占用的评估主要根据最大的QPS以及后端端口资源需要使用的数量来评估，保证在出现预估范围内QPS时系统服务的稳定。