Redis（远程字典服务）从基础到精通

正式分册入口与阅读顺序

先按“数据如何存取 → 请求如何执行 → 数据如何恢复与复制 → 集群如何高可用 → 缓存如何一致 → 锁如何兜底 → 场景如何落地 → 线上如何排障”的顺序阅读；每一册都可独立复习。

00-知识图谱与复习路线：建立知识边界、复习顺序和项目映射。
01-数据结构命令语义：掌握 String（字符串）、Hash（哈希）、List（列表接口）和 ZSet（有序集合）的选型及命令边界。
02-事件循环与网络模型：理解 I/O（输入输出）多路复用、命令执行与阻塞风险。
03-持久化与复制：理解 RDB（快照持久化）、AOF（追加日志）及主从复制的数据恢复边界。
04-主从哨兵与集群：学习哨兵故障转移、Redis Cluster（Redis 集群）分片和迁移；文件生成中也以此路径进入。
05-缓存一致性与缓存问题：处理 Cache Aside（旁路缓存）、穿透、击穿、雪崩与失效窗口。
06-分布式锁全景：掌握加锁、续期、释放、主从切换风险和数据库兜底。
07-延迟队列限流与项目案例：把 ZSet（有序集合）、限流与 WMS（仓储管理系统）/跨境物流任务落到业务链路。
08-线上排障与综合题库：用于慢查询、big key（大键）、hot key（热键）及故障复盘；文件生成中也以此路径进入。

1. 简历关联点

简历中多次出现 Redis（远程字典服务）：底层数据结构、高可用架构、缓存穿透/击穿/雪崩、Lua（脚本语言）原子脚本、ZSet（有序集合）延迟队列、分布式锁、库存防超卖、支付回调幂等、异步任务重试。这个模块要能支撑下面几类追问：

Redis（远程字典服务）为什么快。
Redis（远程字典服务）单线程为什么还能高性能。
Redis（远程字典服务）持久化怎么保证恢复能力。
Redis（远程字典服务）主从、哨兵、集群分别解决什么问题。
Redis（远程字典服务）分布式锁怎么实现，为什么要 Lua（脚本语言）释放锁。
Redisson（Redis 客户端）看门狗如何续期。
RedLock（红锁）到底解决什么问题，又有什么争议。
项目里如何用 Redis（远程字典服务）解决库存防超卖、延迟队列、报警风暴治理。

2. 面试主线

回答 Redis（远程字典服务）问题时，建议从“快 -> 稳 -> 高可用 -> 一致性 -> 项目落地”展开。

Redis（远程字典服务）快，核心原因是内存存储、单线程命令执行、I/O（输入输出）多路复用、高效数据结构。
Redis（远程字典服务）稳，依赖过期删除、内存淘汰、RDB（快照持久化）、AOF（追加日志）、慢查询和大 key（键）治理。
Redis（远程字典服务）高可用，单机解决不了故障，主从解决读扩展，哨兵解决自动故障转移，集群解决容量和分片。
Redis（远程字典服务）锁要讲清加锁、解锁、过期、续期、误删、主从切换、脑裂。
项目落地要讲清为什么选择 Redis（远程字典服务）、风险是什么、兜底在哪里。

3. 基础知识

3.1 Redis（远程字典服务）为什么快

原因	说明
内存存储	数据主要在内存，避免磁盘随机 I/O（输入输出）
单线程命令执行	避免多线程锁竞争和上下文切换
I/O（输入输出）多路复用	一个线程可处理大量连接事件
高效数据结构	SDS（简单动态字符串）、dict（哈希字典）、skiplist（跳表）、quicklist（快速列表）
简单协议	RESP（Redis 序列化协议）解析成本低

Redis（远程字典服务）“单线程”主要指命令执行线程是单线程。现代 Redis（远程字典服务）在网络 I/O（输入输出）、持久化、异步释放等方面可能使用后台线程，但命令执行仍保持串行语义，避免并发写同一数据结构的复杂锁。

3.2 常用数据类型和底层结构

