我司的面试题目公开诚聘 Java 工程师入坑

[jiansihun]

在抽奖场景中，最高峰值为 2w QPS，运营部现有 20000 部 iPhone 手机，决定每 100 人随机抽中一台，覆盖人数 200w 人，送完即止。请如何技术上如何实现该机制。

如有能回答上述问题的 Java 工程师请考虑一下我司广州工作： https://www.lagou.com/gongsi/j29385.html，或者站内私我简历。

[woahishui]

创建一个数据表(可以用数据库或者 nosql)，记录用户的的抽奖记录，每 100 个人分一个标识，使用随机函数标识查询到的记录作为中奖着，这样可以吗

[NewDraw]

@woahishui


缓存+限流+消息队列，200wQPS 都没问题。

[mooncakejs]

2w QPS redis 就可以撑住，hset 用户 id 去重，抽奖形式就很多了，increment value % 100，pull list，或者干脆队列化单线程抽奖。

[woahishui]

呵呵

[woahishui]

都行，方案应该都可行吧

[zyue]

按奖品数量分为 20000 场，对用户 id hash 落到 1-20000 中的某个场次，检查缓存，看对应场次是否因有人抽中而结束，结束的话直接返回未抽中，没有的话执行抽奖等逻辑，可以同步抽取，也可以走 mq 异步处理。

[zz656565]

这点羊毛够黑产薅吗？

[woahishui]

不过我倒觉得这个想法有问题，那么快就完了容易导致服务器压力突然增大，不如让大家先报名，然后在一周后统一抽奖，这样关注度高，时间长，而且还能降低技术难度，降低技术难度意味着可以省去 5000 部手机的钱，相当于只要 15000 部就够了。这是我的建议

[lihongming]

200W 用户总不能是一下来的吧？何不换个姿势，把抽奖过程放到用户入库的过程中？

比如分个随机数给它，根据这个随机数把用户放入一个长度为 2W 的数组，数小的顶走数大的，最后剩下的都是中奖的。

[woahishui]

参加抽奖是参加抽奖，不要将抽奖混合在一起，我是这么想的

[matrix1986]

消息队列，削峰不二之选

[LuciferGo]

刚好前两天在掘金看了这个问题，https://juejin.im/post/5ce1975af265da1bd42450b5

[9684xtpa]

@NewDraw #2
基础之上只要保证，如何覆盖面达到 200W，毕竟是 100:1，这个利用 redis 的 incr 和缓存也能搞定，每个购买的人分配一个数值 ID，每 id%100=0 的人具有购买资格。

[Leigg]

记得奖品抽完后告诉前端请求不要发到后端。

[qwerthhusn]

当然是内定啊，a 这个是老板的意思。。。。

[vincel]

这种场景小米很有发言权，直接前端砍掉 2/3 的请求。

[myself659]

套方案吗？

[horace1117]

不是应该直接 redis 缓存未抽中就行了嘛，抽奖什么的当然是内定

[cyndihuifei]

随机拒绝 1 / 200 的概率，让用户进行后面的请求，直接削减大部分请求

[CRVV]

1. 给登录用户一个 jwt，客户端在发的请求的一个 HTTP header 里带上用户 id
2. 在 load balancer 上，拿用户 id 来决定路由，让同一个用户的请求只会被路由到同一台机器上
3. 接到请求的机器验证 jwt，并且记下来发过请求的用户，如果这个用户已经发过请求就直接返回
4. 随机决定 1% 的用户中奖，然后把数据库上把剩余奖品的数量 atomic x--，如果 x>0 就给用户返回中奖了

数据库上只有 200 QPS 的请求，只要是支持 atomic 操作的数据库应该都能用
其它的部分互不依赖可以无限加机器

没做过类似的东西，大概想了一下这样应该能用