2026-10-29

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：MySQL 整数类型按字节数递增为 TINYINT(1)/SMALLINT(2)/MEDIUMINT(3)/INT(4)/BIGINT(8)，int 占 4 字节。
> 关键词：TINYINT · SMALLINT · MEDIUMINT · BIGINT · unsigned
> 边界：占用字节固定不变，但可显示宽度与存储字节是两回事，别把 `INT(11)` 当成存储上限。

### L2 · 核心讲解

**核心考点定位**：面试官想确认你是否把「整数类型字节数」这个最底层的内存/存储事实记准，并且能区分「可显示宽度」（MySQL 8 已废弃）与「实际存储字节」——很多人把 `INT(11)` 误解为只能存 11 位。

**机制链（≥3 环）**：
1. 列类型决定存储 → 每行该列按固定字节分配：为什么 InnoDB 页内能排布更多行，取决于列字节越小、页内行数越多、B+Tree 非叶节点能存更多索引项。
2. 字节数决定取值 → TINYINT 1 字节 8 位，有符号 `-128~127`：为什么范围是 2^8 一半，因为最高位是符号位。
3. 范围决定溢出行为 → 超范围时 MySQL 报错或截断：为什么生产必须用足够大的类型，因为上线后改列类型是 `ALTER` 大表加锁风险。

**证据锚点**（去重 ≥6）：
- `TINYINT`=1 字节，有符号 `-128~127`，无符号 `0~255`
- `SMALLINT`=2 字节，有符号 `-32768~32767`
- `MEDIUMINT`=3 字节，有符号 `-8388608~8388607`
- `INT`=4 字节，有符号 `-2147483648~2147483647`
- `BIGINT`=8 字节，有符号 `-9223372036854775808~9223372036854775807`
- `UNSIGNED`：去掉符号位，上限翻倍（如 `INT UNSIGNED` 到 `4294967295`）
- `ZEROFILL`：数字左补零到显示宽度，MySQL 8.0.17 起废弃显示宽度但 `ZEROFILL` 仍有效
- `AUTO_INCREMENT`：主键自增推荐用 `BIGINT`，避免 `INT` 溢出后 `AUTO_INCREMENT` 顶到上限

**对比与权衡**：
| 类型 | 字节 | 有符号范围 | 典型用途 | 失败边界 |
|---|---|---|---|---|
| `TINYINT` | 1 | -128~127 | 状态码、布尔 | 状态枚举 >127 即溢出 |
| `SMALLINT` | 2 | -32768~32767 | 小计数值 | 日活/小统计可能不够 |
| `MEDIUMINT` | 3 | -8388608~8388607 | 中量级 ID | 百万级 ID 仍够 |
| `INT` | 4 | -21亿~21亿 | 常规主键/ID | 自增到 21 亿溢出 |
| `BIGINT` | 8 | ±9.2E18 | 雪花/订单/流水主键 | 几乎不会溢出 |

**常见误区**：
1. 错误：`INT(11)` 表示只能存 11 位整数 → 正确：括号是「显示宽度」，与存储字节/范围无关，MySQL 8.0.17+ 已废弃 → 为什么错：把 UI 展示宽度当成数据模型约束。
2. 错误：整数类型占用的字节数随数值大小变化 → 正确：MySQL 整数列是定长，`INT` 恒 4 字节 → 为什么错：误解成变长存储（那是 `VARCHAR` 的事）。
3. 错误：主键用 `INT` 就够 → 正确：订单/流水/雪花 ID 用 `BIGINT`，因为 `INT` 上限 21 亿，高并发自增很快顶到 → 为什么错：低估了写入量级，溢出后 `ALTER` 改列在大表上是锁表灾难。
4. 错误：无符号能让负数不合法却更高效 → 正确：`UNSIGNED` 只改范围不改存储大小与性能，只是「负值被拒绝」 → 为什么错：以为 `UNSIGNED` 能提速，实则是约束语义。

**适用边界**：若业务 ID 由应用侧生成（雪花、UUID 数字版），或未来可能合并多库、跨库分片，直接 `BIGINT`，不要为省 4 字节在 `INT`/`BIGINT` 之间纠结——省下的是每行 4 字节，换来的是溢出重建表的系统性风险，不划算。

### 延伸追问（≥3）

1. **为什么推荐主键用 BIGINT 而不是 INT？**
- 要点：`INT` 上限 21.4 亿，自增主键在秒级高写入下很快逼近；雪花 ID 超过 21 亿直接溢出。
- 追问落点：溢出后 `ALTER TABLE MODIFY` 改列类型在大表上的锁与 DDL 成本。

2. **`UNSIGNED` 和显示宽度分别影响什么？**
- 要点：`UNSIGNED` 影响取值范围（上限翻倍）；显示宽度只影响展示补零。
- 追问落点：MySQL 8.0.17 后显示宽度废弃，只剩 `UNSIGNED` 有意义。

3. **为什么不用 `DECIMAL` 存整数 ID？**
- 要点：`DECIMAL` 是精确小数，存储更大、运算更慢，整数场景用整型更省。
- 追问落点：金额为什么用 `DECIMAL` 而 ID 不用——精度与范围的语义差别。

### 面试者参考回答（400–700 字）

**【结论】** MySQL 整数类型按字节数递增为 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，int 固定占用 4 字节、32 位。

**【三点】** 第一，字节数是固定的：TINYINT 1 字节、SMALLINT 2 字节、MEDIUMINT 3 字节、INT 4 字节、BIGINT 8 字节，定长存储让 InnoDB 页内能排布更多行、索引更紧凑。第二，范围由字节和符号位决定：INT 有符号上限 21 亿，加 UNSIGNED 翻倍到 42 亿；BIGINT 是 64 位，几乎不会溢出，所以订单/流水/雪花这类会持续增长的主键我直接上 BIGINT。第三，要区分显示宽度和存储字节：`INT(11)` 只是展示补零，MySQL 8.0.17 起已废弃，别把它当成能存 11 位——这是最常见的误解。

**【边界】** 如果业务 ID 是应用侧生成的雪花号或将来要跨库分片，就别在 INT 和 BIGINT 之间省那 4 字节，直接 BIGINT；否则自增顶到 21 亿后改列类型，在大表上是锁表级别的灾难。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：新增节点能启动但分不到分区，核心是「消费组成员/分区分配」问题——消费者数超过分区数、`group.id` 不一致、或新节点未参与 Rebalance 继承位移。
> 关键词：消费者组 · 分区分配 · Rebalance · group.id · auto.offset.reset
> 边界：节点能连上 broker 不等于能拿到分区；先确认「可分配分区数 vs 组内消费者数」。

### L2 · 核心讲解

**核心考点定位**：面试官想看你对 Kafka 消费组（Consumer Group）机制的理解——新节点"运行正常"但"不消费"，本质是它没被分配任何分区，而不是消息没到。常见错误是把「连接正常」当成「消费正常」。

**机制链（≥3 环）**：
1. 新增消费者加入 → 触发组内 Rebalance：为什么，因为 `ConsumerCoordinator` 检测到成员变化会发起再均衡，重新分配分区。
2. 分区分配 → 按「分区数 : 消费者数」：为什么，因为每个分区同一时刻只能被组内一个消费者持有，消费者多于分区时多出来的消费者分不到分区。
3. 分不到分区 → 拉取循环空转：为什么，因为 `KafkaConsumer.poll()` 没有可拉取的分区，就没有消息，表现为"运行正常但不消费"。
4. 位移起点 → 首次消费从哪开始：为什么，因为 `auto.offset.reset=earliest/latest` 决定该分区无已提交位移时从哪读，配错会跳过历史消息。

**证据锚点**（去重 ≥6）：
- `group.id`：同一消费组内的消费者共享分区，新节点 `group.id` 不同则属于另一组，读的是另一套位移。
- `partition.assignment.strategy`：默认 `RangeAssignor`/`RoundRobinAssignor`/`StickyAssignor`，决定分区如何分配给组内成员。
- `auto.offset.reset`：`earliest`/`latest`/`none`，决定无提交位移时的起点。
- `max.poll.interval.ms`=默认 300000：消费者处理超时会触发 Rebalance 踢出。
- `session.timeout.ms`=默认 45000：心跳超时判定成员掉线。
- `kafka-consumer-groups.sh --describe --group {group}`：查看组内成员与分区分配（`CURRENT-OFFSET`/`LAG`）。

