WangQuan's Blog

Appearance

Redis 工程实践与常见问题 ​

这篇笔记专门整理 Redis 在真实工程里最容易被忽略、但一旦出问题就很难看的那部分内容：线程模型、事务与 Lua、Pipeline、分布式锁、BigKey、HotKey 等。

这些内容的共同特点是：它们往往不是入门时最先学到的，但却决定了 Redis 能不能在高并发系统里稳定运行。

1. 🌟 Redis 的执行模型应该怎么理解 ​

很多人会把 Redis 直接记成“单线程”，但更实用的理解是：

  1. Redis 的核心命令执行路径长期以单线程为主
  2. 这样可以让共享状态处理更简单，减少锁竞争
  3. 它的性能优势并不只来自“单线程”，而是内存、数据结构和事件模型一起作用

这里“单线程”最容易被误解的地方是：它主要描述的是命令处理主路径，不是说 Redis 进程里永远只有一个线程在做所有事情。

对工程理解来说，真正重要的是：

  1. 很多命令不会并行改同一份内存状态
  2. 单条命令一旦执行得很慢，后面的请求就得排队
  3. 所以 Redis 更怕“大而重”的操作，而不是普通的小命令很多

为什么这个理解重要？

因为一旦只把 Redis 简化成“单线程，所以快”，就容易忽略：

  1. 慢命令会阻塞后续请求
  2. 大 Key 操作会放大单线程执行成本
  3. 网络和序列化也会影响整体延迟

所以 Redis 的命令执行模型虽然简单，但对命令粒度和数据规模的要求更高。

1.1 一条 Redis 请求在服务端通常怎么走 ​

如果只记“单线程”，其实还不太够，因为它没有把请求链路的画面感建立起来。

可以把一次典型请求理解成下面这条路径：

mermaid
flowchart LR
    A[客户端发起命令] --> B[Socket 连接到达 Redis]
    B --> C[I/O 多路复用发现连接可读]
    C --> D[读取并解析命令]
    D --> E[根据 key 找到对应数据结构]
    E --> F[执行命令逻辑]
    F --> G[把结果写回客户端]

这条链路的重点不是“步骤有多少”，而是：

  1. 很多步骤都很短
  2. 中间通常不需要复杂锁协调
  3. 如果操作的数据就在内存里，访问路径会很直接

所以 Redis 的快，更适合理解成：它把高频请求的处理链路压得很短。

1.2 I/O 多路复用 在这里到底解决什么问题 ​

很多人看到这几个字会觉得抽象，可以把它理解成：Redis 不需要给每个连接都单独开一个线程，而是用较少的线程同时盯住很多连接。

它解决的核心问题是：

  1. 连接很多时，线程数量不至于跟着无限膨胀
  2. 某个连接没数据时，不需要一直空等它
  3. 有数据的连接可以更快进入处理路径

所以它带来的价值不是“直接替命令提速”，而是：让 Redis 能以更低的调度成本承接大量短连接或高频请求。

1.3 为什么慢命令会把后续请求一起拖住 ​

这也是理解 Redis 执行模型时必须建立的直觉。

因为核心命令执行路径比较集中，所以只要某条命令特别重，后面的请求就得等它先走完。

典型场景包括：

  1. 一次处理特别大的 Key
  2. 做很重的范围扫描
  3. 返回数据量特别大
  4. Lua 脚本里塞了过多逻辑

这时真正的问题不只是“这条命令自己慢”，而是：它会占住 Redis 当前的处理窗口，让后面的很多小请求也一起排队。

所以工程上真正该警惕的，不是普通小命令很多，而是：

  1. 单次命令太重
  2. 单次返回太大
  3. 单次处理的数据规模失控

1.4 从执行模型角度看，Redis 为什么快、又为什么会慢 ​

把前面这些压缩成一句话，就是：

  1. Redis 快，是因为很多请求路径短、内存访问直接、调度模型简单
  2. Redis 慢，往往不是因为“并发太高”本身，而是因为某些命令把单次执行成本拉长了

所以在工程里，真正重要的不是只记住：Redis 是单线程。

而是继续往下理解：Redis 擅长处理大量短、轻、快的命令；一旦命令变大、变重、变慢，整个后续队列都会一起受影响。

2. Pipeline、事务、Lua 各自解决的是什么问题 ​

这三类能力非常容易被混在一起，但它们解决的其实不是同一个问题。

2.1 Pipeline ​

Pipeline 的重点是：减少多次往返带来的网络开销。

它更偏性能优化，不等于事务。

更具体地说，Pipeline 是把多条命令一次性发出去，让客户端少走很多次网络来回。

它解决的是：

  1. 每条命令都单独发，网络往返成本太高
  2. 批量小操作很多时，延迟被 RTT 放大

但它不解决：

  1. 多条命令必须一起成功或一起失败
  2. 多步逻辑天然原子执行

2.2 事务 ​

Redis 事务通常更适合理解成：

  1. 一组命令按顺序提交执行
  2. 通过 MULTI / EXEC 组织命令

它和关系型数据库事务不是同一个模型，不能直接套用 ACID 的完整期待。

放到执行模型里看，Redis 事务更像：把一批命令打包排队，然后按顺序交给 Redis 执行。

它的重点是“成组提交”，不是关系型数据库那种强隔离、可回滚的复杂事务语义。

2.3 Lua ​

Lua 脚本最重要的价值是：把多步操作放到服务端原子执行，减少竞态窗口。

很多需要“读 -> 判断 -> 写”连在一起完成的逻辑，用 Lua 脚本会比客户端多次发命令更稳。

所以这三者可以这样区分：

  1. Pipeline 解决的是网络往返成本
  2. 事务解决的是一批命令的有序提交
  3. Lua 解决的是多步逻辑在服务端一次执行

