最近几周在做一个较大的项目，直播间发红包，感觉有一些收获
通用的红包模块，是发红包模块、抢红包模块、抢红包记录、发红包记录、手气最佳
红包项目的挑战在于抢红包时的高QPS
抢红包接口不要直连数据库，而是通过rpc
我们可以把抢红包接口单独集群部署，其他接口另外部署在一个集群
一些技术点：
1, 抢红包时的高并发
2, 如何保证人数较少时红包尽可能被抢完
3, 如何保证哪些用户优先抢到红包或者金额较大的红包
4, 如何保证红包金额尽可能的随机
5, 如果保证抢红包不会造成咨损，抢着抢着抢红包的总额大于红包总额
6, 如何保证用户的体验，如提示抢到红包，但没有真正的抢到
7, 依赖DB 还是信任redis ，如何减少数据不一致的情况
8, 分库分表策略
9, 如何应对DB、缓存、甚至机房级的故障
一些好的方案：
处理高并发就是削峰、预处理、打散请求
我们kafka一般不做削峰，而是用做非核心流程异步化
我们常用的是打散请求和预处理
[打散请求] 把抢红包的请求打散比如3s , 这3s出现loading提示
比如说给客户端下发一个maxDelayTime , 客户端对每一个请求在（0, maxDelayTime] 随机延迟请求或者分hash延迟请求
[预处理] 把哪些用户可以抢红包提前下发（抢红包开始之前）
过滤掉一部分流量不去请求接口（客户端简单mock就返回）
反正流量打到后端也大概率抢不到，还不如提前把一部分的流量拦截掉，
只让一部分请求真正的抢
比如说10000个人去抢红包，3000个幸运儿会被提前告知不会去请求后端，客户端简单mock直接返回抢红包失败
剩下7000人去抢，最后100人抢到
说点什么
您将是第一位评论人！