类型	常见用途	典型底层结构
String（字符串）	缓存、计数、分布式锁	SDS（简单动态字符串）
Hash（哈希）	对象字段缓存	listpack（紧凑列表）、dict（哈希字典）
List（列表接口）	简单队列	quicklist（快速列表）
Set（集合接口）	去重、标签	intset（整数集合）、dict（哈希字典）
ZSet（有序集合）	排行榜、延迟队列	listpack（紧凑列表）、skiplist（跳表）+ dict（哈希字典）
Bitmap（位图）	签到、状态标记	String（字符串）位操作
HyperLogLog（基数统计）	UV（独立访客数）估算	概率统计结构
Stream（流）	消息流	radix tree（基数树）

3.3 单线程模型与 I/O（输入输出）多路复用

flowchart TD
    A["客户端连接"] --> B["Socket（套接字）"]
    B --> C["Epoll（事件轮询机制）/Selector（选择器）"]
    C --> D["事件分发器"]
    D --> E["命令读取"]
    E --> F["命令解析"]
    F --> G["单线程执行命令"]
    G --> H["写回响应"]

单线程好处：

数据结构操作串行，避免加锁。
实现简单，延迟稳定。
CPU（中央处理器）多数时候不是瓶颈，网络和内存更关键。

单线程风险：

大 key（键）删除会阻塞。
慢命令会阻塞其他请求。
Lua（脚本语言）脚本执行太久会阻塞。
keys * 这类全量扫描会阻塞。

4. 底层原理

4.1 过期删除

Redis（远程字典服务）过期删除不是每个 key（键）到期立即删除，而是组合策略：

策略	说明	优缺点
惰性删除	访问 key（键）时发现过期再删除	节省 CPU（中央处理器），但可能占内存
定期删除	周期性抽样检查过期 key（键）	平衡 CPU（中央处理器）和内存
内存淘汰	内存达到上限时按策略淘汰	防止内存打满

常见淘汰策略：

策略	含义	适合场景
noeviction（不淘汰）	写入直接报错	强一致缓存或不能丢数据
allkeys-lru（全键最近最少使用）	所有 key（键）按 LRU（最近最少使用）淘汰	通用缓存
volatile-lru（过期键最近最少使用）	只淘汰设置过期时间的 key（键）	缓存与持久 key（键）混用
allkeys-lfu（全键最不常用）	所有 key（键）按 LFU（最不常用）淘汰	热点明显场景
volatile-ttl（过期键最短生存时间）	优先淘汰快过期 key（键）	对过期时间敏感

4.2 RDB（快照持久化）

RDB（快照持久化）是在某个时间点生成数据快照，适合备份和快速恢复。

flowchart LR
    A["触发 RDB（快照持久化）"] --> B["fork（派生）子进程"]
    B --> C["父进程继续处理请求"]
    B --> D["子进程写临时 RDB（快照持久化）文件"]
    D --> E["写完后替换旧文件"]

RDB（快照持久化）优点是恢复快、文件紧凑；缺点是两次快照之间的数据可能丢失。

4.3 AOF（追加日志）

AOF（追加日志）记录写命令，恢复时重放命令。

flowchart TD
    A["写命令执行成功"] --> B["追加到 AOF（追加日志）缓冲区"]
    B --> C{"appendfsync（追加刷盘策略）"}
    C -->|always（每次刷盘）| D["最安全，性能最低"]
    C -->|everysec（每秒刷盘）| E["折中，最多丢 1 秒"]
    C -->|no（系统决定）| F["性能好，风险高"]
    E --> G["AOF rewrite（追加日志重写）压缩文件"]

4.4 主从复制

Redis（远程字典服务）主从复制流程：

sequenceDiagram
    participant S as Slave（从节点）
    participant M as Master（主节点）
    S->>M: PSYNC（部分同步）请求
    M->>M: 生成 RDB（快照持久化）
    M->>S: 发送 RDB（快照持久化）文件
    M->>S: 发送复制缓冲区增量命令
    S->>S: 加载 RDB（快照持久化）并重放增量命令
    M-->>S: 后续持续命令复制

