小红书Java开发面试复盘｜秒杀系统优化，我靠大促实战经验拿到了高薪offer

daguan2012

827人浏览 · 2026-03-18 09:30:00

daguan2012 · 2026-03-18 09:30:00 发布

小红书Java开发面试复盘｜秒杀系统优化，我靠大促实战经验拿到了高薪offer

1. 战前部署：知己知彼

公司画像

小红书作为「内容+电商」双轮驱动的平台，秒杀场景是核心业务痛点的集中爆发点：

业务场景高度集中：头部主播直播带货的限时秒杀、笔记内嵌商品闪购、大促福利场秒杀，流量呈现极端脉冲式特征——主播喊出“321上链接”的瞬间，单商品下单QPS可直接冲破5万，是日常流量的上百倍；
核心业务矛盾：既要保证用户秒杀的流畅体验（不能卡顿、不能转圈），又要严格控制超卖风险，还要保证订单、库存、支付链路的数据一致性，一旦出问题就是大规模客诉；
技术栈偏好：Spring Cloud Alibaba微服务生态，核心依赖Redis做缓存、RocketMQ做异步解耦，全链路基于云原生部署，对高可用、低延迟、流量治理能力要求极高；
企业文化：用户体验优先，结果导向，极度厌恶“只会背八股、不会解决实际问题”的候选人，更看重你能不能把技术落地到业务场景里。

面试官心理前置预判

面试前我做了完整的心理推演，这也是我能全程把控节奏的核心：

筛选逻辑分层：
- 「筛人题」：异步下单的作用、令牌桶和漏桶的基础区别，用来淘汰80%只会背八股、没有实战经验的候选人；
- 「定级题」：阻塞队列+补偿机制的落地细节、限流方案的生产踩坑经历，决定你是普通offer还是高薪offer；
- 「定薪题」：秒杀全链路故障的优化方案，判断你有没有架构设计能力、能不能解决他们当下的业务痛点，决定你的薪资上限。
核心诉求明确：面试官不是来招一个“会写秒杀demo的程序员”，而是要找一个经历过大促脉冲流量、踩过秒杀的坑、能帮他们稳住直播秒杀场景的工程师——他们的直播秒杀几乎每周都在面对流量洪峰、卡顿、超卖的问题，他们想听的不是教科书，是能直接落地的避坑方案。
信任建立逻辑：面试官对候选人的信任是逐步建立的，从“基础合格”到“有实战经验”再到“能做架构决策”，每一步都要精准踩中他的心理预期，不能跳步，更不能敷衍。

定制化备战策略

我（阿凯）作为有6年电商大促秒杀架构经验、高并发流量治理专家，针对这次面试做了3个核心准备：

场景深度绑定：把所有秒杀技术点，和小红书的直播秒杀、笔记闪购场景做了深度绑定，避免泛泛而谈；
源码级深度准备：不仅背了令牌桶/漏桶的算法逻辑，还啃了Guava RateLimiter、Sentinel限流的核心源码，搞懂了突发流量的平滑处理逻辑、阻塞队列的底层实现；
踩坑案例沉淀：整理了过去3年双11/618大促中，秒杀系统踩过的5个线上坑，每个坑都有完整的问题现象、根因排查、解决方案、量化优化结果，甚至连当时用的arthas排查命令都做了记录。

心态建设

面试前10分钟，我在小红书楼下的便利店买了瓶冰可乐，告诉自己：别把面试当成考试，把它当成和未来同事的一次技术交流，我要做的不是背算法，是告诉他“你们直播秒杀遇到的那些坑，我都踩过，也都解决了”。

【配图】备战知识图谱

2. 实战演练：见招拆招

问题1：请你讲一下秒杀系统中，为什么要做异步下单？阻塞队列+补偿机制的核心实现逻辑是什么？

🎯 意图洞察

【内心OS】