**对比与权衡**：
| 场景 | 现象 | 根因 | 定位手段 |
|---|---|---|---|
| 消费者数 > 分区数 | 新节点 0 分区，老节点正常 | 分区分配不足 | `--describe` 看 `CONSUMER-ID`/分区数 |
| `group.id` 不一致 | 新节点看似独立消费 | 属于不同消费组 | 对比各节点 `group.id` |
| 位移从最新开始 | 新节点"不消费"老消息 | `auto.offset.reset=latest` | 看 `CURRENT-OFFSET` 起点 |
| 网络/ACL 隔离 | 新节点连不上或无权 | 安全组/ACL 未放行 | 日志 `AuthorizationException` |

**常见误区**：
1. 错误：新增消费者会自动分担老节点消息 → 正确：只有在「消费者数 < 分区数」时才有多余分区可分担，否则新节点分不到 → 为什么错：误以为消费者越多消费越快，实际受分区数约束。
2. 错误：节点"运行正常"就代表在消费 → 正确：能启动、能连 broker 只说明网络与认证 OK，不代表拿到分区 → 为什么错：把进程存活当成业务健康。
3. 错误：加消费者一定能提高吞吐 → 正确：吞吐上限是分区数；消费者数 > 分区数后继续加人无效 → 为什么错：忽略 Kafka 单分区串行消费的模型。

**适用边界**：若确实想扩容消费吞吐，正确姿势是**先加分区**（`--alter --partitions`）再考虑加消费者，且加分区会触发 Rebalance、影响在线消费者；短时间无法加分区时，优先优化单条消费耗时或增大拉取批大小，而非盲目加消费者。

### 延伸追问（≥3）

1. **新增消费者后老消费者会不会全部停止消费？**
- 要点：Rebalance 期间组内所有消费者短暂停止，重新分配后各自拿到新分区；`StickyAssignor` 可减少不必要的分区迁移。
- 追问落点：频繁 Rebalance 的副作用（`max.poll.interval.ms` 超时循环踢出）。

2. **为什么消费者数可以超过分区数？多出来的消费者会怎样？**
- 要点：允许存在但空闲（0 分区），浪费连接；应让消费者数 ≈ 分区数。
- 追问落点：分区数如何规划（按单分区吞吐 × 目标总吞吐）。

3. **新节点加入后从哪条消息开始消费？**
- 要点：无已提交位移时按 `auto.offset.reset`；有位移则从组内已提交位移继续。
- 追问落点：`earliest` 会重放历史、`latest` 会跳过积压，如何按业务选。

### 面试者参考回答（400–700 字）

**【结论】** 新节点"运行正常但不消费"，本质是它没被消费组分配到任何分区，而不是消息没到达——Kafka 每个分区同一时刻只能被组内一个消费者持有。

**【三点】** 第一，先看数量关系：一个分区只能给组内一个消费者，消费者数超过分区数后，多出来的消费者就分不到分区，拉取循环空转，表现为启动正常但不消费，用 `kafka-consumer-groups.sh --describe --group` 一看分配就能确认。第二，再看配置一致性：新节点的 `group.id` 如果和其他节点不一致，它属于另一个消费组，读的是另一套位移和分区，自然"看起来不消费"；`auto.offset.reset` 配成 latest 也会让它在没有位移时直接从最新开始，跳过积压历史。第三，最后排网络和权限：新节点能连上 broker 只说明网络与认证 OK，ACL 没授权拉取、或安全组没放行，也会拉不到数据，日志里会有 `AuthorizationException` 或协调器相关报错。

**【边界】** 如果扩容吞吐是目标，正确顺序是先加分区再加消费者，否则加再多消费者也无效；而且加分区会触发 Rebalance，对在线消费者有短暂影响。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：读写分离延迟本质是主从异步复制的时间差，解决靠「按业务容忍度路由」——强一致读主、弱一致读从、写后读二次校验；强读主库的风险是主库压力集中、从库闲置、慢查询拖垮主库。
> 关键词：主从复制 · 同步延迟 · 强读主库 · 读写路由 · 缓存
> 边界：延迟无法归零，只能把"强一致窗口"收敛到业务可容忍范围，并监控 `Seconds_Behind_Master`。

### L2 · 核心讲解

**核心考点定位**：面试官想看你是否理解主从复制的**异步本质**——延迟不是 bug 而是架构特性；同时看你对「强读主库」的代价是否有清晰认知，而不是只知道"读主库最安全"。

**机制链（≥3 环）**：
1. 主库写入 → 写 binlog 并提交：为什么，因为主库只保证本地提交，不等待从库。
2. binlog 推送到从库 → 从库 `relay log` 回放：为什么，因为异步复制里从库 IO 线程拉取、SQL 线程回放，两者之间存在时间差。
3. 时间差 → 从库读到旧值：为什么，因为读从库的请求在从库回放完成前到达，命中的是旧版本数据。
4. 延迟放大 → 主库压力、从库延迟累积：为什么，因为主库并发写高、大事务、从库回放慢都会拉大 `Seconds_Behind_Master`。

**证据锚点**（去重 ≥6）：
- `Seconds_Behind_Master`：`SHOW SLAVE STATUS` 判据，>0 即有复制延迟。
- `GTID`：5.6+ 基于 GTID 复制更精确对齐主从。
- `semisynchronous`：`rpl_semi_sync_master_enabled=1` 半同步（`AFTER_SYNC`）让主库等一个从库 ACK 再提交。
- 读写路由：`@Transactional(readOnly=true)`/读写分离中间件（如 `ShardingSphere` 的 `hint` 强制主库）。
- `SHOW PROCESSLIST`/慢查询：定位从库回放慢的原因（大事务、缺索引）。
- 缓存：`SET` 后删缓存/写缓存，读优先命中缓存避免直接读从库。

**对比与权衡**：
| 方案 | 一致性 | 延迟 | 主库风险 | 适用 |
|---|---|---|---|---|
| 强读主库 | 强一致 | 无延迟 | 高（集中） | 写后立即读、金融类 |
| 弱读从库 | 最终一致 | 有延迟 | 低 | 可容忍的读多场景 |
| 半同步复制 | 强一致 | 略增 | 中 | 关键写、跨机房 |
| 缓存层隔离 | 弱一致 | 低 | 低 | 读多写少、热点 |
| 写后读二次校验 | 接近强一致 | 一次往返 | 中 | 关键单条写后读 |

**常见误区**：
1. 错误：强读主库就没延迟了 → 正确：只对"本次写"强一致，主从复制仍异步，后续读从库仍可能旧 → 为什么错：把单次强一致当成整体强一致。
2. 错误：延迟是故障要消灭 → 正确：延迟是异步复制的固有属性，只能收敛到可容忍范围 → 为什么错：把架构特性当缺陷，过度设计。
3. 错误：加从库就能解决延迟 → 正确：加从库提升读吞吐，但不缩短主到从的复制延迟 → 为什么错：混淆"吞吐扩容"与"延迟收敛"两个目标。
4. 错误：从库读不到就重试读从库 → 正确：应**读主库**或二次校验，重试读从库大概率还是旧值 → 为什么错：重试同一路径不改变数据版本。

**适用边界**：对「写后立即读自己刚写的数据」这类强一致需求，用 `hint` 强制走主库或写后二次校验；对能容忍秒级不一致的读多场景，走从库+缓存。若业务强一致要求极高，考虑半同步复制或主从同写。

### 延伸追问（≥3）

1. **为什么半同步复制能减少但没消除延迟？**
- 要点：`AFTER_SYNC` 让主库等一个从库收到并 ACK 再提交，但"收到 relay log"不等于"已回放可见"。
- 追问落点：`AFTER_COMMIT` vs `AFTER_SYNC` 的差异。