复制是异步的，因此主节点写成功不代表从节点已经同步。这一点会影响 Redis（远程字典服务）分布式锁在主从切换时的安全性。

5. 架构图与流程图

5.1 哨兵架构

flowchart TD
    C["客户端"] --> S1["Sentinel（哨兵）1"]
    C --> S2["Sentinel（哨兵）2"]
    C --> S3["Sentinel（哨兵）3"]
    S1 --> M["Master（主节点）"]
    S2 --> M
    S3 --> M
    M --> R1["Replica（从节点）1"]
    M --> R2["Replica（从节点）2"]
    S1 -.监控.-> R1
    S2 -.监控.-> R2

哨兵解决：

监控主从节点是否存活。
主节点故障时选举新主节点。
通知客户端新主节点地址。

哨兵不解决：

单主容量上限。
分片扩容。
强一致复制。

5.2 集群架构

flowchart TD
    C["客户端"] --> A["Master A\nslot（槽）0-5460"]
    C --> B["Master B\nslot（槽）5461-10922"]
    C --> D["Master C\nslot（槽）10923-16383"]
    A --> A1["Replica A1（从节点）"]
    B --> B1["Replica B1（从节点）"]
    D --> D1["Replica C1（从节点）"]
    A -.gossip（流言协议）.-> B
    B -.gossip（流言协议）.-> D
    D -.gossip（流言协议）.-> A

Redis Cluster（Redis 集群）通过 16384 个 slot（槽）分片。key（键）经过 CRC16（循环冗余校验）计算后映射到 slot（槽），slot（槽）再归属到某个主节点。

5.3 缓存问题治理

flowchart TD
    A["请求进入"] --> B{"Redis（远程字典服务）命中?"}
    B -->|命中| C["返回缓存"]
    B -->|未命中| D{"是否非法 key（键）?"}
    D -->|是| E["布隆过滤器/空值缓存\n防穿透"]
    D -->|否| F{"是否热点 key（键）过期?"}
    F -->|是| G["互斥锁/逻辑过期\n防击穿"]
    F -->|否| H["查询 MySQL（关系型数据库）并回填"]
    H --> I["随机过期时间\n防雪崩"]

6. 表格对比

6.1 主从、哨兵、集群

架构	解决问题	优点	缺点
单机	简单缓存	成本低、简单	单点故障、容量有限
主从	读扩展、备份	读写分离、从库备份	主节点故障需人工切换
哨兵	自动故障转移	高可用、自动选主	不解决分片容量
集群	水平扩容	分片、容量高	跨 slot（槽）操作受限、运维复杂

6.2 Redis（远程字典服务）锁方案对比

方案	能力	风险	适合场景
JVM（Java 虚拟机）本地锁	单进程互斥	多实例无效	单体应用、本地内存状态
SET NX PX（不存在才设置并带过期时间）	原子加锁并设置过期	业务超时导致锁过期	简单分布式互斥
Lua（脚本语言）解锁	校验 owner（持有者）后删除	脚本过长会阻塞	防止误删他人锁
Redisson（Redis 客户端）	可重入、看门狗续期	依赖客户端和 Redis（远程字典服务）稳定性	Java（编程语言）项目常用
RedLock（红锁）	多主节点多数派加锁	复杂、有争议、依赖时钟和网络	极高容错需求但需谨慎评估
Zookeeper（分布式协调服务）锁	临时顺序节点	性能低于 Redis（远程字典服务）	强协调、顺序公平

7. 数据演绎

7.1 SET NX PX（不存在才设置并带过期时间）锁演绎

正确加锁：

SET lock:order:1001 requestId-abc NX PX 30000

含义：

lock:order:1001 是锁 key（键）。
requestId-abc 是唯一 owner（持有者）标识。
NX（不存在才设置）保证只有一个线程加锁成功。
PX（毫秒过期时间）保证客户端宕机后锁最终释放。

错误解锁：

DEL lock:order:1001

