Redis集群结构一图看懂，带你快速掌握核心要点和整体架构解析

（此处为文字描述图表结构，非实际图片）

想象一下,我们要管理一个超大的仓库，里面放满了各种数据（键值对），如果只有一个仓库管理员（单个Redis节点），他可能会忙不过来，而且万一他生病了（节点宕机），整个仓库就瘫痪了，Redis集群就是为了解决这个问题而生的，它就像组建了一个仓库管理团队。

核心目标：分而治之与高可用

这个团队有两个核心任务：

1. 分而治之（数据分片）：把海量数据合理地分给团队里的多个成员去管理，这样每个人压力就小多了，整体处理能力极大提升。
2. 高可用（故障转移）：团队里任何一个人突然生病了（节点故障），立刻会有替补队员顶上去，保证仓库业务不中断。

团队组成：节点与角色

一个Redis集群最少需要6个节点才能稳定运行（原因后面说），这6个节点分为两种角色，就像团队里的正式工和后备人员：

1. 主节点（Master）：正式工，负责“干活”，他们直接存储数据，处理客户端的读写请求，集群中总共有3个主节点。
2. 从节点（Slave）：后备人员，每个主节点配一个从节点，他们不直接干活，但会实时复制对应主节点管理的所有数据，相当于主节点的完整备份。

3主3从,一共6个节点，构成了一个最小的高可用Redis集群。（来源：Redis官方文档对集群最小配置的说明）

数据如何分配：哈希槽（Hash Slot）

团队有了,数据怎么分呢？Redis集群引入了一个核心概念叫哈希槽，你可以把它想象成仓库里的固定编号的货架。

• 总量固定：整个集群一共有16384个货架（哈希槽），编号从0到16383，这个数字是精心设计的，权衡了数据分布的均匀性和节点间通信的负担。（来源：Redis官方设计与实现）
• 分配货架：集群启动时，这16384个货架会尽可能平均地分配给3个主节点（正式工）来管理，主节点A管理0-5460号货架，主节点B管理5461-10922号货架，主节点C管理10923-16383号货架。
• 数据入住：当客户端要存入一个数据（比如一个键值对 user:1001）时，集群会用一个公式（CRC16算法）计算键名 user:1001 的哈希值，然后用这个值对16384取模，得到一个介于0到16383之间的数字，这个数字就决定了数据应该放在哪个编号的货架上，进而就知道该由哪个主节点来负责存储，通过这种方式，数据被自动、均匀地分散到了所有主节点上。

客户端如何工作：重定向机制

客户端不像我们,能看到整个仓库的平面图，它一开始可能只知道集群中某一个节点的地址（比如只知道主节点A的地址）。

1. 初次连接：客户端连接上主节点A，想查询一个数据 order:2005。
2. 计算与判断：主节点A自己计算一下，发现 order:2005 这个键根据哈希槽算法，应该存放在10925号货架上。
3. 礼貌指引：主节点A一看，10925号货架不归我管，是归主节点C管的，于是它不会自己处理这个请求，而是向客户端返回一个 MOVED重定向错误，并明确告诉客户端：“这个数据在主节点C那里，这是它的地址和端口”。
4. 智能学习：收到重定向指令的客户端（通常是智能客户端）会根据这个信息，去连接正确的主节点C获取数据，并缓存下“键 order:2005 属于节点C”这个映射关系，下次再访问类似的数据时就可以直接连接正确的节点，提高效率。

高可用如何实现：主从切换

现在来看看后备人员（从节点）是如何发挥作用的。

• 日常同步：每个从节点都通过异步复制的方式，与其对应的主节点保持数据一致。
• 心跳监测：集群中的所有节点（主和从）之间都保持着定期的心跳通信（PING/PONG），用来检测其他节点是否正常在线。
• 故障发现：如果某个主节点（比如主节点B）在规定时间内没有响应大多数节点的PING命令，集群中的其他主节点就会通过投票达成共识，判定主节点B“失联”了。
• 故障转移：一旦确认主节点B故障，它的从节点（比如Slave B）就会在其他主节点的投票授权下，“晋升”为新的主节点，接管原来主节点B负责的所有哈希槽（货架），这个过程是自动的。
• 服务恢复：客户端之后如果再访问原属于主节点B的数据，就会收到重定向到新的主节点（原Slave B）的指令，整个服务在短暂中断后恢复正常，等故障的主节点B修复后重新加入集群，它会自动成为新主节点的一个从节点。

总结一下整体架构流程：

客户端请求一个数据 -> 集群节点通过哈希槽算法判断该数据由哪个主节点负责 -> 如果本节点不负责，则返回重定向信息 -> 客户端连接正确的主节点完成操作，所有从节点实时备份主节点数据，并在主节点故障时自动顶替上岗，实现高可用。

通过这种设计,Redis集群实现了横向扩展（通过增加主节点来增加容量和性能）和高可用性（通过主从复制和故障转移），能够应对大规模数据和高并发场景。