秒杀系统核心知识点
- 高并发，cache，锁机制
- 基于缓存架构redis,Memcached的先进先出队列。
- 稍微大一点的秒杀，肯定是分布式的集群的，并发来自于多个节点的JVM，synchronized所有在JVM上加锁是不行了
- 数据库压力
- 秒杀超卖问题
- 如何防止用户来刷， 黑名单？IP限制？
- 利用memcached的带原子性特性的操作做并发控制
秒杀系统看似简单，实则暗藏高并发、超卖、刷单等“爆雷点”。
想扛住流量洪峰，得用这三板斧：拦截无效请求、缓存扛压力、原子操作保公平。
第一招：把流量拦在门外
比如10件商品秒杀，用户一窝蜂涌入，系统会先“层层设卡”。每台服务器用计数器（比如初始值10）快速筛掉超量请求，只放行1000个进下一关。接着，用Memcached的原子操作（比如商品ID对应库存值10），让所有服务器同步扣减库存，最后只留10个“幸运儿”进入下单环节。多这一步，数据库压力骤减99%！
第二招：缓存当“盾牌”
数据库最怕高并发读写，所以秒杀数据全放Redis或Memcached里。这些缓存单机就能扛10万次/秒的请求，还能用原子操作避免超卖——比如扣库存时用decr(key,1)，确保只有前10个扣减成功的用户能下单。
第三招：分布式锁防作弊
黑产用脚本刷单？系统会限制同一IP或用户ID的请求频率，甚至抛验证码拦截机器操作。而库存扣减成功后，订单处理交给异步队列，用户只需等支付结果，系统压力进一步分散。
最后防线：数据库“轻装上阵”
冲到数据库的请求已是“精兵简政”。用一句SQLupdate库存表set count=count-1 where id=商品ID and count>0，既能防超卖，又能保证事务原子性。即便有突发流量，直接返回静态页面“秒杀结束”，用户体验不打折。
这套组合拳，让秒杀系统既扛得住流量，又守得住公平，黑产看了都摇头！
总结：
1、前端三板斧【扩容】【限流】【静态化】
2、后端两条路【内存】+【排队】