写在前面在之前的文章中我们学习了Redis的主从复制和哨兵模式它们解决了数据备份和故障转移的问题。但当数据量越来越大单机内存无法满足需求时我们就需要Redis Cluster集群方案了。今天我们就来深入理解Redis Cluster的原理与实践。文章目录写在前面一、为什么需要Redis Cluster1.1 单机Redis的瓶颈1.2 传统方案的局限性1.3 Redis Cluster的优势二、Cluster原理详解2.1 哈希槽Hash Slot机制2.2 为什么是16384个槽2.3 集群架构图2.4 节点通信机制三、Cluster配置实战3.1 集群规划3.2 配置文件3.3 创建集群3.4 集群常用命令四、数据迁移4.1 槽位迁移4.2 数据迁移注意事项五、故障转移5.1 故障检测5.2 故障转移过程5.3 手动故障转移六、踩坑提醒6.1 跨槽查询问题6.2 批量操作限制6.3 客户端连接6.4 集群配置常见错误七、Cluster与哨兵对比7.1 功能对比7.2 适用场景八、面试高频考点8.1 Redis Cluster和哨兵的区别8.2 为什么Redis Cluster使用16384个槽8.3 Redis Cluster如何保证数据一致性九、参考资料十、互动话题一、为什么需要Redis Cluster1.1 单机Redis的瓶颈实际场景某电商平台的商品数据达到500GB单机Redis内存只有64GB无法存储全部数据怎么办单机Redis面临的问题问题类型具体表现影响程度内存限制单机内存有限无法存储海量数据严重QPS瓶颈单机QPS约10万高并发场景不够用中等网络带宽大流量场景下带宽成为瓶颈中等单点故障机器宕机导致服务不可用严重1.2 传统方案的局限性主从复制只能做数据备份无法扩展存储容量哨兵模式实现高可用但仍然是单机存储数据量受限于单机内存客户端分片在客户端做数据分片但需要客户端维护分片逻辑迁移困难1.3 Redis Cluster的优势Redis Cluster是Redis官方提供的分布式解决方案具有以下特点数据分片自动将数据分散到多个节点高可用每个分片都有主从复制去中心化无中心节点所有节点平等自动故障转移节点故障时自动切换在线扩缩容支持动态添加删除节点二、Cluster原理详解2.1 哈希槽Hash Slot机制核心原理Redis Cluster采用虚拟槽分区将键空间划分为16384个槽每个节点负责一部分槽。# 计算key属于哪个槽 CLUSTER KEYSLOT mykey # 返回槽号如12546槽位计算公式slot CRC16(key) % 163842.2 为什么是16384个槽面试高频考点为什么Redis Cluster使用16384个槽而不是65536或其他数值因素分析心跳包大小16384个槽位只需要2KB的位图65536需要8KB节点数量16384个槽最多支持16384个主节点实际足够槽位粒度太多槽位会导致数据迁移时粒度过细网络带宽心跳包越小网络开销越小经验之谈在实际生产环境中Redis Cluster建议主节点数量不超过1000个16384个槽完全够用。2.3 集群架构图┌─────────────────────────────────────────────────────────┐ │ Redis Cluster │ ├─────────────────────────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Master A │ │ Master B │ │ Master C │ │ │ │ 槽0-5461 │ │槽5462-10922│ │槽10923-16383│ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │ │Slave A │ │Slave B │ │Slave C │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────┘2.4 节点通信机制Redis Cluster采用Gossip协议进行节点间通信消息类型作用发送频率PING检测节点是否在线每秒随机选5个节点PONG响应PING消息收到PING时回复MEET请求加入集群添加节点时发送FAIL标记节点下线检测到故障时广播三、Cluster配置实战3.1 集群规划实际场景搭建一个3主3从的Redis Cluster集群6个节点分别部署在不同服务器上。节点规划节点IP端口角色node1192.168.1.1016379Masternode2192.168.1.1026379Masternode3192.168.1.1036379Masternode4192.168.1.1046379Slavenode5192.168.1.1056379Slavenode6192.168.1.1066379Slave3.2 配置文件每个节点的redis.conf配置# 开启集群模式 cluster-enabled yes # 集群配置文件自动生成 cluster-config-file nodes-6379.conf # 节点超时时间毫秒 cluster-node-timeout 15000 # 开启AOF持久化 appendonly yes # 绑定IP bind 0.0.0.0 # 保护模式关闭 protected-mode no # 端口 port 6379 # 后台运行 daemonize yes3.3 创建集群使用redis-cli创建集群# Redis 5.0 使用以下命令redis-cli--clustercreate\192.168.1.101:6379\192.168.1.102:6379\192.168.1.103:6379\192.168.1.104:6379\192.168.1.105:6379\192.168.1.106:6379\--cluster-replicas1参数说明--cluster-replicas 1每个主节点有1个从节点3.4 集群常用命令# 查看集群信息 CLUSTER INFO # 查看集群节点 CLUSTER NODES # 查看key所在的槽 CLUSTER KEYSLOT mykey # 查看槽所在节点 CLUSTER GETKEYSINSLOT 12546 10四、数据迁移4.1 槽位迁移实际场景需要向集群添加一个新节点需要重新分配槽位。添加新节点# 添加新主节点redis-cli--clusteradd-node192.168.1.107:6379192.168.1.101:6379# 重新分配槽位redis-cli--clusterreshard192.168.1.101:6379迁移过程目标节点导入槽位源节点逐个迁移key更新集群元数据迁移完成4.2 数据迁移注意事项注意点说明迁移时间大量数据迁移需要较长时间服务影响迁移期间服务可用但可能有短暂阻塞ASK重定向迁移期间访问迁移中的key需要重定向批量迁移建议在低峰期进行迁移操作五、故障转移5.1 故障检测Redis Cluster故障检测流程节点A发送PING → 节点B无响应 → 标记PFAIL(疑似下线) ↓ 多数节点确认PFAIL → 标记FAIL(真正下线) ↓ 从节点发起选举 → 选举成功 → 升级为主节点5.2 故障转移过程踩坑提醒故障转移期间部分请求可能返回MOVED错误客户端需要正确处理重定向。故障转移步骤从节点检测到主节点下线从节点发起选举请求获得多数主节点投票从节点升级为主节点更新集群槽位映射通知其他节点5.3 手动故障转移# 在从节点上执行手动升级为主节点 CLUSTER FAILOVER # 强制故障转移不等待主节点确认 CLUSTER FAILOVER FORCE # 接管故障主节点主节点已下线 CLUSTER FAILOVER TAKEOVER六、踩坑提醒6.1 跨槽查询问题踩坑提醒Redis Cluster中多key操作如MGET、MSET要求所有key在同一个槽否则报错错误示例# 这两个key可能在不同槽 MGET user:1:name user:2:name # 报错CROSSSLOT Keys in request dont hash to the same slot解决方案使用Hash Tags# 使用{}指定hash tag大括号内的内容参与槽计算 MGET {user}:1:name {user}:2:name # 这样两个key会落在同一个槽6.2 批量操作限制操作类型限制解决方案MGET/MSET必须同槽使用Hash TagsLua脚本默认同槽使用Hash Tags或keys参数事务MULTI必须同槽使用Hash TagsSCAN命令单节点扫描遍历所有节点6.3 客户端连接经验之谈建议使用支持集群模式的客户端如Jedis、Lettuce、redis-py-cluster等它们会自动处理MOVED和ASK重定向。6.4 集群配置常见错误错误原因解决方案集群不可写槽位未全部分配确保所有槽都已分配节点无法加入网络不通或配置错误检查防火墙和配置重定向循环配置文件冲突清理nodes.conf重新创建七、Cluster与哨兵对比7.1 功能对比对比项Redis Cluster哨兵模式数据分片支持不支持高可用支持支持主从复制支持支持故障转移自动自动在线扩容支持不支持客户端支持需要集群客户端普通客户端部署复杂度较高较低最小节点数6个3主3从3个1主2从3哨兵7.2 适用场景选择Cluster数据量大需要分片存储需要横向扩展单机内存无法满足需求选择哨兵数据量不大主要需要高可用部署运维简单八、面试高频考点8.1 Redis Cluster和哨兵的区别答案Redis Cluster和哨兵的主要区别在于功能定位哨兵主要解决高可用问题Cluster既解决高可用又解决数据分片问题数据存储哨兵模式下所有数据在单机Cluster数据分散在多个节点扩展性Cluster支持在线扩缩容哨兵不支持最小部署Cluster至少需要6个节点哨兵需要3个节点1主2从3哨兵客户端Cluster需要支持集群协议的客户端哨兵使用普通客户端即可8.2 为什么Redis Cluster使用16384个槽答案心跳包大小16384个槽只需要2KB位图表示65536需要8KB节省网络带宽节点数量限制实际生产中主节点不超过1000个16384个槽足够分配数据迁移粒度槽位太多会导致迁移粒度过细增加迁移复杂度历史原因设计时的权衡结果兼顾了效率和实用性8.3 Redis Cluster如何保证数据一致性答案异步复制主节点写入后异步同步到从节点存在短暂不一致最终一致性网络正常情况下数据最终会一致读写分离默认读写都在主节点保证强一致性WAIT命令可以使用WAIT命令等待复制完成九、参考资料Redis官方文档 - Redis Cluster十、互动话题你的项目中是否使用过Redis Cluster遇到了哪些问题在数据迁移过程中如何保证业务的平滑过渡对于小规模数据你会选择Cluster还是哨兵模式为什么欢迎在评论区分享你的经验和看法下期预告Day12我们将学习Redis缓存应用实战深入理解缓存穿透、击穿、雪崩的解决方案。
【Redis】Cluster集群Day11（2026年）
写在前面在之前的文章中我们学习了Redis的主从复制和哨兵模式它们解决了数据备份和故障转移的问题。但当数据量越来越大单机内存无法满足需求时我们就需要Redis Cluster集群方案了。今天我们就来深入理解Redis Cluster的原理与实践。文章目录写在前面一、为什么需要Redis Cluster1.1 单机Redis的瓶颈1.2 传统方案的局限性1.3 Redis Cluster的优势二、Cluster原理详解2.1 哈希槽Hash Slot机制2.2 为什么是16384个槽2.3 集群架构图2.4 节点通信机制三、Cluster配置实战3.1 集群规划3.2 配置文件3.3 创建集群3.4 集群常用命令四、数据迁移4.1 槽位迁移4.2 数据迁移注意事项五、故障转移5.1 故障检测5.2 故障转移过程5.3 手动故障转移六、踩坑提醒6.1 跨槽查询问题6.2 批量操作限制6.3 客户端连接6.4 集群配置常见错误七、Cluster与哨兵对比7.1 功能对比7.2 适用场景八、面试高频考点8.1 Redis Cluster和哨兵的区别8.2 为什么Redis Cluster使用16384个槽8.3 Redis Cluster如何保证数据一致性九、参考资料十、互动话题一、为什么需要Redis Cluster1.1 单机Redis的瓶颈实际场景某电商平台的商品数据达到500GB单机Redis内存只有64GB无法存储全部数据怎么办单机Redis面临的问题问题类型具体表现影响程度内存限制单机内存有限无法存储海量数据严重QPS瓶颈单机QPS约10万高并发场景不够用中等网络带宽大流量场景下带宽成为瓶颈中等单点故障机器宕机导致服务不可用严重1.2 传统方案的局限性主从复制只能做数据备份无法扩展存储容量哨兵模式实现高可用但仍然是单机存储数据量受限于单机内存客户端分片在客户端做数据分片但需要客户端维护分片逻辑迁移困难1.3 Redis Cluster的优势Redis Cluster是Redis官方提供的分布式解决方案具有以下特点数据分片自动将数据分散到多个节点高可用每个分片都有主从复制去中心化无中心节点所有节点平等自动故障转移节点故障时自动切换在线扩缩容支持动态添加删除节点二、Cluster原理详解2.1 哈希槽Hash Slot机制核心原理Redis Cluster采用虚拟槽分区将键空间划分为16384个槽每个节点负责一部分槽。# 计算key属于哪个槽 CLUSTER KEYSLOT mykey # 返回槽号如12546槽位计算公式slot CRC16(key) % 163842.2 为什么是16384个槽面试高频考点为什么Redis Cluster使用16384个槽而不是65536或其他数值因素分析心跳包大小16384个槽位只需要2KB的位图65536需要8KB节点数量16384个槽最多支持16384个主节点实际足够槽位粒度太多槽位会导致数据迁移时粒度过细网络带宽心跳包越小网络开销越小经验之谈在实际生产环境中Redis Cluster建议主节点数量不超过1000个16384个槽完全够用。2.3 集群架构图┌─────────────────────────────────────────────────────────┐ │ Redis Cluster │ ├─────────────────────────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Master A │ │ Master B │ │ Master C │ │ │ │ 槽0-5461 │ │槽5462-10922│ │槽10923-16383│ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │ │ │Slave A │ │Slave B │ │Slave C │ │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────┘2.4 节点通信机制Redis Cluster采用Gossip协议进行节点间通信消息类型作用发送频率PING检测节点是否在线每秒随机选5个节点PONG响应PING消息收到PING时回复MEET请求加入集群添加节点时发送FAIL标记节点下线检测到故障时广播三、Cluster配置实战3.1 集群规划实际场景搭建一个3主3从的Redis Cluster集群6个节点分别部署在不同服务器上。节点规划节点IP端口角色node1192.168.1.1016379Masternode2192.168.1.1026379Masternode3192.168.1.1036379Masternode4192.168.1.1046379Slavenode5192.168.1.1056379Slavenode6192.168.1.1066379Slave3.2 配置文件每个节点的redis.conf配置# 开启集群模式 cluster-enabled yes # 集群配置文件自动生成 cluster-config-file nodes-6379.conf # 节点超时时间毫秒 cluster-node-timeout 15000 # 开启AOF持久化 appendonly yes # 绑定IP bind 0.0.0.0 # 保护模式关闭 protected-mode no # 端口 port 6379 # 后台运行 daemonize yes3.3 创建集群使用redis-cli创建集群# Redis 5.0 使用以下命令redis-cli--clustercreate\192.168.1.101:6379\192.168.1.102:6379\192.168.1.103:6379\192.168.1.104:6379\192.168.1.105:6379\192.168.1.106:6379\--cluster-replicas1参数说明--cluster-replicas 1每个主节点有1个从节点3.4 集群常用命令# 查看集群信息 CLUSTER INFO # 查看集群节点 CLUSTER NODES # 查看key所在的槽 CLUSTER KEYSLOT mykey # 查看槽所在节点 CLUSTER GETKEYSINSLOT 12546 10四、数据迁移4.1 槽位迁移实际场景需要向集群添加一个新节点需要重新分配槽位。添加新节点# 添加新主节点redis-cli--clusteradd-node192.168.1.107:6379192.168.1.101:6379# 重新分配槽位redis-cli--clusterreshard192.168.1.101:6379迁移过程目标节点导入槽位源节点逐个迁移key更新集群元数据迁移完成4.2 数据迁移注意事项注意点说明迁移时间大量数据迁移需要较长时间服务影响迁移期间服务可用但可能有短暂阻塞ASK重定向迁移期间访问迁移中的key需要重定向批量迁移建议在低峰期进行迁移操作五、故障转移5.1 故障检测Redis Cluster故障检测流程节点A发送PING → 节点B无响应 → 标记PFAIL(疑似下线) ↓ 多数节点确认PFAIL → 标记FAIL(真正下线) ↓ 从节点发起选举 → 选举成功 → 升级为主节点5.2 故障转移过程踩坑提醒故障转移期间部分请求可能返回MOVED错误客户端需要正确处理重定向。故障转移步骤从节点检测到主节点下线从节点发起选举请求获得多数主节点投票从节点升级为主节点更新集群槽位映射通知其他节点5.3 手动故障转移# 在从节点上执行手动升级为主节点 CLUSTER FAILOVER # 强制故障转移不等待主节点确认 CLUSTER FAILOVER FORCE # 接管故障主节点主节点已下线 CLUSTER FAILOVER TAKEOVER六、踩坑提醒6.1 跨槽查询问题踩坑提醒Redis Cluster中多key操作如MGET、MSET要求所有key在同一个槽否则报错错误示例# 这两个key可能在不同槽 MGET user:1:name user:2:name # 报错CROSSSLOT Keys in request dont hash to the same slot解决方案使用Hash Tags# 使用{}指定hash tag大括号内的内容参与槽计算 MGET {user}:1:name {user}:2:name # 这样两个key会落在同一个槽6.2 批量操作限制操作类型限制解决方案MGET/MSET必须同槽使用Hash TagsLua脚本默认同槽使用Hash Tags或keys参数事务MULTI必须同槽使用Hash TagsSCAN命令单节点扫描遍历所有节点6.3 客户端连接经验之谈建议使用支持集群模式的客户端如Jedis、Lettuce、redis-py-cluster等它们会自动处理MOVED和ASK重定向。6.4 集群配置常见错误错误原因解决方案集群不可写槽位未全部分配确保所有槽都已分配节点无法加入网络不通或配置错误检查防火墙和配置重定向循环配置文件冲突清理nodes.conf重新创建七、Cluster与哨兵对比7.1 功能对比对比项Redis Cluster哨兵模式数据分片支持不支持高可用支持支持主从复制支持支持故障转移自动自动在线扩容支持不支持客户端支持需要集群客户端普通客户端部署复杂度较高较低最小节点数6个3主3从3个1主2从3哨兵7.2 适用场景选择Cluster数据量大需要分片存储需要横向扩展单机内存无法满足需求选择哨兵数据量不大主要需要高可用部署运维简单八、面试高频考点8.1 Redis Cluster和哨兵的区别答案Redis Cluster和哨兵的主要区别在于功能定位哨兵主要解决高可用问题Cluster既解决高可用又解决数据分片问题数据存储哨兵模式下所有数据在单机Cluster数据分散在多个节点扩展性Cluster支持在线扩缩容哨兵不支持最小部署Cluster至少需要6个节点哨兵需要3个节点1主2从3哨兵客户端Cluster需要支持集群协议的客户端哨兵使用普通客户端即可8.2 为什么Redis Cluster使用16384个槽答案心跳包大小16384个槽只需要2KB位图表示65536需要8KB节省网络带宽节点数量限制实际生产中主节点不超过1000个16384个槽足够分配数据迁移粒度槽位太多会导致迁移粒度过细增加迁移复杂度历史原因设计时的权衡结果兼顾了效率和实用性8.3 Redis Cluster如何保证数据一致性答案异步复制主节点写入后异步同步到从节点存在短暂不一致最终一致性网络正常情况下数据最终会一致读写分离默认读写都在主节点保证强一致性WAIT命令可以使用WAIT命令等待复制完成九、参考资料Redis官方文档 - Redis Cluster十、互动话题你的项目中是否使用过Redis Cluster遇到了哪些问题在数据迁移过程中如何保证业务的平滑过渡对于小规模数据你会选择Cluster还是哨兵模式为什么欢迎在评论区分享你的经验和看法下期预告Day12我们将学习Redis缓存应用实战深入理解缓存穿透、击穿、雪崩的解决方案。
