dW 编辑推荐：如何设计一个小而美的秒杀系统？

Posted 2021-05-02 developerWorks中国

现如今，春节抢红包的活动已经逐渐变成大家过年的新风俗。亲朋好友的相互馈赠，微信、微博、支付宝等各大平台种类繁多的红包让大家收到手软。鸡年春节，公司的老总们也想给 15万的全国员工发福利，于是我们构建了一套旨在支撑 10 万每秒请求峰值的抢红包系统。经实践证明，春节期间我们成功的为所有的小伙伴提供了高可靠的服务，红包总发放量近百万，抢红包的峰值流量达到 3 万/秒，最快的一轮抢红包活动 3 秒钟所有红包全部抢完，系统运行零故障。

红包系统面临的挑战

红包系统，类似于电商平台的秒杀系统，本质上都是在一个很短的时间内面对巨大的请求流量，将有限的库存商品分发出去，并完成交易操作。比如 12306抢票，库存的火车票是有限的，但瞬时的流量非常大，且都是在请求相同的资源，这里面数据库的并发读写冲突以及资源的锁请求冲突非常严重。现在，我们将分析实现这样一个红包系统，需要面临如下的一些挑战：

首先，到活动整点时刻，我们有 15 万员工同时涌入系统抢某轮红包，瞬间的流量是很大的，而目前我们整个链路上的系统和服务基础设施，都没有承受过如此高的吞吐量，要在短时间内实现业务需求，在技术上的风险较大。

其次，公司是第一次开展这样的活动，我们很难预知大家参与活动的情况，极端情况下可能会出现某轮红包没抢完，需要合并到下轮接着发放。这就要求系统有一个动态的红包发放策略和预算控制，其中涉及到的动态计算会是个较大的问题（这也是为系统高吞吐服务），实际的系统实现中我们采用了一些预处理机制。

最后，这个系统是为了春节的庆祝活动而研发的定制系统，且只上线运行一次，这意味着我们无法积累经验去对服务做持续的优化。并且相关的配套环境没有经过实际运行检验，缺少参考指标，系统的薄弱环节发现的难度大。所以必须要追求设计至简，尽量减少对环境的依赖（数据路径越长，出问题的环节越多），并且实现高可伸缩性，需要尽一切努力保证可靠性，即使有某环节失误，系统依然能够保障核心的用户体验正常。

能负责有技术挑战的项目，对于工程师来说总是压力和兴趣并存的。接手项目后一个月的时间内我们完成了技术调研，原型设计研发，线上运维等工作。关于这个过程中的细节，下面为读者一一道来。

系统设计

系统架构图如图 1 所示。整个系统的主干采用主流的 Web 后台设计结构，子系统各自部署为集群模式并且独立。APP 客户端与网关接入层（负责用户鉴权、流量负载均衡、整合数据缓存等）进行交互，再往后是核心的逻辑系统（用户资格校验、红包分发、数据异步持久化、异步财务到账、降级等），数据持久化采用的mysql 集群。除此之外还有静态资源的管理（红包页面图片、视频等资源的访问优化）以及配套的服务整体运行监控。所有的静态资源提前部署在了第三方的 CDN 服务上。为了保障整体系统可靠性，我们做了包括数据预处理、水平分库、多级缓存、精简 RPC 调用、过载保护等多项设计优化，并且在原生容器、MySQL 等服务基础设施上针对特殊的业务场景做了优化。

更多内容，请阅读原文。