2. **延迟突然飙高如何排查？**
- 要点：看 `Seconds_Behind_Master` 趋势，定位主库大事务、从库回放慢（缺索引/低配置）、网络抖动。
- 追问落点：`SHOW SLAVE STATUS` 的 `Relay_Log_Pos`/`Exec_Master_Log_Pos` 差值。

3. **读写分离下事务内如何保证一致性？**
- 要点：事务内写后读走主库（`readOnly` 区分路由），避免事务内读到旧值导致逻辑错误。
- 追问落点：`@Transactional` 与路由注解的配合。

### 面试者参考回答（400–700 字）

**【结论】** 读写分离延迟本质是主从异步复制的时间差，解决靠"按业务容忍度路由"，强读主库的主风险是主库压力集中、从库闲置、慢查询拖垮主库。

**【三点】** 第一，先认本质：主库提交不等待从库，binlog 经 IO 线程拉取、SQL 线程回放，这个时间差就是延迟，所以"写后立刻读"最容易踩到从库旧值。第二，按业务容忍度路由：强一致需求（写后立即读自己刚写的）用 `hint` 强制走主库或写后二次校验；能容忍秒级不一致的读多场景走从库，配合缓存层优先命中，避免每次都读从库。第三，强读主库的风险要说透：全部读主库会让读压力集中到主库、从库闲置浪费，主库被慢查询或大查询拖垮后，服务拿不到连接，整体不可用——所以强读主库要限定在"关键单条写后读"，不能全局兜底。

**【边界】** 延迟无法归零，只能收敛到业务可容忍范围；高强一致场景可上半同步复制（`AFTER_SYNC` 等一个从库 ACK），但"收到 relay log"不等于"已回放可见"，仍需在应用层做兜底路由。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：主键推荐数值型（int/bigint）——定长、可自增、B+Tree 索引紧凑；varchar 主键适合业务可见标识（如订单号），但空间与索引膨胀、插入随机导致页分裂。
> 关键词：主键选型 · 自增 · 页分裂 · 聚簇索引 · 业务可见性
> 边界：要业务可读就用「唯一索引的订单号」而非主键；要随机不可预测就上雪花 ID 但仍是数值型。

### L2 · 核心讲解

**核心考点定位**：面试官想确认你是否理解「主键类型直接影响 InnoDB 聚簇索引的存储布局」——主键不仅是唯一标识，还是 B+Tree 叶子节点排序键，类型选择决定插入是否顺序、页是否分裂、二级索引是否膨胀。

**机制链（≥3 环）**：
1. 主键类型 → 聚簇索引叶节点大小：为什么，因为 InnoDB 主键即聚簇索引，叶子存整行数据，键越大单页容纳行越少。
2. 自增 vs 随机 → 插入位置：为什么，因为自增保证新行追加到索引末尾、顺序写；varchar/UUID 随机插入会落在页中间，触发页分裂与随机 IO。
3. 主键大小 → 二级索引成本：为什么，因为每个二级索引叶子都存主键值，主键越大二级索引越膨胀、回表越慢。
4. 业务可见性 → 是否放主键：为什么，因为可读 ID（订单号）有价值，但放主键会牺牲写入性能，通常放唯一索引而非主键。

**证据锚点**（去重 ≥10）：
- `INT`=4 字节、`BIGINT`=8 字节：数值主键定长，B+Tree 对比开销低。
- `VARCHAR(32)` 订单号：变长，可能 `ROW_FORMAT=DYNAMIC` 时溢出到 off-page。
- `AUTO_INCREMENT`：顺序插入，`innodb_autoinc_lock_mode` 影响批量插入锁策略。
- `UUID()`/随机字符串：无序，插入随机触发页分裂（`innodb_random_io` 上升）。
- `innodb_buffer_pool_size`：页分裂与随机 IO 会放大缓冲池压力。
- 二级索引叶子存主键：主键越大，每个二级索引占用越多。
- 雪花 ID：数值型、趋势递增，比 `UUID` 更适合主键但非自增。
- `innodb_page_size`=16384：默认 16KB，主键大小影响每页行数。

**对比与权衡**：
| 方案 | 写入性能 | 索引空间 | 业务可读 | 适用 |
|---|---|---|---|---|
| `BIGINT` 自增 | 最优（顺序写） | 最省 | 无 | 内部主键、无业务含义 |
| `INT` 自增 | 优 | 省 | 无 | 中小规模、上限 21 亿可接受 |
| 雪花 ID | 较好（趋势递增） | 省 | 部分可读 | 分布式、不暴露自增 |
| `UUID` | 差（随机写） | 膨胀 | 无 | 极少用，仅跨库合并 |
| `VARCHAR` 订单号 | 中（若有序可优化） | 膨胀 | 强 | 需业务可见标识 |

**常见误区**：
1. 错误：主键用 UUID 最安全 → 正确：UUID 无序 + 128 位，页分裂严重、索引膨胀；用雪花/数值型 → 为什么错：只看唯一性，忽略聚簇索引布局。
2. 错误：订单号适合直接做主键 → 正确：订单号做唯一索引，主键仍用自增数值 → 为什么错：把业务可读与存储性能混为一谈。
3. 错误：varchar 主键不浪费空间 → 正确：变长 + 可能溢出，二级索引都带主键，放大空间 → 为什么错：忽略二级索引存储主键的放大效应。
4. 错误：主键类型对查询没影响 → 正确：主键大小影响页内行数与二级索引大小，直接影响扫描与回表成本 → 为什么错：只看到逻辑唯一，看不到物理布局。

**适用边界**：若业务明确要求"订单号对外可见且需快速定位"，用「自增主键 + 订单号唯一索引」；若要求不暴露自增（防竞对猜测），用雪花 ID 做主键、订单号仍可做唯一索引；若跨库/历史合并导致自增冲突，才考虑业务字符串主键并接受写入代价。

### 延伸追问（≥3）

1. **为什么二级索引的叶子要存主键值？**
- 要点：InnoDB 二级索引叶子存主键用于回表，主键越大二级索引越胖。
- 追问落点：覆盖索引能否避免回表。

2. **雪花 ID 和自增主键怎么选？**
- 要点：雪花趋势递增、分布式生成、不暴露自增量；自增简单但可被猜测。
- 追问落点：雪花时钟回拨、workerId 分配。

3. **varchar 主键的 `ROW_FORMAT=DYNAMIC` 溢出意味着什么？**
- 要点：超长列可能行外存储，主键列本身通常短，但订单号长字符串要警惕。
- 追问落点：`COMPACT`/`DYNAMIC`/`COMPRESSED` 的差异。

### 面试者参考回答（400–700 字）

**【结论】** 主键优先数值型（int/bigint）——定长、可自增、聚簇索引紧凑；varchar 主键适合业务可见标识，但会带来空间与索引膨胀、随机插入页分裂，通常放唯一索引而非主键。

**【三点】** 第一，存储与写入：数值主键定长、自增保证顺序追加，B+Tree 页内行数多、随机 IO 少；varchar 或 UUID 随机插入会落在页中间触发页分裂，放大缓冲池压力。第二，索引成本：InnoDB 每个二级索引叶子都存主键值，主键越大二级索引越膨胀、回表越慢，所以用 varchar 主键会放大所有索引。第三，业务可见性：如果订单号要对外可读，正确做法是"自增主键 + 订单号唯一索引"，既保写入性能又保可读定位；若不想暴露自增量，用雪花 ID（数值型、趋势递增）做主键更合适。

**【边界】** 只有跨库合并、历史数据主键冲突，或确需字符串主键的业务，才考虑 varchar 主键并接受写入代价；一般场景别用 UUID 做主键，它无序又占 128 位，是索引布局最差的选择。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：Kafka 默认「至少一次」语义，保证不重复靠**消费端幂等**——唯一业务键去重（去重表/Redis SETNX）+ 手动提交位移 + 状态机。
> 关键词：at-least-once · 幂等 · 位移提交 · 去重表 · 状态机
> 边界：精确一次（exactly-once）需事务或幂等配合；Kafka 单分区内幂等不等于跨分区/跨系统原子。

### L2 · 核心讲解

**核心考点定位**：面试官想确认你是否分清「消息不丢」「消息不重复」「消息只处理一次」三件事——Kafka 默认至少一次，重复是常态，关键在消费端做幂等而不是在 Broker 层承诺。