3. 🌟 为什么分布式锁不能只停留在 setnx ​

Redis 分布式锁最容易被过度简化成一句：

  1. setnx
  2. 成功就是加锁

这里的核心误区是把“拿到一个 Key”直接等同于“拿到一把可靠的锁”。

setnx 的字面意思只是“当 Key 不存在时才设置成功”，它只能说明：

  1. 当前这个 Key 之前还没人占用
  2. 这一刻你把它抢到了

但锁在工程上还隐含着更多语义：

  1. 这把锁多久自动失效
  2. 谁持有这把锁
  3. 释放时会不会删掉别人的锁
  4. 持锁任务超时了怎么办

但真正要把它做稳，至少要考虑这些问题：

  1. 加锁是否原子
  2. 是否设置了过期时间，防止死锁
  3. 是否写入唯一标识，避免误删别人的锁
  4. 解锁是否安全
  5. 业务执行时间超过锁超时时间怎么办

所以一个更稳妥的分布式锁实现，重点通常包括：

  1. 原子加锁
  2. 唯一标识
  3. 原子校验后释放
  4. 结合业务时长设计锁续期或超时策略

更常见的工程写法会用类似 SET key value NX EX seconds 这样的方式一次性完成“只有不存在才能加锁”和“顺便设置过期时间”，而不是把 setnx 和 expire 拆成两步。

Redis 可以做轻量级分布式锁，但它不是“写一条命令就结束”的能力。

4. 🌟 BigKey 和 HotKey 为什么必须治理 ​

4.1 BigKey ​

BigKey 指的是体量特别大的 Key，例如：

  1. 一个特别大的字符串
  2. 一个成员极多的集合
  3. 一个字段特别多的 Hash

这里的“大”，不是只看 Key 名字长不长，而是看这个 Key 对应的 value 或内部成员规模是不是已经大到会明显拖慢读写、删除、迁移。

它带来的问题通常包括：

  1. 单次操作耗时变长
  2. 阻塞事件循环
  3. 网络传输和序列化成本放大
  4. 删除或迁移时造成抖动

4.2 HotKey ​

HotKey 指的是访问特别集中的 Key。

这里的“热”不是指这个 Key 本身多大，而是：大量请求在短时间内反复打到同一个 Key 上。

它带来的问题通常包括：

  1. 单点流量过高
  2. 某个节点压力异常集中
  3. 一旦失效就触发大规模回源

4.3 典型治理思路 ​

  1. 拆分大 Key
  2. 控制 Value 大小
  3. 对热点数据做多级缓存
  4. 对超热点 Key 做预热、限流和异步刷新

所以 BigKey 和 HotKey 虽然经常一起出现，但本质不是一回事：

  1. BigKey 主要是“单次操作太重”
  2. HotKey 主要是“同一个点位流量太集中”
  3. 一个 Key 甚至可能既大又热，这时问题会被放得更明显

5. 慢查询和阻塞问题经常从哪里来 ​

Redis 虽然快，但一旦出现慢查询，根因通常很集中：

  1. 一次处理的数据量太大
  2. 大范围扫描或聚合操作过重
  3. BigKey 操作成本过高
  4. Lua 脚本逻辑过重
  5. 网络往返或批量传输过大

这里的“慢查询”在 Redis 里不要只按数据库里那种 SQL 视角理解。

更贴近排障场景的说法是：某条 Redis 命令虽然最终执行成功了，但单次执行时间已经长到足以拖慢后续请求。

所以排查 Redis 卡顿时，更值得看的是：是不是有某些命令把单次执行时间拉长了。

这也是为什么 Redis 设计里经常强调：

  1. 避免大 Key
  2. 控制单次操作规模
  3. 避免阻塞式重操作

6. Pub/Sub、延迟队列、Stream 的边界怎么理解 ​

Redis 可以承担一些轻量消息能力，但不同能力的边界并不一样。

6.1 Pub/Sub ​

更适合：

  1. 实时通知
  2. 轻量广播

它不适合承担强可靠消息系统的全部职责。

因为 Pub/Sub 的语义更接近：我现在发出去，正在订阅的人就收到；当时不在线或没接住的人，通常不会帮你长期兜底保存。

6.2 延迟队列基础实现 ​

常见会借助：

  1. ZSet
  2. 时间戳作为 score

适合轻量延迟任务，但如果任务规模、可靠性和重试治理要求很高，就需要更专业的调度系统。

它的含义可以理解成：

  1. 把任务按“应该执行的时间”排好序
  2. 消费端不断扫描“已经到点”的任务
  3. 到点后再把它们取出来执行

6.3 Stream ​

Stream 更适合：

  1. 消息流
  2. 消费组
  3. Redis 内部轻量消息处理

它比 Pub/Sub 更适合保留消息和做消费协作，但也不是所有消息场景的统一答案。

如果把三者压成一句话来记：

  1. Pub/Sub 更像实时广播
  2. ZSet 延迟队列更像按时间排队
  3. Stream 更像 Redis 提供的一套轻量消息流模型

7. 一份实用的工程检查清单 ​

可以优先检查这些问题：

  1. 是否存在 BigKey 或 HotKey
  2. 是否有耗时很长的单次命令
  3. 分布式锁是否考虑了唯一标识和安全释放
  4. Pipeline、事务、Lua 是否用在各自合适的位置
  5. Pub/Sub、Stream、延迟队列是否在合理边界内使用
  6. 是否把 Redis 的轻量能力误当成重型中间件替代方案

Redis 工程实践最重要的，不是多会几条命令，而是知道哪些问题一旦规模上来会先出故障。

基于 VitePress 构建的个人技术笔记。

Copyright © 2026 WangQuan's Blog