一、为何需要分片集群？

在讨论具体方案之前，我们先明确分片集群要解决的问题：

单节点瓶颈：无论是内存容量还是处理能力（QPS），单个 Redis 实例都有物理上限。
高可用性需求：单点故障会导致整个服务中断，这在生产环境中是不可接受的。
数据安全：需要备份机制防止数据丢失。

传统的单机 Redis 或简单的主从复制，虽然能解决部分问题（如读扩展、数据备份），但无法突破单节点容量限制，也无法在主节点故障时实现完全自动的无感知切换。因此，分片集群应运而生。

二、Redis 分片集群：数据分摊与扩展基石

分片（Sharding） 是将数据集分割成多个部分，并将这些部分分布到集群中的多个节点上存储的技术。Redis 的分片集群方案（如 Redis Cluster）正是基于此理念。

核心思想：

数据分片：将整个 Redis 键空间划分为多个逻辑分区（在 Redis Cluster 中称为哈希槽，共 16384 个）。每个哈希槽负责一部分键值对。
节点分布：将不同的哈希槽分配给集群中的不同 Redis 节点（主节点）负责。
数据路由：客户端（或代理）根据键计算出它属于哪个哈希槽，然后将请求发送给负责该哈希槽的节点。

工作方式：

哈希算法：通常使用 CRC16 等哈希算法计算键的哈希值，然后对哈希槽数量取模，确定键属于哪个槽。
slot = CRC16(key) % 16384
请求路由：客户端（需要使用支持 Redis Cluster 协议的客户端库）根据计算出的槽位，将命令发送给对应的节点。
自动迁移：当需要扩容或缩容时，Redis Cluster 可以自动在节点间迁移哈希槽，尽量减少对客户端的影响。

分片集群的优势：

水平扩展：通过增加节点数量，可以线性提升集群的总存储容量和处理能力。
高可用基础：为每个分片（主节点）配置从节点，构成了高可用的基础。

三、主从模式：数据冗余与读写分离

主从模式（Master-Slave Replication） 是 Redis 实现数据冗余和高可用性的基础机制。它本身不直接解决分片问题，但常与分片集群结合使用。

工作原理：

主节点（Master）：负责处理写请求，并将数据变更通过**复制（Replication）**机制同步到从节点。
从节点（Slave / Replica）：从主节点同步数据，可以处理读请求。一个主节点可以拥有多个从节点。

复制过程：

全量复制：从节点向主节点发送复制请求，主节点将当前所有数据（RDB 快照）发送给从节点。
增量复制：全量复制完成后，主节点将后续产生的所有写操作（通过命令流）持续发送给从节点，从节点执行这些命令以保持数据同步。

主从模式的作用：

数据冗余与备份：从节点是主节点数据的副本，提供数据备份，防止主节点数据丢失。
读写分离：可以将读请求分散到多个从节点，减轻主节点的压力，提升整体吞吐量。写操作仍需访问主节点。
高可用基础：当主节点故障时，可以从从节点中选举一个作为新的主节点，实现服务的快速恢复（但这通常需要 Sentinel 或 Cluster 的介入来完成自动化切换）。

限制：

不具备自动故障转移能力：虽然从节点有数据，但默认情况下无法自动接管主节点的工作。需要人工干预或借助 Sentinel/Cluster。
无法解决单节点容量瓶颈：所有写操作都集中到主节点，主节点仍然是性能和容量的瓶颈。

四、哨兵机制：自动化主从切换与监控

哨兵（Sentinel） 机制在主从模式的基础上，提供了自动化的监控、通知和故障转移能力，是实现 Redis 高可用的关键组件。

核心功能：

监控（Monitoring）：哨兵会持续监控主节点和从节点的健康状态。
通知（Notification）：当它发现某个节点故障或状态变化时，可以通知配置的客户端（如通过消息队列、HTTP API 等）。
自动故障转移（Automatic Failover）：当主节点被判定为下线（客观下线）时，哨兵会自动选择一个从节点，将其提升为新的主节点，并让其他从节点指向新的主节点。
配置提供者（Configuration Provider）：在故障转移完成后，哨兵可以为客户端提供新的主节点地址，使客户端能够自动切换连接。

工作流程（以主节点故障为例）：

主观下线（SDOWN）：单个哨兵发现主节点在指定时间内没有响应，认为其主观下线。
客观下线（ODOWN）：多个哨兵通过投票机制确认主节点确实下线（达到配置的 quorum 数）。
领导者选举：在客观下线的状态下，哨兵集群会选举出一个领导者哨兵，负责执行故障转移。
故障转移执行：
- 选择一个从节点作为新的主节点（通常选择优先级高、数据新、延迟低的从节点）。
- 将选中的从节点提升为主节点（执行 SLAVEOF NO ONE）。
- 通知其他从节点将 slaveof 指向新的主节点。
- 通知客户端新的主节点信息。

哨兵模式的优势：

自动化：大大减少了人工干预，实现了故障的快速自动恢复。
高可用：确保了主从架构下的服务连续性。
可扩展性：可以通过增加哨兵实例来提高监控的冗余度和可靠性。

哨兵模式的局限：

不解决分片问题：哨兵本身不进行数据分片，它管理的仍然是一个逻辑上的整体 Redis 服务（尽管可能由多个主从节点组成）。
写性能瓶颈：所有写操作仍然集中在一个主节点上。

五、分片集群 + 哨兵：完整的高可用方案

为了同时实现水平扩展和高可用，最佳实践是将 Redis 分片集群与哨兵机制结合使用。

架构示意：

复制

       +-----------------+       +-----------------+       +-----------------+|  Redis Node 1   |       |  Redis Node 2   |       |  Redis Node 3   ||  (Master)       |       |  (Master)       |       |  (Master)       |+-------+---------+       +-------+---------+       +-------+---------+|                      |                      ||                      |                      |+-------v---------+       +-------v---------+       +-------v---------+|  Redis Node 1a  |       |  Redis Node 2a  |       |  Redis Node 3a  ||  (Replica)      |       |  (Replica)      |       |  (Replica)      |+-----------------+       +-----------------+       +-----------------+|                      ||                      |+--------v--------+       +-------v---------+|  Redis Sentinel 1 |       |  Redis Sentinel 2 |+-------+--------+       +-------+--------+|                      ||                      |+-------v--------+       +-------v---------+|  Redis Sentinel 3 |       |  Redis Sentinel 4 |+-------------------+       +-----------------+

引用

工作方式：

分片：数据被分片到多个主节点（Node 1, Node 2, Node 3）上。
主从复制：每个主节点都配置一个或多个从节点（Node 1a, Node 2a, Node 3a），实现数据冗余和读写分离。
哨兵监控：哨兵集群监控所有主节点和从节点的健康状态。
自动故障转移：如果某个主节点（例如 Node 1）故障，哨兵会自动将它的一个从节点（Node 1a）提升为新的主节点，并更新其他从节点和客户端的配置。这个过程对应用是透明的。