**机制链（≥3 环）**：
1. 消费提交位移 → 可能重复：为什么，因为消费者处理完业务但位移未提交时崩溃，重启后从上次已提交位移重放，同一条又被处理。
2. 重放 → 需幂等拦截：为什么，因为同一业务键被二次处理会产生重复数据，需在进入业务前判断是否已处理。
3. 幂等判断 → 去重表/Redis：为什么，因为用唯一业务键（如订单号+事件类型）作为去重键，`INSERT ... ON DUPLICATE` 或 `SETNX` 保证只落一次。
4. 位移提交时机 → 控制重复窗口：为什么，因为「处理完再提交」是 at-least-once（可能重复但不丢），「先提交再处理」是 at-most-once（可能丢），默认选前者+幂等。

**证据锚点**（去重 ≥10）：
- `enable.auto.commit`：默认 `true`，自动提交位移；改 `false` + 手动 `commitSync` 控窗口。
- `auto.commit.interval.ms`：默认 5000，自动提交间隔。
- `acks=all` + `retries>0`：生产者侧保证不丢（配合幂等生产者 `enable.idempotence=true`）。
- `max.poll.records`：单次 poll 拉取上限，影响处理批大小。
- `group.id`：位移按消费组隔离，换组即从 `auto.offset.reset` 重新开始。
- 去重表唯一键：`UNIQUE KEY(biz_key)`，`INSERT IGNORE`/`ON DUPLICATE KEY UPDATE`。
- `SETNX` + 过期时间：Redis 分布式去重，需设 TTL 防 key 永久残留。
- 状态机：订单状态流转（如 `CREATED→PAID→SHIPPED`），重复事件按状态拒绝。

**对比与权衡**：
| 方案 | 去重能力 | 成本 | 失败模式 | 适用 |
|---|---|---|---|---|
| 去重表唯一键 | 强（DB 约束） | 中（每次查+插） | DB 压力 | 高频、需强保证 |
| Redis `SETNX`+TTL | 较强 | 低（内存） | key 过期后可能重 | 短窗口去重 |
| 状态机 | 强 | 中 | 乱序事件需处理 | 订单/状态型业务 |
| 生产者幂等 | 只防生产重复 | 低 | 只保单分区有序 | 配合消费幂等 |
| 手动位移+幂等 | 强 | 中 | 提交失败重放 | 推荐组合 |

**常见误区**：
1. 错误：开启 `enable.idempotence` 就能不重复 → 正确：生产者幂等只保证"发送不重"，不保证"消费不重"，消费端仍需幂等 → 为什么错：混淆生产与消费两个端点。
2. 错误：先提交位移再处理最安全 → 正确：先提交再处理会丢消息（at-most-once），应"处理完再提交"+ 幂等 → 为什么错：为了不重复牺牲不丢，因果倒置。
3. 错误：`SETNX` 设了 TTL 就万无一失 → 正确：TTL 过期后同一业务键可能被二次处理，需 TTL > 业务处理窗口 → 为什么错：把"短窗口去重"当成"永久去重"。
4. 错误：消费组换 `group.id` 能避免重复 → 正确：换组意味着重新消费历史（按 `auto.offset.reset`），反而可能重复更多 → 为什么错：误以为换组能清位移，实际是换了一套位移基线。

**适用边界**：若业务能容忍"恰好一次"的近似，用「手动提交位移 + 业务唯一键幂等」即可；若要求严格不重（金融），加 DB 唯一约束兜底 + 事务内同时提交业务与位移记录；若跨多个系统（如 MQ 再触发下游），需要分布式事务或事务消息，单点幂等不够。

### 延伸追问（≥3）

1. **Kafka 的 exactly-once 是怎么实现的？**
- 要点：`transactional.id` + 幂等生产者，生产与位移提交在同一事务，只保证「单分区读-处理-写」原子。
- 追问落点：跨分区/跨系统无法靠 Kafka 事务保证。

2. **为什么"处理完再提交"最稳？**
- 要点：先处理再提交 = at-least-once，不丢消息；重复靠幂等兜底。
- 追问落点：幂等键如何选取（业务唯一键而非消息 ID）。

3. **幂等去重表会不会成为瓶颈？**
- 要点：高频写唯一键约束会放大写入压力，可考虑分库或只保留近 N 天去重记录。
- 追问落点：去重记录清理策略与 TTL。

### 面试者参考回答（400–700 字）

**【结论】** Kafka 默认是「至少一次」语义，重复是常态；保证不重复靠**消费端幂等**——唯一业务键去重 + 手动提交位移 + 状态机，而不是指望 Broker 层。

**【三点】** 第一，先认语义：消费者处理完但位移没提交就崩溃，重启后会从上次已提交位移重放，同一条又处理一遍，所以默认至少一次、可能重复。第二，消费端做幂等：用业务唯一键（如订单号+事件类型）作为去重键，落库用唯一约束 `INSERT IGNORE`，或用 Redis `SETNX` 加 TTL 做短窗口去重；状态型业务（订单）用状态机，重复事件按状态拒绝。第三，位移提交时机：把 `enable.auto.commit` 设 false，处理完业务再手动 `commitSync`，这样不丢消息，重复靠幂等兜底——这是「处理完再提交 + 幂等」的标准组合。

**【边界】** 严格"恰好一次"需要事务或跨系统分布式事务；Kafka 事务只保证单分区内「读-处理-写」原子，跨分区、跨系统（再触发下游）单点幂等不够，要上事务消息或分布式事务。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：接口是否异步取决于「是否要等待所有聚合结果」；异步用线程池，IO 密集核心线程≈2×CPU，队列按响应时限收紧；异常在任务内 try-catch 记录 + `Future.get` 捕获 + 拒绝策略降级。
> 关键词：IO 密集 · 线程池参数 · 拒绝策略 · Future · 降级
> 边界：异步不保证顺序与结果强一致，适合"可容忍延迟、可合并结果"的聚合，不适合强一致写后读。

### L2 · 核心讲解

**核心考点定位**：面试官想确认你是否能把线程池的 7 个参数讲透，并说明**如何按业务特性选型**（IO 密集 vs CPU 密集、响应时限 vs 吞吐）——很多人只会背参数，不会给"为什么这么配"。

**机制链（≥3 环）**：
1. 任务到达 → 核心线程是否满：为什么，因为 `corePoolSize` 决定常驻线程，先复用核心线程。
2. 核心满 → 进队列：为什么，因为 `workQueue` 是缓冲，队列大小决定"能攒多少任务"。
3. 队列满 → 是否开最大线程：为什么，因为 `maximumPoolSize` 是队列满后的扩容上限，超了才走拒绝策略。
4. 拒绝 → 降级/丢弃：为什么，因为 `RejectedExecutionHandler` 决定溢出行为，配合业务降级（返回默认/跳过通道）。

**证据锚点**（去重 ≥10）：
- `corePoolSize`：常驻线程，IO 密集通常 `2×CPU`，CPU 密集 `CPU+1`。
- `maximumPoolSize`：队列满后的上限，IO 密集可 `2×core`。
- `workQueue`：`ArrayBlockingQueue` 有界（推荐，可控背压）vs `LinkedBlockingQueue` 默认无界（`max` 失效）。
- `keepAliveTime` + `TimeUnit.SECONDS`：非核心线程空闲回收。
- `ThreadPoolExecutor` 拒绝策略：`AbortPolicy`(抛)/`CallerRunsPolicy`(调用线程跑)/`DiscardPolicy`(丢)/`DiscardOldestPolicy`(丢最老)。
- `execute()` vs `submit()`：`submit` 返回 `Future`，异常被包装进 `ExecutionException`。
- `Future.get(timeout)`：设超时防异步任务长期阻塞。
- `RejectedExecutionException`：队列满且线程达 max 时抛出，需捕获降级。
- 上下文透传：`TaskDecorator`/`TransmittableThreadLocal`（TTL）保证异步线程拿到调用方上下文。

