第2章：Windows、WSL2 与 Docker 环境搭建Redis

1. 项目背景

1.1 业务场景

团队技术栈多样，运维老李的笔记本是 Ubuntu，后端开发小王是 Windows 11 + WSL2，测试张姐用的是公司配的 MacBook。上周小王照着网上的教程，直接下载了一个 Windows 版的 redis-server.exe，启动后发现版本是 5.0，但项目要求用 Redis 8.6 的 Stream 消费组和字段级过期能力。更糟的是，小王在 Windows 上能正常运行 BGSAVE（因为 Windows 版的 fork 实现不同），但同样的命令在 Linux 生产环境却因为内存过大导致 fork 失败。

张姐那边也有问题——她用 Docker 启动了 Redis，连上 RedisInsight 后发现看不到数据，排查了半天才发现 Docker 的网络模式让她从宿主机访问 localhost:6379 时走的是另一个网络命名空间。三个人折腾了一天，愣是没让环境统一起来。

1.2 痛点

环境不一致是实战学习中最大的阻力来源：

问题	表现	后果
Redis 版本不同	Windows 版只到 5.0，Linux 版到 8.6	Stream、ACL v2、字段级过期等新能力无法验证
配置不统一	有人用默认配置（无密码、无 AOF），有人改了但没记录	"我这里可以，你那里不行"
数据目录混乱	持久化文件散落各处	容器重启后数据丢失，无法复现持久化恢复流程
网络不通	宿主机、容器、WSL2 的网络栈不同	RedisInsight 连不上、redis-benchmark 报错
缺少可视化工具	只用 redis-cli 看文本输出	无法直观观察 key 分布、内存占用、慢查询趋势

1.3 本章目标

不只"装一个 Redis"，而是搭建一套可重复、可销毁、可扩展、接近生产的实验环境。这个环境将支撑后续所有章节的实战内容——从单机数据结构到 Sentinel 高可用、Cluster 集群、Prometheus 监控，全程不需要重新折腾环境。

具体交付物：

1. 一份 redis.conf 最小但合理的配置文件（带密码、AOF、数据目录）。
2. 一份 docker-compose.yml（Redis + RedisInsight 可视化工具）。
3. 掌握 redis-cli、redis-benchmark、redisinsight 的使用。
4. 一份环境故障排查清单（端口冲突、认证失败、挂载异常、网络不通）。

---

2. 项目设计

2.1 第一幕：为什么不用 Windows 原生版？

小胖："我以前学 Redis，直接官网下载一个 redis-server.exe，双击就启动了，多简单。为什么还要装 Docker？Docker Desktop 占好几 G 内存呢。"

小白："Windows 原生版的 Redis 是微软维护的 fork，最新版本只到 5.0.x。我们专栏要用的 Stream 消费组、ACL v2、字段级过期、Redis Functions、JSON 模块、Vector 检索，这些在 5.0 上全都没有。难道你打算每个新功能都去网上找'降级方案'吗？"

小胖："那 WSL2 呢？我听说 WSL2 可以直接用 Linux 版 Redis？"

大师："WSL2 确实可以用 Linux 版，但它和 Docker Desktop 之间是互补关系。我从三方面总结一下："

环境方案	Redis 版本	启动方式	文件系统	网络	适合谁
Windows 原生 .exe	最高 5.0	双击 exe	Windows 路径	Windows 网络栈	不推荐——版本和生产差距大
WSL2 直接安装	可装 8.x	apt install	WSL2 虚拟磁盘	WSL2 独立 IP	适合习惯 Linux 命令行、想深入系统层的同学
Docker Desktop (Windows)	任意版本	docker run	WSL2 后端	端口映射	专栏首选——版本可控、配置挂载、环境可销毁重建
Docker (WSL2 内)	任意版本	docker run	WSL2 内目录	端口映射到宿主机	进阶推荐——更接近生产体验

大师："就像去健身房。Windows 原生版是你家客厅的健身环——能出汗，但和专业器械完全不同。WSL2 是社区健身房——器械齐全，但你要自己带毛巾和水杯。Docker 是标准化的健身包——每次打开都是一套标准器械，坏了换一包就行。"

技术映射：Docker 通过镜像固定 Redis 版本，通过 Compose 固定启动参数、网络拓扑和数据卷。这是实现"开发/测试/生产环境一致性"最低成本的方式。

小胖："那听你的，用 Docker。但我有个小问题——Docker Desktop 和 WSL2 是啥关系？我装了 Docker Desktop 之后，好像自动装了一个 WSL2？"

