深入学习 Redis Cluster - 集群是啥,数如何理解据分片算法

Redis集群与数据分片解析
28 篇文章 ¥9.90 ¥99.00

目录

一、集群模式

1.1、集群是什么,解决了什么问题

1.2、数据分片算法(重点/考点)

1.2.1、哈希求余

a)算法思路

b)面临的问题

1.2.2、一致性哈希算法

a)算法思路

b)面临的问题

1.2.3、哈希槽分区算法(redis使用)

a)算法思想

b)问题一:redis 集群是最多有 16384 个分片么?

c)问题二:为什么是 16384 个槽位


一、集群模式


前言

重点:什么是 redis 集群,解决了什么问题?三种分片算法是什么,优缺点是什么?哈希槽分片算法为什么是 16384槽位,为什么最多是 16384 集群?

1.1、集群是什么,解决了什么问题

集群这个词,有两种说法:

  • 广义的集群:只要你是多个机器,构成的分布式系统,都可以成为是一个 “集群”,也就是说,之前所讲的 主从结构、哨兵模式,也可以称为是一个 “广义的集群”.
  • 狭义的集群:这个说的就是 redis 提供的集群模式.  这个集群模式之下,主要就是解决,存储空间不足的问题.

Ps:之前讲到,哨兵模式提高了系统的可用性,本质上还是 redis 主从节点存储数据,也就要求一个主节点/从节点,就得存储整个数据的 “全集”.

Redis cluster 的核心思路就是多搞几台机器,每台机器只存储全集数据的一部分.

例如 有