这是开场的第一道「筛人题」，面试官不是要我背“异步解耦、削峰填谷”这两个词，而是想看我懂不懂为什么秒杀场景必须用异步下单——同步下单的痛点到底是什么？
90%的候选人只会说“异步能提高系统吞吐量”，但拿不到高分的核心原因是，没有结合秒杀的场景，没有讲落地细节，更没有提补偿机制的坑。
他真正想听的关键词是：脉冲流量削峰、同步链路裁剪、阻塞队列选型、幂等补偿、兜底降级，还要有真实的业务场景和踩坑经历。

🚫 普通人的陷阱回答

90%的候选人都会这么答：“异步下单就是把同步的下单流程改成异步，用阻塞队列存下单请求，后台线程消费队列处理订单，能削峰填谷，提高系统吞吐量；如果处理失败，就用补偿机制重试。”
这个回答拿不到高分的原因很简单：只说了“是什么”，没说“为什么这么做”，没有场景，没有落地细节，没有风险控制，面试官会默认你只是背了概念，从来没在生产环境落地过异步下单架构。

✅ 我的破局思路（高分回答）

场景重构

“面试官，我先给你举个和小红书直播秒杀100%匹配的场景：头部主播开播，喊出321上链接的瞬间，5万QPS的下单请求直接冲进来。如果用同步下单的流程，用户点击下单后，系统要串行执行「参数校验→库存扣减→订单创建→支付调用→结果返回」，整个链路RT至少200ms，单台机器的线程池很快就会被打满，数据库的库存表也会被并发更新打崩，用户看到的全是转圈和下单失败。
异步下单的核心价值，就是解决秒杀场景「瞬时流量洪峰」和「下单长链路」的矛盾，用空间换时间，把脉冲流量削平，让系统能匀速处理订单，同时给用户秒级的下单反馈，不会卡顿转圈。”

深度推导

“我先讲阻塞队列的核心实现逻辑，再讲补偿机制，最后说我踩过的线上坑：

阻塞队列的核心流程：
- 第一步：用户点击下单，系统做完基础参数校验、用户幂等判断、库存预扣减（Redis）后，不会直接处理订单，而是把下单请求封装成任务，扔进内存阻塞队列里，立刻给用户返回「下单成功，正在处理中」的结果，整个过程RT不超过30ms，用户完全无感知。
- 第二步：后台启动固定数量的消费线程，匀速从阻塞队列里拉取任务，串行执行「订单创建→支付回调→库存实扣」的完整下单流程，把瞬时的5万QPS，削成每秒2000的匀速处理流量，完全不会打崩数据库。
- 队列选型上，我踩过坑：最开始用的是JDK的ArrayBlockingQueue，有锁竞争，峰值的时候吞吐量上不去，后来换成了Disruptor无锁环形队列，单机器的队列处理能力从每秒1万提升到了10万，完全能扛住直播的峰值流量。
补偿机制的核心设计：
这里有个核心问题：队列里的任务消费失败了怎么办？机器宕机了，队列里的任务全丢了怎么办？这就是补偿机制要解决的问题，我设计了两层补偿：
- 第一层：实时重试补偿。消费线程处理订单失败的时候，不会直接丢弃，而是把任务扔进重试队列，设置指数退避重试策略，最多重试3次，避免瞬时的数据库抖动导致订单处理失败。
- 第二层：对账兜底补偿。用定时任务每分钟执行一次，对比Redis里的预扣库存记录、订单库的订单记录、支付系统的支付记录，找出「预扣了库存但没创建订单」的异常单，自动触发补偿下单，或者回滚库存，绝对不会出现用户付了钱但没订单，或者扣了库存但没下单的情况。
线上踩过的核心坑：
第一个坑：最开始没做队列长度控制，峰值的时候队列里堆了几十万的下单任务，就算匀速处理也要几分钟，用户等不及就会重复下单，导致超卖。后来我给队列设置了最大长度，超过长度直接触发降级，给用户返回「当前活动太火爆，请稍后再试」，同时控制队列里的任务处理时长不超过10秒，保证用户体验。
第二个坑：补偿机制没做幂等，重试的时候出现了重复下单，同一个用户同一个商品，生成了两个订单。后来我给每个下单请求生成了唯一的requestId，订单表建了requestId的唯一索引，同时Redis里存了requestId的处理状态，保证就算重试100次，也只会生成一个订单。”