大师："好问题。Docker Desktop for Windows 默认使用 WSL2 作为后端引擎。你在 Windows 上运行 docker run，实际是在 WSL2 的 Linux 内核里跑的。WSL2 里的 /var/lib/docker 存储镜像和容器数据，你在 Windows 上是看不到的——也别去手动动它。"

2.2 第二幕：学习环境需要配密码和 AOF 吗？

小胖："学习环境配密码不是给自己添麻烦吗？每次连 redis-cli 都要加 -a redis123。还有 AOF（Append Only File），我一台学习机，数据丢了就丢了呗。"

小白："我倒是觉得早点接触密码好。至少不会养成'Redis 无密码裸奔'的习惯。上次公司代码审查，我发现有人把 Redis 密码硬编码在前端配置文件里——因为他从学习阶段就觉得'密码可有可无'。"

大师："密码和 AOF 不是'生产才需要的东西'，而是'理解 Redis 边界的东西'。"

他画了一张对比图：

无密码的环境                            带密码的环境
┌─────────────────┐                   ┌─────────────────┐
│ redis-cli       │                   │ redis-cli        │
│    │            │                   │    │             │
│    │ 直接连接    │                   │    │ -a redis123 │
│    ▼            │                   │    ▼             │
│ Redis Server     │                   │ Redis Server     │
│ (无密码，无安全)  │                   │ (ACL 校验)       │
└─────────────────┘                   └─────────────────┘

无 AOF 的环境                            带 AOF 的环境
┌─────────────────┐                   ┌─────────────────┐
│ 重启 → 数据全丢  │                   │ 重启 → AOF 回放  │
│ "Redis 不稳？"   │                   │ 数据基本恢复     │
└─────────────────┘                   └─────────────────┘

大师："密码让你理解 Redis 的安全模型——它不是'内网就绝对安全'，你后面会学到 ACL 用户体系、TLS 加密、命令权限。AOF 让你理解 Redis 的持久化模型——不是'内存数据库就是临时数据'，Redis 可以选择性地持久化，不同场景用不同策略。"

技术映射：学习环境的配置应该向生产靠近，否则形成错误认知（"Redis 不要密码""Redis 重启数据就丢"）后很难纠正。

小白："那我追问一个问题——学习环境的数据挂载到宿主机，有什么坑吗？"

大师："三个关键点。第一，Windows 路径不能有中文、空格和特殊字符，否则 Docker Desktop 的 WSL2 后端可能无法正确挂载。第二，持久化文件（RDB、AOF）放在 /data 目录，不要在外部手动修改这些文件。第三，权限问题——某些 Docker 镜像的 Redis 以 redis 用户运行（UID 999），如果宿主机目录权限不对，Redis 可能无法写入 AOF 文件。"

2.3 第三幕：RedisInsight 到底有多大用？

小胖："redis-cli 不就能看所有数据吗？还要装一个 RedisInsight，又是浏览器又是界面，多麻烦。"

小白："redis-cli 看单个 key 还行，但你能一眼看出当前有多少 key、各类型分布、内存占用最大的 key 是哪个吗？如果要分析慢查询日志的趋势，redis-cli 只能一条一条 SLOWLOG GET。"

大师："RedisInsight 是 Redis 官方出的可视化管理工具。它不替代 redis-cli——redis-cli 是调试利器，RedisInsight 是全景地图。我给你列几个用 redis-cli 做不到或者很麻烦的事情："

操作	redis-cli	RedisInsight
发现大 key	需要 redis-cli --bigkeys 扫描	一键查看 key 大小排行，按类型筛选
分析慢查询	SLOWLOG GET 10 手动查看	图表展示慢查询趋势，支持筛选时间范围
内存分析	需要 MEMORY USAGE key 逐个查看	内存分布饼图，按命名空间聚合
批量操作	需要写脚本	可视化过滤、编辑、删除
实时监控	MONITOR 是一条条刷屏	图表展示 QPS、延迟、连接数

大师："学习阶段，RedisInsight 最大的价值是让你'看见' Redis 里面发生了什么。比如你写入 100 个购物车 key，它能用饼图展示 Hash 类型的占比；你设置了不同 TTL 的 key，它能直观显示哪些即将过期。"

技术映射：redis-cli 是"命令行显微镜"——精确但不直观；RedisInsight 是"运营仪表盘"——帮你快速发现问题，再决定去哪里放大观察。