<think>嗯,用户现在想了解Redis Cluster集群的实现原理,之前已经讨论过Redis哨兵机制,看来用户对Redis的高可用方案有系统性学习的需求。从引用内容看,用户提供的资料聚焦在集群基础概念和Redis Cluster的实践操作上,但缺少对底层机制的详细说明。 用户可能正在设计分布式系统,需要评估Redis Cluster是否适合其业务场景。考虑到用户之前研究过哨兵,这次提问明显是想对比两种方案的差异。不过用户没有明确说明应用场景,需要避免过度假设。 从技术深度看,Redis Cluster的实现涉及多个核心机制: - 分片策略(16384个槽位如何分配) - Gossip协议在节点通信中的具体应用 - 故障检测与转移的触发条件 - 客户端重定向机制 特别要注意引用[3]提到的"任何节点相互连通"特性,这其实是集群总线(Cluster Bus)在发挥作用。而引用[5]强调的TCP端口说明需要解释清楚节点间三种端口(客户端、据、集群总线)的分工。 用户可能存在的认知盲区是:认为Redis Cluster完全去中心化。实际上它采用半中心化设计,由主节点共同管理槽位映射。这点需要在回答中明确。 关于据一致性,虽然Redis Cluster是AP系统,但需要说明它如何通过异步复制和配置纪元(epoch)保证最终一致性。引用[4]提到的面试场景暗示用户可能有求职需求,可以适当补充面试高频考点。 最后要提醒用户注意两个实践细节:跨槽位命令的限制和集群扩容时的据迁移风险,这些在引用[2]的手动搭建实验中应该会遇到。</think>Redis ClusterRedis 官方提供的分布式解决方案,其核心原理是通过**分片(Sharding)**、**节点间通信(Gossip 协议)** 和 **自动故障转移** 实现高可用与水平扩展。以下是其工作原理的详细解析: --- ### 一、核心架构设计 1. **去中心化架构** Redis Cluster 由多个节点(Node)组成,每个节点均存储据并参与集群管理,**无中心节点**。客户端可连接任意节点访问据[^3][^4]。 2. **分片(Sharding)** -据划分为 **16384 个哈希槽(Slot)**,每个键通过 CRC16 算法计算哈希值,再对 16384 取模确定所属槽位: $$ \text{Slot} = \text{CRC16}(key) \mod 16384 $$ - 槽位均匀分配给所有主节点(如 3 主节点时,每个节点管理约 5461 个槽)[^3][^5]。 3. **主从复制** 每个主节点(Master)配置至少一个从节点(Slave),主节点处理写请求,从节点同步据提供读能力与故障容灾[^5]。 ```mermaid graph LR A[客户端] --> B[节点1: 主] A --> C[节点2: 主] A --> D[节点3: 主] B --> E[节点4: 从] C --> F[节点5: 从] D --> G[节点6: 从] ``` --- ### 二、关键工作机制 #### 1. **节点发现与状态维护(Gossip 协议)** - 节点间通过 **TCP 端口(默认 16379)** 建立集群总线(Cluster Bus),每秒随机选择部分节点交换信息(PING/PONG)[^5]。 - 消息包含:节点状态、槽位映射、故障标识等,最终实现集群状态一致性[^3][^4]。 #### 2. **请求路由机制** - **直接访问**:若客户端请求的键所属槽位在当前节点,直接响应。 - **重定向(MOVED)**:若键所属槽位在其他节点,返回 `MOVED <slot> <target-node-ip>:<port>` 指令,客户端重连目标节点[^3][^4]。 - **重试(ASK)**:在槽迁移过程中,若据未完全迁移,返回 `ASK` 指令引导客户端临时访问目标节点[^4]。 #### 3. **自动故障转移(无需哨兵)** - **故障检测**: 节点间通过 PING/PONG 检测存活。若某主节点在 `cluster-node-timeout`(默认 15 秒)内无响应,其他主节点将其标记为 **疑似下线(PFAIL)**;超过半主节点确认后升级为 **已下线(FAIL)**[^4][^5]。 - **主从切换**: 当主节点被标记 FAIL,其从节点触发选举: 1. 从节点延迟一定时间(与复制偏移量成正比)发起竞选。 2. 主节点投票(需获得多票)。 3. 胜出从节点执行 `SLAVEOF NO ONE` 成为新主节点,接管原主槽位[^4][^5]。 #### 4. **据迁移与扩容** - **槽位迁移**: 使用 `CLUSTER ADDSLOTS` 或 `redis-trib` 工具迁移槽位。迁移过程中: - 源节点对迁移槽的键设置 `ASKING` 标志。 - 目标节点仅处理带 `ASKING` 标志的请求[^2][^4]。 - **扩容流程**: 1. 添加新主节点并分配空槽。 2. 从其他节点迁移部分槽至新节点。 3. 添加从节点同步新主据[^2]。 --- ### 三、集群特性与限制 | **特性** | **说明** | |-------------------------|--------------------------------------------------------------------------| | 高可用 | 主节点故障时从节点自动切换,服务中断时间 < 2 秒[^4] | | 水平扩展 | 支持动态增删节点,据自动重分布 | | 最终一致性 | 主从异步复制,极端情况下可能丢失写入(可通过 `WAIT` 命令优化)[^5] | | **关键限制** | | | 跨槽命令不支持 | 如 `MGET`、`MSET` 需所有键在同一槽位,否则需使用 `Hash Tag`(如 `{user}:1`) | | 事务仅支持单节点 | 所有键必须在同一槽位才能使用事务[^3] | | 数据库仅支持 DB0 | Cluster 模式下不可切换数据库[^4] | --- ### 四、集群搭建示例(简化步骤) ```bash # 1. 启动6个节点(3主3从) redis-server --port 7000 --cluster-enabled yes ... # 2. 构建集群 redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 ... \ --cluster-replicas 1 # 3. 验证状态 redis-cli -p 7000 cluster nodes ``` --- ### 五、Redis Cluster vs 哨兵模式 | **维度** | **Redis Cluster** | **哨兵模式** | |----------------|---------------------------------|----------------------------| | 架构 | 去中心化 | 中心化(哨兵集群) | | 扩展性 | 水平扩展(支持千节点) | 仅主从复制,读写分离 | | 分片 | 内置分片(槽位) | 需客户端或代理分片 | | 故障转移 | 节点自主选举 | 哨兵监控与触发切换 | | 适用场景 | 大据量、高并发 | 中小规模、高可用优先 | > 提示:Redis Cluster 适用于需**水平扩展**的场景,而哨兵模式更适合**高可用但据量中等**的场景[^1][^4]。 --- ### 相关问题 1. Redis Cluster 如何解决跨槽位命令的执行问题? 2. 集群扩容时如何避免据迁移导致的服务中断? 3. Redis Cluster 的 `Hash Tag` 机制如何工作?有何风险? 4. 为什么 Redis Cluster 的槽位量固定为 16384? 5. 如何监控 Redis Cluster 的节点状态与槽位分布?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

陈亦康

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值