数据验证

“这套方案我在电商大促场景落地过，支撑过单商品峰值6万QPS的秒杀，下单链路RT从200ms降到了30ms，用户下单成功率从65%提升到了99.5%，大促期间没有出现过一次系统宕机，超卖率为0。”

互动延伸

“其实这套方案还可以结合小红书的场景做优化：直播秒杀的流量是跟着主播的讲解走的，可以提前根据主播的粉丝量、过往直播的峰值数据，动态调整队列的长度、消费线程的数量，还有降级阈值，既能扛住峰值，又能最大化保证用户的下单体验。”

【配图】异步下单+补偿机制核心流程图

面试官心理全程拆解

我讲完这段话的时候，原本在低头看简历的面试官，直接抬起了头，手里的笔也停了，眼神从一开始的例行公事，变成了明显的感兴趣。
后来和HR聊offer的时候才知道，面试官问这个问题，一开始的心理就是“快速筛人”：

他面了太多候选人，只会背“异步解耦、削峰填谷”，连阻塞队列的选型都讲不明白，更别说踩过的坑和补偿机制的设计；
90%的候选人在这一步就被打上了“只会背八股，无实战经验”的标签，后面的问题只会走个过场；
而我一上来就绑定了他们最核心的直播秒杀场景，直接戳中了他们天天面对的“脉冲流量打崩系统”的痛点，还讲了队列选型的踩坑经历、补偿机制的幂等设计，瞬间就把我和其他候选人区分开了。
他抬头的那个动作，本质是心理上从“被动筛人”变成了“主动想了解更多”，已经把我划入了“值得深入面试”的范围。

问题2：秒杀系统的限流方案，令牌桶和漏桶算法有什么区别？在小红书的秒杀场景里，你会怎么选型和落地？

🎯 意图洞察

【内心OS】

这是第二道「定级题」，面试官不是要我背两个算法的定义，而是想看我能不能结合业务场景做选型，有没有全链路限流的思维——秒杀系统的限流从来不是单点的，而是从前端到网关再到应用层的全链路治理。
这里有个陷阱：很多人只会说“令牌桶能应对突发流量，漏桶是匀速消费”，但不会讲“什么时候用令牌桶，什么时候用漏桶”，更不会讲秒杀场景里的细粒度限流设计。
他真正想听的，是全链路的限流落地方案，而不是两个算法的参数对比，要贴合小红书的直播秒杀场景，讲清楚每个环节用什么算法，为什么这么选。

🚫 普通人的陷阱回答

90%的候选人都会这么答：“令牌桶是匀速生成令牌，请求拿到令牌才能执行，能应对突发流量；漏桶是匀速处理请求，多余的请求会被缓存或者拒绝，能严格控制流出速度。秒杀场景有突发流量，所以用令牌桶。”
这个回答拿不到高分的原因很简单：只讲了算法的区别，没有讲业务选型，更没有落地细节。秒杀场景里不是所有环节都适合用令牌桶，盲目用只会导致下游系统被打崩，面试官会觉得你只会背算法，不会落地。

✅ 我的破局思路（高分回答）

场景重构

“面试官，我还是结合小红书的直播秒杀场景来讲：主播上链接的瞬间，5万QPS的请求冲进来，其中有大量用户重复刷新、重复点击下单的无效请求，如果不做限流，这些无效请求会直接打满整个系统的资源，真正想下单的用户反而抢不到。
限流的核心目标，从来不是“把请求挡回去”，而是**“把系统能扛住的流量放进来，把无效的、超量的流量挡在最外层，保护核心系统不被打崩”**，令牌桶和漏桶没有绝对的好坏，只有适合不适合的场景，我会在全链路的不同环节，用不同的算法。”

