一、 主从复制：数据冗余的基石与边界
主从复制是 Redis 高可用的地基，其本质是异步的数据流同步。它解决了“数据备份”和“读扩展”的问题，但同时也引入了“一致性窗口”这一固有缺陷。
1. 全量与增量复制的判定标准
很多资料将“断连时间长短”作为触发全量复制的条件，这并不准确。唯一的判定标准是：从库请求的复制偏移量（offset）是否仍存在于主库的复制积压缓冲区内。
- 增量复制：从库重连后发送自身 offset，若该 offset 在缓冲区有效范围内，主库仅补发缺失的命令流。即使断连时间很短，但如果期间写入量巨大导致 offset 被环形覆盖，依然会触发全量复制。
- 全量复制：当 offset 失效、首次连接、或从库执行了
FLUSHALL等操作时触发。主库 fork 子进程生成 RDB 快照发送给从库，同时将生成快照期间的新写入命令缓存到复制积压缓冲区。从库加载完 RDB 后，再消费缓冲区中的增量命令完成追平。 - 隐性开销：即使主库未开启 RDB 持久化，全量复制时仍会在内存中生成临时 RDB 文件。这是生产环境中大 Key 过多导致主库 OOM 的常见元凶。
2. 复制积压缓冲区的容量规划
这是一个固定大小的环形缓冲区，默认 1MB。它的核心作用是容忍短暂的异步复制延迟。容量设置必须基于业务峰值写入速率计算：
推荐公式：缓冲区大小 ≥ 峰值写入带宽 × 预期最大断连恢复时间 × 安全系数（通常取 2~3）
例如，峰值写入 10MB/s，允许最长 30s 的断连恢复窗口，则缓冲区至少应设为10 × 30 × 3 = 900MB。设置过小会导致频繁全量复制，设置过大则浪费内存。需注意：仅当所有从库全部断开时，缓冲区内存才会被释放。
3. 异步复制的一致性代价
由于复制是异步的，主库写入成功后、从库尚未同步前的这段时间窗口内，数据处于不一致状态。这意味着：
- 读写分离场景：刚写入的数据立即从从库读取，可能读到旧值。
- 分布式锁场景：主库加锁成功但未同步到从库时宕机，新主节点（原从库）上没有这把锁，可能导致两个客户端同时持有锁。这不是主从模式的特有缺陷，而是所有异步复制系统的通病。Redis 本身不适合做强一致性分布式锁，应选用 etcd/ZooKeeper 等基于共识算法的组件。
二、 哨兵模式：自动化故障转移的裁判官
主从模式解决了数据冗余，但主节点宕机后仍需人工介入切换。哨兵（Sentinel）的职责就是将这个人工过程自动化，但它本身不存储数据，只是一个独立的监控与决策系统。
1. 主观下线与客观下线：防止误判的双重保险
- 主观下线：单个哨兵在配置时间内未收到主节点的有效回复，单方面标记其为下线。这可能是网络抖动导致的误判。
- 客观下线：当超过
quorum（配置的法定人数）个哨兵都报告主观下线时，才确认主节点真正不可用。这是将“个体感知”上升为“集体共识”的关键步骤。
2. Leader 哨兵选举：类 Raft 的简化投票
多个哨兵同时发现客观下线时，必须先选出一个 Leader 来执行故障转移，避免冲突。这里需要特别澄清：哨兵使用的并非完整的 Raft 协议，而是借鉴了 Raft Leader Election 思想的自研简化投票机制。它不包含 Raft 的日志复制、状态机和任期持久化等核心组件。
选举规则遵循严格的优先级链：
- 过滤掉不健康、断连、延迟过高的从库
replica-priority数值最小的从库优先（设为 0 表示永不参选）- 复制偏移量最大的从库优先（数据最新）
- Run ID 字典序最小的从库兜底
3. 奇数节点与脑裂防护
哨兵数量必须配置为奇数（3/5/7），根本原因在于多数派投票机制要求。偶数个哨兵在网络分区时，可能出现两个分区各自拥有半数节点，都无法达成“超过半数”的共识，导致整个集群无法执行故障转移。
脑裂的真正含义是：网络分区导致旧主节点与新主节点同时存在且都认为自己是合法的，各自独立接收写请求。奇数节点+多数派机制正是为了防止这种情况——只有获得多数派认可的节点才能晋升为主，少数派分区中的旧主会被强制降级为从库或拒绝写入。
三、 Redis Cluster：分片时代的去中心化架构
当数据量和吞吐量超出单机极限时，Cluster 模式通过哈希槽分片实现了水平扩展。但它的设计哲学与前两层有本质区别：它是一个部分可用的分布式系统，而非强一致的整体。
1. 槽位分配与路由机制
- 所有数据被映射到 16384 个哈希槽，每个节点负责一部分槽位。槽位归属通过
CLUSTER ADDSLOTS等命令手动分配，内核不提供自动数据再平衡功能。 - 客户端路由感知：客户端不参与 Gossip 协议。启动时从任一节点获取槽位映射表并本地缓存；当请求发往错误节点时，收到
MOVED响应，客户端据此更新本地缓存并重定向请求。Gossip 仅在服务端节点间传播，用于维护集群元数据的一致性。
2. 故障转移 vs 数据再平衡：必须区分的两件事
这是理解 Cluster 可用性的核心分水岭：
| 操作 | 是否自动 | 说明 |
|---|---|---|
| 主节点宕机 → 从节点晋升 | ✅ 自动 | 从节点通过选举成为新主，接管原槽位，服务秒级恢复 |
| 新增节点 → 槽位迁移 | ❌ 手动 | 需使用redis-cli --cluster reshard或云厂商管控工具 |
| 负载不均 → 槽位再平衡 | ❌ 手动 | 同上，内核不会因负载高低自动挪动槽位 |
Redis 刻意不做自动再平衡，是因为数据迁移是有损操作（网络带宽、CPU 消耗、短暂阻塞），必须由人或受控平台在业务低峰期有计划地执行，避免黑盒式的自动均衡引发性能雪崩。
3. 部分可用性模型
当某个槽位的主从节点全部挂掉时：
- 该槽位对应的 Key 彻底不可用，返回
CLUSTERDOWN - 其他正常槽位的 Key 依然可以正常读写
这与传统数据库“一挂全挂”完全不同。生产环境强烈建议将cluster-require-full-coverage设置为no，让健康的分片继续提供服务，避免局部故障演变为全局雪崩。但这也意味着：Redis Cluster 没有跨分片的数据冗余，主从全挂等于该分片数据永久丢失。防御手段只能是部署拓扑上的跨机架/跨 AZ 容灾，以及合理的副本数量规划。
四、 架构选型决策树
在实际工程中，不应盲目追求“最高级”的架构，而应根据业务规模精准匹配：
- 单机足够→ 不要引入任何高可用组件，运维成本最低
- 需要读扩展 + 简单故障转移→ 主从 + 哨兵（数据量 < 单机上限）
- 数据量/吞吐量超单机→ Cluster 模式（接受部分可用性模型）
- 需要强一致性锁/事务→ 不要用 Redis，选ZooKeeper
- 纯缓存加速→ 先评估本地缓存能否解决 80% 需求，再考虑 Redis
Redis 的伟大不在于无可替代，而在于它在特定历史时期提供了工程成本与技术能力的最优折中。理解它的边界，比掌握它的用法更重要。
