总共有10亿个红包，在某个时间一起来抢红包，如何设计
主要考察的是如何设计高并发系统，但实际上存在一定变通处理方式，不一定全在技术上
通常在考虑系统QPS时，应当按业务上的极限QPS作为系统必须承担的QPS设计，比如10亿个红包，因为用户量巨大，极限QPS是可能是10亿
但是一般来说几万QPS已经是比较高的并发了，就需要比较大的集群和高并发架构来处理了，所以不可能真正实现10亿的并发架构，而是通过一些变通的方法来处理，比如在业务上做一些处理规避掉部分流量
但尽可能地需要实现高并发架构，思路是将大部分流量拦截在系统承载能力低的模块之前
在相应法律法规、规章制度、活动说明、用户体验允许的情况下，可以做以下处理
- 根据某些规则对部分用户直接返回没抢到。比如有些用户曾经被系统识别为恶意用户、垃圾用户、僵尸用户，直接告诉用户已经抢完
- 分散不同客户端打开活动入口的时间。比如将1秒内的10亿流量分散到10秒，那么平均每秒只有1亿了
- 增加客户端入口点击门槛。比如需要手机摇一摇、画一个图案才能触发抢红包的接口
网关是会接触实打实10亿流量的地方，也是拦截掉最多无效流量的地方，同理，缓存也是
- 限流策略。比如在压力测试中我们测到系统1亿QPS达到了极限，那么超过的部分直接返回已经抢完，通过Nginx的lua脚本可以查redis看到QPS数据从而可以动态调节
- 作弊拦截。通过对UA、IP规则直接将抢红包的作弊流量拦截掉
- 异步削峰。对Redis中的红包预减数量，立即返回抢红包成功请用户等待，然后把发送消息发给消息队列，进行流量的第二次削峰，让后台服务慢慢处理
- 服务逻辑。比如业务逻辑是使用事务控制对数据库的创建红包记录，减红包数量的操作，那么创建操作要放到减数量操作之前，从而避免减数量update的行锁持有时间
- 机器配置。当然是服务器机器配置约高越好，数据库配置越猛越好，高并发抢红包主要是CPU的负载较高，要选择偏向CPU性能的机器