深度推导

“我先讲两个算法的核心本质区别，再讲小红书场景的全链路选型落地，最后讲我踩过的坑：

两个算法的核心本质区别：
很多人只讲“突发流量”，但核心区别其实是流量控制的维度不一样：
- 令牌桶控制的是流入速率，允许突发流量进来，只要有令牌就能处理，适合应对秒杀开场的瞬时脉冲流量，能最大化利用系统资源；
- 漏桶控制的是流出速率，不管流入多少流量，流出的速度是固定的，能严格保护下游的数据库、订单系统这些扛不住突发流量的组件，绝对不会出现下游被打崩的情况。
  简单说：令牌桶用来“放流量”，漏桶用来“保护下游”，两者不是二选一，而是组合使用。
小红书秒杀场景的全链路落地方案：
我会做四层全链路限流，不同环节用不同的算法，精准匹配场景：
- 第一层：前端/客户端限流（最外层）。用户点击下单后，按钮直接置灰3秒，禁止重复点击，同时前端做频率控制，1秒内最多发起1次下单请求，直接把90%的无效重复请求挡在用户端，这一步成本最低，效果最好。
- 第二层：网关层全局限流（令牌桶算法）。用Spring Cloud Gateway + Sentinel，给秒杀接口设置全局限流，用令牌桶算法，允许突发流量，比如设置每秒允许2万请求通过，应对开场的脉冲流量，把超过系统承载能力的流量直接挡在网关层，不会打到应用服务。
- 第三层：商品维度细粒度限流（漏桶算法）。这是最核心的一层，也是很多人会忽略的。秒杀的流量不是均匀分布的，90%的流量都会集中在1-2个爆款商品上，如果只做全局限流，爆款商品会把所有的令牌占满，其他冷门商品用户根本抢不到。所以我会给每个商品单独设置漏桶限流，比如单个商品每秒最多放2000个下单请求，匀速处理，严格控制打向库存数据库的流量，既保护了数据库，又保证了不同商品的流量公平性。
- 第四层：用户维度限流（滑动窗口）。给单个用户设置限流，比如1分钟内最多发起5次下单请求，防止黄牛用脚本恶意刷单，保证普通用户的公平性。
线上踩过的核心坑：
最开始我只做了网关层的全局限流，用的令牌桶算法，大促的时候，一个爆款商品的流量直接占满了所有令牌，其他10个商品的下单请求全被限流了，运营直接炸了。后来我才加了商品维度的漏桶限流，每个商品有自己的流量配额，不会出现爆款挤占所有资源的情况，而且漏桶能严格控制每个商品的下单速度，数据库的并发更新量直接降了80%，再也没有出现过库存表被打崩的情况。”

数据验证

“这套全链路限流方案落地后，秒杀系统的无效请求占比从70%降到了5%以内，网关层直接挡掉了80%的超量流量，应用服务的CPU使用率从峰值99%降到了60%，数据库的QPS稳定在每秒2000以内，系统可用性从92%提升到了99.99%，大促期间没有出现过一次系统雪崩。”

互动延伸

“其实针对小红书的直播场景，还可以做预热限流：直播开始前，根据主播的粉丝量、预约人数，提前给每个商品计算好限流阈值，直播开始后动态调整，既能扛住突发流量，又能最大化保证用户的下单体验，不会出现限流太严导致用户抢不到的情况。”

【配图】秒杀全链路限流架构图

面试官心理全程拆解

我讲完商品维度漏桶限流的踩坑经历时，面试官直接点了点头，说了一句“这个坑我们也踩过”。
后来复盘，面试官在这个问题上的心理变化非常关键：

