百行代码实现电商秒杀系统高并发实战

兄弟们，说到电商秒杀，很多人第一反应就是高并发、分布式、消息队列这些大词儿，感觉没个几百台服务器都不敢碰。其实啊，咱们个人开发者或者小团队，想做个秒杀活动练练手，真不用那么复杂。我最近就自己折腾了一个，核心业务逻辑用百行代码就搞定了，上线跑了几天，虽然流量不大，但该踩的坑一个没落下。今天就把我的实战经验，包括怎么用百行代码去设计接口、控制库存、防止超卖，全部分享出来，咱们一起聊聊。

先别急着写代码，库存超卖才是最大的敌人

我一开始也是头铁，想着不就是个下单嘛，数据库update一下库存减一，完事。结果一测试，好家伙，100个库存卖出去300多单。问题就出在并发环境下，多个请求同时读到库存是1，然后都去减，最后变成-2。这就是典型的超卖。要解决这个，百行代码里最关键的一行就是对库存操作加上条件判断。比如SQL写成 UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock > 0，这样只有库存大于0的时候才能更新成功，影响行数为0就说明抢完了。这行代码可以说是整个秒杀系统的基石，简单粗暴但有效。

当然，光靠这个还不够。如果你的接口不做任何限流，瞬间几万个请求打到数据库上，就算不超卖，数据库也得给你干宕机。所以我用了一个非常简单的计数器来做限流，就是 AtomicInteger，每当有请求进来就自增，超过阈值直接返回“已售罄”或者“排队中”。这招虽然简陋，但对于百行代码级别的系统来说，足够扛住大部分压力了。别小看这个计数器，它能把大部分无效请求挡在门外，保护后面的数据库。

Redis预减库存，让百行代码的响应速度飞起

如果只是单机玩，上面的办法够用了。但为了模拟真实场景，我把库存也放到了Redis里。因为Redis是单线程的，操作是原子性的，用它的 decr 命令来预减库存，效率比直接操作数据库高了好几个数量级。流程是这样的：秒杀开始前，先把库存数量加载到Redis里。用户点秒杀按钮，后端先执行 decr，如果返回值大于等于0，说明还有库存，就放行去创建订单；如果返回负数，说明库存没了，直接返回失败，并且把Redis里的数值加回去（当然，实际为了性能，通常就不加了，直接丢弃）。

这一步操作，让我这百行代码的秒杀接口，QPS直接翻了好几倍。因为大部分请求在Redis层面就被拦截了，根本不会去碰数据库。而且，配合上刚才说的数据库乐观锁，双重保险，既保证了速度，又保证了最终数据的一致性。我用Jmeter简单压测了一下，模拟500个并发，接口的响应时间平均在20毫秒左右，这个成绩对于一个小项目来说，我觉得挺惊喜的，重要的是思路清晰了。

消息队列削峰填谷，异步下单保护系统

还有个问题，就是瞬间的写压力。就算Redis拦住了大部分请求，但总归有几百个幸运儿抢到了资格，他们要同时去数据库建订单。这时候如果直接同步写库，数据库依然可能扛不住。我的做法是在百行代码里引入了一个非常轻量级的消息队列，其实就是JDK自带的 LinkedBlockingQueue。抢到库存的请求，不直接写订单，而是把用户ID和商品ID封装成一个消息，丢到队列里，然后立刻返回“正在排队中”。

后台用一个单线程的消费者，慢慢从队列里取消息，一条一条地创建订单。这样就实现了异步下单，把瞬间的并发写操作，转换成了平缓的串行操作。虽然用户体验上稍微慢了一点点（其实也就是几百毫秒），但系统的稳定性得到了极大的提升。这个思路，跟大厂用的RabbitMQ、Kafka原理是一样的，只是我们简化了实现。对于学习来说，能让你更清楚消息队列到底解决了什么问题。

页面静态化与按钮置灰，前端也要配合好

别光顾着后端，前端如果不做处理，后端再牛也白搭。我做的第一件事就是把秒杀页面能静态化的内容全部静态化，静态页面放到Nginx上，动态数据比如库存剩余数量，通过一个单独的接口去获取。这样，大部分流量都在Nginx层面就被处理了，根本到不了后端服务。另一个小技巧就是秒杀按钮。活动没开始的时候，按钮是置灰的，到了时间点才点亮。用户点击一次之后，按钮立刻变成“已抢购”并且禁用，防止用户手抖重复提交。这些细节虽然不增加并发量，但能有效减少无效请求，变相提升了系统的处理能力。

说实话，真正把这一套流程走下来，你会发现，所谓的高并发秒杀系统，核心并不是用了多牛的技术，而是对现有资源的合理利用和对请求链路的巧妙设计。我写的这套东西，满打满算核心代码真的就是一百行左右，但包含了乐观锁、分布式缓存（单机Redis模拟）、消息队列（单机队列模拟）、限流这几个关键点。对于想学习高并发知识的朋友来说，这是一个很好的起点，能让你直观地看到每个组件在系统里扮演什么角色。

总结一下踩过的坑和优化心得

最后说几个我实际开发中遇到的坑吧。第一个，就是Redis和数据库的库存一致性。我是通过先更新数据库，再更新Redis的方式，虽然极端情况下可能有不一致，但配合上定时任务去校对，问题不大。第二个，就是防重提交。除了前端按钮置灰，后端我也用了简单的Token机制，每个用户进入秒杀页时生成一个唯一的token，下单时必须携带这个token，后端用完后立即删除。这样即使前端被绕过，后端也能保证用户只能抢购一次。第三个，别忘记日志。每一个请求的耗时、成功失败状态，都要记录下来，方便出了问题去排查。

总之，这百行代码的秒杀系统虽然简单，但五脏俱全。它让我对高并发场景下的核心问题有了非常深刻的理解。如果你也想试试，强烈建议不要直接去复制别人的代码，而是先看我说的这几个点，自己动手去写一遍。相信我，当你亲手用一百行代码扛住几百个并发的时候，那种成就感，比你看十篇教程都强。这其中的经验，对于你以后去理解更复杂的分布式系统，也会有很大的帮助。