第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 监控，全程不需要重新折腾环境。

具体交付物：

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

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 边界的东西'。"

他画了一张对比图：

arduino 复制代码

无密码的环境                            带密码的环境
┌─────────────────┐                   ┌─────────────────┐
│ 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 准备项目目录

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

text 复制代码

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

bash 复制代码

# 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

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

yaml 复制代码

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 启动并验证环境

bash 复制代码

# 启动所有服务（后台运行）
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 连接

带密码连接：

bash 复制代码

# 方式一：命令行指定密码
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

执行第一组验证命令：

bash 复制代码

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 测试持久化：数据在重启后是否还在

bash 复制代码

# 写入一些测试数据
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 没有正确加载。检查日志：

bash 复制代码

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

3.7 配置 RedisInsight

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

添加 Redis 数据库：

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

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

点击 "Test Connection"，确认连接成功。
点击 "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 基础压测

bash 复制代码

# 在容器内执行压测
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：端口冲突

bash 复制代码

# 现象
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：认证失败

ruby 复制代码

# 现象
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：数据卷挂载失败

bash 复制代码

# 检查挂载是否生效
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 写权限问题

bash 复制代码

# 现象：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

markdown 复制代码

常见原因排查：
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 创建文件：

ini 复制代码

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

然后重启 WSL：

bash 复制代码

wsl --shutdown

3.10 环境清理与重建

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

bash 复制代码

# 停止并删除容器（数据卷保留）
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 适用与不适用场景

适用场景：

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

不适用场景：

生产部署------需要 ACL、TLS、监控、备份、资源限制和高可用架构（将在第 29-31 章展开）。
高并发压测------容器网络和资源限制会影响真实 QPS，压测应在裸金属或 K8s 中进行。
需要直连 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 思考题

环境题 ：如果有一天你需要把本章的 Docker Compose 环境从 Windows 迁移到 Linux 生产服务器，docker-compose.yml 和 redis.conf 中分别需要修改哪些配置？请至少列出 5 项。
故障题 ：你在本地执行 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 到源码，构建高可用缓存系统