# 题目

总共有10亿个红包,在某个时间一起来抢红包,如何设计

# 分析

主要考察的是如何设计高并发系统,但实际上存在一定变通处理方式,不一定全在技术上

通常在考虑系统QPS时,应当按业务上的极限QPS作为系统必须承担的QPS设计,比如10亿个红包,因为用户量巨大,极限QPS是可能是10亿

但是一般来说几万QPS已经是比较高的并发了,就需要比较大的集群和高并发架构来处理了,所以不可能真正实现10亿的并发架构,而是通过一些变通的方法来处理,比如在业务上做一些处理规避掉部分流量

但尽可能地需要实现高并发架构,思路是将大部分流量拦截在系统承载能力低的模块之前

# 回答

# 业务上适当规避

在相应法律法规、规章制度、活动说明、用户体验允许的情况下,可以做以下处理

  1. 根据某些规则对部分用户直接返回没抢到。比如有些用户曾经被系统识别为恶意用户、垃圾用户、僵尸用户,直接告诉用户已经抢完
  2. 分散不同客户端打开活动入口的时间。比如将1秒内的10亿流量分散到10秒,那么平均每秒只有1亿了
  3. 增加客户端入口点击门槛。比如需要手机摇一摇、画一个图案才能触发抢红包的接口

# 技术上硬核抗压

网关是会接触实打实10亿流量的地方,也是拦截掉最多无效流量的地方,同理,缓存也是

  1. 限流策略。比如在压力测试中我们测到系统1亿QPS达到了极限,那么超过的部分直接返回已经抢完,通过Nginx的lua脚本可以查redis看到QPS数据从而可以动态调节
  2. 作弊拦截。通过对UA、IP规则直接将抢红包的作弊流量拦截掉
  3. 异步削峰。对Redis中的红包预减数量,立即返回抢红包成功请用户等待,然后把发送消息发给消息队列,进行流量的第二次削峰,让后台服务慢慢处理
  4. 服务逻辑。比如业务逻辑是使用事务控制对数据库的创建红包记录,减红包数量的操作,那么创建操作要放到减数量操作之前,从而避免减数量update的行锁持有时间
  5. 机器配置。当然是服务器机器配置约高越好,数据库配置越猛越好,高并发抢红包主要是CPU的负载较高,要选择偏向CPU性能的机器