---

3. 项目实战

3.1 准备项目目录

在实验目录（建议放在纯英文路径下）创建以下结构：

redis-lab/
├── docker-compose.yml    # 编排文件
├── redis.conf            # Redis 配置文件
├── data/                 # 持久化数据目录（RDB、AOF 文件）
└── README.md             # 环境说明（可选）

# PowerShell (Windows)
mkdir redis-lab
cd redis-lab
mkdir data
New-Item -ItemType File -Name docker-compose.yml
New-Item -ItemType File -Name redis.conf

3.2 编写 redis.conf

# === 网络配置 ===
bind 0.0.0.0
port 6379
protected-mode yes
timeout 300
tcp-keepalive 300

# === 安全配置 ===
requirepass redis123

# === 持久化配置 ===
# AOF
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# RDB
save 900 1
save 300 10
save 60 10000

# 数据目录
dir /data

# === 内存配置 ===
# 学习环境限制 512MB，生产需按实际规划
maxmemory 512mb
maxmemory-policy allkeys-lru

# === 慢查询日志 ===
slowlog-log-slower-than 10000
slowlog-max-len 128

# === 日志 ===
loglevel notice
logfile ""

# === 其他 ===
databases 16

关键配置解释：

配置项	值	说明
bind 0.0.0.0	绑定所有网卡	容器内使用，让宿主机能访问。生产环境应限制为内网 IP
protected-mode yes	启用保护模式	无密码时只允许本地连接。配合 requirepass 使用更安全
requirepass redis123	密码	学习环境用简单密码，生产必须用强密码且定期轮换
appendfsync everysec	每秒刷盘	性能和安全的折中——最多丢 1 秒数据
save 900 1	900 秒内至少 1 个 key 变化则触发 bgsave	RDB 自动触发条件
maxmemory 512mb	最大内存	容器无法获取宿主机的真实内存限制，手动指定避免 OOM
maxmemory-policy allkeys-lru	淘汰策略	内存满时淘汰最近最少使用的 key
slowlog-log-slower-than 10000	10 毫秒	超过此时长的命令记录到慢查询日志
loglevel notice	日志级别	学习环境用 notice，生产调试时可用 verbose
logfile ""	空字符串	输出到 stdout，方便 docker logs 查看

3.3 编写 docker-compose.yml

version: "3.8"

services:
  redis:
    image: redis:8.6
    container_name: redis-lab
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - ./redis.conf:/usr/local/etc/redis/redis.conf:ro
      - ./data:/data
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "redis123", "ping"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 10s
    networks:
      - redis-net

  redisinsight:
    image: redis/redisinsight:latest
    container_name: redisinsight-lab
    restart: unless-stopped
    ports:
      - "5540:5540"
    volumes:
      - ./redisinsight-data:/db
    networks:
      - redis-net

networks:
  redis-net:
    driver: bridge

编排说明：

配置	说明
restart: unless-stopped	容器异常退出时自动重启，除非手动 stop。学习环境防止误关后自动拉起
volumes 中的 :ro	redis.conf 以只读模式挂载，避免容器内误改
healthcheck	Docker 健康检查——每 10 秒发一次 PING，连接失败视为不健康
redisinsight-data 目录	RedisInsight 自己会管理连接配置，挂载到宿主机方便反复创建
networks	两个容器在同一网络中，RedisInsight 用 redis-lab:6379 即可连接

3.4 启动并验证环境

# 启动所有服务（后台运行）
docker compose up -d

# 查看容器状态
docker compose ps
# 期望输出:
# NAME                STATUS              PORTS
# redis-lab           Up (healthy)        0.0.0.0:6379->6379/tcp
# redisinsight-lab    Up                  0.0.0.0:5540->5540/tcp

# 查看 Redis 日志
docker logs redis-lab --tail 20

# 观察健康检查状态
docker inspect redis-lab --format='{{json .State.Health}}' | ConvertFrom-Json | Select-Object Status

3.5 使用 redis-cli 连接

带密码连接：

# 方式一：命令行指定密码
docker exec -it redis-lab redis-cli -a redis123

# 方式二：先进入再认证
docker exec -it redis-lab redis-cli
127.0.0.1:6379> AUTH redis123
OK

# 方式三：通过环境变量（redis-cli 6.0+ 支持 --pass 等价 -a）
docker exec -it redis-lab redis-cli --pass redis123

执行第一组验证命令：

