2. Redis 基础回顾：核心数据结构、持久化机制、主从复制原理
在深入中间件通信故障排查之前，必须牢固掌握 Redis 的三大基石：数据结构决定了缓存与任务的表达方式；持久化决定了故障恢复时的数据完整性；主从复制决定了系统的高可用与读写分离能力。本节将逐一拆解这些核心概念，为后续的故障场景分析打下基础。
2.1 核心数据结构
Redis 提供了 5 种基本数据结构，每种都有独特的底层编码和适用场景。在异步任务编排中，List 常用于任务队列，Sorted Set 用于延迟任务调度，Hash 用于存储任务元数据。
| 数据结构 | 底层编码（Redis 6/7） | 典型命令 | 异步任务编排中的用途 |
|---|---|---|---|
| String | int / embstr / raw | SET GET INCR |
计数器、分布式锁、任务状态标记 |
| List | quicklist（ziplist + linkedlist） | LPUSH BRPOP LLEN |
先进先出任务队列、消息缓冲 |
| Hash | listpack / hashtable | HSET HGET HGETALL |
任务详情、配置项、元数据存储 |
| Set | intset / hashtable | SADD SMEMBERS SISMEMBER |
去重集合、任务标签、白名单 |
| Sorted Set | listpack / skiplist | ZADD ZRANGEBYSCORE ZREM |
延迟队列、优先级调度、定时任务 |
排查要点：当任务队列出现阻塞或数据不一致时，优先检查 List 的
BLPOP 超时设置，以及 Sorted Set 的 score 精度是否满足毫秒级调度需求。
2.2 持久化机制
Redis 提供两种持久化方式：RDB（快照）和 AOF（追加文件）。在中间件通信故障场景中，持久化策略直接影响数据丢失窗口和恢复速度。
2.2.1 RDB 快照
- 触发方式：手动
SAVE/BGSAVE，或自动根据配置save m n（m 秒内 n 次修改）。 - 优点：文件紧凑，恢复速度快，适合全量备份。
- 缺点：可能丢失最后一次快照后的所有数据；
BGSAVE时 fork 子进程可能造成短暂阻塞。
2.2.2 AOF 追加文件
- 写回策略：
always（每次写操作都 fsync）、everysec（每秒 fsync）、no（由操作系统决定）。 - 优点：数据安全性高，最多丢失 1 秒数据（everysec 策略）。
- 缺点：文件体积大，恢复速度慢；AOF 重写期间可能消耗大量 CPU 和内存。
| 对比维度 | RDB | AOF |
|---|---|---|
| 数据完整性 | 低（可能丢失大量数据） | 高（最多丢失 1 秒数据） |
| 恢复速度 | 快 | 慢 |
| 文件大小 | 紧凑 | 较大 |
| 对性能影响 | fork 时可能阻塞 | 写回策略影响写入性能 |
| 故障排查价值 | 可快速恢复全量缓存 | 可回放操作日志定位问题 |
故障场景提示：如果 Redis 主节点宕机后重启，且只开启了 RDB，那么所有未落盘的异步任务数据将永久丢失。生产环境建议同时开启 RDB + AOF（everysec），并配置合理的自动触发条件。
2.3 主从复制原理
主从复制是 Redis 高可用的基础。在异步任务编排中间件中，主节点负责写入任务，从节点负责读取任务状态或承担读流量。理解复制流程是排查数据不一致、延迟同步等故障的前提。
2.3.1 复制流程（全量同步 + 增量同步）
- 从节点发起连接：从节点向主节点发送
PSYNC命令，携带 runid 和 offset。 - 主节点判断：如果从节点是首次连接或复制积压缓冲区中已无所需数据，则触发全量同步。
- 全量同步：主节点执行
BGSAVE生成 RDB 快照，同时将新写入命令缓存到复制积压缓冲区。RDB 传输给从节点后，从节点加载快照。 - 增量同步：主节点将缓冲区中的增量命令持续发送给从节点，从节点执行这些命令以保持数据一致。
- 长连接维护：主从之间保持 TCP 长连接，主节点定期发送
PING检测从节点存活。
2.3.2 常见复制故障与排查方向
| 故障现象 | 可能原因 | 排查命令 / 方法 |
|---|---|---|
| 主从数据不一致 | 网络延迟、从节点写入被阻塞、主从时钟不同步 | INFO replication 查看 offset 差距；DEBUG sleep 测试延迟 |
| 全量同步频繁触发 | 复制积压缓冲区过小、网络闪断导致 offset 丢失 | 调整 repl-backlog-size（建议 64MB+） |
| 从节点无法连接主节点 | 防火墙、主节点 requirepass 未同步、主节点 bind 配置限制 |
检查 masterauth 配置；telnet 测试端口连通性 |
| 复制延迟持续增长 | 主节点写入量过大、从节点性能不足、网络带宽瓶颈 | 监控 master_repl_offset 与 slave_repl_offset 差值 |
中间件通信视角：当异步任务编排中间件依赖 Redis 主从复制时，建议将任务写入操作强制路由到主节点，将任务状态查询路由到从节点。同时，在从节点上设置
slave-read-only yes，防止误写入导致数据分裂。
2.4 数据结构与持久化在故障排查中的联动
在中间件通信故障场景中，数据结构和持久化机制往往需要联合分析。例如：
- 如果使用 List 作为任务队列，且开启了 AOF
always策略，那么每次LPUSH都会触发 fsync，可能成为写入瓶颈。 - 如果使用 Sorted Set 存储延迟任务，且主从切换后 score 精度丢失，可能导致任务提前或延迟执行。
- 如果 RDB 快照生成期间主节点阻塞，所有写入命令（包括任务入队）都会排队，造成中间件通信超时。