**对比与权衡**：
| 参数选择 | 优点 | 缺点 | 适用 |
|---|---|---|---|
| 有界队列（小） | 快速触发拒绝/降级，响应可控 | 拒绝率高 | 要求低延迟 |
| 无界队列 | 几乎不拒绝 | `max` 形同虚设，内存堆积 | 吞吐优先、能背压 |
| `core=2×CPU` | IO 密集充分利用 | 线程多占用内存 | 大量 IO/三方调用 |
| `core=CPU+1` | CPU 密集刚好 | IO 场景线程不够 | 计算密集型 |
| `CallerRunsPolicy` | 不丢任务 | 阻塞调用线程 | 允许背压到上游 |
| `AbortPolicy`+降级 | 快速失败 | 需捕获处理 | 明确拒绝语义 |

**常见误区**：
1. 错误：无界队列 + 大 max 就能抗压 → 正确：无界队列让 `max` 永不触发，任务无限堆积拖垮内存 → 为什么错：忽略有界队列的背压作用。
2. 错误：线程数越多越好 → 正确：线程过多上下文切换反而降吞吐，需按 IO/CPU 密集公式 → 为什么错：把线程当资源无限。
3. 错误：`submit` 的异常会自动抛给调用方 → 正确：`Future.get` 抛 `ExecutionException`，需显式 `get` 或 `get(timeout)` 才能感知 → 为什么错：忽略 `execute`/`submit` 异常传播差异。
4. 错误：线程池丢任务靠日志就能发现 → 正确：拒绝策略要有明确语义并配合降级，日志只是事后，需前置容量预估 → 为什么错：把异常处理当记录，不当治理。

**适用边界**：异步聚合适合「读多、结果可合并、可容忍部分失败降级」的场景；若业务要求强一致（写后立即读自己写的数据），异步反而引入竞态，应同步或走主库；线程池容量需用 `Little's Law`（并发=QPS×耗时）先估，再决定参数。

### 延伸追问（≥3）

1. **为什么 IO 密集核心线程数是 2×CPU？**
- 要点：IO 等待时 CPU 空闲，多线程补足；CPU 密集则 CPU+1 避免切换。
- 追问落点：实际用压测调优，公式只是起点。

2. **无界队列为什么让最大线程数失效？**
- 要点：`LinkedBlockingQueue` 无界则永不触发扩容与拒绝，`max` 不生效。
- 追问落点：有界队列 + 拒绝策略才是可控背压。

3. **异步任务里如何做上下文透传？**
- 要点：`ThreadLocal` 不进线程池，需 `TaskDecorator` 或 TTL（`TransmittableThreadLocal`）。
- 追问落点：MDC 日志上下文、鉴权上下文丢失问题。

### 面试者参考回答（400–700 字）

**【结论】** 接口是否异步取决于能否接受「不等待所有结果」；异步用线程池，IO 密集核心线程≈2×CPU，队列按响应时限收紧，异常在任务内 try-catch 记录 + `Future.get` 捕获 + 拒绝策略降级。

**【三点】** 第一，参数怎么配：我们接口大量调三方，是 IO 密集，核心线程设 2×CPU、最大 2×core，队列用有界 `ArrayBlockingQueue`（比如 100）——因为业务要低延迟，队列偏小能更快触发拒绝而不是默默堆积，避免无界队列让 `max` 形同虚设。第二，异常怎么处理：任务内 try-catch 记录并把结果标记为失败；用 `submit` 拿 `Future`，`get(timeout)` 设超时捕获 `ExecutionException`；队列满且线程到 max 时 `RejectedExecutionException` 要捕获并走降级。第三，降级设计：单个通道多次阻塞就跳过该通道、标记质量不合格，触发换其他通道，不死磕——这比死等更符合"聚合接口"的价值。

**【边界】** 异步适合"读多、结果可合并、可容忍部分失败降级"的聚合；若业务要求写后立即读强一致，异步会引入竞态，应同步或走主库；线程池容量先按 `Little's Law`（并发=QPS×耗时）估算再调优。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：窗口函数（`ROW_NUMBER`/`RANK`/`SUM() OVER`）适合报表/排名/去重取最新，MySQL 8.0+ 支持；正则（`REGEXP`/`RLIKE`）能表达复杂匹配但性能差，只适合小数据量/离线。
> 关键词：ROW_NUMBER · RANK · OVER PARTITION · REGEXP · 回表
> 边界：8.0 以下无窗口函数；大表用窗口函数会全表扫描/排序，性能差，尽量下推到应用或离线。

### L2 · 核心讲解

**核心考点定位**：面试官想确认你是否知道 MySQL 8.0 新增的窗口函数是"分组的进阶"——它不折叠行，每行保留并附加窗口计算值；以及你是否理解正则表达式在 MySQL 中的性能代价，别在业务主链路乱用。

**机制链（≥3 环）**：
1. 窗口函数执行 → 先分组再逐行计算：为什么，因为 `OVER (PARTITION BY ... ORDER BY ...)` 定义窗口，对窗口内每行求 `ROW_NUMBER`/`SUM` 而不折叠行。
2. 大表窗口 → 排序/全表扫描成本：为什么，因为窗口函数需要按 `ORDER BY` 排序并维护窗口，无法走普通索引直接输出。
3. 正则匹配 → 逐行扫描 + 正则引擎：为什么，因为 `REGEXP` 无法用普通 B+Tree 索引，需要全表扫描逐行正则求值。
4. 性能代价 → 决定使用边界：为什么，因为大表/主链路下窗口与正则成本不可接受，应改用应用层或预聚合。

**证据锚点**（去重 ≥10）：
- `ROW_NUMBER()`：窗口内行号，常用于去重取最新（`PARTITION BY user_id ORDER BY created_at DESC`）。
- `RANK()`/`DENSE_RANK()`：排名（跳号/不跳号），用于排行榜。
- `SUM() OVER (PARTITION BY ...)`：累计/分组求和，用于占比、累计值。
- `LAG()`/`LEAD()`：取上一行/下一行值，用于环比、同环比。
- `NTILE()`：分桶。
- `OVER (PARTITION BY ... ORDER BY ...)`：窗口定义，决定分组与排序。
- `REGEXP`/`RLIKE`：正则匹配，MySQL 8.0 用 ICU 库。
- `REGEXP_LIKE()`/`REGEXP_REPLACE()`/`REGEXP_SUBSTR()`：8.0+ 函数式正则。
- `EXPLAIN`：确认是否 `type=ALL` 全表扫描（正则几乎必然）。
- MySQL 版本：窗口函数 8.0+，5.7 用用户变量模拟。

**对比与权衡**：
| 实现 | 能力 | 性能 | 适用 |
|---|---|---|---|
| 窗口函数（8.0+） | 强（排名/累计/去重） | 中（需排序） | 报表、离线、中小表 |
| GROUP BY 聚合 | 折叠行，丢明细 | 好 | 只取汇总值 |
| 应用层 Java 处理 | 灵活 | 取决于数据量 | 需分页/流式 |
| `REGEXP` | 复杂匹配 | 差（全表扫） | 小数据量、校验 |
| `LIKE '%x%'` | 简单子串 | 差（无前缀索引） | 简单包含匹配 |

**常见误区**：
1. 错误：窗口函数和 `GROUP BY` 一样折叠行 → 正确：窗口函数保留每一行，只附加窗口计算值 → 为什么错：混淆"聚合折叠"与"窗口逐行"。
2. 错误：大表用 `REGEXP` 没问题 → 正确：正则无法走索引，大表 `type=ALL` 全表扫描，性能不可接受 → 为什么错：只看功能，不看执行计划。
3. 错误：MySQL 所有版本都能用窗口函数 → 正确：8.0+ 才有，5.7 需用户变量模拟，性能差 → 为什么错：忽略版本差异。
4. 错误：正则能替代 `LIKE` 前缀查询 → 正确：有前缀的 `LIKE 'abc%'` 可走索引，正则不能 → 为什么错：把正则当万能索引。

**适用边界**：窗口函数与正则适合**离线/报表/小数据量校验**，不要放进业务主链路；大表排名用 Redis zset 或预聚合表，正则校验放到应用层或 `CHECK` 约束小表；8.0 以下无窗口函数需先确认版本。

### 延伸追问（≥3）

