一、核心概念与架构特点
Redis Cluster 是 Redis 官方在 3.0 版本（2015年） 推出的分布式解决方案，旨在突破单机 Redis 在内存容量、并发吞吐和网络带宽上的瓶颈。它采用无中心、去中心化的架构，每个节点都与其他节点保持互连，没有中心代理层。其核心特点如下：
-
多主多从：区别于传统主从+哨兵的单主写瓶颈，Redis Cluster 支持多个主节点同时提供读写服务，每个主节点可挂载多个从节点（副本）。
-
自动分片：数据按哈希槽（Hash Slot）划分为 16384 个区间，每个主节点负责一部分槽位。
-
高可用：具备内置的故障检测和自动故障转移能力，无需额外依赖哨兵组件。
-
Gossip 通信：节点间采用 Gossip 协议交换状态、槽位映射等元数据，保证集群状态最终一致。
-
智能客户端：客户端直接连接任一节点，收到重定向错误后更新本地槽位缓存，无需中间代理。
二、数据分片：哈希槽机制
Redis Cluster 的数据分片采用哈希槽（Hash Slot） 模型，这是其区别于一致性哈希（Consistent Hashing）的核心设计。
-
固定槽数：集群将整个键空间划分为固定的 16384 个槽位（0~16383），这个数量是设计上对网络消息包大小和节点心跳开销的一个平衡点。
-
槽位计算：每个键通过
CRC16(key) % 16384公式映射到具体槽位。例如，键mykey的槽位为CRC16("mykey") % 16384 = 5475。 -
槽位分配：每个主节点负责一段连续的槽位范围。例如在 3 主节点集群中：Master1 负责 0~5460，Master2 负责 5461~10922，Master3 负责 10923~16383。
-
Hash Tag：可以通过
{...}将多个 key 强制映射到同一槽位。例如user:{100}:name和user:{100}:age都会落入相同槽位，从而支持多键操作。 -
水平扩展：增减节点时，只需迁移对应槽位及其数据，无需重新哈希所有数据，实现了平滑的在线扩缩容。
三、节点通信：Gossip 协议
Redis Cluster 采用 Gossip（流言）协议 来维护集群元数据的一致性，这是一种去中心化的、基于随机传播的最终一致性协议。
-
通信端口：节点间通信使用 服务端口 + 10000 的独立端口。例如，服务端口 6379 对应的集群总线端口为 16379。
-
消息类型：Gossip 协议定义了多种消息类型：
-
MEET：用于邀请新节点加入集群。
-
PING/PONG：节点间交换状态、槽位映射、配置纪元（configEpoch）等元数据。
-
FAIL：宣告某个节点被确认为下线。
-
-
通信频率与优化：每个节点每秒会执行 10 次 PING 交换，每次随机选择 5 个 最久未通信的节点发送消息，同时附带自身及 1/10 其他节点的元数据。若某个节点的通信延时超过
cluster-node-timeout / 2，则立即发送 PING，避免数据交换滞后。 -
优点与局限：Gossip 协议的好处是节点负载几乎不随集群规模线性增长，扩展性好；其局限在于元数据更新存在传播延迟，集群规模的感知有一定滞后性。
四、请求路由与重定向
由于数据分散在多个主节点上，客户端需要将请求发送到正确的节点。Redis Cluster 不依赖代理，而是通过重定向机制配合智能客户端来实现路由。
-
MOVED 重定向：若客户端将请求发送到错误的节点，该节点会返回
MOVED <slot> <ip:port>错误，告知客户端该槽位永久由新节点负责。智能客户端会更新本地槽位映射缓存，后续请求直接发往正确节点。 -
ASK 重定向：在槽位迁移过程中，源节点可能只持有部分数据。当客户端请求一个正在迁移的 key 时，节点返回
ASK <slot> <ip:port>，告知客户端临时到目标节点尝试。与 MOVED 不同，客户端不更新本地槽位缓存，因为迁移尚未完成。 -
智能客户端：成熟的 Redis 客户端（如 Jedis、Lettuce、go-redis）会自动处理 MOVED/ASK 重定向，维护并定期更新槽位映射表，对上层应用透明。
五、故障检测与自动转移
Redis Cluster 内置了一套完整的故障检测与自动切换机制，无需像传统主从架构那样依赖独立的哨兵（Sentinel）进程。
5.1 故障检测流程
故障检测分为单节点视角 → 信息传播 → 下线判决三个阶段：
-
主观下线（PFAIL）：节点 A 发现节点 B 在
cluster-node-timeout时间内无响应，则将其标记为 PFAIL（疑似下线）。 -
Gossip 传播：节点 A 通过 PING/PONG 消息将 PFAIL 状态传播给其他节点。
-
客观下线（FAIL）：当集群中超过半数的主节点都将节点 B 标记为 PFAIL 后，集群达成共识，将节点 B 正式标记为 FAIL（确认下线），并广播 FAIL 消息。
5.2 故障转移选举
一旦某主节点被标记为 FAIL，其从节点会发起选举，选举机制借鉴了 Raft 算法的思路：
-
从节点发现主节点下线后，增加自身的配置纪元（configEpoch），并向所有主节点发送投票请求。
-
主节点采用先到先得原则，每个主节点在每个纪元内只能投一票。
-
获得多数主节点（N/2+1） 投票的从节点，成功当选为新主节点，接管原主节点负责的槽位。
-
新主节点广播自身信息，完成数据同步和角色切换。
六、扩缩容与数据迁移
Redis Cluster 支持在线扩缩容，通过迁移哈希槽来实现节点的增加与下线，整个过程无需停机。
6.1 扩容步骤
-
启动新的 Redis 实例（主节点和对应的从节点）。
-
使用
CLUSTER MEET命令将新节点加入集群。 -
使用
redis-cli --cluster reshard或redis-trib.rb reshard命令，将部分槽位从现有主节点迁移到新主节点。 -
迁移过程中，源节点处于导出状态，目标节点处于导入状态，数据逐批迁移。
6.2 缩容步骤
-
将待下线节点上的槽位迁移到其他主节点。
-
槽位迁移完成后，使用
CLUSTER FORGET命令将节点从集群中移除。 -
停止并下线该节点实例。
七、部署与配置最佳实践
7.1 节点规模规划
-
最小规模：至少 6 个节点（3 主 3 从），以保证数据可靠性和故障转移能力。
-
生产推荐：根据数据量和 QPS 动态规划分片数，建议初始分片数 ≥ 6，主节点数量取奇数个（3/5/7）以保证投票多数性。
-
跨机房部署：主节点和从节点分布在不同可用区，确保单机房故障时数据不丢失。
7.2 关键配置参数
| 参数 | 说明 | 建议值 |
|---|---|---|
cluster-enabled | 启用集群模式 | yes |
cluster-config-file | 集群状态持久化文件 | nodes.conf |
cluster-node-timeout | 节点超时阈值（毫秒） | 15000（15秒） |
cluster-migration-barrier | 从节点迁移所需的最少主节点数 | 1 |
cluster-require-full-coverage | 是否要求所有槽位都有主节点 | 生产建议 yes |
replica-read-only | 从节点是否只读 | yes |
7.3 故障检测灵敏度策略
Redis Enterprise 提供了两种故障检测灵敏度策略，可通过 rladmin tune cluster failure_detection_sensitivity 切换：
-
high（本地网络）：适用于低延迟、低抖动的数据中心网络，故障检测更快，切换更迅速。
-
low（云环境）：适用于高延迟抖动（网络抖动）的云环境，容错性更高。
八、监控与性能优化
8.1 关键监控指标
-
集群级：槽位覆盖率（16384 个槽是否全部分配）、节点在线数、故障转移次数。
-
节点级：
instantaneous_ops_per_sec（QPS）、used_memory（内存使用率）、keyspace_hits（缓存命中率）、主从复制延迟、网络 I/O。 -
告警阈值：内存使用率 > 85% 触发扩容；主从延迟 > 500ms 触发告警。
8.2 性能优化建议
-
避免热点 Key：使用 Hash Tag 或本地缓存分散压力。
-
合理设置超时：
cluster-node-timeout不宜过短（避免频繁误判），也不宜过长（影响故障切换速度）。 -
Pipeline 批量操作：将同槽位的命令合并发送，减少网络往返。
-
重平衡窗口选择：在业务低峰期执行槽位重平衡，减少迁移对性能的影响。
-
IO 多线程：Redis 6.0+ 支持 IO 多线程，可提升高吞吐场景下的性能。
8.3 常用监控工具
-
Prometheus + Grafana：采集集群指标、可视化展示、配置告警规则。
-
Redis Exporter：将 Redis 指标暴露为 Prometheus 格式。
-
redis-cli --cluster check：检查集群健康状态、槽位分布、数据一致性。
九、Redis Cluster 的优缺点总结
优点
-
水平扩展能力强：数据自动分片，支持在线扩缩容，突破单机容量瓶颈。
-
高可用内置：主从复制 + 自动故障转移，无需额外组件。
-
去中心化：无单点故障，任意节点均可对外服务。
-
性能优秀：智能客户端直连节点，无代理层性能损耗。
缺点与局限
-
多键操作限制：默认不支持跨槽位的多键操作（如
mget、mset），需借助 Hash Tag 将相关键映射到同一槽位。 -
事务支持受限：只支持同一槽位内的事务（
MULTI/EXEC），跨槽位事务无法保证原子性。 -
客户端复杂度：要求使用支持集群模式的智能客户端，传统单机客户端无法直接使用。
-
网络要求高：节点间频繁的 Gossip 通信对网络延迟和稳定性要求较高。
十、与其他 Redis 高可用方案的对比
| 特性 | 主从复制（Replication） | 哨兵模式（Sentinel） | Redis Cluster |
|---|---|---|---|
| 数据分布 | 全量存储，每个节点数据相同 | 全量存储 | 分片存储，每个节点部分数据 |
| 扩展性 | 仅垂直扩展 | 仅垂直扩展 | 水平扩展（在线扩缩容） |
| 故障转移 | 手动 | 自动（Sentinel 选举） | 自动（内置选举） |
| 写性能 | 单主写瓶颈 | 单主写瓶颈 | 多主并发写 |
| 部署复杂度 | 低 | 中 | 高 |
| 适用场景 | 小型应用、读写分离 | 中大型应用、高可用需求 | 海量数据、高并发、高可用 |
总结
Redis Cluster 是 Redis 官方提供的分布式解决方案，通过哈希槽分片、Gossip 通信、内置选举等机制，实现了数据水平扩展和高可用。它适用于海量数据、高并发、高可用的业务场景。但同时也带来了多键操作限制、客户端兼容性要求等使用复杂度，需要根据实际业务需求在 Redis Cluster 与主从+哨兵之间做出合适的技术选型。
扫一扫
7399
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
