主题 16场景题与项目追问

16.1场景题在考什么

「设计一个秒杀系统」这种题，面试官心里有三条线，答满第一条只是及格：

16.2防超卖：三种写法，同一份并发

库存 10，100 个人同时抢。三种写法各跑一遍：

=== 100 个并发，库存 10 ===
A 先查再改           下单成功 100 单，订单表 100 条，剩余库存    4，耗时  1317 ms
B 条件更新           下单成功  10 单，订单表  10 条，剩余库存    0，耗时  2047 ms
C 乐观锁 version    下单成功  10 单，订单表  10 条，剩余库存    0，耗时  7130 ms

再跑一次（并发结果会随调度变化，但结论不变）：

A 先查再改           下单成功  97 单，订单表  97 条，剩余库存    0，耗时  1513 ms
B 条件更新           下单成功  10 单，订单表  10 条，剩余库存    0，耗时  7133 ms
C 乐观锁 version    下单成功  10 单，订单表  10 条，剩余库存    0，耗时  4722 ms

A 的错法为什么这么典型

select num from stock where id=1;   -- 读到 10
if (num > 0) {                      -- 10 > 0，成立
    // ... 业务处理 2ms ...
    update stock set num = 9 where id=1;
}

100 个线程都读到了 10，都判断成立，都下单，最后都写回 9。 结果：订单 100 条，库存只从 10 变成 4——卖了 100 件，账上只扣了 6 件。

B 为什么一条 SQL 就够

update stock set num = num - 1 where id = 1 and num > 0;

两个关键点：

• num = num - 1 而不是 num = 9——在数据库里算，不在应用里算， 不存在「用旧值覆盖新值」；
• and num > 0——把判断和更新合成一个原子操作。 InnoDB 执行时会加行锁（12 章实测过 X,REC_NOT_GAP）， 并发的 update 排队执行，每个都能读到前一个的结果。

返回的影响行数 n == 1 就代表抢到，n == 0 就代表没库存。不需要再查一次。

C 为什么反而慢

乐观锁的写法是「读版本号 → 带版本号更新 → 影响行数为 0 就重试」：

select num, version from stock where id=1;      -- num=10, version=0
update stock set num=num-1, version=version+1
 where id=1 and version=0;                       -- 只有一个线程能成功

它不会超卖（结果和 B 一样是 10 单），但耗时 4722~7130ms，比 B 慢一倍以上。 因为 100 个线程里 90 个都要重试最多 50 次，每次重试都是一次完整往返。 冲突越激烈，乐观锁越吃亏——这正是它叫「乐观」的代价：它假设冲突很少。

16.3分布式 ID：雪花算法的 340 万 QPS 和两个坑

单机自增主键在分库分表之后就不唯一了，所以需要分布式 ID。雪花算法是最常见的答案， 它的结构是 64 位 = 1 位符号 + 41 位时间 + 10 位机器 + 12 位序列：

实测生成 100 万个：

生成 1000000 个 ID，用时 294 ms，去重后 1000000 个，QPS 340 万
拆解一个 ID：时间戳 1793863431321，数据中心 1，机器 1，序列 0
原值 393691765443530752（18 位十进制，long 能装下）

340 万 QPS，去重后还是 100 万——但这已经接近理论上限了： 4096 × 1000 = 409.6 万/秒。超过这个数，序列号就会在同一毫秒内绕回 0， 代码里必须 while (ts <= lastTs) ts = now() 等到下一毫秒，否则就撞 ID。

坑一：时钟回拨

服务器对时（NTP）时，时钟可能往回跳几十毫秒。这时 now < lastTs， 如果不管，就会生成和之前重复的 ID。三种处理方式：

我的实现用的是第二种（back > 5ms 就抛异常），代码里那三行就是全部：

if (ts < lastTs) {
    long back = lastTs - ts;
    if (back > 5) throw new IllegalStateException("时钟回拨 " + back + "ms");
    ts = lastTs;                       // 小幅回拨：等在原地，等它追上来
}

坑二：机器号怎么分配

10 位机器号是写死的，两台机器配成同一个号，就会生成重复 ID—— 而且不会报错，只会在数据库主键冲突时才发现。

• 小规模：配置文件写死，部署时人工保证不重复；
• 中等规模：用 Zookeeper / etcd 的顺序节点自动分配；
• 云上：用Pod 序号或 IP 后两段取模，但要注意扩容后可能撞号。

16.4幂等：三种方案，按成本排

「用户点了两次提交，怎么只下一单」——这题的关键是先说清「幂等键」是什么， 再说用什么存。

第 1 条是兜底方案：不管前面用什么，数据库唯一索引都要加—— 因为它是唯一不会被并发绕过的一层。第 2 条在 13.9 已经实测过： SET lock uuidA NX PX 3000 第二次返回 None，而且必须带 value 用 Lua 释放。

16.5怎么讲项目：STAR 加三个数字

「介绍一下你的项目」这道题，最怕讲成流水账。用 STAR 但每一段都塞一个数字：

16.6速记卡与自查

动手清单与自查表