127.0.0.1:6379> PING
PONG

127.0.0.1:6379> SET lab:env "docker-compose-v1"
OK

127.0.0.1:6379> GET lab:env
"docker-compose-v1"

# 验证 AOF 已开启
127.0.0.1:6379> CONFIG GET appendonly
1) "appendonly"
2) "yes"

# 验证 maxmemory 配置
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "536870912"    # 512 MB = 536870912 字节

# 验证数据目录
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/data"

3.6 测试持久化：数据在重启后是否还在

# 写入一些测试数据
docker exec redis-lab redis-cli -a redis123 SET check:restore "before-restart"
docker exec redis-lab redis-cli -a redis123 SET check:counter 42

# 重启容器
docker compose restart redis

# 等待 Redis 启动完成（healthcheck 通过）
Start-Sleep -Seconds 5

# 读取之前的数据
docker exec redis-lab redis-cli -a redis123 GET check:restore
# 期望输出: "before-restart"

docker exec redis-lab redis-cli -a redis123 GET check:counter
# 期望输出: "42"

如果返回 (nil)，说明 AOF 或 RDB 没有正确加载。检查日志：

docker logs redis-lab | Select-String -Pattern "DB loaded|AOF"

3.7 配置 RedisInsight

浏览器打开：http://localhost:5540

添加 Redis 数据库：

1. 点击 "Add Redis Database"。
2. 填写连接信息：

• Host：redis-lab（容器间通信使用 Compose 的 service name）
• Port：6379
• Database Alias：本地学习环境
• Username：留空（暂未配置 ACL 多用户）
• Password：redis123

3. 点击 "Test Connection"，确认连接成功。
4. 点击 "Add Redis Database"。

也可以在宿主机上使用不同方式连接：

连接来源	Host	说明
RedisInsight 容器内	redis-lab	Docker 内部 DNS 解析 service name
宿主机浏览器 (RedisInsight UI)	host.docker.internal 或 localhost	取决于 RedisInsight 是连接宿主机端口还是内部网络

推荐把 RedisInsight 和 Redis 放在同一个 Compose 网络中（本章就是这么做），这样 RedisInsight 直接通过 service name redis-lab:6379 连接，不走宿主机端口映射。

连接成功后，在 RedisInsight 中浏览：

• Browser：查看和搜索 key，支持按类型筛选。
• CLI：内置命令行，支持命令补全。
• Analysis → Memory Analyzer：查看内存使用分布。
• Analysis → Slow Log：查看慢查询记录和趋势。

3.8 使用 redis-benchmark 基础压测

# 在容器内执行压测
docker exec -it redis-lab redis-benchmark -a redis123 -n 100000 -c 50 -t get,set -q

# 输出示例：
# SET: 82345.67 requests per second, p50=0.247 msec
# GET: 86956.52 requests per second, p50=0.233 msec

# 测试不同并发数下的表现
docker exec -it redis-lab redis-benchmark -a redis123 -n 100000 -c 10 -t get -q
docker exec -it redis-lab redis-benchmark -a redis123 -n 100000 -c 100 -t get -q
docker exec -it redis-lab redis-benchmark -a redis123 -n 100000 -c 200 -t get -q

# 带延迟分位数的压测
docker exec -it redis-lab redis-benchmark -a redis123 -n 100000 -c 50 --csv

预期现象：

• 低并发时（10-50），P50 延迟通常在 0.2-0.3ms。
• 高并发时（200+），延迟略微增加，主要瓶颈在客户端并发模型而非 Redis 本身。
• 如果 QPS 远低于预期（例如只有几万），检查是否在虚拟机中运行，或宿主机 CPU 资源不足。

3.9 常见坑与解决

坑1：端口冲突

# 现象
Error starting userland proxy: listen tcp4 0.0.0.0:6379: bind: address already in use

# 诊断
netstat -ano | findstr :6379
# 或
Get-NetTCPConnection -LocalPort 6379

# 解决方式一：停止占用端口的进程
taskkill /PID <PID> /F

# 解决方式二：修改 docker-compose.yml 端口映射
ports:
  - "6380:6379"   # 宿主机 6380 → 容器 6379

坑2：认证失败

# 现象
127.0.0.1:6379> GET foo
(error) NOAUTH Authentication required.

# 原因：连接时未提供密码
# 解决：AUTH redis123

# 现象
127.0.0.1:6379> AUTH wrongpassword
(error) WRONGPASS invalid username-password pair or user is disabled.