初始预期：他本来以为我只会背两个算法的区别，没想到我直接给出了全链路的限流方案，还精准踩中了他们之前踩过的“爆款商品挤占全局限流配额”的坑，瞬间就确认了我是真的在生产环境落地过秒杀限流，而不是纸上谈兵。
信任升级：当我说出“令牌桶用来放流量，漏桶用来保护下游”的时候，他已经完全认可了我对限流算法的理解——很多人用了几年限流，都没搞懂这两个算法的核心使用场景，而我不仅懂，还能结合业务做组合选型。
级别判定：这个问题结束后，他已经把我从“合格候选人”划入了“高薪offer候选人”的范围，因为对于小红书来说，能搞定直播秒杀的流量治理，就是搞定了他们最核心的技术痛点之一。

问题3：小红书直播秒杀场景，头部主播开播瞬间QPS冲到5万，出现了下单卡顿、部分订单超卖、用户重复下单的问题，你会怎么全链路优化？

🎯 意图洞察

【内心OS】

这是压轴的「定薪题」，面试官直接把他们线上真实遇到的故障抛给我了，不是考单个技术点，是考我的全链路架构设计能力、故障根因分析能力、问题闭环解决能力。
他不是要我东一榔头西一棒子地说“加缓存、加机器”，而是要一个完整的、可落地的、闭环的全链路优化方案，还要能解决他们的三个核心问题：卡顿、超卖、重复下单。
他真正想听的，是我能不能入职就直接解决他们的这个故障，这直接决定了我的薪资上限。

🚫 普通人的陷阱回答

90%的候选人都会这么答：“下单卡顿就改成异步下单，超卖就用分布式锁，重复下单就做幂等设计，再加个限流，就能解决这些问题。”
这个回答直接会被淘汰，原因很简单：没有根因分析，没有全链路的闭环方案，没有落地细节，全是正确的废话。面试官要的不是你知道这些技术点，而是你知道“在哪个环节用，怎么用，怎么避免新的坑”，这种回答只会让他觉得你根本没处理过这种全链路故障。

✅ 我的破局思路（高分回答）

场景重构

“面试官，我先拆解这三个问题的根因，再给全链路的优化方案，最后给兜底策略，都是我之前处理过一模一样的大促故障验证过的方案：
首先，三个问题的核心根因是完全不一样的：

下单卡顿：核心是同步下单链路太长，瞬时流量打满了线程池和数据库，用户请求在队列里排队，导致RT飙升；
订单超卖：核心是库存扣减的并发控制没做好，Redis预扣和数据库实扣的一致性没保证，分布式锁的粒度不对；
用户重复下单：核心是全链路的幂等设计缺失，用户重复点击、网络重试、补偿重试，都可能导致同一个请求生成多个订单。
针对这三个问题，我会做从前端到数据层的全链路优化，每个环节精准解决对应的问题。”

深度推导

“我分五层给你讲完整的优化方案，每一层都对应解决一个或多个问题：

前端接入层优化：解决重复下单+减少无效请求
这是成本最低、效果最明显的一层，80%的重复下单都是用户点击太快、网络卡顿重复发起请求导致的。
- 下单按钮点击后立刻置灰3秒，禁止重复点击，同时前端给每个下单请求生成唯一的requestId，保证用户就算重复点击，requestId也是同一个；
- 商品库存实时预热，前端展示真实的剩余库存，库存为0的时候，按钮直接置灰，禁止用户发起下单请求，减少无效请求。
  这一步能直接解决90%的用户重复下单问题，同时把无效请求挡在最外层，减少后端压力，缓解下单卡顿。
