3. 缓存读写分离核心概念
在 Redis 高并发架构中，读写分离是提升缓存吞吐量、降低主节点压力的核心手段。本章深入剖析主从复制原理、读写分离架构图以及一致性挑战，为后续接口契约设计奠定理论基础。
3.1 主从复制原理
Redis 主从复制采用异步复制模型，支持一主多从、链式复制。复制过程分为全量同步与增量同步两个阶段。
| 阶段 | 触发条件 | 核心操作 | 数据流向 |
|---|---|---|---|
| 全量同步 | 从节点首次连接 / 断连后复制积压缓冲区不足 | 主节点生成 RDB 快照 + 发送缓冲区增量命令 | 主 → 从 |
| 增量同步 | 从节点正常在线，持续接收写命令 | 主节点将写命令写入 repl_backlog，从节点定时拉取 | 主 → 从 |
| 命令传播 | 主节点每执行一条写命令 | 立即异步发送给所有已连接的从节点 | 主 → 从 |
关键参数： repl-backlog-size 默认 1MB，建议根据业务写入量调整为 64MB~256MB，避免频繁全量同步。
3.2 读写分离架构图
读写分离架构将 Redis 节点分为两类角色：主节点负责处理写请求（SET、DEL、EXPIRE 等），从节点负责处理读请求（GET、MGET、HGETALL 等）。客户端通过路由层或 SDK 实现请求分发。
架构收益： 读 QPS 可随从节点数量线性扩展，写 QPS 不受从节点数量影响。典型场景下，1 主 3 从可支撑 10 万+ 读 QPS。
3.3 一致性挑战
读写分离架构天然面临数据一致性问题：主节点写入后，从节点存在复制延迟，导致客户端可能读到旧数据。延迟时间通常在毫秒到秒级，取决于网络、主节点负载和从节点处理能力。
| 一致性级别 | 描述 | 适用场景 | 实现代价 |
|---|---|---|---|
| 最终一致性 | 从节点最终会同步主节点数据，但存在时间窗口 | 非关键缓存、用户昵称、商品列表 | 低 |
| 读写一致性 | 写后立即读，强制从主节点读取 | 订单状态、支付结果、库存扣减 | 中 |
| 单调读一致性 | 同一客户端多次读取，不会读到比之前更旧的数据 | 用户会话、配置信息 | 中 |
| 强一致性 | 所有节点数据实时一致 | 金融交易、分布式锁 | 高（需 WAIT 命令） |
常见陷阱： 使用 Redis 读写分离时，如果业务要求“写后立即读到自己写的数据”，必须将读请求路由到主节点，否则可能读到旧数据导致业务异常（如支付成功但页面显示未支付）。
3.4 延迟监控与补偿策略
生产环境中必须建立复制延迟监控机制，并制定相应的补偿策略。
- 监控指标： 通过
INFO replication命令获取master_repl_offset和slave_repl_offset，计算差值即为延迟字节数；结合每秒写入量估算延迟时间。 - 阈值告警： 延迟超过 1 秒触发告警，超过 5 秒自动摘除从节点读流量。
- 补偿策略： 读请求发现数据不存在或过期时，可尝试从主节点回源读取；SDK 层支持按 key 维度强制路由到主节点。
# 监控复制延迟脚本示例
redis-cli -h slave_host INFO replication | grep -E "master_repl_offset|slave_repl_offset"
# 输出示例：
# master_repl_offset:12345678
# slave_repl_offset:12345600
# 延迟 = 78 字节，约 0.5ms（根据写入速率估算）
最佳实践： 在接口契约中明确标注“是否允许最终一致性”。对于强一致性要求的接口，契约中必须声明
consistency=strong，路由层据此将读请求转发至主节点。