阿里三面：秒杀系统如何设计？竟然败在这题了。。。

樱塚大人:
视频讲的非常不错，但处理真正的高并系统发还要额外考虑cdn，LB，高防和waf的性能瓶颈，分布式锁的过期时间，redis连接池和出入向流量瓶颈，用户端限频柔性策略，流式计算和消息对列进行解偶，分布式表的设计，虚拟化/容器的调度机制，内核的各项参数buffer tcp reuse，应用框架的内存管理机制，异常处理，服务降级和熔断等等

【回复】就几百用户，考虑那么多，老板还吃不吃饭啊[滑稽][滑稽]
【回复】是的 所以脱离实际场景谈需求就是搞笑的
耐心si种美德:
这还不简单？直接做成点了秒杀按钮，直接toast提示商品已抢完不就好了，还能帮商家节约成本[脱单doge]

【回复】小米：这都被你发现了？
【回复】对的，反正也抢不到，用最短的时间满足了99.999%用户的需求，财务亲自给你发钱
她和她的竹:
昨天面试问我秒杀，被面试官问惨了，怎么说面试官都不满意。

【回复】回复 @骑单车的贝塔 :确实 有些面试官张口就来怎么处理高并发，其实他们公司可能到倒闭 并发都超不过三千
【回复】你问他日活跃，没多少别扯这些东西[偷笑]
【回复】回复 @胖迪不胖呦 :其实他们有空研究高并发，还不如把他们的业务做好，这样就不至于倒闭了[喜极而泣]，不过业务要搞好分分钟比高并发还难[笑哭]
四处察察:
[doge]redis支持每秒81w次的读取，至于缓存和数据库的一致性，当然是提前把数据库的数据刷到缓存里啊，秒杀按钮点击时立即同缓存中的数据进行处理判定，肯定是少部分成功，其它人直接返回失败的json了。成功那部分的少部分人数据库轻松就抗住了[doge][doge][doge]

渴望蓝天彡:
这还不简单，直接在页面上随机1%的记录会把秒杀请求发到服务器，其它99%直接显示没有库存，反正绝大部分用户也看不出来[doge]

【回复】回复 @苏三说技术 :那是剩下的1%的事了，至少这样直接就把压力减少了一百倍，效果立竿见影
爆炸之boom:
首先秒杀问题必须得结合场景来设计，看你有多大流量，结合流量来申请服务器以及负载均衡的数量。没有足够数量的服务器后端设计的再好都没用吧。其次，得根据预估的流量来设计秒杀方案，比如说百人秒杀同一物品与万人秒杀同一物品与百万人秒杀的方案也不可能一样。百人秒杀可能数据库就能扛得住。万人秒杀可能redis可以扛得住，而到百万人秒杀，可能就得用服务器缓存来解决问题了。其次，页面本身肯定是前后端分离设计，以减少服务器压力的。

Maozhenyu:
很有意思，虽然后端高并发我之前没有实际接触过，也没有深入学习过。但之前自己“凭空”设计/改造的一个高并发的东西却正好用到了其中的一些逻辑（锁、缓存架构），也许就是潜移默化来的吧。看这个视频前没听过布隆过滤器，但为了防止视频中类似的非法请求，我设计的是一种无io校验机制+失败结果缓存，可以挡掉大多数的非法请求。

苏三说技术:
传统美德不能丢，如果看了视频有些收获，请给我三连喔，谢谢你的鼓励[喜欢]

栎树下:
业务方面要求在一次抽奖活动中能够随时调整奖品库存和中奖概率，服不服。

sheiy:
redis放商品个数个有规则的key 请求秒杀按规则生成key 如果key存在就加锁再获取key 如果还存在就发mq秒杀成功并删除key

【回复】补一句页面还是要按规则过滤掉部分请求
苏三说技术:
我微信公众号文章地址：https://mp.weixin.qq.com/s/l05_28xe6O4vZUQEmnu2Ug

大臭努:
LUA表达式那段，扣减是不是应该decrBy？我记得incrBy是加一来着

【回复】回复 @YKXHAPPY :哦哦[打call]
凑合凑合12138:
要是客户把手机时间调前了那？时间怎么同步？服务器要不要检查每个请求的时间戳？还是时间到了在开放端口？

【回复】前端做交互，后端做安全。
行者无疆7056:
Synchronize还有个问题吧，在集群环境不起作用，是吧

苏三说技术:
苏三目前有专业团队，可以接毕业设计开发，或者其他的系统开发需求，有需要的可以加我微信：li_su123，备注：毕设或系统开发。

wwyx薇薇一笑:
如何保证redis扣减库存成功了但是写入db失败了的一致性呢？视频里面没提哦，万一db写入失败了，消息都没法发出去，那不是少卖了吗？

【回复】秒杀本来就是赔本赚吆喝, 少卖不是啥不能接受的事
【回复】redis提前预热的，库存早扣了
JumpServer:
问下，如果秒杀的商品多的话，这时候难道为每个商品都生成一个静态页面吗？