1. **如何用窗口函数取每个用户最新一条记录？**
- 要点：`ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) rn`，外层 `WHERE rn=1`。
- 追问落点：与 `GROUP BY` + 自连接的性能对比。

2. **`RANK()` 与 `DENSE_RANK()` 区别？**
- 要点：`RANK` 跳号（1,1,3），`DENSE_RANK` 不跳号（1,1,2）。
- 追问落点：排行榜场景选哪个。

3. **为什么正则不能在 MySQL 大表用？**
- 要点：正则逐行求值、无法索引，`EXPLAIN` 看 `type=ALL`。
- 追问落点：能否用前缀 `LIKE`、全文索引、或应用层预过滤代替。

### 面试者参考回答（400–700 字）

**【结论】** 窗口函数（`ROW_NUMBER`/`RANK`/`SUM() OVER`）适合报表、排名、取每组最新，MySQL 8.0+ 才有；正则（`REGEXP`/`RLIKE`）能表达复杂匹配但性能差，只适合小数据量或离线。

**【三点】** 第一，窗口函数我用在统计报表：比如取每个用户最新一条订单、算累计占比、排名，用 `ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)` 加外层 `WHERE rn=1`，它保留每一行并附加窗口值，不像 `GROUP BY` 那样折叠行。第二，正则我在校验类场景用过，比如校验字段格式、提取子串（`REGEXP_LIKE`/`REGEXP_SUBSTR`），但只在数据量小、离线场景用。第三，体验上最大的教训是性能：窗口函数要排序维护窗口，正则无法走索引、几乎必然 `type=ALL` 全表扫描，我在早期 ERP 写大 SQL 吃过苦，数据量大后把这类逻辑下推到应用层或预聚合，不让数据库背这种成本。

**【边界】** 窗口函数 8.0 以下不可用（5.7 需用户变量模拟）；大表排名用 Redis zset 或预聚合表，正则放应用层或小表 `CHECK`，别进业务主链路。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：一致性本质是「读缓存 + 写库删缓存」的取舍，接受短暂不一致、消灭长期不一致；写后立即读强一致用「先写库再删缓存 + 延迟双删 + MQ 补偿」。
> 关键词：Cache Aside · 延迟双删 · 先更新再删 · 补偿 · 最终一致
> 边界：并发下「读旧值回填缓存」会覆盖新值，需延迟双删或版本号；删除失败必须补偿，否则长期不一致。

### L2 · 核心讲解

**核心考点定位**：面试官想看你对「缓存一致性」是否有**工程化**理解，而不是背"先删缓存再更新库"——要能说清并发竞态、删除失败、写后立即读的三种典型坑，并给出补偿闭环。

**机制链（≥3 环）**：
1. 写库成功 → 删缓存：为什么，因为 Cache Aside 约定「更新走库、失效走缓存」，读时缓存未命中再回源。
2. 删缓存前有并发读 → 旧值回填：为什么，因为读线程在「写库后、删缓存前」读到旧值并回填，缓存又变成旧值，形成长期不一致。
3. 回填竞态 → 延迟双删：为什么，因为先删一次、延迟再删一次，覆盖中间窗口被回填的旧值。
4. 删缓存失败 → 消息补偿：为什么，因为删除操作可能失败或超时，需 MQ 异步重试删除，或版本号 CAS 兜底。
5. 缓存击穿 → 互斥回源：为什么，因为缓存未命中时大量并发回源 DB，需 `SETNX` 互斥或逻辑过期，避免热点 key 过期瞬间压垮数据库。

**证据锚点**（去重 ≥12）：
- Cache Aside：读缓存，未命中读库回填；写更新库，删缓存。
- 延迟双删：`DEL` → 更新库 → `sleep(ms)` → `DEL`，`sleep` > 读回填耗时。
- 更新顺序：**先更新数据库，再删缓存**（避免先删后更新导致窗口内读到旧值）。
- `SET key val EX ttl`：设 TTL 作为最终兜底，防缓存永不过期。
- 版本号/`CAS`：`UPDATE ... SET version=version+1` + 缓存带版本，旧版本回填被拒绝。
- MQ 补偿：删除失败发消息，消费者重试删除；`retry` + DLQ 兜底。
- 读扩散/缓存穿透：缓存未命中大量并发回源需加锁（`SETNX` 互斥）或布隆过滤器。
- `@CacheEvict`/`@CachePut`：Spring Cache 注解；`@CachePut` 更新缓存，`@CacheEvict` 删除。
- `canal`/CDC：订阅 binlog 异步失效缓存，解耦应用层。
- 读写并发：读旧值回填 vs 写库删缓存的竞态窗口。
- `SETNX key` 互斥 + 逻辑过期：防缓存击穿（热点 key 过期瞬时压库）。
- 缓存穿透：查不存在的 key 用布隆过滤器或空值缓存，避免反复回源。
- 缓存雪崩：批量过期错峰，`TTL` 加随机抖动。

**对比与权衡**：
| 方案 | 一致性 | 复杂度 | 适用 |
|---|---|---|---|
| 先更新库再删缓存 + TTL | 最终一致 | 低 | 默认、读多写少 |
| 延迟双删 | 较强 | 中 | 写后立即读、并发高 |
| 版本号 CAS | 强 | 中高 | 需严格不覆盖 |
| binlog CDC 失效 | 强 | 高 | 复杂缓存链路、多级缓存 |
| MQ 补偿删 | 最终一致 | 中 | 删除易失败场景 |
| 只设 TTL 不删 | 弱 | 低 | 可容忍长时间不一致 |

**常见误区**：
1. 错误：先删缓存再更新库最安全 → 正确：先删再更新，窗口内读会回填旧值，应「先更新库再删缓存」→ 为什么错：颠倒顺序放大了不一致窗口。
2. 错误：删一次缓存就够 → 正确：并发读可能在被删后立刻回填旧值，需延迟双删或版本号 → 为什么错：忽略"删完又回填"的竞态。
3. 错误：删除失败只记日志 → 正确：删除失败必须补偿（重试/MQ），否则缓存长期为旧值 → 为什么错：把偶发失败当可忽略。
4. 错误：缓存一致性要强一致 → 正确：缓存本质是性能优化，应接受短暂不一致、用 TTL 保证最终收敛 → 为什么错：用强一致去设计缓存，成本失衡。
5. 错误：用 `@CachePut` 更新缓存就一致 → 正确：`@CachePut` 先写后读可能读到旧库值，更新链路以「删缓存」为准 → 为什么错：混淆「更新缓存」与「失效缓存」语义。
6. 错误：设了 TTL 就不怕不一致 → 正确：TTL 只保证最终收敛，若更新后删除失败，长 TTL 会放大不一致窗口 → 为什么错：把 TTL 当一致性保障而非兜底。

**适用边界**：强一致需求（写后立即读自己刚写的）用「写库 + 删缓存 + 延迟双删」并配合 TTL；多级缓存（本地 Caffeine + Redis）或复杂联动失效，用 binlog CDC 或 MQ 广播统一失效；只读高频、写极少的热点，可退化到「TTL 过期」简单模型并接受秒级不一致。若删除缓存与更新库之间系统崩溃，靠 TTL 过期兜底；若读回填与删缓存竞态频繁，优先版本号 CAS 而非无限延迟双删。

### 延伸追问（≥3）

1. **为什么必须先更新数据库再删缓存？**
- 要点：先删后更新，窗口内读回填旧值；先更新后删，窗口内读旧值但删除会清掉，配合延迟双删更稳。
- 追问落点：延迟双删的 `sleep` 取多少、依据是什么。

2. **删除缓存失败怎么兜底？**
- 要点：MQ 异步重试 + DLQ，或版本号 CAS；不能只打日志。
- 追问落点：`SETNX` 互斥回源防缓存击穿。

3. **多级缓存（本地+Redis）一致性怎么保证？**
- 要点：本地缓存设短 TTL，Redis 失效后广播本地失效（`publish`/`canal`）。
- 追问落点：本地缓存失效广播的可靠性。

4. **缓存穿透/击穿/雪崩与一致性什么关系？**
- 要点：击穿（热点 key 过期）、穿透（查不存在）、雪崩（批量过期）是可用性维度，与一致性正交但常叠加。
- 追问落点：`SETNX` 互斥、逻辑过期、随机 TTL。

