4. Redis 缓存入门：核心数据结构、Docker 部署与持久化机制

Redis 是后端缓存一致性的核心组件。本章从数据结构、Docker 部署、持久化三个维度建立 Redis 操作基础，为后续缓存同步调试提供可复现的实验环境。

4.1 Redis 核心数据结构与适用场景

Redis 提供 5 种基本数据类型，每种对应不同的缓存模式。下表列出核心操作命令与典型用例：

数据类型 底层编码 核心命令 典型场景
String int / embstr / raw SET / GET / INCR / DECR 计数器、分布式锁、Session 缓存
Hash ziplist / hashtable HSET / HGET / HGETALL / HINCRBY 对象缓存（用户信息、商品详情）
List quicklist LPUSH / RPUSH / LPOP / BRPOP 消息队列、时间线、最新列表
Set intset / hashtable SADD / SREM / SMEMBERS / SINTER 标签系统、好友关系、去重
Sorted Set ziplist / skiplist ZADD / ZRANGE / ZREVRANK / ZINCRBY 排行榜、延时队列、限流滑动窗口
选型建议： 缓存单个值用 String；缓存结构化对象用 Hash；需要排序或范围查询用 Sorted Set；需要集合运算用 Set；需要 FIFO 或阻塞消费用 List。

4.2 Docker 部署单机 Redis

使用 Docker 快速搭建可复现的 Redis 实验环境，避免宿主机污染。以下步骤适用于后续所有缓存同步调试场景。

4.2.1 拉取镜像与启动容器

# 拉取指定版本（推荐 7.0+）
docker pull redis:7.0-alpine

# 启动单机 Redis，暴露 6379 端口
docker run -d \
  --name redis-single \
  -p 6379:6379 \
  redis:7.0-alpine \
  redis-server --appendonly yes

4.2.2 验证连接与基本操作

# 进入容器交互式客户端
docker exec -it redis-single redis-cli

# 测试写入与读取
127.0.0.1:6379> SET cache:user:1001 "{\"name\":\"Alice\"}"
OK
127.0.0.1:6379> GET cache:user:1001
"{\"name\":\"Alice\"}"
127.0.0.1:6379> TYPE cache:user:1001
string

4.2.3 持久化配置挂载

生产环境需将数据目录与配置文件挂载到宿主机：

docker run -d \
  --name redis-persist \
  -p 6379:6379 \
  -v /data/redis:/data \
  -v /etc/redis/redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7.0-alpine \
  redis-server /usr/local/etc/redis/redis.conf
注意： 容器删除后数据会丢失。必须挂载 /data 卷或启用持久化机制，否则缓存恢复测试将无法复现。

4.3 Redis 持久化机制：RDB 与 AOF

Redis 提供两种持久化方式，理解其差异是缓存一致性调试的前提——持久化策略直接影响故障恢复后的缓存状态。

4.3.1 RDB（快照）

RDB 在指定时间间隔生成全量二进制快照，适合备份与快速重启。触发方式包括：

  • 手动触发： SAVE（同步阻塞） / BGSAVE（异步 fork）
  • 自动触发： 配置 save <seconds> <changes> 条件
  • 关闭时触发： 配置 stop-writes-on-bgsave-error yes
# redis.conf 示例：60 秒内至少 1000 次写入则触发 BGSAVE
save 60 1000
save 300 100
save 3600 1
dbfilename dump.rdb
dir /data

4.3.2 AOF（追加文件）

AOF 记录每次写操作指令，通过回放实现数据恢复，数据安全性更高。三种 fsync 策略对比：

策略 配置值 数据安全性 性能影响 最多丢失数据
每秒同步 appendfsync everysec 高 中等 1 秒写操作
每次写入同步 appendfsync always 极高 低（约 30% 性能损失） 1 次写操作
由操作系统决定 appendfsync no 低 最高 30 秒以上写操作 
# redis.conf 启用 AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

4.3.3 RDB vs AOF 对比

维度 RDB AOF
文件大小 小（二进制压缩） 大（文本协议）
恢复速度 快（直接加载） 慢（逐条回放）
数据丢失风险 较高（快照间隔） 低（取决于 fsync 策略）
对写性能影响 低（fork 子进程） 中等（追加写入）
可读性 不可读 可读（纯文本指令）
适用场景 备份、冷启动、灾备 数据安全优先、实时恢复
生产建议： 同时开启 RDB + AOF。RDB 用于快速重启与备份，AOF 用于最小化数据丢失。Redis 重启时优先加载 AOF（数据更完整）。

4.4 持久化流程与数据恢复路径

下图展示 Redis 持久化写入与恢复的完整链路，帮助理解缓存数据在磁盘与内存之间的流转：

Redis 持久化流程与恢复路径 Redis 持久化流程与恢复路径 客户端 写命令 Redis 内存 BGSAVE / 定时快照 dump.rdb 追加写入 AOF 缓冲区 fsync 刷盘 appendonly.aof 重启加载：AOF 优先 → RDB 兜底 恢复回内存 说明：写命令同时进入内存与 AOF 缓冲区；BGSAVE 异步生成 RDB 快照；重启时优先加载 AOF 文件

4.5 混合持久化与最佳实践

Redis 4.0+ 支持混合持久化（aof-use-rdb-preamble yes），AOF 文件头部包含 RDB 快照，后续追加增量 AOF 日志。这种方式结合了 RDB 的快速恢复与 AOF 的低数据丢失优势。

# 启用混合持久化
aof-use-rdb-preamble yes

# 查看持久化状态
127.0.0.1:6379> INFO persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1710000000
aof_enabled:1
aof_rewrite_in_progress:0
aof_last_rewrite_time_sec:-1
调试建议： 在后续缓存同步实验中，建议同时开启 RDB + AOF（everysec），并定期执行 BGREWRITEAOF 压缩 AOF 文件。这能保证容器重启后缓存状态可追溯，便于排查一致性偏差。
← 上一章 📖 返回目录 下一章 →