一、秒杀系统概述

大家好，我是你们的老朋友。今天咱们聊聊秒杀系统——这个让无数程序员又爱又恨的东西。

说实话，我第一次接触秒杀系统是在2015年。那时候公司要做双十一活动，老板说「搞个秒杀吧，简单」。结果呢？上线当天系统直接挂了，用户骂声一片。嗯，从那以后我就明白了一个道理：秒杀系统，看着简单，做起来全是坑。

什么是秒杀系统

秒杀系统，说白了就是「短时间内大量用户抢购有限商品」的系统。比如限量100台的手机，10万人同时抢。谁先抢到算谁的。

你可能会问：「这不就是个下单系统吗？」
对，但也不对。普通下单系统，10万人同时下单，数据库直接炸了。秒杀系统要做的，就是在这10万人里，精准选出那100个幸运儿，同时保证系统不崩溃。

秒杀系统的业务特点

我总结了一下，秒杀系统有这几个明显的特征：

• 瞬时流量极高——平时每秒几百请求，秒杀时每秒几万甚至几十万。我在项目中见过最夸张的，峰值QPS直接飙到50万。
• 商品数量极少——库存可能只有几十件、几百件。99.9%的用户注定抢不到。
• 时间窗口极短——通常就几秒钟。过了这个点，流量瞬间回落。
• 读写比例失衡——读多写少。大家都在查库存、查价格，但真正下单的只有极少数。
• 业务逻辑简单——就是「扣库存+生成订单」。但简单不代表容易实现。

你想想看，这些特点加在一起，意味着什么？意味着你的系统要能扛住平时1000倍的流量，但实际处理的业务量只有平时的1%。这本身就是个矛盾。

秒杀系统的技术挑战

说到技术挑战，我踩过的坑可以写本书了。这里挑几个最核心的说说：

1. 高并发下的库存超卖

这是最经典的坑。两个用户同时抢最后一件商品，数据库层面如果没处理好，两个人都能下单成功。库存变成-1，这就尴尬了。

2. 流量冲击与系统雪崩

秒杀开始那一瞬间，流量像洪水一样涌进来。如果系统扛不住，就会像多米诺骨牌一样——数据库先挂，然后应用服务器跟着挂，最后整个集群都挂了。

为什么会这样？因为请求会排队，队列满了就超时，超时了客户端就重试，重试又带来更多请求……嗯，这就是典型的「雪崩效应」。

3. 数据一致性问题

用户付了钱，但库存没扣减？或者库存扣了，但用户没付钱？这两种情况都会引发客诉。我见过最严重的，一次秒杀活动因为数据不一致，导致公司赔了200多万。

4. 恶意请求与刷单

这个我深有体会。有些「聪明人」会写脚本，用机器人的速度去抢。普通用户手速再快，也快不过程序。所以防刷机制是必须的。

技术挑战	影响	常见解决方案
库存超卖	资损、客诉	Redis+Lua、分布式锁
流量冲击	系统崩溃	限流、降级、队列削峰
数据不一致	财务对不上	最终一致性、对账系统
恶意刷单	公平性受损	风控、验证码、限频

秒杀系统的核心指标

做技术的人，不能光凭感觉说话。你得有数据。我个人习惯用这几个指标来衡量秒杀系统的好坏：

• QPS（每秒查询数）——系统能扛住多少并发请求。一般秒杀系统要求至少10万+ QPS。
• 成功率——真正下单成功的用户比例。这个指标能反映出系统的「有效吞吐」。
• 响应时间——用户从点击到看到结果需要多久。超过3秒，用户基本就流失了。
• 库存准确率——活动结束后，库存和订单对得上吗？理想情况是100%。
• 系统可用性——秒杀期间系统不能挂。99.99%是基本要求。

好了，这一章的内容就到这里。秒杀系统的基本概念、业务特点、技术挑战和核心指标，咱们都过了一遍。下一章我会带你看看秒杀系统的整体架构设计——说白了，就是怎么把这些挑战一个一个解决掉。

记住一句话：秒杀系统不是拼谁的技术更炫，而是拼谁的系统更稳。稳，才是王道。