# 原因：密码不匹配
# 解决：检查 redis.conf 中 requirepass 的值

坑3：数据卷挂载失败

# 检查挂载是否生效
docker inspect redis-lab --format='{{json .Mounts}}' | ConvertFrom-Json

# 预期输出包含：
# "Source": "/host_mnt/d/your/path/redis-lab/data"
# "Destination": "/data"

# 如果 Mounts 为空或路径不对，检查：
# 1. docker-compose.yml 中是否使用了相对路径（相对于 compose 文件所在目录）
# 2. Windows 路径中是否有中文或特殊字符
# 3. Docker Desktop 的 Resources → File Sharing 是否包含实验目录

坑4：容器内 AOF 写权限问题

# 现象：Redis 启动后日志显示
# Can't open the append-only file: Permission denied

# 诊断
docker exec redis-lab ls -la /data

# 如果输出为空目录或权限显示 nobody:
# 原因：Redis 容器内以 redis 用户（UID 999）运行，宿主机 data/ 目录权限不足

# 解决：给 data 目录开放写权限（Windows 上通常不需要额外处理）
# 如果问题持续，可以尝试删除 data 目录后重新创建
Remove-Item -Recurse -Force .\data
mkdir data
docker compose down && docker compose up -d

坑5：RedisInsight 连不上 Redis

常见原因排查：
1. Redis 是否在运行：docker compose ps
2. RedisInsight 的 Host 写对了吗：
   - 如果 RedisInsight 和 Redis 在同一个 docker-compose 网络 → Host 填 redis-lab
   - 如果从宿主机浏览器通过端口映射访问 → Host 填 localhost 或 宿主机 IP
3. 密码是否匹配 redis.conf 中的 requirepass
4. 防火墙是否拦截了 5540 或 6379 端口

坑6：WSL2 内存占用过高

Docker Desktop 基于 WSL2，WSL2 默认会占用较多内存。可以限制：

在用户目录 C:\Users\<用户名>\.wslconfig 创建文件：

[wsl2]
memory=4GB
processors=2
swap=2GB

然后重启 WSL：

wsl --shutdown

3.10 环境清理与重建

当你需要"从头开始"时（比如实验把数据搞乱了）：

# 停止并删除容器（数据卷保留）
docker compose down

# 停止并删除容器 + 数据卷（彻底重置）
docker compose down -v

# 清理持久化数据
Remove-Item -Recurse -Force .\data\*
mkdir data

# 重新启动
docker compose up -d

---

4. 项目总结

4.1 交付物检查清单

交付物	验证方式
docker-compose.yml 可正常启动	docker compose up -d → docker compose ps 显示 healthy
redis.conf 密码生效	redis-cli 无密码连接报 NOAUTH
AOF 持久化生效	CONFIG GET appendonly 返回 yes，/data/ 下有 appendonly.aof 文件
重启后数据保留	写入 key → docker compose restart → 读取 key 成功
RedisInsight 可连接	浏览器 http://localhost:5540 ，添加数据库连接成功
redis-benchmark 可运行	输出 QPS 和延迟分位数

4.2 优点与缺点

方案特点	详细说明
优点1：版本可控	镜像 redis:8.6 固定版本，团队所有人启动后获得完全相同的 Redis 环境和能力
优点2：配置透明	redis.conf 集中管理所有配置，修改一处立即生效，方便团队 Code Review
优点3：可销毁重建	实验环境玩坏了不需要手动修复，docker compose down -v && docker compose up -d 即可恢复
优点4：可视化加持	RedisInsight 让学习者直观看见内存分布、key 类型和慢查询趋势
优点5：扩展方便	后续加 Sentinel、Cluster、Prometheus 只需在 compose 文件加 service
缺点1：Docker Desktop 较重	占用磁盘和内存，但对学习来说利大于弊
缺点2：网络模型有差异	Docker 的网络抽象增加了一层复杂度，连接方式需要理解容器网络
缺点3：性能受限	容器内的 Redis 性能略低于裸金属（但学习场景完全够用）
缺点4：WSL2 需要单独配置	内存和处理器限制需手动配置，否则可能占用过多资源

4.3 适用与不适用场景

适用场景：

1. 本地学习和实验——后续 40 章全部基于此环境。
2. 团队新成员培训——一份 compose 文件交给新人，10 分钟启动。
3. 功能验证——需要快速验证某个命令或配置的效果。
4. 故障演练——可以放心地制造崩溃、配置错误等场景。
5. 中小规模 Demo 开发——作为临时 Redis 依赖。

