【十万火急】性能问题求解

[wilson2017]

做了一个直播互动的功能：抢红包
功能逻辑如下：

到一个时间点时，屏幕会出现红包雨的效果，参与直播的用户进行点击拆红包，累计红包数量可兑换成现金，直接转入自己的微信账户中。


碰到的瓶颈问题：

大量用户同时在抢红包时，服务器CPU会急剧飙高，导致整个页面都卡死，甚至服务器宕机


服务器配置：

网站服务器：WinSvr 2008R2 , 30M带宽，16核CPU，内存32G

数据库服务器：WinSvr 2008R2 , 1M带宽（内网连接），16核CPU，内存32G

程序实现逻辑

通过客户端脚本记录用户抢到的红包数量存储到本地缓存中，抢完后再调用服务端接口来计算红包数量应得的红包金额，最后发红包。

以上，求各路大神给出比较好的优化方案

[by_封爱]

2000个人请求一个接口 问题不大吧.... 我觉得是"抢红包"代码的问题...

[wilson2017]

用户量在1500~3000个左右

[wanghui0380]

我们不管你用户量有多大 既然是抢，拼的是“运气”，所以能不进入服务器正式操作也是运气 so，做个“令牌桶限流"就好，抢到令牌的进，没抢到令牌的，直接扔掉不处理

[wanghui0380]

回答这类问题，我们这种实际一线处理问题的人，跟博客园那些高大上的内卷式技术大神不一样 他们告诉你是怎么内卷，怎么堵门。 我们告诉你的是，怎么向外看，怎么跟其他行业的学习。 java，go，甚至都不是这个行业的学习 比如：水利专家怎么看。 你这问题和水利专家的情况一样，如果发洪水了，怎么保护下游 那么 1.加固下游堤坝 2.修建防洪坝 3.修建分洪坝，溢流坝。 4.建立泄洪区 5.利用上面所有设施进行，库容调节，进行分流，消峰，错峰，弃水等调度手段 所以借用人家玩了几千的经验 1.加固下游堤坝------------改善你现有的处理逻辑，尽量降低cpu 2.修建防洪坝-------------------利用mq，kafaka,redis，先将数据入水库，然后在过坝调度 3.修建分洪坝，溢流坝-----------利用api网关，进行分流，熔断 4.建立泄洪区----------------利用令牌桶，漏桶进行限流弃水 5.利用上面所有设施进行--------------利用上面所有的收到，进行流量调度

[wanghui0380]

内卷式大神主要就在 加固下游堤坝------------改善你现有的处理逻辑，尽量降低cpu 这里玩 但是几千年的洪水经验告诉我们，这种其实作用有限。 中国历史所有朝代都在不停加固堤防，但是洪灾也没小过。（俺们电视剧，总在修河堤，修河堤。发大水，发大水） 但是近代综合性水利工程以后，这种情况才好很多。所以我们的建议是，进行综合性治理和调度，而不是仅仅就讨论加固堤坝

[一品梅]

REDIS研究研究，研究完发出来心得

[快乐起航2020]

数据库服务器和网站服务器对调下 可以么

[极客诗人]

其实我更好奇 红包雨的产生逻辑 究竟是每个红包均为真 --那么对应的每个红包都有对应的唯一值作为关系确定与抢到的用户关联 （如果是这种，无非就是按照#3 所说的设计） 还是说时间点内红包累计数量 然后再做统计 这种的话，是不会出现所谓的性能问题。 但是这种对应的安全规范也需要做对等，比如说会产生X个红包（X为阙值），然后数量判断肯定不会操作这个X，对应发放红包即可。

[cannycsy]

做队列处理不就行啦，你不要一下子全部到帐，给个独立的队列让它一条条处理就是百万数据都没问题，也不会卡。