如果线程 A 锁过期后线程 B 已重新加锁，线程 A 再执行 DEL（删除）会误删线程 B 的锁。

正确解锁必须用 Lua（脚本语言）保证“判断 owner（持有者）+ 删除”原子执行：

if redis.call('get', KEYS[1]) == ARGV[1] then
  return redis.call('del', KEYS[1])
else
  return 0
end

时序图：

sequenceDiagram
    participant A as 服务A
    participant R as Redis（远程字典服务）
    participant B as 服务B
    A->>R: SET lock NX PX 30000 成功
    A->>A: 执行业务超过 30 秒
    R-->>R: 锁自动过期
    B->>R: SET lock NX PX 30000 成功
    A->>R: Lua（脚本语言）校验 owner（持有者）
    R-->>A: owner（持有者）不匹配，不删除

7.2 Redisson（Redis 客户端）看门狗

Redisson（Redis 客户端）默认锁过期时间通常是 30 秒。如果业务没执行完，看门狗会定期续期。

flowchart TD
    A["线程加锁成功"] --> B["设置过期时间 30 秒"]
    B --> C["启动 watchdog（看门狗）"]
    C --> D{"业务是否完成?"}
    D -->|否| E["定期续期"]
    E --> D
    D -->|是| F["Lua（脚本语言）校验并解锁"]
    C --> G{"客户端是否宕机?"}
    G -->|是| H["无人续期，锁自然过期"]

看门狗解决了“业务执行时间超过锁过期时间”的问题，但不能解决所有问题：

Redis（远程字典服务）主从异步复制丢锁。
网络分区导致客户端误判。
锁内业务没有幂等，重试仍可能出错。

7.3 主从切换导致锁丢失

时间	事件	结果
T1	服务 A 在 Master（主节点）加锁成功	Master（主节点）存在锁
T2	锁还没复制到 Replica（从节点）	Replica（从节点）没有锁
T3	Master（主节点）宕机	哨兵触发切换
T4	Replica（从节点）升为新 Master（主节点）	新 Master（主节点）没有锁
T5	服务 B 加锁成功	A 和 B 可能同时执行业务

结论：Redis（远程字典服务）锁默认偏 AP（可用性和分区容错），不能当作绝对强一致锁。资金扣费、库存扣减必须有 MySQL（关系型数据库）唯一索引、乐观锁、幂等流水兜底。

7.4 ZSet（有序集合）延迟队列

ZSet（有序集合）延迟队列把执行时间作为 score（分数），任务 ID（标识）作为 member（成员）。

ZADD queue:delay 1710000000000 task-1001

消费逻辑：

查询 score（分数）小于当前时间的任务。
用 Lua（脚本语言）或分布式锁抢占任务。
成功后删除 ZSet（有序集合）成员。
执行业务，失败后按重试次数重新写入未来时间。

flowchart LR
    A["ZSet（有序集合）延迟队列"] --> B["按 score（分数）取到期任务"]
    B --> C["Lua（脚本语言）原子抢占"]
    C --> D["执行业务"]
    D -->|成功| E["记录完成"]
    D -->|失败| F["增加 retry（重试次数）并延迟重投"]

8. 线上排查与实战经验

8.1 Redis（远程字典服务）慢查询

排查方向：

slowlog（慢日志）查看慢命令。
bigkeys（大键扫描）定位大 key（键）。
查看 CPU（中央处理器）、内存、网络带宽。
检查是否有 keys（全量键扫描）、hgetall（全量哈希读取）、smembers（全量集合读取）。
检查 Lua（脚本语言）脚本是否执行太久。

治理方式：

大 key（键）拆分。
使用 scan（渐进扫描）代替 keys（全量键扫描）。
删除大 key（键）使用异步删除。
热点 key（键）本地缓存或多级缓存。
对高风险命令加审计。

8.2 缓存穿透、击穿、雪崩