不适用场景：

1. 生产部署——需要 ACL、TLS、监控、备份、资源限制和高可用架构（将在第 29-31 章展开）。
2. 高并发压测——容器网络和资源限制会影响真实 QPS，压测应在裸金属或 K8s 中进行。
3. 需要直连 Windows 进程的场景——如果你的应用是 Windows 原生进程且不方便改网络配置，可能需要在 WSL2 中运行应用。

4.4 常见踩坑经验

案例	表象	根因	解法
团队新人启动失败	docker compose up 报错 "port already in use"	本地已安装 MySQL 占用 6379 端口	修改 compose 端口映射为 6380:6379，环境文档注明
AOF 文件把宿主机 C 盘写满	电脑变卡，发现 data/ 目录下 AOF 文件超过 5GB	开启了 appendonly 但没有配置 rewrite 阈值，学习环境的压测数据被全部记录	添加 auto-aof-rewrite-min-size 配置，定期清理 data 目录
RedisIninsight 连不上	页面 "Connection refused"	把 Host 写成 localhost，但 RedisInsight 在容器内，localhost 指向自己	Host 使用 Compose service name redis-lab
Windows 路径中文导致挂载失败	容器内 /data 为空	Docker Desktop 对包含中文的路径处理有 bug	把实验目录移到纯英文路径下，如 D:\projects\redis-lab
WSL2 内存占用过高	任务管理器显示 vmmem 进程占用 8GB	WSL2 默认不限制内存，Docker 未使用的内存也不会释放给宿主机	创建 .wslconfig 限制内存和处理器数量

4.5 思考题

1. 环境题：如果有一天你需要把本章的 Docker Compose 环境从 Windows 迁移到 Linux 生产服务器，docker-compose.yml 和 redis.conf 中分别需要修改哪些配置？请至少列出 5 项。

2. 故障题：你在本地执行 docker compose up -d 后，docker compose ps 显示 redis-lab 状态是 Up (unhealthy)。请列出从最快到最深的排查步骤（至少 4 步），最终定位根因并修复。

（答案提示将在下一章末尾给出。）

上一章思考题答案提示（第1章）：

第1题：key 格式建议为 sms:daily:{userId}:{date}，如 sms:daily:1001:20260718。写入时执行 INCR sms:daily:1001:20260718，如果是首次递增则配合 EXPIRE 设置到当天 23:59:59 的剩余秒数。过期策略：计算距离当天结束的剩余秒数作为 TTL，确保 key 在跨天后自动清除。

第2题（至少 5 种根因）：① 上游服务调用量骤降（业务侧问题）；② 网络故障导致客户端无法连接到 Redis（但 connected_clients 显示旧连接未断开）；③ 客户端连接池耗尽，新请求在客户端排队但未到达 Redis；④ Redis 主线程被慢命令阻塞（需看 slowlog）；⑤ 客户端连接未减少但都处于 IDLE 状态——优先排查慢查询日志和延迟监控。

下一章预告：第3章——字符串 String 实战：验证码、计数器与分布式开关。

延伸阅读与资源

Redis 8 实战精讲：从 CRUD 到源码，构建高可用缓存系统
Java 工程师进阶：从 JVM 生产排障到OpenJDK原理
MySQL Server 9从入门到进阶的实战之旅
Nacos 3.x 注册配置中心实战修炼：从入门到源码扩展
Elasticsearch从入门到进阶的实战之旅
RabbitMQ从入门到进阶的实战之旅：从单机到大促高可用架构
Celery 入门到进阶之路：从异步任务到自研调度平台
LangGraph 生产级实战进阶：从零到生产级Agent工作流开发
Dify 从入门到源码：LLM 应用平台实战修炼
从零到生产级：FastAPI 异步高并发、源码与 SRE 实战
实战SQLAlchemy 2.0： 从 CRUD 到生产级架构
从零打造企业级 AI 助手：LangChain RAG、Agent 与生产实战
后端工程师 AI 转型课：Ollama 私有化大模型从入门到生产
MongoDB 实战进阶与内核修炼
NumPy 从入门到生产落地：全链路实战指南（科学计算/向量化/性能调优）
Milvus向量数据库实战修炼：从 0 到 1 精通向量检索与生产落地
Python 3实战精进：从脚本到高并发订单引擎
python入门：Rquests从菜鸟脚本到企业级SDK的网络实战圣经