bigbigeggs

你这么单纯的么，别人为什么要配合你，那就按规则办事。
人家都在会上当着老板说了，年后有资源，你让他给排期，然后风险上报不就行了，这么简单的事

@dilu 感谢，的确给些假数据，对方就比较迷惑了。的确可以试试这种方法，感觉可以作为迫不得已的一种屈服

@AliCN 接口不太可能停，认证指的是登录这种？

@summerwar 看了下请求头，什么都有。UA referer 这些全构造了，像一个真人一样，头大

@cyrivlclth 这种营销手段，很少会有用户参与的，太没有参与感了。事实上，在一些节日大促，比如 618 双 11 ，的确会有一波不小的流量，等服务扛不住了，自然而然就会想到例如缓存，业务随机拦截，mq 异步等等，当然大部分业务不会遇到这种情况

@Pantheoon 🤣🤣 兄弟，的确真实。“而是如何用 2 天时间在屎山一样的代码中，拉齐一样是屎山代码的兄弟域” 这句话 我赞同，当然大部分是面试用用。不过在真实的工作中，遇到高并发，缓存这块还是需要第一时间想到的解决手段

”在我自己的小水管，压不上去，如果哪位大佬有比较好的机器，欢迎压测一波，看看性能能到哪里去“ 这里可能被大家误解了，我的意思是 我自己用我的服务器压不上去，我知道瓶颈点不在代码，是在于机器。而很多时候，我们做营销活动，不是说加机器就能把 qps 给提升上去的，所以思路很重要。我的意思是 如果哪位大佬有比较强劲的机器，我的代码都是开源的，很容易部署的，可以放在他的服务器压测一波，看看瓶颈点在哪里

@NavsSite @cyrivlclth @zhhmax 代码主要是思路和逻辑，值得学习。最主要代码是 grantPrize 这一块，逻辑我已经贴出来了。其中的思路，比如缓存，锁，随机比例拦截，预减库存等等思路都是处理高并发的手段，很多细节没有一一列举，包括如何保证 redis 库存和 mysql 一致，如果业务在活动中想修改库存怎么办，怎么保证不重复领取等等问题。 至于百万 qps ，也就非常好实现了，在实际 mysql 减库存之前，利用缓存，随机预处理已经拦截了 99%的流量，剩下 1%很大，也可以用 mq 异步来处理。一台 redis 达到 10W qps ，基本工业级别都是分布式，水平扩展，达到百万 qps 非常的简单。

@buffzty 小水管看来撑不住，我看日志 连接池不够用了，拿不到资源，cpu 飙到了 90%多了。明天我加大 web 容器连接池试试，再试试你说的抢占式服务器，明天研究下