Redis 主要有三种主流的方式来构建集群，以满足不同场景下对性能、容量、高可用性的需求。我将从核心原理、优缺点和适用场景三个方面来详细介绍。

三种核心集群策略概览

策略 核心目标 数据分布 高可用实现 适用场景
主从复制 (Replication) 数据冗余、读写分离 全量复制（所有节点数据相同） 手动或外部工具切换 读多写少、数据备份、故障恢复
哨兵模式 (Sentinel) 高可用 (HA) 全量复制（所有节点数据相同） Sentinel 进程自动监控和故障转移 对可用性要求高的读写分离场景
集群模式 (Cluster) 可扩展性 & 高可用 分片 (Sharding)，数据分布式存储 集成在集群中，主从切换+分片迁移 海量数据、高并发、既要读也要写的场景

1. 主从复制 (Replication)

这是最基础的模式，通常由一个 主节点 (Master) 和若干个 从节点 (Slave/Replica) 组成。

  • 工作原理：

    1. 从节点启动后，向主节点发送 SYNC 命令。
    2. 主节点执行 BGSAVE 生成 RDB 快照文件，并缓存期间的写命令。
    3. 主节点将 RDB 文件发送给从节点，从节点加载 RDB 文件。
    4. 主节点再将缓存的写命令发送给从节点，从节点执行这些命令，达到与主节点一致的状态。
    5. 之后，主节点持续通过异步的方式将写命令传播（Replication）给所有从节点，保持数据最终一致。

  • 优点：

    • 数据冗余：实现了数据的多备份。
    • 读写分离：所有写操作必须发生在主节点，读操作可以分流到从节点，极大提升了读吞吐量。
    • 故障恢复：主节点宕机后，可以手动将一个从节点提升为主节点，继续提供服务（需要客户端配合切换连接）。

  • 缺点：

    • 不具备自动故障转移 (Failover)：主节点宕机需要人工干预，无法实现高可用。
    • 写操作无法扩展：所有写操作都在单一主节点，性能有上限。
    • 存储容量受限：每个节点都存储全量数据，无法解决海量数据存储问题。

  • 架构图：

    1
    2
    3
    [Client] (Write) -> | Master | -> (Replicates) -> | Slave 1 |
    [Client] (Read)  -> | Slave 2 |
    [Client] (Read)  -> | Slave 3 |

2. 哨兵模式 (Sentinel)

哨兵模式构建在主从复制之上，引入了 Redis Sentinel 这样一个分布式系统来监控、自动故障转移和配置提供。

  • 工作原理：

    1. 监控 (Monitoring)：多个 Sentinel 进程会不断地检查主节点和从节点是否正常运行。
    2. 自动故障转移 (Automatic Failover)：当 Sentinel 集群（通常至少3个节点）判定主节点客观下线（Objectively Down）时，它会自动执行故障转移操作：
      a. 选举出一个 Leader Sentinel。
      b. Leader Sentinel 从从节点中选出一个（基于优先级、复制偏移量等规则）将其提升为新的主节点。
      c. 让其他从节点复制新的主节点。
      d. 通知客户端（通过 Pub/Sub 或脚本）新的主节点地址。
    3. 配置提供 (Configuration Provider)：客户端可以连接 Sentinel 集群来查询当前的主节点地址。

  • 优点：

    • 高可用性：实现了自动的故障转移，服务中断时间大大缩短。
    • 继承了主从复制的所有优点（读写分离、数据冗余）。

  • 缺点：

    • 写能力和存储容量仍未解决：和主从复制一样，写操作和存储容量仍然受限于单个主节点。
    • 配置稍复杂：需要部署和管理额外的 Sentinel 进程。

  • 架构图：

    1
    2
    3
    4
    5
    6
    [Sentinel 1]  [Sentinel 2]  [Sentinel 3]
          \          |          /
           \         |         /
            \        |        /
            | Master | -> | Slave 1 |
                          | Slave 2 |

    （客户端连接 Sentinel 集群来获取主节点信息）

3. 集群模式 (Cluster)

这是 Redis 官方提供的真正的分布式数据库解决方案，同时解决了高可用和海量数据存储的问题。

  • 核心概念：数据分片 (Sharding)

    • Redis Cluster 将整个数据集划分为 16384 个哈希槽（Hash Slot）。
    • 每个键通过 CRC16 算法计算后，再对 16384 取模，决定它属于哪个槽。
    • 集群中的每个主节点负责一部分哈希槽。
    • 示例：一个三主节点的集群，槽分配可能是：Node1 (0-5460), Node2 (5461-10922), Node3 (10923-16383)。

  • 工作原理：

    1. 数据路由：
      • 客户端缓存路由表：客户端可以随机连接一个集群节点。如果请求的 key 不在该节点上，节点会返回 MOVED 错误和正确的节点地址，客户端会重定向并缓存这个映射关系。
      • 智能客户端：成熟的客户端（如 Lettuce）会在内部维护槽位与节点的映射关系，直接请求正确的节点，避免 MOVED 错误。
    2. 高可用性：
      • 集群每个主节点都可以有多个从节点。
      • 当某个主节点宕机时，它的从节点会自动被提升为主节点，继续负责原来的哈希槽。
    3. 节点通信：
      • 所有节点通过 Gossip 协议彼此交换信息，最终保持整个集群状态的一致。

  • 优点：

    • 横向扩展： both 写性能 and 存储容量 都可以通过增加主节点线性提升。
    • 内置高可用：集成了主从复制和自动故障转移，无需额外部署 Sentinel。
    • 原生支持：官方标准方案，未来持续优化，兼容性好。

  • 缺点：

    • 客户端实现更复杂：需要支持 Cluster 协议的客户端。
    • 不支持多数据库：只能使用 db0。
    • 事务、Lua 脚本 等操作受限，要求操作的 key 必须在同一个节点（同一个哈希槽）。可以使用哈希标签（Hash Tag），如 user:{123}.profile 和 user:{123}.account，强制将多个 key 分配到同一个槽来解决。

  • 架构图：

    1
    2
    3
    [Master A] (Slots 0-5500)  <- [Slave A1]
    [Master B] (Slots 5501-11000) <- [Slave B1]
    [Master C] (Slots 11001-16383) <- [Slave C1]

总结与选型建议

需求场景 推荐策略 理由
小型应用，读写分离，数据备份 主从复制 简单、轻量，足以满足基本冗余和读扩展需求。
中型应用，高可用是核心诉求 哨兵模式 (Sentinel) 在读写分离的基础上，实现了自动化故障转移，保证了服务的高可用性。
大型应用，海量数据和高并发 集群模式 (Cluster) 唯一选择。能同时解决数据量、写并发和高可用问题，是面向未来的方案。
超大规模，多租户，混合云 代理模式 (如 Codis/Twemproxy) 第三方方案，提供了更灵活的管理和迁移能力，但对新特性支持可能滞后。

最终建议：
对于新项目，如果预计数据和流量会持续增长，应优先考虑直接使用 Redis Cluster。它是官方标准和未来方向，避免了从 Sentinel 模式迁移到 Cluster 的麻烦。只有在业务极其简单，明确不会遇到容量和写性能瓶颈时，才考虑主从或哨兵模式。