现如今，春节抢红包的活动已经逐渐变成大家过年的新风俗。亲朋好友的相互馈赠，微信、微博、支付宝等各大平台种类繁多的红包让大家收到手软。鸡年春节，公司的老总们也想给 15 万的全国员工发福利，于是我们构建了一套旨在支撑 10 万每秒请求峰值的抢红包系统。经实践证明，春节期间我们成功的为所有的小伙伴提供了高可靠的服务，红包总发放量近百万，抢红包的峰值流量达到 3 万/秒，最快的一轮抢红包活动 3 秒钟所有红包全部抢完，系统运行零故障。
红包系统面临的挑战红包系统，类似于电商平台的秒杀系统，本质上都是在一个很短的时间内面对巨大的请求流量，将有限的库存商品分发出去，并完成交易操作。比如 12306 抢票，库存的火车票是有限的，但瞬时的流量非常大，且都是在请求相同的资源，这里面数据库的并发读写冲突以及资源的锁请求冲突非常严重。现在，我们将分析实现这样一个红包系统，需要面临如下的一些挑战：
首先，到活动整点时刻，我们有 15 万员工同时涌入系统抢某轮红包，瞬间的流量是很大的，而目前我们整个链路上的系统和服务基础设施，都没有承受过如此高的吞吐量，要在短时间内实现业务需求，在技术上的风险较大。
其次，公司是第一次开展这样的活动，我们很难预知大家参与活动的情况，极端情况下可能会出现某轮红包没抢完，需要合并到下轮接着发放。这就要求系统有一个动态的红包发放策略和预算控制，其中涉及到的动态计算会是个较大的问题（这也是为系统高吞吐服务），实际的系统实现中我们采用了一些预处理机制。
最后，这个系统是为了春节的庆祝活动而研发的定制系统，且只上线运行一次，这意味着我们无法积累经验去对服务做持续的优化。并且相关的配套环境没有经过实际运行检验，缺少参考指标，系统的薄弱环节发现的难度大。所以必须要追求设计至简，尽量减少对环境的依赖（数据路径越长，出问题的环节越多），并且实现高可伸缩性，需要尽一切努力保证可靠性，即使有某环节失误，系统依然能够保障核心的用户体验正常。
能负责有技术挑战的项目，对于工程师来说总是压力和兴趣并存的。接手项目后一个月的时间内我们完成了技术调研，原型设计研发，线上运维等工作。关于这个过程中的细节，下面为读者一一道来。
系统设计系统架构图如图 1 所示。整个系统的主干采用主流的 Web 后台设计结构，子系统各自部署为集群模式并且独立。APP 客户端与网关接入层（负责用户鉴权、流量负载均衡、整合数据缓存等）进行交互，再往后是核心的逻辑系统（用户资格校验、红包分发、数据异步持久化、异步财务到账、降级等），数据持久化采用的 MySQL 集群。除此之外还有静态资源的管理（红包页面图片、视频等资源的访问优化）以及配套的服务整体运行监控。所有的静态资源提前部署在了第三方的 CDN 服务上。为了保障整体系统可靠性，我们做了包括数据预处理、水平分库、多级缓存、精简 RPC 调用、过载保护等多项设计优化，并且在原生容器、MySQL 等服务基础设施上针对特殊的业务场景做了优化。
图 1. 系统架构 红包本身的信息通过预处理资源接口获取。运行中用户和红包的映射关系动态生成。底层使用内部开发的 DB 中间件在 MySQL 数据库集群上做红包发放结果持久化，以供异步支付红包金额到用户账户使用。整个系统的绝大部分模块都有性能和保活监控。
优化方案优化方案中最重要的目标是保障关键流程在应对大量请求时能稳定运行，做到这一点，需要很高的系统可用性。因此，业务流程和数据流程要尽量精简，减少容易出错的环节。此外，cache、DB、网络、容器环境，任何一个部分都有可能会出现短时故障，我们需要提前做处理预案。针对以上的目标难点，我们总结了如下的实践经验。
数据预处理我们结合活动预案要求，将红包本身的属性信息（金额，状态，祝福语，发放策略），使用一定的算法提前生成好所有的信息，这些数据所占空间不是很大。为了最大化提升性能，我们事先将这些红包数据，我们事先存储在数据库中，然后在容器加载服务启动时，直接加载到本地缓存中当作只读数据。另外，我们将员工信息也做了一定的裁剪，最基本的信息也和红包数据一样，预先生成，服务启动时加载。
此外，我们的活动页面，有很多视频和图片资源，如果这么多的用户从网关实时访问，带宽很可能直接就被这些大流量的请求占满了，用户体验可想而知。最后这些静态资源，我们都部署在了 CDN 上，通过数据预热的方式加速客户端的访问速度，网关的流量主要是来自于抢红包期间的小数据请求。 |
