今天突然想起来还要写秒杀那章，但半小时前刚跟产品经理聊完优化方案，感觉脑子里全是数据模型和数据库查询，手一抖全写成了讲 Redis 原理。

这玩意儿要是真按教科书来写，估摸咱们工程师早就被劝退，建议直接上代码实战。 那会儿总认定秒杀就是数据库压力大，那是看错了。当年某电商大促，线上订单量直接飙到峰值，结局数据库里堆积了一堆慢查询，最终咱们团队紧急切流，把数据库作为中间件扛过了这波冲击。

那时候大家都忙得脚不沾地，哪位关心底层逻辑？目前回头看，光靠切流治标不治本，根儿早就烂在数据库里了。 实际上秒杀的核心不在于流量有多大，而在于系统有没有“分身术”。当用户蜂拥而至，服务器像挤地铁一样，一旦闸机卡住，排队的人就得在那儿干瞪眼，数据还得一个个慢慢挪，这时候用户体验直接崩盘。

这时候你得想明白，流量是死的，但用户的感知是活的。

要是用户等一分钟，他认定慢，那这漏斗就有一半漏了。 先把最接近核心的那层逻辑搞定。假设你要在 10 秒内处理 100 万下单请求，每个请求得在毫秒级搞定。

这时候你就得先搞清楚，数据到底是哪位在扛。是内存？是磁盘？还是数据库？别光想着加 CPU，CPU 再强也扛不住内存泄漏。

比如上次有个项目，为了提升并发，直接把缓存放在低配机器上，结局运行了一周，整个挂了，根本没人知道是啥缘由，要不就通过监控报警，但报警也有滞后。

故此你得懂系统架构，知道不同组件的瓶颈在哪，然后针对性地优化。 说到性能优化，Redis 这块是绕不开的。

要是全用数据库算库存，那简直就是自杀式冲锋。库存是个数字，它不形成价值，但计算它的工夫能形成价值。Redis 的内存寻址就像字典，只要键值对存有，就能 O(1) 秒回查。平时我们可能只是好办存个 ID 和价格，但秒杀场景下，可能涉及用户 ID、商品 SKU、库存数量，就连优惠券快照，数据结构要是设计不好，瞬间就变成 O(n) 的暴力破解。

这时候就得用 MapStruct 要么自定义的序列化策略，把复杂的对象拆成原子的一维 ID，这样既快又稳。 但数据多了，光靠内存也不中，内存一旦满，数据就得落盘。

这时候就得寻思持久化策略。Redis 的 RDB 快照是经典的“快照式”，就像翻到某一页，前面没变，后面可能新加，但删了之前的。而 AOF 是日志式，每一秒都记录下来，故障恢复快，但文件大了再读也慢。

实际上两者取个平衡点，比如平时存 RDB，突发流量时切换 AOF，要么根据负载动态调整，这样既保证了速度，又不至于磁盘爆满。 还有增量更新的思路，大量人死磕唯一索引还是走错路了。

只有唯一索引，每次更新都要回表，这简直是在浪费计算资源。更好的做法是用位图，要么基于工夫戳的乐观锁。

比如每次更新都加个版本号，要是版本号变了就重新校验库存，不用的就跳过。

这种思路在微服务架构里特别常见，多个服务互相调用，哪位发现版本号不对，就触发重试机制，而不是一上来就刷新整个表。 实际上代码优化和架构设计有时候比底层原理更关键。

比如在高并发下，线程池为啥选固定大小而不是动态扩容？出于线程是资源的稀缺品，频繁创建销毁线程本身就有开销。定大小就是为了让线程消亡和创建之间有一个缓冲期，避免雪崩。

还有锁机制，最好办踩坑的是死锁。死锁的本质是饿得慌，一个线程等另一个线程，另一个线程又等第一个，最终形成死循环。

这时候应当用乐观锁而不是悲观锁，要么寻思分布式锁，把锁粒度放得细一点，避免跨服务锁竞争。 自然，所有这些底层优化，最终都要服务到用户体验。

比如在秒杀时，用户下单时，前端最好给出一个明显的“等待”反馈，告诉用户“您的订单已提交，正在处理中”，而不是一点动静都没有，那样界面忒死板了。后期发现订单状态是异步更新的，那就得加个延迟队列，把下单动作推进去，后台慢慢去处理。 最终总结一下，秒杀这事儿，本质上是系统如何优雅地承受瞬间的过载。

不是堆加堆加，哪块性能高往哪推，哪块有瓶颈就砍哪。数据如何存、如何读、如何补，这些东西都得在代码层面做出来。别光盯着数据库看，得盯着整个系统的链路去思索。

毕竟，真正的性能优化，是让系统在后台默默扛住流量，前台给用户一个丝滑的体验，而不是让用户在等待中的焦虑感和挫败感。