问题	现象	方案
缓存穿透	请求不存在数据，直接打到 MySQL（关系型数据库）	布隆过滤器、空值缓存、参数校验
缓存击穿	热点 key（键）过期，大量请求打到 MySQL（关系型数据库）	互斥锁、逻辑过期、热点预热
缓存雪崩	大量 key（键）同时过期或 Redis（远程字典服务）故障	过期时间随机化、多级缓存、限流降级

8.3 分布式锁排查

当出现重复执行、超扣、任务重复消费时，排查：

锁 key（键）粒度是否过粗或过细。
owner（持有者）是否唯一。
加锁和设置过期是否一个原子命令。
解锁是否使用 Lua（脚本语言）校验 owner（持有者）。
业务耗时是否超过锁过期时间。
Redisson（Redis 客户端）看门狗是否启用。
Redis（远程字典服务）是否发生主从切换。
业务是否有 MySQL（关系型数据库）唯一索引、状态机、幂等流水兜底。

9. 项目落地话术

9.1 库存防超卖话术

“库存防超卖不能只靠 Redis（远程字典服务）锁。我的设计会分三层：第一层用 Redis（远程字典服务）Lua（脚本语言）保证批量 SKU（库存单位）冻结原子性；第二层用 MySQL（关系型数据库）乐观锁和库存流水保证最终可追溯；第三层用幂等键防止重复冻结和重复回滚。Redis（远程字典服务）负责抗高并发，MySQL（关系型数据库）负责最终正确性。”

9.2 支付回调幂等话术

“支付回调可能重复、乱序、丢失，所以我不会只用 Redis（远程字典服务）锁。我会用唯一流水号做 MySQL（关系型数据库）唯一约束，用 Redis（远程字典服务）锁降低并发冲突，再用状态机控制只允许从待支付流转到已支付。即使 Redis（远程字典服务）锁失效，数据库唯一约束和状态机也能兜底。”

9.3 ZSet（有序集合）延迟队列话术

“我在订单履约、面单拉取、轨迹推送里用过 Redis（远程字典服务）ZSet（有序集合）实现延迟队列。score（分数）放下次执行时间，member（成员）放任务 ID（标识）。消费者只取到期任务，通过 Lua（脚本语言）抢占，成功后执行业务。失败就按重试次数做阶梯延迟，超过最大次数进入异常状态，避免无限重试风暴。”

10. 高频面试题与追问

10.1 Redis（远程字典服务）为什么单线程还快？

因为 Redis（远程字典服务）主要在内存操作，命令执行很快；单线程避免锁竞争；I/O（输入输出）多路复用让单线程处理大量连接；数据结构高度优化。瓶颈通常是网络、大 key（键）、慢命令，而不是线程数。

10.2 Redis（远程字典服务）分布式锁为什么要设置过期时间？

如果客户端加锁后宕机，没有过期时间锁会永远不释放。PX（毫秒过期时间）是故障释放兜底，但过期时间太短会导致业务没执行完锁先释放，所以要结合 Redisson（Redis 客户端）看门狗或合理估算业务耗时。

10.3 为什么解锁要用 Lua（脚本语言）？

因为解锁需要“先判断 owner（持有者），再删除 key（键）”。如果分成 GET（获取）和 DEL（删除）两个命令，中间可能被其他线程加锁，导致误删。Lua（脚本语言）在 Redis（远程字典服务）中原子执行，可以避免这个问题。

10.4 RedLock（红锁）安全吗？

RedLock（红锁）通过多个独立 Redis（远程字典服务）主节点多数派加锁，提高单点故障下的安全性。但它依赖网络、时钟和超时假设，实现复杂，也有争议。实际业务里，如果是资金和库存，我更倾向于 Redis（远程字典服务）锁做并发控制，MySQL（关系型数据库）唯一约束、乐观锁、事务流水做最终兜底。

10.5 Redis（远程字典服务）集群下多 key（键）操作有什么限制？

Redis Cluster（Redis 集群）按 slot（槽）分片，多 key（键）操作要求 key（键）在同一个 slot（槽）。可以使用花括号标签让相关 key（键）落到同一 slot（槽），但要注意热点集中。

模块综合热门面试题补强

