如何设计一个抢红包系统（商品秒杀同理）

参考资料：https://www.jianshu.com/p/c4a743bbe3a4

这种情况下要解决的问题：

• 同一时间同时进行抢购，网站瞬时访问流量激增。
• 访问请求数量远远大于库存数量，但是只有少部分用户能够秒杀成功（高并发访问的数据安全性）。

优化思路

1. 数据预处理，系统启动时将红包（商品）信息存到缓存中，并用唯一id进行标识，将后续逻辑精简为维护用户与ID的关系。
2. 异步处理，将后续逻辑放置队列or数据库中。
3. 并发处理，采用redis的单线程+自减数值特性，提前将所有id分发至redis的各个broker，负载均衡将请求分发到不同应用实例--redis实例，这样可达成线性扩容特性。另一种方式是，使用redis的集合（set）存储结构，同时存储商品id和用户id。
4. 其他：限制单个用户IP的qps，前端按钮置灰，前端资源静态化。

下面是一套旨在支撑10万每秒请求峰值的抢红包系统。经实践证明，春节期间我们成功的为所有的小伙伴提供了高可靠的服务，红包总发放量近百万，抢红包的峰值流量达到3万/秒，最快的一轮抢红包活动3秒钟所有红包全部抢完，系统运行0故障。

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

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

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

最后，这个系统是为了春节的庆祝活动而研发的定制系统，且只上线运行一次，这意味着我们无法积累经验去对服务做持续的优化。并且相关的配套环境没有经过实际运行检验&#