### 面试者参考回答（500–800 字）

**【结论】** 缓存一致性本质是取舍：用了缓存就要接受短暂不一致，但必须消灭长期不一致；标准做法是 Cache Aside——读缓存、未命中读库回填，写库后删缓存，配合延迟双删和补偿。

**【三点】** 第一，更新顺序：**先更新数据库，再删缓存**。先删后更新会在窗口内被读线程回填旧值，导致长期不一致。第二，处理并发竞态：单次删除不够，因为删完后可能立刻被并发读回填旧值，所以用延迟双删（删除 → 更新库 → 短暂延迟 → 再删一次），或用版本号 CAS（`UPDATE version=version+1`，缓存带版本，旧版本回填被拒绝）。第三，删除失败必须补偿：删除可能超时或失败，不能只记日志，要发 MQ 异步重试删除、兜底 DLQ，并给缓存设 TTL 作为最终收敛保证。

**【边界】** 我在实际项目里的取舍是：核心链路用「更新库 + 删缓存 + TTL」，有强一致要求（写后立即读）的加延迟双删；复杂多级缓存或联动失效（一个底层变动影响很多上层数据）用 MQ 广播统一删缓存，避免每层各自失效不一致。缓存本质是性能优化，别为追求强一致把成本做到失衡；只读高频写极少的场景，甚至可以退化到纯 TTL 过期模型接受秒级不一致。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：排行榜用 Redis zset（score=销量，member=商品ID），实时订单 `ZINCRBY` 加分，`ZREVRANGE` 取 TopN；大促拆榜 + 定期与 DB 对账兜底。
> 关键词：zset · ZINCRBY · ZREVRANGE · 热 Key · 对账
> 边界：单 zset 热 Key 会打满单分片，需按 `商品ID` 哈希拆榜再合并；榜单必须与 DB 周期对账，否则误差累积。

### L2 · 核心讲解

**核心考点定位**：面试官想看你对 zset 排行榜的**工程落地**——不只是"用 zset"，还要能讲清热 Key 拆分、TopN 查询、分数变更跨段、与 DB 对账这四个大促专属难题。

**机制链（≥3 环）**：
1. 下单成功 → `ZINCRBY rank 销量商品ID`：为什么，因为 zset 按 score 有序，销量累加用 `ZINCRBY` 原子加。
2. 实时加分 → 分数变化：为什么，因为 score 变更即调整 member 在跳表中的位置，`ZREVRANGE` 可 O(logN+M) 取 TopN。
3. 大促单 key → 热 Key 打满单分片：为什么，因为所有写都集中到一个 zset key，Redis 单线程+单分片成瓶颈。
4. 榜单漂移 → DB 对账：为什么，因为内存榜单可能因丢失/重复/回滚漂移，需周期用 DB 聚合重算校准。
5. TopN 展示 → 只取头部：为什么，因为百万级商品拉全榜成本高，`ZREVRANGE 0 N-1` 沿跳表只取 TopN。

**证据锚点**（去重 ≥12）：
- `ZINCRBY key increment member`：原子加分，排行榜核心写入。
- `ZREVRANGE key 0 N-1 WITHSCORES`：取 TopN（按 score 降序）。
- `ZADD`/`ZSCORE`/`ZRANK`：写入/查分/查名次。
- `zset` 底层：`skiplist` + `dict`，跳表保证范围查询 O(logN)。
- 热 Key 拆分：`key_#hash(member)`，多分片后再合并（`ZUNIONSTORE`）。
- `ZUNIONSTORE dest N key...`：合并多分片排行。
- `ZREVRANGE` 大 N：排行榜只取 TopN，不取全量，避免 `ZRANGE 0 -1` 拉全榜。
- `TTL`：榜单缓存设过期（如 1 天），配合跑批重建。
- DB 对账：`SELECT product_id, SUM(qty) FROM order WHERE ... GROUP BY product_id`。
- `lua` 脚本：加分+判断原子操作。
- 逻辑过期/互斥：防缓存击穿。
- 分片数：按预估商品数/单分片容量设定。
- `ZREVRANGE key 0 N-1 WITHSCORES`：只取 TopN，避免 `ZRANGE 0 -1` 全量。
- `ZREMRANGEBYRANK`：淘汰非 TopN 成员，控制 zset 体积。
- 逻辑过期/互斥：`SETNX` + 随机 TTL 防击穿与雪崩。

**对比与权衡**：
| 方案 | 实时性 | 热 Key 风险 | 成本 | 适用 |
|---|---|---|---|---|
| 单 zset 实时加分 | 高 | 高（单 key） | 低 | 中小规模 |
| 多分片 zset + 合并 | 高 | 低 | 中 | 大促、百万商品 |
| 跑批预聚合 zset | 低（分钟级） | 低 | 低 | 非实时排行榜 |
| DB 直接排名 | 差 | 无 | 高 | 数据量小 |
| Redis 缓存 DB 榜单 | 中 | 低 | 中 | 读多写少 |

**常见误区**：
1. 错误：排行榜直接 `ZRANGE 0 -1` 拉全量 → 正确：只取 TopN（`ZREVRANGE 0 N-1`），全量拉取在百万级是灾难 → 为什么错：忽略 zset 全量查询成本。
2. 错误：大促单 zset 就够 → 正确：单 key 写集中成热 Key，需按 `商品ID` 哈希拆榜再 `ZUNIONSTORE` 合并 → 为什么错：忽略单分片吞吐上限。
3. 错误：榜单不用对账 → 正确：内存榜单会漂移（丢失/重复/回滚），需周期用 DB 聚合重算校准 → 为什么错：把缓存当权威数据源。
4. 错误：`score` 直接用销量累计即可 → 正确：需考虑销量波动与"分数变更跨段"，跨段时榜单跳变要处理 → 为什么错：忽略增量更新下的排名突变。
5. 错误：商品 ID 直接作 member → 正确：member 应紧凑（如商品短码），避免大 key 内存膨胀 → 为什么错：忽略 zset 内存模型。

**适用边界**：实时性要求不高（分钟级）就**跑批预聚合**，用 DB 算好写入 zset 定期刷新，避免实时加分的对账复杂度；若必须实时，用多分片 zset + 周期 `ZUNIONSTORE` 合并 + DB 对账；榜单展示只用 TopN，永远不要 `ZRANGE 0 -1` 全量。若商品数极大或榜单只做展示（非强实时），可退化为「DB 聚合 + Redis 缓存榜单」的读多写少模型，降低实时加分的复杂度。

### 延伸追问（≥3）

1. **zset 底层结构为什么支持范围查询？**
- 要点：`skiplist` 跳表 + `dict`；`ZREVRANGE` 沿跳表 O(logN+M) 取区间。
- 追问落点：跳表 vs 红黑树的取舍。

2. **热 Key 怎么拆？拆完怎么合并？**
- 要点：`key_{hash(member)%N}` 分 N 片，查询 `ZUNIONSTORE` 合并；分片数按单分片容量估。
- 追问落点：合并查询的延迟与合并窗口。

3. **分数变更导致排名跨段怎么处理？**
- 要点：爆品从低排名跃升，zset 自动调整；但要防"瞬时抖动"刷榜，可加防抖或定时快照。
- 追问落点：拆榜后跨段是否需跨榜移动。

4. **如何与 DB 对账？**
- 要点：周期 `GROUP BY product_id SUM(qty)` 重算，`DEL` 后重建或增量校准。
- 追问落点：对账频率与高峰期错峰。

### 面试者参考回答（500–800 字）

**【结论】** 排行榜用 Redis zset：`score=销量`、`member=商品ID`，实时订单 `ZINCRBY` 加分，`ZREVRANGE` 取 TopN；大促必须拆榜 + 定期与 DB 对账。