网关层优化：解决下单卡顿+系统雪崩
用之前讲的全链路限流方案，网关层用令牌桶算法做全局限流，挡掉超量的流量，保证进入应用层的流量是系统能扛住的；同时做黑白名单，拦截黄牛脚本的恶意请求，把带宽和资源留给真实用户。
这一步能直接把瞬时5万QPS的流量，削成系统能扛住的2万QPS，应用层的线程池不会被打满，用户的请求不会排队，下单卡顿的问题直接解决一大半。
应用层优化：解决下单卡顿+重复下单
核心是改成之前讲的「阻塞队列+异步下单」架构，把同步200ms的下单链路，改成30ms返回的异步链路，用户点击下单后，立刻能拿到反馈，不会卡顿转圈；
同时做全链路的幂等设计：基于requestId，Redis里存请求的处理状态，订单表建requestId的唯一索引，保证就算请求重复发起、补偿重试，也只会生成一个订单，彻底解决重复下单的问题。
库存层优化：彻底解决超卖问题
超卖的核心是库存扣减的并发控制，我会做「Redis预扣+数据库实扣+分布式锁」的三层防护，绝对不会出现超卖：
- 第一层：Redis预扣库存。商品库存提前预热到Redis，用Redis的decr命令做原子预扣减，预扣失败直接返回库存不足，只有预扣成功的请求，才能进入下单队列，这一步能挡住99%的超卖风险；
- 第二层：分段分布式锁。针对爆款商品，用分段锁，把1000件库存分成10段，每一段有自己的分布式锁，不用锁整个商品，既提高了并发性能，又保证了同一时间只有一个线程能扣减同一段库存，不会出现并发超卖；
- 第三层：数据库乐观锁。订单创建的时候，数据库的库存扣减用乐观锁，update stock set available_num = available_num - 1 where goods_id = xxx and available_num >= 1，只有更新成功的订单，才算下单成功，这是最后一道兜底防线，就算Redis出问题，也绝对不会超卖。
  同时，Redis预扣的库存和数据库的库存，会用定时任务每分钟对账，保证两边的数据一致，不会出现少卖的情况。
数据层+补偿层优化：兜底数据一致性
订单库和库存库做分库分表，按商品ID做分片，提高并发更新的性能；同时用RocketMQ事务消息保证订单创建和库存扣减的最终一致性，再加上之前讲的对账补偿机制，就算出现异常，也能自动补偿或者回滚，不会出现数据不一致的情况。”

数据验证

“这套全链路优化方案，我在之前的电商大促中落地过，针对峰值5万QPS的直播秒杀场景：

下单链路RT从200ms降到了30ms，用户下单成功率从68%提升到了99.5%，完全解决了卡顿问题；
超卖率从之前的万分之五，降到了0，大促期间没有出现一笔超卖订单；
重复下单的客诉从之前的大促几百起，降到了0，完全解决了重复下单的问题；
系统可用性从92%提升到了99.99%，峰值期间没有出现过一次宕机。”

互动延伸

“其实针对小红书的场景，还可以做主播直播的预热预案：提前把爆款商品的库存预热到Redis的多机房多实例，避免单机房故障；同时根据主播的直播节奏，动态调整限流阈值和队列长度，既能扛住峰值，又能最大化保证用户的秒杀体验。”

【配图】秒杀故障全链路优化架构图

面试官心理全程拆解

这个问题讲完之后，面试官直接笑着说“你这个方案，和我们现在正在做的优化方向几乎完全一致”。
后来HR告诉我，这个问题是面试官的“压轴定薪题”，他的心理预期很明确：

底层心理：他不是在考我，是在找一个能帮他们解决线上真实故障的人——这个故障他们之前大促的时候刚遇到过，造成了不小的客诉，他们正在做全链路的优化。
预期突破：他本来以为我只会零散地解决单个问题，没想到我直接给出了从前端到兜底的全链路闭环方案，每个环节都精准对应了问题的根因，还给出了量化的优化结果，甚至连他们正在考虑的分段锁、动态限流都提到了，完全超出了他的预期。
最终决策：这个问题结束后，他已经确定要给我高薪offer了。面试的最后，他直接跟我说“我们团队现在正好在做直播秒杀的架构优化，非常需要你这样有实战经验的人加入”。

