Ch10 · Java Interview Lab
把高并发、MQ、JVM、缓存一致性、线上排查这些难讲的场景题，拆成「面试官问题 → 工程链路 → 动画推演 → 30 秒表达」。
Live Preview
面试官问题
订单 30 分钟未支付，怎么自动关单且不误关？
业务约束
支付回调和关单消息可能同时到达。
系统链路
订单状态机 + 延迟队列 + 支付服务 + 订单库。
风险点
重复消息、ACK 丢失、CAS 失败、补偿漏扫。
30 秒答案
先建模状态机，再讲延迟触发、CAS 幂等和补偿扫描。
Core Labs
先练这 4 题：每题都从面试官问法进入，拆到工程链路、动画推演、错误回答和 30 秒表达。
下单 30 分钟不付款自动关单，支付回调撞车也不能误关。
用户下单后 30 分钟未支付要自动关闭订单并释放库存，你会怎么设计？如果关单消息和支付回调同时到达，怎么保证已支付订单不会被关？
考延迟任务选型、订单状态机、幂等消费、支付与关单并发竞态，以及漏消息后的补偿能力。
看业务时钟到点后，延迟队列如何触发消费者；消费者先读支付状态，再通过 CAS 推动订单状态机；补偿扫描器只处理异常漏网订单。
我开一个定时任务每分钟扫全表，找到超时订单就直接改成 CLOSED。支付了的话理论上不会扫到。
10 万请求抢 100 件库存，先削峰，再防超卖，最后异步落库。
如果让你设计一个秒杀系统，10 万 QPS 同时涌入但库存只有 100 件，你怎么保证不超卖、数据库不被打挂、失败还能回滚？
考分层削峰、热点库存原子扣减、异步下单、最终一致、失败回滚与补偿对账。
看请求粒子流如何被资格网关、风控和 Redis 库存池逐层削减；只有预扣成功的少量请求进入 MQ，消费者再平稳写 DB。
请求进来直接查数据库库存，库存大于 0 就扣减并创建订单。并发高就把数据库机器加多一点。
MQ 至少一次投递不可避免，业务要靠幂等表做到效果只发生一次。
MQ 怎么保证消息只被消费一次？如果 Consumer 业务处理成功了，但 ACK 丢了，Broker 又重投，怎么保证不会重复扣款或重复发货？
考 MQ 投递语义、ACK 丢失导致重复投递、消费端幂等、去重表设计，以及业务副作用的边界。
看 ACK 信号在网络中丢失后 Broker 如何重投；Consumer 第二次收到消息先查幂等表，发现已处理后跳过业务副作用。
只要消费成功后 ACK 就行，MQ 会保证消息只投一次；或者用 synchronized 防止同一时刻重复消费。
先判断是生产突增还是消费变慢，再定位慢点并限速回放。
线上 MQ 突然堆积了几百万条消息，Lag 持续上涨，你怎么判断原因、怎么快速恢复，又怎么避免把下游打崩？
考生产/消费速率判断、Consumer 慢点定位、下游依赖排查、扩容边界、限速回放与告警指标。
看 Producer 管道变粗、Consumer 工人处理不过来时 Backlog 水位和 Lag 曲线如何上涨；点击扩容或优化慢 SQL 后指标如何恢复。
直接多加几台 Consumer，把消息赶紧消费完；如果还不行就清掉队列重新来。
Learning Routes
不同路线解决不同面试场景：会讲项目、扛高并发、讲 MQ、做排查、处理一致性和发布迁移。
简历项目表达、分层架构、技术选型、项目亮点
能把项目从业务目标讲到架构分层、技术取舍、线上指标和个人贡献。
秒杀、库存超卖、热点数据、10 万 QPS
能解释洪峰怎么挡、库存怎么扣、热点怎么隔离，以及数据库为什么不会被打挂。
幂等消费、顺序消费、消息堆积、死信补偿
能讲清 MQ 为什么会重投、如何幂等、如何保证局部有序，以及堆积怎么恢复。
CPU 飙高、OOM、Full GC、死锁、慢接口
能从告警出发，用指标和工具把问题定位到线程、SQL、对象或下游依赖。
缓存一致性、平滑迁移、灰度发布、多活容灾
能把一致性问题拆成写路径、读路径、补偿路径和发布回滚路径。
Answer Practice
一眼看懂一个场景题从问题、约束、状态机到面试表达的完整链路。
合法跃迁：WAIT_PAY → CLOSED / PAID。已支付不可关单。
下单成功，订单置 WAIT_PAY，预扣 1 件库存，同时向 MQ 投递一条 30 分钟延迟消息。
支付回调和关单消息同时到怎么办？
两边都不能盲改状态。支付只允许 WAIT_PAY -> PAID，关单只允许 WAIT_PAY -> CLOSED，用版本号或 where status='WAIT_PAY' 的 CAS 保证只有一方成功。
消息重复消费怎么办？
重复消费只会再次尝试 WAIT_PAY -> CLOSED。订单已 CLOSED 或 PAID 时直接 ack，库存释放也用流水或状态判断做幂等。
MQ 消息丢了怎么办？
MQ 是快路径，补偿扫描是安全网。扫 expireAt 已过且 WAIT_PAY 的订单，按同样的状态机逻辑补关单。