像很多团队一样我见过太多人把 Redis Cluster 当成了“只要数据多了就上”的万灵药结果集群搭起来之后槽位迁移慢、客户端报 MOVED 重试、故障切换丢数据各种问题接踵而至。真正把 Cluster 吃透的人不会只盯着cluster meet敲命令而是会先搞清楚它到底解决了什么问题、在什么场景下是合适的、在什么场景下反而是负担。Redis Cluster 是 Redis 官方的分布式解决方案核心目标其实就两件事把数据打散到多个节点上以及在部分节点失效时仍然能对外提供服务。它不像主从复制那样只是“多几份备份”也不像哨兵那样只负责故障切换而是把分片和高可用这两件事揉在了一起。这篇文章我会从分片原理、节点通信、故障转移、部署实操、扩缩容、客户端选型到生产环境踩坑把整个集群机制一层层拆开讲适合已经用过 Redis 但没深入看过 Cluster 的开发者也适合正在准备把业务迁到集群上的运维同学。1. 从单机到集群Redis Cluster 到底解决了哪些痛点1.1 单机、主从、哨兵各自的局限先回到最基础的问题为什么会有 Redis Cluster 这个东西。单机 Redis 部署最简单所有数据在一台机器上读写延迟极低但它的天花板也很明确内存上限受机器物理内存约束一台 64G 的机器数据超过 50G 就开始吃力因为还要留内存给操作系统页缓存、AOF 重写缓冲以及碎片开销。更别提单点故障——机器宕机整个缓存层直接消失数据库瞬间被打爆。主从复制解决了单点问题。一个 master 挂多个 replicamaster 挂了可以由 replica 顶上。但主从复制解决的问题是“可用性”不是“容量”。master 和 replica 存的是同一份数据replica 只是把数据多复制了几份内存总量并没有增加。你 master 存不下 60G加再多的 replica 也照样存不下。哨兵Sentinel解决的是故障自动切换的问题。主从复制本身不会自动把请求切到 replica 上需要人为干预或者通过哨兵来监控 master 的存活状态在 master 挂掉的时候执行 failover把 replica 提升为新的 master。哨兵架构能解决高可用但依然没解决容量瓶颈。你仍然需要一台足够大的机器来承载全量数据。这三个阶段的演进脉络很清晰单机讲性能主从讲可用性哨兵讲自动切换。到了数据量真正大到单机装不下的时候就必须引入分片——把数据按照某种规则分散到多台机器上每台机器只存一部分数据这样总容量就可以水平扩展。Redis Cluster 就是这个思路的官方实现。1.2 现网业务什么时候必须上 Cluster根据我在不少生产环境里看到的实际情况什么时候该上 Cluster 是有比较明确的信号的。最典型的一种是单机 Redis 内存使用率达到 70% 以上并且业务增长预期还比较明确比如半年内可能翻倍这时候靠升级机器内存只是缓兵之计。另一种情况是单个 key 的 QPS 极高比如某个热点 key 每秒被访问几十万次单线程的 Redis 实例 CPU 已经接近打满即使加了从库分担读压力写路径依然卡在 master 上。还有一种容易被忽略的场景你在大数据生态里比如 Spark、Kafka、Hadoop 组件做 shuffle、状态存储、元数据缓存时对 Redis 容量的需求往往是突发的。热词里有人搜“kafka redis 集群”其实就是把 Redis Cluster 当作流处理任务的分布式状态后端来用。这种情况下固定的单机容量根本无法跟上任务的分布式调度范围Cluster 的按需扩容能力就成了刚需。但反过来我也要说一句如果你的数据总量不足 20GQPS 不到 10 万单机或者哨兵架构完全够用强行上 Cluster 只会给自己添麻烦。集群模式下key 要带哈希标签才能保证事务性跨槽位操作要小心运维复杂度也高一个量级。数据量没到那个份上Cluster 带来的收益是负的。1.3 Cluster 与主从、哨兵的架构选型对比做个表格来看更直观维度单机主从复制哨兵Redis Cluster数据容量单机内存上限同 master同 master多节点分摊容量可扩展高可用无手动切换自动切换自动切换写入扩展不支持不支持不支持支持多 master 分摊写读扩展不支持支持支持支持运维复杂度极低低中高适用数据量10G10G20G20G 或写入吞吐要求高这个表格基本能回答大多数团队“我到底要不要上集群”的疑问。核心取舍点就一个你的数据规模是不是已经超过了一台机器能承载的合理范围。如果答案是“是”Cluster 几乎是唯一正解如果答案是否定的那 Cluster 只是负担。2. 数据分片与槽位分配16384 个槽是怎么决定数据去留的2.1 槽位 Slot 的设计逻辑Redis Cluster 没有用传统的一致性哈希环而是设计了一个固定长度为 16384 的槽位空间。整个集群有 0 到 16383 共 16384 个槽每个 key 通过 CRC16 算法计算出一个 16 位的哈希值再对 16384 取模得到的结果就是这个 key 所属的槽位。集群里的每个 master 节点负责其中一段连续的槽区间比如节点 A 负责 0-5460节点 B 负责 5461-10922节点 C 负责 10923-16383。为什么不直接用一致性哈希一致性哈希的优点是节点增减时影响的数据范围小但它引入了“虚拟节点”的概念实现复杂度更高而且 Redis 需要在客户端和服务器之间对“key 到底落在哪个节点”达成一致如果客户端自己实现一致性哈希版本和策略就容易分裂。固定槽位的好处是槽位的分配是元数据可以显式地迁移和维护而且槽位的数量是固定的计算简单任何节点都可以独立判断某个 key 是否由自己负责。16384 这个数字也不是随便定的。CRC16 可以产生 16 位也就是 65536 个不同的值但 Redis 作者选择了 16384。原因主要有两个一是槽位越多节点间交换的位图bitmap就越大Gossip 消息体也越大浪费带宽二是 16384 已经足够支撑 1000 个 master 节点的集群规模每个节点平均分到 16 个槽左右负载足够均衡。实际生产环境里大多数集群也就 3 到 10 个 master16384 绰绰有余。2.2 CRC16 与哈希标签 Hash Tagkey 到槽位的映射公式是slot CRC16(key) 16383因为 16384 正好是 2 的 14 次方所以取模可以用位与运算代替性能更高。这里有个很重要的算法特点CRC16 是针对 key 的完整字符串计算而不是针对某个前缀。也就是说user:1001和user:2001会被完全随机地分布到不同槽位所以跨 key 的操作天然受限。为了支持某些需要把多个 key 放到同一个槽位的场景Redis 提供了哈希标签Hash Tag机制。当 key 中出现了花括号{}时CRC16 只计算花括号内的子串。比如user:{1001}:profile和user:{1001}:orders这两个 key 的花括号内都是1001所以它们会被路由到同一个槽位。这个机制对于实现批量操作、事务、Lua 脚本非常关键——因为这些操作都要求涉及的 key 必须在同一个槽里。但是哈希标签也是一把双刃剑。如果你把所有 key 都加上同一个标签比如app:{global}:xxx这些 key 全被路由到一个槽位集群分片就失去了意义。更严重的是业务热 key 配合固定的哈希标签会把某个节点的 CPU 和内存打满形成数据倾斜和热点问题。正确用法是标签的基数必须足够大比如按用户 ID、订单 ID 这类自然高基数字段做标签并且只对确实需要事务保障的少量 key 使用。2.3 MOVED 与 ASK 重定向客户端如何找到正确的节点客户端向集群节点发送命令时节点会先计算这个 key 的槽位再检查自己是否负责这个槽位。如果负责就直接执行命令如果不负责节点不会帮忙转发而是返回一个 MOVED 错误错误里带上了正确的节点地址。客户端拿到这个地址之后需要重新发送命令到正确的节点并且缓存这个槽位和节点的映射关系后续再访问这个槽位就直接打到对应节点上避免每次都重定向。MOVED 是槽位稳定时的永久重定向但集群在做槽位迁移的时候会出现另一种情况目标槽正在从一个节点迁移到另一个节点。此时访问旧节点它如果发现自己已经没有这个 key会返回 ASK 错误告诉客户端去新节点找。ASK 和 MOVED 本质的区别在于MOVED 表示槽位的归属已经变了客户端要更新本地缓存ASK 表示这只是一个临时状态槽位还在迁移中客户端只对当前这一次请求做转发不需要更新缓存。理解这两种重定向很重要因为生产环境里出现的很多“命令超时”“延迟抖动”根因都是客户端没处理好重定向逻辑。Jedis 和 Lettuce 这类成熟客户端内置了重定向处理但如果你自己封装连接池或者用了一些比较底层的客户端就得手动处理 MOVED 和 ASK。还有个细节集群模式下客户端连接任意节点都能获取到集群的拓扑信息所以从哪个节点开始请求其实无所谓关键是拿到拓扑后要缓存下来。3. 节点通信与集群配置Gossip 协议和 cluster bus 是怎么协同的3.1 集群总线一条独立的 TCP 连接Redis Cluster 中的每个节点会同时开启两个 TCP 端口。一个是客户端连接的端口默认 6379用于处理命令请求另一个是集群总线端口默认是客户端端口加 10000也就是 16379用于节点之间的通信。这两个端口必须区分开因为它们的流量特征完全不同前者是命令和响应对延迟极其敏感后者是节点间的状态同步、故障检测、配置发布对带宽和频率要求更高。所有节点之间的通信都走这个 cluster bus包括 Gossip 消息、配置更新、故障投票等。Redis 会尽量多路复用这条连接避免为每个节点对都建立大量 TCP 连接。默认情况下节点之间的连接数维持在 O(N) 级别N 是节点数。这个设计在生产环境里有个实际意义你配置防火墙或者云安全组的时候不能只放行客户端端口集群总线端口也必须放行否则节点之间无法互通集群会一直处于疑似故障状态。3.2 Gossip 协议节点怎么知道彼此的存在和状态集群中的节点通过 Gossip 协议来传播彼此的存活状态和槽位分配信息。这个过程不是靠中心化协调者来广播而是每个节点周期性地向随机选择的一部分节点发送 Ping 消息消息里携带了自己所知道的部分节点状态。收到消息的节点会合并这些信息并在自己的下一个周期里继续传播给其他节点。这种方式的好处是没有单点瓶颈任何节点挂了都不会导致整个集群的元数据无法同步代价是状态传播有延迟节点状态的一致性不是实时的是最终一致的。node 之间通过CLUSTER MEET命令来建立联系。第一次握手时当前节点会与目标节点互相交换 node id、IP、端口等信息并把对方加入自己的节点列表。握手成功后节点会持续地通过 Gossip 维护这份列表。这里有个常见误区cluster meet只需要在任意一个节点上执行一次不用在所有节点上执行因为新节点加入后它的信息会通过 Gossip 传遍整个集群。实际操作中你只要在一个节点上执行CLUSTER MEET指向新节点其他节点会自动与之建立连接。3.3 心跳与主观下线、客观下线每个节点每隔 1 秒会向集群中的其他节点发送一次 Ping同时也会以 1 秒为周期随机挑选几个节点发送更详细的状态信息。当一个节点在cluster-node-timeout默认 15000 毫秒内没有收到某个节点的响应它就会把这个节点标记为PFAIL主观下线。这个状态是单个节点的判断可能是网络抖动导致的误判所以还不能触发故障转移。当集群中超过半数持有槽位的 master 节点都将某个节点标记为 PFAIL 时这个节点的状态就会被提升为FAIL客观下线。此时集群认为这个节点真正不可用了会对它负责的槽位发起故障转移流程。这里的关键阈值是“超过半数 master”也就是说一个只有 3 个 master 的集群至少需要 2 个 master 都认为某个节点挂了才会确认它客观下线。这个设计保证了误判率很低但也带来了一个隐患如果集群由于网络分区被割裂成两半只有少数派那一侧无法凑齐多数票故障转移就不会发生整个分区可能一直在等待。cluster-node-timeout的配置很讲究。太短网络抖动频繁触发 failover造成不必要的主从切换太长master 真的挂了之后客户端要等待很久才能感知到不可用。线上我一般建议设置在 5 到 15 秒之间具体要根据网络环境的稳定性来调整。如果你在云上跑专线网络比较稳定可以适当缩短如果是跨机房或者网络条件较差的环境建议保持默认值甚至调大。4. 主从复制与故障转移从 master 宕机到新的 master 上岗4.1 集群中的主从怎么分配集群中的每一个 master 节点都建议配置至少一个 replica 节点。replica 节点的作用和主从复制中的从库类似从 master 同步全量数据然后持续接收增量数据。但集群中的 replica 有一个额外的职责当它对应的 master 发生故障时replica 会被选举为新的 master接管原来 master 的槽位继续对外服务。这里有个值得一提的设计集群支持 replica 迁移replica migration。当某个 master 挂了且它没有可用的 replica 时其他 master 节点上的空闲 replica 可以自动迁移过去补上这个空缺。这个机制的目的是提高整个集群的容灾能力。比如你有 3 个 master每个配 1 个 replica其中 A 节点连同它的 replica 一起都挂了那么 B 或 C 上的 replica 会有一个被迁移到 A 的槽位上确保 A 的槽位依然有副本可以接管。主从的分配和数据复制仍然依赖每个节点上的replicaof配置或者通过CLUSTER REPLICATE命令动态指定。在集群模式下replica 节点会监听自己的 master 是否存活并实时同步复制偏移量。要查看每个节点的复制状态和健康度最方便的命令是CLUSTER NODES输出中能明确看到每个节点的 role、master 的 node id、复制偏移量等关键信息。4.2 故障切换的投票与选举机制当集群判定某个 master 客观下线并且这个 master 有可用的 replica 时就会触发一次故障切换。整个过程和 Raft 的选举机制很像但简化了很多。所有存活的、对下线 master 的槽位有备份数据的 replica都会尝试发起选举。它们会向所有持有槽位的其他 master 发送FAILOVER_AUTH_REQUEST每个 master 对于一个 term纪元只能投一票拥有超过半数 master 投票的 replica 胜出被提升为新的 master。选举成功后新 master 会通过CLUSTER FAILOVER完成槽位的接管。这个过程中有一个非常重要的机制所有参与投票的节点会递增自己的currentEpoch当前纪元纪元就像一个全局的版本号用来区分不同的选举轮次。如果两个 replica 因为网络原因同时发起了选举纪元能保证集群最终只会接受其中一个胜出避免出现脑裂。4.3 数据不丢失是有条件的集群模式下主从复制默认是异步的。master 执行完写命令后直接返回客户端确认然后异步地把命令复制给 replica。如果 master 在数据复制到 replica 之前就宕机了这部分数据就会丢失。这在大多数缓存场景下是可以接受的但对于把 Redis 当存储用的业务是一个需要认真对待的隐患。为了降低丢失数据的概率需要同时做好几件事。第一开启WAIT命令让写操作等待至少 N 个 replica 确认后再返回但这会显著增加写延迟。第二配置min-replicas-to-write和min-replicas-max-lag当 replica 落后 master 太多或者没有足够的健康 replica 时直接拒绝写入宁可服务不可用也不能丢数据。第三合理设置 AOF 和 RDB 持久化策略确保即使在极端情况下已经落盘的数据也能在重启后恢复。我见过很多团队只开 RDB一旦机器故障重启丢失最近一次 RDB 快照之后的所有数据这种配置在集群模式下尤其危险。5. 从零搭建一个三主三从集群完整实操与验证5.1 环境准备与配置文件搭建集群需要至少 6 个 Redis 实例我习惯按照 3 主 3 从来做部署这样既能测试分片效果也能验证故障切换。创建集群之前每个实例都需要独立端口、独立的数据目录和配置文件。先准备目录结构mkdir -p /data/redis-cluster/{7001,7002,7003,7004,7005,7006}/{data,conf}每个节点对应一份 redis.conf关键配置如下以 7001 为例port 7001 cluster-enabled yes cluster-config-file nodes-7001.conf cluster-node-timeout 5000 appendonly yes appendfilename appendonly-7001.aof dir /data/redis-cluster/7001/data daemonize yes pidfile /var/run/redis-7001.pid logfile /data/redis-cluster/7001/redis.log protected-mode no bind 0.0.0.0这里面cluster-enabled yes是最核心的开关没有它后面的集群命令都无法使用。cluster-config-file是由 Redis 自己维护的记录当前节点的 node id、槽位分配情况、集群内其他节点的信息不需要手动创建。cluster-node-timeout设成 5000 毫秒适合测试环境快速触发故障转移。5.2 用 redis-cli 建立集群所有 6 个节点都启动后在任意一个节点上执行集群创建命令redis-cli --cluster create \ 192.168.1.11:7001 192.168.1.12:7002 192.168.1.13:7003 \ 192.168.1.14:7004 192.168.1.15:7005 192.168.1.16:7006 \ --cluster-replicas 1--cluster-replicas 1表示每个 master 配一个 replica。命令执行后redis-cli 会自己计算槽位分配方案然后要求你确认。确认后它会自动执行CLUSTER MEET、分配槽位、设置 replica 关系整个过程不需要手动干预。如果你在云服务器上部署IP 一定要用节点之间实际可以互通的内网 IP不要用 127.0.0.1。集群一旦建立nodes.conf 里记录的就是你传入的 IP后面改起来非常麻烦。搭好后可以用redis-cli --cluster check 192.168.1.11:7001检查集群状态输出会明确显示每个节点的角色、负责的槽位范围、复制关系是否正常。5.3 验证分片和故障转移集群建好后连接任意节点写几个测试 keyredis-cli -c -h 192.168.1.11 -p 7001 set user:1001 hello set user:2001 world set order:5001 ok-c参数让 redis-cli 自动跟随重定向。你会发现不同的 key 会被路由到不同的节点上。如果不用-c直接连接 7001 并写入不属于它的 key会直接收到 MOVED 错误。这个测试能直观地验证槽位分片是否生效。故障转移的验证更简单。把 7001 节点的进程 kill 掉观察集群状态redis-cli --cluster check 192.168.1.11:7001在cluster-node-timeout设置的时间内集群会自动把 7001 的 replica假设是 7004提升为 master整个过程通常 5 到 10 秒内完成。客户端只需要通过集群拓扑感知到节点角色变化后续写入会打到新的 master 上。这个测试同时也验证了集群模式下自动故障切换的核心能力。6. 集群扩容与缩容槽位迁移背后的细节6.1 添加新节点往集群里加节点分两步先用CLUSTER MEET把新节点加入集群然后给它分配槽位。新加入的节点默认是一个 without slots 的 master 节点或者说你可以让它作为某个 master 的 replica 加进来。加入新 masterredis-cli --cluster add-node 192.168.1.17:7007 192.168.1.11:7001执行后 7007 就在集群里了但它一个槽位都没有不承担任何数据。接下来要把一部分槽从现有节点迁移过来redis-cli --cluster reshard 192.168.1.11:7001这个命令是交互式的会让你输入要迁移多少个槽、目标节点的 node id、从哪些源节点迁移。在迁移过程中源节点会把对应的 key 逐步搬到目标节点迁移完成后更新槽位归属。6.2 槽位迁移的过程一次槽位迁移拉长了看其实就是三步。第一步目标节点向源节点发送CLUSTER SETSLOT {slot} IMPORTING {sourceNodeId}表示我准备接收这个槽第二步源节点发送CLUSTER SETSLOT {slot} MIGRATING {targetNodeId}表示我正在迁出这个槽第三步源节点把槽内的所有 key 通过MIGRATE命令逐个搬到目标节点等所有 key 搬完后广播CLUSTER SETSLOT {slot} NODE {targetNodeId}让整个集群都知道这个槽的新归属。如果你的某个槽里有大量 key迁移会很耗时。这里有并行和限速的权衡redis-cli --cluster reshard支持--cluster-pipeline参数控制每次批量迁移的 key 数管道越大迁移越快但会对源节点造成较大的 CPU 和网络压力。生产环境迁移时我建议管道值先取个中间值比如 10观察一下源节点负载再调。6.3 缩容的正确顺序缩容一般是指把某个 master 及其 replica 移出集群。关键是先把该节点的所有槽位迁移到其他节点确认这个节点不再持有任何数据再执行下线操作。槽位迁移完成后用CLUSTER FORGET让其他节点都忘记这个节点然后停掉它的进程。这里有个容易踩的坑如果你直接 kill 掉一个还持有槽位的 master集群会因为这个节点的槽位无人负责而进入不完整状态插入数据会报错客户端可能收到CLUSTERDOWN Hash slot not served。所以在执行缩容之前务必先确认该节点槽位已经清空可以通过redis-cli --cluster check查看输出的slots:列表应该为空。7. 客户端选型与接入要点为什么你的连接总是报错7.1 主流客户端对 Cluster 的支持程度Java 生态里最常见的是 Jedis、Lettuce 和 Redisson它们对 Cluster 的支持方式差异很大。Jedis 使用简单、线程安全需要靠连接池来控制但它对 Cluster 的支持偏向基础——它会在本地缓存槽位和节点的映射收到 MOVED 后更新缓存本质上是一个“聪明客户端”的经典实现。Lettuce 基于 Netty支持异步和响应式编程对 Cluster 拓扑的感知更智能它能订阅集群节点的拓扑变化事件实时刷新路由表在高并发场景下性能更好。Redisson 则是在 Cluster 之上封装了分布式对象、分布式锁、限流器等高级功能但它的实现比较重适合需要用分布式特性的场景。如果你的服务跑在 Spring Boot 里需要特别留个心眼Spring Data Redis 默认用的是 Lettuce但很多老项目直接配置了 Jedis。在集群模式下Lettuce 对拓扑刷新的处理比 Jedis 更积极故障切换后的重连速度更快。我自己在 Spring Cloud Gateway 或 Sentinel 集成 Redis 集群的时候首选 Lettuce因为网关对线程阻塞极其敏感异步客户端更合适。7.2 连接池与路由的常见问题集群模式下最常见的连接问题有两个。第一个是没有开启cluster-mode直接用了单机客户端连接集群节点。这种情况下客户端收到 MOVED 错误后不会自动重定向只会把错误抛给应用然后应用层就是一片redis.clients.jedis.exceptions.JedisMovedDataException。解决方式很简单用支持集群模式的客户端类并在连接地址里配置多个节点比如redis://192.168.1.11:7001,192.168.1.12:7002。第二个问题是连接池数量和节点拓扑不匹配。很多团队只配置了一个连接池指向集群里的一台节点这在逻辑上其实没问题——通过任意节点的视角都能拿到完整拓扑但如果这台节点挂了连接池就没有备用路径。我建议配置时把集群内所有 master 节点都填进去让客户端在某个节点不可达时能自动切换到其他节点获取拓扑。7.3 哈希标签在客户端层面的使用在客户端代码里使用哈希标签要注意一点标签的正确位置是在 key 的中间不是前缀。比如user:info:{1001}是对的因为花括号部分是参与哈希计算的子串{user:info}:1001会导致所有用户都命中同一个槽这和之前提到的问题是一样的。在亿级用户场景下用{user_id}:xxx做标签可以让同一个用户的所有数据落在同一个节点同时不同用户的标签值不同分片的均衡性也得到保证。还需要注意MGET、事务、Lua 脚本这些操作在集群模式下都要求操作的 key 在同一个槽。即便你用哈希标签把 key 组合好也仍然可能在跨节点执行时收到CROSSSLOT错误。所以写 Lua 脚本之前一定要检查脚本里访问的所有 key 是否都属于同一个槽位。8. 生产环境实战扩容迁移、数据倾斜与踩坑排查心得8.1 扩缩容过程中的客户端抖动处理有一次我在生产集群做扩容迁移了大约 2000 万个 key过程持续了半个多小时。迁移期间客户端时不时出现几百毫秒的延迟尖刺排查下来发现是这么回事槽位迁移过程中被迁移的 key 在源节点上被请求时源节点会返回 ASK 重定向客户端需要额外发起一次请求到目标节点。在某些老版本客户端里ASK 重定向的处理逻辑是同步串行的导致单个请求的耗时翻倍。解决的思路有两个层面。第一个是客户端层面升级到支持异步重定向的版本或者调整连接池参数避免单连接上的请求排队过多。第二个是运维层面尽量把迁移安排在低峰期并且控制迁移速度别让--cluster-pipeline过大以减少 ASK 重定向的频率。还有个技巧迁移前先用redis-cli --cluster reshard查看每个节点的大 key把明显的大 key 手动处理掉再迁移。8.2 数据倾斜一个 hot key 打爆一个节点数据倾斜是集群生产环境里最常见的问题之一。表现形式很典型某个 master 节点的 CPU 和内存明显比其他节点高客户端请求都集中在少部分 key 上。这种热 key 的产生往往和业务相关比如秒杀场景下的商品详情、排行榜里的头部用户、或者消息队列消费中的某个被抢读的 key。定位方法不复杂在可疑节点上执行redis-cli --hotkeys它会利用object freq信息统计最热的 key。找到之后常见的优化手段是给热 key 加随机后缀把压力分散到多个节点。比如product:1001拆成product:1001:0到product:1001:9十个 key读取时随机选一个。这种做法的代价是数据不再是单一副本一致性需要业务侧去处理但换取的是集群整体吞吐的稳定性。也可以用本地缓存把热 key 的请求拦截在应用层只有缓存失效时才穿透到 Redis。8.3 脑裂、网络分区与 cluster-require-full-coverage网络分区是集群模式里比较隐蔽的危险场景。当节点间的网络被隔离成两个分区时少数派分区的节点会发现自己无法联系上多数派于是认为集群处于异常状态。此时如果配置了cluster-require-full-coverage yes默认开启集群会拒绝任何没有覆盖全部槽位的请求表现就是整个集群从客户端视角看直接不可用。这个配置的初衷是保证数据完整性但在很多业务场景下宁可部分节点不可用也不能让整个集群雪崩。所以线上建议根据业务容忍度调整如果 Redis 只是缓存cluster-require-full-coverage no更合适因为部分节点不可用时其他节点的数据依然可以正常读写如果 Redis 存的是核心状态数据那保持默认的 yes 更安全避免把缺失槽位的写入错误地当成成功。脑裂的另一个层面是老 master 被隔离后可能继续接受写入但等分区恢复后这些写入会因为新 master 已经接管而丢失所以前面提到的min-replicas-to-write配置在集群模式下同样有效它能在 master 与至少一个 replica 失联时拒绝写入从源头上减少这类数据丢失。8.4 集群运维中的监控指标集群上线之后监控是保命的。至少需要盯着这几个指标每个节点的connected_clients、used_memory、instantaneous_ops_per_sec、cluster_state、cluster_slots_assigned、以及主从复制的master_repl_offset延迟。如果某个节点的复制偏移量和 master 差距持续增大说明网络带宽或磁盘 IO 已经吃紧需要及时扩容或者清理冷数据。另外一个容易被忽略的点是持久化文件对集群健康的影响。AOF 重写和 RDB 快照在写入磁盘时会占用大量 IO如果一台机器上同时运行了多个 Redis 实例所有实例同时执行持久化的概率不低瞬时 IO 压力会把延迟打上天。我习惯给不同节点设置不同的auto-aof-rewrite-percentage触发阈值并在系统层面用taskset绑核、用ionice调整 IO 优先级尽最大可能避免持久化风暴。说到底Redis Cluster 并不能解决所有分布式缓存的问题但它确实是官方给出的、经过大规模验证的方案。从数据分片到故障转移每个机制都有清晰的设计意图。真正把它跑稳靠的不是把参数调得多花哨而是理解这些机制背后的约束条件然后根据自己业务的真实规模做取舍。我在生产环境里踩过很多坑最后沉淀下来最有用的一句话是不要等到故障发生才去翻文档平时多演练故障切换、多观察槽位分布比什么参数都值钱。 
长河君 · 2026/10/7 12:55:18 · 阅读 1.2k Redis Cluster核心原理与生产实践：从槽位分配到故障转移
像很多团队一样我见过太多人把 Redis Cluster 当成了“只要数据多了就上”的万灵药结果集群搭起来之后槽位迁移慢、客户端报 MOVED 重试、故障切换丢数据各种问题接踵而至。真正把 Cluster 吃透的人不会只盯着cluster meet敲命令而是会先搞清楚它到底解决了什么问题、在什么场景下是合适的、在什么场景下反而是负担。Redis Cluster 是 Redis 官方的分布式解决方案核心目标其实就两件事把数据打散到多个节点上以及在部分节点失效时仍然能对外提供服务。它不像主从复制那样只是“多几份备份”也不像哨兵那样只负责故障切换而是把分片和高可用这两件事揉在了一起。这篇文章我会从分片原理、节点通信、故障转移、部署实操、扩缩容、客户端选型到生产环境踩坑把整个集群机制一层层拆开讲适合已经用过 Redis 但没深入看过 Cluster 的开发者也适合正在准备把业务迁到集群上的运维同学。1. 从单机到集群Redis Cluster 到底解决了哪些痛点1.1 单机、主从、哨兵各自的局限先回到最基础的问题为什么会有 Redis Cluster 这个东西。单机 Redis 部署最简单所有数据在一台机器上读写延迟极低但它的天花板也很明确内存上限受机器物理内存约束一台 64G 的机器数据超过 50G 就开始吃力因为还要留内存给操作系统页缓存、AOF 重写缓冲以及碎片开销。更别提单点故障——机器宕机整个缓存层直接消失数据库瞬间被打爆。主从复制解决了单点问题。一个 master 挂多个 replicamaster 挂了可以由 replica 顶上。但主从复制解决的问题是“可用性”不是“容量”。master 和 replica 存的是同一份数据replica 只是把数据多复制了几份内存总量并没有增加。你 master 存不下 60G加再多的 replica 也照样存不下。哨兵Sentinel解决的是故障自动切换的问题。主从复制本身不会自动把请求切到 replica 上需要人为干预或者通过哨兵来监控 master 的存活状态在 master 挂掉的时候执行 failover把 replica 提升为新的 master。哨兵架构能解决高可用但依然没解决容量瓶颈。你仍然需要一台足够大的机器来承载全量数据。这三个阶段的演进脉络很清晰单机讲性能主从讲可用性哨兵讲自动切换。到了数据量真正大到单机装不下的时候就必须引入分片——把数据按照某种规则分散到多台机器上每台机器只存一部分数据这样总容量就可以水平扩展。Redis Cluster 就是这个思路的官方实现。1.2 现网业务什么时候必须上 Cluster根据我在不少生产环境里看到的实际情况什么时候该上 Cluster 是有比较明确的信号的。最典型的一种是单机 Redis 内存使用率达到 70% 以上并且业务增长预期还比较明确比如半年内可能翻倍这时候靠升级机器内存只是缓兵之计。另一种情况是单个 key 的 QPS 极高比如某个热点 key 每秒被访问几十万次单线程的 Redis 实例 CPU 已经接近打满即使加了从库分担读压力写路径依然卡在 master 上。还有一种容易被忽略的场景你在大数据生态里比如 Spark、Kafka、Hadoop 组件做 shuffle、状态存储、元数据缓存时对 Redis 容量的需求往往是突发的。热词里有人搜“kafka redis 集群”其实就是把 Redis Cluster 当作流处理任务的分布式状态后端来用。这种情况下固定的单机容量根本无法跟上任务的分布式调度范围Cluster 的按需扩容能力就成了刚需。但反过来我也要说一句如果你的数据总量不足 20GQPS 不到 10 万单机或者哨兵架构完全够用强行上 Cluster 只会给自己添麻烦。集群模式下key 要带哈希标签才能保证事务性跨槽位操作要小心运维复杂度也高一个量级。数据量没到那个份上Cluster 带来的收益是负的。1.3 Cluster 与主从、哨兵的架构选型对比做个表格来看更直观维度单机主从复制哨兵Redis Cluster数据容量单机内存上限同 master同 master多节点分摊容量可扩展高可用无手动切换自动切换自动切换写入扩展不支持不支持不支持支持多 master 分摊写读扩展不支持支持支持支持运维复杂度极低低中高适用数据量10G10G20G20G 或写入吞吐要求高这个表格基本能回答大多数团队“我到底要不要上集群”的疑问。核心取舍点就一个你的数据规模是不是已经超过了一台机器能承载的合理范围。如果答案是“是”Cluster 几乎是唯一正解如果答案是否定的那 Cluster 只是负担。2. 数据分片与槽位分配16384 个槽是怎么决定数据去留的2.1 槽位 Slot 的设计逻辑Redis Cluster 没有用传统的一致性哈希环而是设计了一个固定长度为 16384 的槽位空间。整个集群有 0 到 16383 共 16384 个槽每个 key 通过 CRC16 算法计算出一个 16 位的哈希值再对 16384 取模得到的结果就是这个 key 所属的槽位。集群里的每个 master 节点负责其中一段连续的槽区间比如节点 A 负责 0-5460节点 B 负责 5461-10922节点 C 负责 10923-16383。为什么不直接用一致性哈希一致性哈希的优点是节点增减时影响的数据范围小但它引入了“虚拟节点”的概念实现复杂度更高而且 Redis 需要在客户端和服务器之间对“key 到底落在哪个节点”达成一致如果客户端自己实现一致性哈希版本和策略就容易分裂。固定槽位的好处是槽位的分配是元数据可以显式地迁移和维护而且槽位的数量是固定的计算简单任何节点都可以独立判断某个 key 是否由自己负责。16384 这个数字也不是随便定的。CRC16 可以产生 16 位也就是 65536 个不同的值但 Redis 作者选择了 16384。原因主要有两个一是槽位越多节点间交换的位图bitmap就越大Gossip 消息体也越大浪费带宽二是 16384 已经足够支撑 1000 个 master 节点的集群规模每个节点平均分到 16 个槽左右负载足够均衡。实际生产环境里大多数集群也就 3 到 10 个 master16384 绰绰有余。2.2 CRC16 与哈希标签 Hash Tagkey 到槽位的映射公式是slot CRC16(key) 16383因为 16384 正好是 2 的 14 次方所以取模可以用位与运算代替性能更高。这里有个很重要的算法特点CRC16 是针对 key 的完整字符串计算而不是针对某个前缀。也就是说user:1001和user:2001会被完全随机地分布到不同槽位所以跨 key 的操作天然受限。为了支持某些需要把多个 key 放到同一个槽位的场景Redis 提供了哈希标签Hash Tag机制。当 key 中出现了花括号{}时CRC16 只计算花括号内的子串。比如user:{1001}:profile和user:{1001}:orders这两个 key 的花括号内都是1001所以它们会被路由到同一个槽位。这个机制对于实现批量操作、事务、Lua 脚本非常关键——因为这些操作都要求涉及的 key 必须在同一个槽里。但是哈希标签也是一把双刃剑。如果你把所有 key 都加上同一个标签比如app:{global}:xxx这些 key 全被路由到一个槽位集群分片就失去了意义。更严重的是业务热 key 配合固定的哈希标签会把某个节点的 CPU 和内存打满形成数据倾斜和热点问题。正确用法是标签的基数必须足够大比如按用户 ID、订单 ID 这类自然高基数字段做标签并且只对确实需要事务保障的少量 key 使用。2.3 MOVED 与 ASK 重定向客户端如何找到正确的节点客户端向集群节点发送命令时节点会先计算这个 key 的槽位再检查自己是否负责这个槽位。如果负责就直接执行命令如果不负责节点不会帮忙转发而是返回一个 MOVED 错误错误里带上了正确的节点地址。客户端拿到这个地址之后需要重新发送命令到正确的节点并且缓存这个槽位和节点的映射关系后续再访问这个槽位就直接打到对应节点上避免每次都重定向。MOVED 是槽位稳定时的永久重定向但集群在做槽位迁移的时候会出现另一种情况目标槽正在从一个节点迁移到另一个节点。此时访问旧节点它如果发现自己已经没有这个 key会返回 ASK 错误告诉客户端去新节点找。ASK 和 MOVED 本质的区别在于MOVED 表示槽位的归属已经变了客户端要更新本地缓存ASK 表示这只是一个临时状态槽位还在迁移中客户端只对当前这一次请求做转发不需要更新缓存。理解这两种重定向很重要因为生产环境里出现的很多“命令超时”“延迟抖动”根因都是客户端没处理好重定向逻辑。Jedis 和 Lettuce 这类成熟客户端内置了重定向处理但如果你自己封装连接池或者用了一些比较底层的客户端就得手动处理 MOVED 和 ASK。还有个细节集群模式下客户端连接任意节点都能获取到集群的拓扑信息所以从哪个节点开始请求其实无所谓关键是拿到拓扑后要缓存下来。3. 节点通信与集群配置Gossip 协议和 cluster bus 是怎么协同的3.1 集群总线一条独立的 TCP 连接Redis Cluster 中的每个节点会同时开启两个 TCP 端口。一个是客户端连接的端口默认 6379用于处理命令请求另一个是集群总线端口默认是客户端端口加 10000也就是 16379用于节点之间的通信。这两个端口必须区分开因为它们的流量特征完全不同前者是命令和响应对延迟极其敏感后者是节点间的状态同步、故障检测、配置发布对带宽和频率要求更高。所有节点之间的通信都走这个 cluster bus包括 Gossip 消息、配置更新、故障投票等。Redis 会尽量多路复用这条连接避免为每个节点对都建立大量 TCP 连接。默认情况下节点之间的连接数维持在 O(N) 级别N 是节点数。这个设计在生产环境里有个实际意义你配置防火墙或者云安全组的时候不能只放行客户端端口集群总线端口也必须放行否则节点之间无法互通集群会一直处于疑似故障状态。3.2 Gossip 协议节点怎么知道彼此的存在和状态集群中的节点通过 Gossip 协议来传播彼此的存活状态和槽位分配信息。这个过程不是靠中心化协调者来广播而是每个节点周期性地向随机选择的一部分节点发送 Ping 消息消息里携带了自己所知道的部分节点状态。收到消息的节点会合并这些信息并在自己的下一个周期里继续传播给其他节点。这种方式的好处是没有单点瓶颈任何节点挂了都不会导致整个集群的元数据无法同步代价是状态传播有延迟节点状态的一致性不是实时的是最终一致的。node 之间通过CLUSTER MEET命令来建立联系。第一次握手时当前节点会与目标节点互相交换 node id、IP、端口等信息并把对方加入自己的节点列表。握手成功后节点会持续地通过 Gossip 维护这份列表。这里有个常见误区cluster meet只需要在任意一个节点上执行一次不用在所有节点上执行因为新节点加入后它的信息会通过 Gossip 传遍整个集群。实际操作中你只要在一个节点上执行CLUSTER MEET指向新节点其他节点会自动与之建立连接。3.3 心跳与主观下线、客观下线每个节点每隔 1 秒会向集群中的其他节点发送一次 Ping同时也会以 1 秒为周期随机挑选几个节点发送更详细的状态信息。当一个节点在cluster-node-timeout默认 15000 毫秒内没有收到某个节点的响应它就会把这个节点标记为PFAIL主观下线。这个状态是单个节点的判断可能是网络抖动导致的误判所以还不能触发故障转移。当集群中超过半数持有槽位的 master 节点都将某个节点标记为 PFAIL 时这个节点的状态就会被提升为FAIL客观下线。此时集群认为这个节点真正不可用了会对它负责的槽位发起故障转移流程。这里的关键阈值是“超过半数 master”也就是说一个只有 3 个 master 的集群至少需要 2 个 master 都认为某个节点挂了才会确认它客观下线。这个设计保证了误判率很低但也带来了一个隐患如果集群由于网络分区被割裂成两半只有少数派那一侧无法凑齐多数票故障转移就不会发生整个分区可能一直在等待。cluster-node-timeout的配置很讲究。太短网络抖动频繁触发 failover造成不必要的主从切换太长master 真的挂了之后客户端要等待很久才能感知到不可用。线上我一般建议设置在 5 到 15 秒之间具体要根据网络环境的稳定性来调整。如果你在云上跑专线网络比较稳定可以适当缩短如果是跨机房或者网络条件较差的环境建议保持默认值甚至调大。4. 主从复制与故障转移从 master 宕机到新的 master 上岗4.1 集群中的主从怎么分配集群中的每一个 master 节点都建议配置至少一个 replica 节点。replica 节点的作用和主从复制中的从库类似从 master 同步全量数据然后持续接收增量数据。但集群中的 replica 有一个额外的职责当它对应的 master 发生故障时replica 会被选举为新的 master接管原来 master 的槽位继续对外服务。这里有个值得一提的设计集群支持 replica 迁移replica migration。当某个 master 挂了且它没有可用的 replica 时其他 master 节点上的空闲 replica 可以自动迁移过去补上这个空缺。这个机制的目的是提高整个集群的容灾能力。比如你有 3 个 master每个配 1 个 replica其中 A 节点连同它的 replica 一起都挂了那么 B 或 C 上的 replica 会有一个被迁移到 A 的槽位上确保 A 的槽位依然有副本可以接管。主从的分配和数据复制仍然依赖每个节点上的replicaof配置或者通过CLUSTER REPLICATE命令动态指定。在集群模式下replica 节点会监听自己的 master 是否存活并实时同步复制偏移量。要查看每个节点的复制状态和健康度最方便的命令是CLUSTER NODES输出中能明确看到每个节点的 role、master 的 node id、复制偏移量等关键信息。4.2 故障切换的投票与选举机制当集群判定某个 master 客观下线并且这个 master 有可用的 replica 时就会触发一次故障切换。整个过程和 Raft 的选举机制很像但简化了很多。所有存活的、对下线 master 的槽位有备份数据的 replica都会尝试发起选举。它们会向所有持有槽位的其他 master 发送FAILOVER_AUTH_REQUEST每个 master 对于一个 term纪元只能投一票拥有超过半数 master 投票的 replica 胜出被提升为新的 master。选举成功后新 master 会通过CLUSTER FAILOVER完成槽位的接管。这个过程中有一个非常重要的机制所有参与投票的节点会递增自己的currentEpoch当前纪元纪元就像一个全局的版本号用来区分不同的选举轮次。如果两个 replica 因为网络原因同时发起了选举纪元能保证集群最终只会接受其中一个胜出避免出现脑裂。4.3 数据不丢失是有条件的集群模式下主从复制默认是异步的。master 执行完写命令后直接返回客户端确认然后异步地把命令复制给 replica。如果 master 在数据复制到 replica 之前就宕机了这部分数据就会丢失。这在大多数缓存场景下是可以接受的但对于把 Redis 当存储用的业务是一个需要认真对待的隐患。为了降低丢失数据的概率需要同时做好几件事。第一开启WAIT命令让写操作等待至少 N 个 replica 确认后再返回但这会显著增加写延迟。第二配置min-replicas-to-write和min-replicas-max-lag当 replica 落后 master 太多或者没有足够的健康 replica 时直接拒绝写入宁可服务不可用也不能丢数据。第三合理设置 AOF 和 RDB 持久化策略确保即使在极端情况下已经落盘的数据也能在重启后恢复。我见过很多团队只开 RDB一旦机器故障重启丢失最近一次 RDB 快照之后的所有数据这种配置在集群模式下尤其危险。5. 从零搭建一个三主三从集群完整实操与验证5.1 环境准备与配置文件搭建集群需要至少 6 个 Redis 实例我习惯按照 3 主 3 从来做部署这样既能测试分片效果也能验证故障切换。创建集群之前每个实例都需要独立端口、独立的数据目录和配置文件。先准备目录结构mkdir -p /data/redis-cluster/{7001,7002,7003,7004,7005,7006}/{data,conf}每个节点对应一份 redis.conf关键配置如下以 7001 为例port 7001 cluster-enabled yes cluster-config-file nodes-7001.conf cluster-node-timeout 5000 appendonly yes appendfilename appendonly-7001.aof dir /data/redis-cluster/7001/data daemonize yes pidfile /var/run/redis-7001.pid logfile /data/redis-cluster/7001/redis.log protected-mode no bind 0.0.0.0这里面cluster-enabled yes是最核心的开关没有它后面的集群命令都无法使用。cluster-config-file是由 Redis 自己维护的记录当前节点的 node id、槽位分配情况、集群内其他节点的信息不需要手动创建。cluster-node-timeout设成 5000 毫秒适合测试环境快速触发故障转移。5.2 用 redis-cli 建立集群所有 6 个节点都启动后在任意一个节点上执行集群创建命令redis-cli --cluster create \ 192.168.1.11:7001 192.168.1.12:7002 192.168.1.13:7003 \ 192.168.1.14:7004 192.168.1.15:7005 192.168.1.16:7006 \ --cluster-replicas 1--cluster-replicas 1表示每个 master 配一个 replica。命令执行后redis-cli 会自己计算槽位分配方案然后要求你确认。确认后它会自动执行CLUSTER MEET、分配槽位、设置 replica 关系整个过程不需要手动干预。如果你在云服务器上部署IP 一定要用节点之间实际可以互通的内网 IP不要用 127.0.0.1。集群一旦建立nodes.conf 里记录的就是你传入的 IP后面改起来非常麻烦。搭好后可以用redis-cli --cluster check 192.168.1.11:7001检查集群状态输出会明确显示每个节点的角色、负责的槽位范围、复制关系是否正常。5.3 验证分片和故障转移集群建好后连接任意节点写几个测试 keyredis-cli -c -h 192.168.1.11 -p 7001 set user:1001 hello set user:2001 world set order:5001 ok-c参数让 redis-cli 自动跟随重定向。你会发现不同的 key 会被路由到不同的节点上。如果不用-c直接连接 7001 并写入不属于它的 key会直接收到 MOVED 错误。这个测试能直观地验证槽位分片是否生效。故障转移的验证更简单。把 7001 节点的进程 kill 掉观察集群状态redis-cli --cluster check 192.168.1.11:7001在cluster-node-timeout设置的时间内集群会自动把 7001 的 replica假设是 7004提升为 master整个过程通常 5 到 10 秒内完成。客户端只需要通过集群拓扑感知到节点角色变化后续写入会打到新的 master 上。这个测试同时也验证了集群模式下自动故障切换的核心能力。6. 集群扩容与缩容槽位迁移背后的细节6.1 添加新节点往集群里加节点分两步先用CLUSTER MEET把新节点加入集群然后给它分配槽位。新加入的节点默认是一个 without slots 的 master 节点或者说你可以让它作为某个 master 的 replica 加进来。加入新 masterredis-cli --cluster add-node 192.168.1.17:7007 192.168.1.11:7001执行后 7007 就在集群里了但它一个槽位都没有不承担任何数据。接下来要把一部分槽从现有节点迁移过来redis-cli --cluster reshard 192.168.1.11:7001这个命令是交互式的会让你输入要迁移多少个槽、目标节点的 node id、从哪些源节点迁移。在迁移过程中源节点会把对应的 key 逐步搬到目标节点迁移完成后更新槽位归属。6.2 槽位迁移的过程一次槽位迁移拉长了看其实就是三步。第一步目标节点向源节点发送CLUSTER SETSLOT {slot} IMPORTING {sourceNodeId}表示我准备接收这个槽第二步源节点发送CLUSTER SETSLOT {slot} MIGRATING {targetNodeId}表示我正在迁出这个槽第三步源节点把槽内的所有 key 通过MIGRATE命令逐个搬到目标节点等所有 key 搬完后广播CLUSTER SETSLOT {slot} NODE {targetNodeId}让整个集群都知道这个槽的新归属。如果你的某个槽里有大量 key迁移会很耗时。这里有并行和限速的权衡redis-cli --cluster reshard支持--cluster-pipeline参数控制每次批量迁移的 key 数管道越大迁移越快但会对源节点造成较大的 CPU 和网络压力。生产环境迁移时我建议管道值先取个中间值比如 10观察一下源节点负载再调。6.3 缩容的正确顺序缩容一般是指把某个 master 及其 replica 移出集群。关键是先把该节点的所有槽位迁移到其他节点确认这个节点不再持有任何数据再执行下线操作。槽位迁移完成后用CLUSTER FORGET让其他节点都忘记这个节点然后停掉它的进程。这里有个容易踩的坑如果你直接 kill 掉一个还持有槽位的 master集群会因为这个节点的槽位无人负责而进入不完整状态插入数据会报错客户端可能收到CLUSTERDOWN Hash slot not served。所以在执行缩容之前务必先确认该节点槽位已经清空可以通过redis-cli --cluster check查看输出的slots:列表应该为空。7. 客户端选型与接入要点为什么你的连接总是报错7.1 主流客户端对 Cluster 的支持程度Java 生态里最常见的是 Jedis、Lettuce 和 Redisson它们对 Cluster 的支持方式差异很大。Jedis 使用简单、线程安全需要靠连接池来控制但它对 Cluster 的支持偏向基础——它会在本地缓存槽位和节点的映射收到 MOVED 后更新缓存本质上是一个“聪明客户端”的经典实现。Lettuce 基于 Netty支持异步和响应式编程对 Cluster 拓扑的感知更智能它能订阅集群节点的拓扑变化事件实时刷新路由表在高并发场景下性能更好。Redisson 则是在 Cluster 之上封装了分布式对象、分布式锁、限流器等高级功能但它的实现比较重适合需要用分布式特性的场景。如果你的服务跑在 Spring Boot 里需要特别留个心眼Spring Data Redis 默认用的是 Lettuce但很多老项目直接配置了 Jedis。在集群模式下Lettuce 对拓扑刷新的处理比 Jedis 更积极故障切换后的重连速度更快。我自己在 Spring Cloud Gateway 或 Sentinel 集成 Redis 集群的时候首选 Lettuce因为网关对线程阻塞极其敏感异步客户端更合适。7.2 连接池与路由的常见问题集群模式下最常见的连接问题有两个。第一个是没有开启cluster-mode直接用了单机客户端连接集群节点。这种情况下客户端收到 MOVED 错误后不会自动重定向只会把错误抛给应用然后应用层就是一片redis.clients.jedis.exceptions.JedisMovedDataException。解决方式很简单用支持集群模式的客户端类并在连接地址里配置多个节点比如redis://192.168.1.11:7001,192.168.1.12:7002。第二个问题是连接池数量和节点拓扑不匹配。很多团队只配置了一个连接池指向集群里的一台节点这在逻辑上其实没问题——通过任意节点的视角都能拿到完整拓扑但如果这台节点挂了连接池就没有备用路径。我建议配置时把集群内所有 master 节点都填进去让客户端在某个节点不可达时能自动切换到其他节点获取拓扑。7.3 哈希标签在客户端层面的使用在客户端代码里使用哈希标签要注意一点标签的正确位置是在 key 的中间不是前缀。比如user:info:{1001}是对的因为花括号部分是参与哈希计算的子串{user:info}:1001会导致所有用户都命中同一个槽这和之前提到的问题是一样的。在亿级用户场景下用{user_id}:xxx做标签可以让同一个用户的所有数据落在同一个节点同时不同用户的标签值不同分片的均衡性也得到保证。还需要注意MGET、事务、Lua 脚本这些操作在集群模式下都要求操作的 key 在同一个槽。即便你用哈希标签把 key 组合好也仍然可能在跨节点执行时收到CROSSSLOT错误。所以写 Lua 脚本之前一定要检查脚本里访问的所有 key 是否都属于同一个槽位。8. 生产环境实战扩容迁移、数据倾斜与踩坑排查心得8.1 扩缩容过程中的客户端抖动处理有一次我在生产集群做扩容迁移了大约 2000 万个 key过程持续了半个多小时。迁移期间客户端时不时出现几百毫秒的延迟尖刺排查下来发现是这么回事槽位迁移过程中被迁移的 key 在源节点上被请求时源节点会返回 ASK 重定向客户端需要额外发起一次请求到目标节点。在某些老版本客户端里ASK 重定向的处理逻辑是同步串行的导致单个请求的耗时翻倍。解决的思路有两个层面。第一个是客户端层面升级到支持异步重定向的版本或者调整连接池参数避免单连接上的请求排队过多。第二个是运维层面尽量把迁移安排在低峰期并且控制迁移速度别让--cluster-pipeline过大以减少 ASK 重定向的频率。还有个技巧迁移前先用redis-cli --cluster reshard查看每个节点的大 key把明显的大 key 手动处理掉再迁移。8.2 数据倾斜一个 hot key 打爆一个节点数据倾斜是集群生产环境里最常见的问题之一。表现形式很典型某个 master 节点的 CPU 和内存明显比其他节点高客户端请求都集中在少部分 key 上。这种热 key 的产生往往和业务相关比如秒杀场景下的商品详情、排行榜里的头部用户、或者消息队列消费中的某个被抢读的 key。定位方法不复杂在可疑节点上执行redis-cli --hotkeys它会利用object freq信息统计最热的 key。找到之后常见的优化手段是给热 key 加随机后缀把压力分散到多个节点。比如product:1001拆成product:1001:0到product:1001:9十个 key读取时随机选一个。这种做法的代价是数据不再是单一副本一致性需要业务侧去处理但换取的是集群整体吞吐的稳定性。也可以用本地缓存把热 key 的请求拦截在应用层只有缓存失效时才穿透到 Redis。8.3 脑裂、网络分区与 cluster-require-full-coverage网络分区是集群模式里比较隐蔽的危险场景。当节点间的网络被隔离成两个分区时少数派分区的节点会发现自己无法联系上多数派于是认为集群处于异常状态。此时如果配置了cluster-require-full-coverage yes默认开启集群会拒绝任何没有覆盖全部槽位的请求表现就是整个集群从客户端视角看直接不可用。这个配置的初衷是保证数据完整性但在很多业务场景下宁可部分节点不可用也不能让整个集群雪崩。所以线上建议根据业务容忍度调整如果 Redis 只是缓存cluster-require-full-coverage no更合适因为部分节点不可用时其他节点的数据依然可以正常读写如果 Redis 存的是核心状态数据那保持默认的 yes 更安全避免把缺失槽位的写入错误地当成成功。脑裂的另一个层面是老 master 被隔离后可能继续接受写入但等分区恢复后这些写入会因为新 master 已经接管而丢失所以前面提到的min-replicas-to-write配置在集群模式下同样有效它能在 master 与至少一个 replica 失联时拒绝写入从源头上减少这类数据丢失。8.4 集群运维中的监控指标集群上线之后监控是保命的。至少需要盯着这几个指标每个节点的connected_clients、used_memory、instantaneous_ops_per_sec、cluster_state、cluster_slots_assigned、以及主从复制的master_repl_offset延迟。如果某个节点的复制偏移量和 master 差距持续增大说明网络带宽或磁盘 IO 已经吃紧需要及时扩容或者清理冷数据。另外一个容易被忽略的点是持久化文件对集群健康的影响。AOF 重写和 RDB 快照在写入磁盘时会占用大量 IO如果一台机器上同时运行了多个 Redis 实例所有实例同时执行持久化的概率不低瞬时 IO 压力会把延迟打上天。我习惯给不同节点设置不同的auto-aof-rewrite-percentage触发阈值并在系统层面用taskset绑核、用ionice调整 IO 优先级尽最大可能避免持久化风暴。说到底Redis Cluster 并不能解决所有分布式缓存的问题但它确实是官方给出的、经过大规模验证的方案。从数据分片到故障转移每个机制都有清晰的设计意图。真正把它跑稳靠的不是把参数调得多花哨而是理解这些机制背后的约束条件然后根据自己业务的真实规模做取舍。我在生产环境里踩过很多坑最后沉淀下来最有用的一句话是不要等到故障发生才去翻文档平时多演练故障切换、多观察槽位分布比什么参数都值钱。