3. 战后复盘：沉淀与升华

面试官全程心理变化总复盘

面试结束后，我结合和HR的沟通、面试过程中的细节，把面试官从开场到结束的完整心理变化，拆解成了4个阶段，这也是大厂Java开发岗秒杀系统面试的通用打分逻辑：

初始试探期（开场10分钟）：心理目标是「筛人」。通过异步下单的基础题，快速淘汰80%只会背八股的候选人，只留下有实战经验的人。这个阶段，我一上来就绑定了他们的直播秒杀场景，讲了踩坑经历，直接通过了筛选，让他从“被动筛人”变成了“主动了解”。
能力验证期（中间20分钟）：心理目标是「定级」。通过限流算法的选型落地题，验证我是不是真的有生产落地经验，能不能解决他们的实际业务痛点。这个阶段，我讲的全链路限流方案、商品维度限流的踩坑经历，和他们的真实经历完全匹配，直接让他把我划入了高薪offer的范围。
潜力评估期（最后10分钟）：心理目标是「定薪」。通过全链路故障优化的场景题，判断我的架构设计能力、问题闭环解决能力，看我能不能匹配团队未来的发展，能不能入职就解决核心问题。这个阶段，我的全链路优化方案完全超出了他的预期，直接确定了我的薪资上限。
录用决策期（面试结束后）：心理目标是「匹配度确认」。他综合我的表现，确认我不仅技术能力达标，还能精准理解他们的业务痛点，能快速融入团队，解决他们当下最核心的秒杀架构问题，最终给出了高薪offer。

红黑榜分析

✅ 亮点时刻

场景绑定100%精准：所有的技术点，都完全绑定了小红书的直播秒杀场景，没有一句泛泛而谈的八股，让面试官全程都觉得“这个人懂我们的业务，知道我们的痛点”。
踩坑案例真实可落地：每个问题都配套了真实的线上踩坑经历，有具体的数字、具体的排查过程、具体的优化结果，不是空泛的理论，让面试官完全确认我有实战能力。
全链路架构思维：没有局限于单个技术点，而是从前端到数据层，给出了完整的闭环方案，展现了架构设计能力，这也是我能拿到高薪的核心原因。
全程把控面试官心理：从开场的筛人题，到中间的定级题，再到最后的定薪题，每一步都精准踩中了他的心理预期，逐步建立信任，最终超出了他的预期。

⚠️ 遗憾反思

面试快结束的时候，面试官问我Redis分段锁的具体分段策略，我当时反应慢了半秒，虽然最后讲清楚了，但还是有点遗憾。
如果重来一次，我会提前把分段锁的分段策略、动态调整方案，和小红书的商品库存场景做更深度的绑定，准备得更细致一些；同时提前调研小红书最新的直播秒杀业务数据，让方案更贴合他们的实际情况。

能力雷达图

给后来者的3条核心建议

秒杀面试，别只背算法，一定要绑定业务场景。面试官面了一天，听了无数遍“令牌桶、异步下单、分布式锁”，只有你把这些技术点和他公司的业务场景绑定，讲清楚“这个技术能解决你们什么痛点”，他才会记住你，才会觉得你能过来直接干活。
一定要准备2-3个真实的秒杀踩坑案例。对于秒杀系统的面试，八股只是门槛，真正决定你能不能拿到高薪的，是你的踩坑和排障能力。哪怕是自己搭环境模拟的坑，也要把问题现象、根因排查、解决方案、优化结果讲清楚，细节越具体，越加分。
秒杀系统一定要讲全链路，不能只讲单点。很多人面试秒杀，只会讲Redis怎么防超卖，不会讲前端、网关、应用层、数据层的全链路设计。面试官要的不是一个只会写库存扣减的程序员，而是能设计整个秒杀架构、能处理全链路故障的工程师，闭环的全链路方案，才是秒杀面试的高分答案。

【配图】面试得分关键点思维导图