10.6 Redis（远程字典服务）为什么单线程还能高性能？

问题：Redis（远程字典服务）为什么单线程还能高性能？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.7 SDS（简单动态字符串）相比 C（编程语言）字符串有什么优势？

问题：SDS（简单动态字符串）相比 C（编程语言）字符串有什么优势？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.8 dict（哈希字典）如何渐进式 rehash（重新哈希）？

问题：dict（哈希字典）如何渐进式 rehash（重新哈希）？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.9 skiplist（跳表）为什么适合 ZSet（有序集合）？

问题：skiplist（跳表）为什么适合 ZSet（有序集合）？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.10 RDB（快照持久化）和 AOF（追加日志）怎么取舍？

问题：RDB（快照持久化）和 AOF（追加日志）怎么取舍？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.11 AOF（追加日志）重写会不会阻塞主线程？

问题：AOF（追加日志）重写会不会阻塞主线程？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.12 主从复制为什么可能丢锁？

问题：主从复制为什么可能丢锁？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.13 哨兵主观下线和客观下线有什么区别？

问题：哨兵主观下线和客观下线有什么区别？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.14 Redis Cluster（Redis 集群）MOVED（迁移中标记）和 ASK（临时重定向）有什么区别？

问题：Redis Cluster（Redis 集群）MOVED（迁移中标记）和 ASK（临时重定向）有什么区别？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.15 缓存穿透、击穿、雪崩分别怎么治理？

问题：缓存穿透、击穿、雪崩分别怎么治理？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.16 Cache Aside（旁路缓存）如何保证最终一致性？

问题：Cache Aside（旁路缓存）如何保证最终一致性？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.17 延迟双删有什么问题？

问题：延迟双删有什么问题？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.18 Redis（远程字典服务）事务为什么不支持回滚？

问题：Redis（远程字典服务）事务为什么不支持回滚？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.19 Pipeline（管道）和事务有什么区别？

问题：Pipeline（管道）和事务有什么区别？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.20 Stream（流）和 ZSet（有序集合）延迟队列怎么选？

问题：Stream（流）和 ZSet（有序集合）延迟队列怎么选？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.21 Redisson（Redis 客户端）看门狗如何续期？

问题：Redisson（Redis 客户端）看门狗如何续期？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.22 RedLock（红锁）的安全假设是什么？

问题：RedLock（红锁）的安全假设是什么？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.23 big key（大键）如何排查和拆分？

问题：big key（大键）如何排查和拆分？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.24 hot key（热键）如何治理？

问题：hot key（热键）如何治理？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

10.25 Redis（远程字典服务）锁如何与 MySQL（关系型数据库）幂等兜底？

问题：Redis（远程字典服务）锁如何与 MySQL（关系型数据库）幂等兜底？
考点：核心概念、底层机制、失败边界、项目落地。
回答思路：先给结论，再讲工作流程和关键取舍，最后结合库存防超卖、支付回调幂等、ZSet（有序集合）延迟队列说明线上怎么兜底。
进阶追问：如果出现并发冲突、数据不一致、性能下降或服务重启，你如何定位、恢复和复盘？

11. 本模块复习清单

能解释 Redis（远程字典服务）为什么快。
能说清 Redis（远程字典服务）单线程模型和 I/O（输入输出）多路复用。
能对比 String（字符串）、Hash（哈希）、List（列表接口）、Set（集合接口）、ZSet（有序集合）。
能讲 RDB（快照持久化）和 AOF（追加日志）的优缺点。
能画出主从复制、哨兵、集群架构。
能说明缓存穿透、击穿、雪崩及治理。
能完整讲 Redis（远程字典服务）分布式锁：SET NX PX（不存在才设置并带过期时间）、Lua（脚本语言）解锁、Redisson（Redis 客户端）看门狗、RedLock（红锁）。
能说明 Redis（远程字典服务）锁在主从切换时的风险。
能把 Redis（远程字典服务）锁、MySQL（关系型数据库）乐观锁、幂等流水组合成库存和支付方案。