@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 容器连接池试试，再试试你说的抢占式服务器，明天研究下

@buffzty 好的 大佬 别刷了(哭了)，明天有空 写了 ip 封禁，超过多少次的，直接给封了

@buffzty 老哥，刚才我给下线了，怕扛不住。我想说有没有大佬有好的机器，可以把项目部署一下，压测一波



哪位老哥在压测呀，别压我的小水管呀，等会我限流了，在这样搞

@xiaowangge 的确，阿里国际 不算阿里核心业务把，听说加班贼严重，而却很多老阿里人

<a href="https://imgur.com/dvuVb1e"><img src="https://i.imgur.com/dvuVb1e.png" title="source: imgur.com" /></a>

大家有些网址不要乱来，我这边数据库都能看得到的
[图片]( https://imgur.com/a/51agHXO)

哪个公司？

@oiYuer 如果单说性能的话，要求非常非常高。openresty+lua 是一个很好的解决方案，但它的稳定性感觉有待商榷

@nicoljiang 感谢分享，刚才简单 google 了下 leveldb ，有点像 mongdb ？如果效率高，可以考虑使用，至于为什么我没有选择计数器，使用计数器还需要单独维护一个全局变量，使用中间件的话，反而降低了短链的稳定性

@mosliu 1. 机器性能不够，500W murmur64 0 冲突，1000W 不好说 2. 数据库慢，其实可以通过分库分表，读写分离，依然可以得到很好的性能，微博底层就是数据库。如果不选择数据库，选择 hbase ，es 等，反而有更多的其他问题需要解决。3. bloomfilter 过滤器我感觉这里用处不大，如果存在不一定真的不存在，如果不存在才是真的一定不存在，这个存在还是去查数据库，感觉用处有限