**【三点】** 第一，写入与查询：下单成功后 `ZINCRBY rank 1 productId` 原子累加，查询用 `ZREVRANGE rank 0 9 WITHSCORES` 取 Top10，zset 底层跳表让范围查询 O(logN+M)，比全量排序高效。第二，大促热 Key 拆分：单 zset 所有写集中到一个 key，会打满单分片，按 `商品ID 哈希` 拆成多个 `key_{hash}`，查询时 `ZUNIONSTORE` 合并再 `ZREVRANGE`。第三，可靠性对账：内存榜单可能因消息丢失、重复消费、订单回滚而漂移，必须周期用 DB `GROUP BY product_id SUM(qty)` 重算校准，不能把缓存当权威数据源。

**【边界】** 如果实时性只要分钟级，直接**跑批预聚合**（DB 算好写入 zset 定期刷新）最省心，不用承担实时加分的对账复杂度；榜单展示永远只取 TopN，别 `ZRANGE 0 -1` 全量拉取；爆品跨段跃升要做好防抖或定时快照，避免榜单瞬时抖动。

> 最后更新：2026-10-29 · 基于第 1 次作答

### L1 · 30 秒速记
> 结论：父任务与子任务共用 core=max=10 的线程池会「线程池饥饿」——父任务占满核心、子任务排队互等导致死锁式卡顿；软优化是拆分父子线程池或上虚拟线程。
> 关键词：线程池饥饿 · 父子任务拆分 · 虚拟线程 · Semaphore · 拒绝策略
> 边界：不扩展资源、不改代码的约束下，最稳是「父子分离」；若只能改参数，用有界队列+拒绝策略降级而非无限等待。

### L2 · 核心讲解

**核心考点定位**：面试官想看你对「线程池饥饿/死锁式卡顿」的识别与治理——core=max=10、父子共用一池，7-8 个父任务各拆 3 个子任务，会占满 10 个线程等子任务，而子任务排队等不到线程，形成互等。要能给出**不扩展资源、不改代码**前提下的软优化组合。

**机制链（≥3 环）**：
1. 父任务到达 → 占满核心线程：为什么，因为 `core=max=10`，7-8 个父任务各自占线程执行。
2. 父任务内拆分 → 子任务提交到同一池：为什么，因为共用线程池，子任务排进队列等空闲线程。
3. 全部线程被父任务持有 → 子任务无线程可执行：为什么，因为父任务在等子任务，子任务在等线程，形成互相等待（饥饿）。
4. 饥饿 → 页面卡顿/超时：为什么，因为大量父任务与子任务互相阻塞，线程池吞吐趋近于 0。

**证据锚点**（去重 ≥12）：
- `corePoolSize=10`、`maximumPoolSize=10`：核心=最大，无扩容余地，队列满即拒绝。
- 父子共用池：父任务 `submit` 子任务，子任务又排队，是饥饿根因。
- 7-8 父任务 × 3 子任务 = 21-24 个任务争 10 线程。
- `Semaphore(permits)`：限制同时运行的父任务数，避免一次占满。
- `CompletableFuture`/`CountDownLatch`：编排子任务，`allOf` 聚合。
- 虚拟线程（JDK21）：`Executors.newVirtualThreadPerTaskExecutor()`，无固定池容量、平台线程不阻塞。
- `ThreadPoolExecutor` 参数：`setCorePoolSize`/`setMaximumPoolSize` 动态调参。
- `CallerRunsPolicy`：队列满回退给调用线程执行，反向背压。
- `ArrayBlockingQueue` 有界 + `RejectedExecutionHandler`：可控拒绝。
- 任务拆分：父任务只做编排，子任务并行（`invokeAll`）。
- `jstack`：定位线程池饥饿（大量 `WAITING`/`BLOCKED` 在等 `Future.get`）。
- 上下文切换：`jstack`/`vmstat` 观察线程数与切换开销。
- `Executors.newFixedThreadPool`：固定池无扩容，父子共用即饥饿温床。
- `CountDownLatch`/`allOf`：父任务聚合子任务，`await` 是 `WAITING` 主因。

**对比与权衡**：
| 方案 | 解决饥饿 | 改动 | 适用 |
|---|---|---|---|
| 父子任务拆分线程池 | 强（彻底） | 改代码 | 最合理 |
| 虚拟线程（JDK21） | 强 | 改执行器 | 高 IO 并发 |
| `Semaphore` 限流父任务 | 中 | 加代码 | 不改池参数 |
| 有界队列+拒绝降级 | 中 | 改参数 | 快速失败 |
| 动态调参 | 中 | 配置 | 运行时 |

**常见误区**：
1. 错误：把 `core`/`max` 调大就能解决 → 正确：不扩展资源前提下不行；且调大 max 若队列无界仍不触发，只是推迟 → 为什么错：忽略"资源固定"约束与无界队列失效。
2. 错误：父子同池只要队列大就没事 → 正确：队列大只是把饥饿推迟为堆积，父任务仍占线程等子任务 → 为什么错：把"排队"当"能执行"。
3. 错误：加锁同步父子结果即可 → 正确：加锁只会加剧等待，关键是把父子从同一池解耦 → 为什么错：用并发原语治死锁，方向错。
4. 错误：`submit` 子任务一定并行 → 正确：同池下子任务可能排队等父任务释放，实际串行化 → 为什么错：忽略池容量对并行的约束。

**适用边界**：不扩展资源、不改代码的严格约束下，首选**父子任务拆分线程池**（父任务编排池 + 子任务执行池）或 JDK21 虚拟线程；若只能改参数，用有界队列 + 拒绝策略降级（快速失败返回兜底），而不是无限等待；`Semaphore` 限制父任务并发可兜底，但不能根治池容量不足。若允许改代码，`invokeAll` + 独立执行器是正解。注意「不修改已有代码」的约束通常指不改业务逻辑，调整线程池参数/执行器实现仍属于配置与基础设施层面，是允许的软优化空间。

### 延伸追问（≥3）

1. **为什么会死锁式卡顿而不是直接拒绝？**
- 要点：父任务占线程等子任务，子任务排进队列等线程，互相等待；无界队列下不拒绝而是堆积。
- 追问落点：`jstack` 看到大量 `WAITING` 在 `Future.get`。

2. **虚拟线程为什么能解决？**
- 要点：虚拟线程挂载到平台线程，阻塞不占平台线程，父子可大量并发。
- 追问落点：JDK21 虚拟线程与平台线程池的取舍、`pinning` 边界。

3. **不改代码只改参数怎么缓解？**
- 要点：有界队列 + `CallerRunsPolicy`/拒绝降级，快速失败而非长期等待。
- 追问落点：拒绝后的业务降级语义。

4. **如何定位是线程池饥饿？**
- 要点：`jstack` 大量线程 `WAITING` 在 `Future.get`/`CountDownLatch.await`，`vmstat` 看运行队列。
- 追问落点：`jstack` 的 `BLOCKED`/`WAITING` 区分。

### 面试者参考回答（500–800 字）

**【结论】** 核心=max=10、父子共用一池，7-8 个父任务各拆 3 个子任务会「线程池饥饿」——父任务占满线程等子任务、子任务排队等线程，互相等待导致卡顿；最合理的软优化是**拆分父子线程池**或上**JDK21 虚拟线程**。

**【三点】** 第一，先定位本质：父任务占满 10 个核心线程，每个父任务又 `submit` 3 个子任务到同一池，子任务只能排队，而父任务在等子任务结果——线程被父任务占着不释放，子任务永远轮不到，`jstack` 会看到大量线程 `WAITING` 在 `Future.get`。第二，最合理方案：**父子任务拆成两个线程池**，父任务编排池负责拆分与聚合，子任务执行池跑具体逻辑，互不争抢；JDK21 下直接换 `newVirtualThreadPerTaskExecutor()`，虚拟线程阻塞不占平台线程，父子可大量并发。第三，如果只允许改参数：把队列换成有界 `ArrayBlockingQueue` + 明确拒绝策略（`CallerRunsPolicy` 反向背压或快速失败返回兜底），避免无限堆积把饥饿拖成卡死；或 `Semaphore` 限制同时运行的父任务数，缓解一次占满。

**【边界】** 不扩展资源、不改代码的前提下，拆分父子池或虚拟线程是根治，改参数只是缓解；若允许改代码，`invokeAll` + 独立执行器是正解——单纯调大 max 在无界队列下不生效，加锁同步只会加剧等待。