Redis分片集群在后端面试里出现的频率有多高？我最近帮朋友做模拟面试，十份简历里至少有五六份写着“精通Redis”，可真问到分片集群，能讲透的人少得可怜。很多人不是没用过，而是只停留在主从复制和哨兵那层，一听到“分片”就开始含糊。
这篇文章就把大厂面试官围绕 Redis 分片集群最常考的核心考点，从“为什么需要分片”到“Cluster 怎么运作”，再到“面试现场怎么组织回答”，一层层拆开讲。无论你是准备面试，还是正在管理一个逐渐逼近单机瓶颈的 Redis 环境，这套内容都值得过一遍。
1. 面试官一句“分片集群都不懂”，背后到底在考什么
面试中突然来一句“Redis 分片集群都不懂，还来面试”，听着像是刁难，其实是一个递进式探底的信号。考官真正想看的不是你背了多少 Redis 命令，而是你有没有建立一套从单机到分布式的完整认知框架。
1.1 从单机 Redis 到分片集群：一套标准的递进式考法
我见过很多候选人的 Redis 知识是“点状”的：知道 String、Hash、List 怎么用，知道缓存穿透、击穿、雪崩的应对手段，主从复制也能说出个大概。但面试官只要顺着这条线往下推，问题很快就暴露了。
典型的提问路径是这样的：先问单机 Redis 的 QPS 上限大概在什么量级，再问主从复制解决了什么问题，接着问哨兵模式和高可用是怎么回事，最后问“如果数据量超过单机内存，写入也打满了一个实例，怎么办”。到“怎么办”这一步，正确的答案就是分片集群。
这个递进不是随便设计的。单机 Redis 是基础，主从复制解决“读压力”，哨兵解决“故障自动切换”，分片集群解决“容量上限和写入单点”。如果候选人连前几层都讲不清，分片集群自然更讲不清。面试官那句话，本质上是在快速过滤“只背了八股、没有深入理解”的候选人。
1.2 最常见到的三个知识盲区
根据我看到的实际问题，候选人最容易在这三处翻车。
盲区一：以为分片就是简单的 key 取模。很多人知道分布式存储会把数据分散到多台机器上，于是想当然认为 Redis 分片就是hash(key)%节点数。但这解释不了槽位迁移、节点扩缩容时的数据重分布，也说不清为什么 Redis 官方不用一致性哈希。
盲区二：说不清 MOVED 和 ASK 的区别。这两个错误码是 Redis Cluster 重定向的核心。如果只能说出“key 不在当前节点就返回一个地址”，说明没看过协议细节，更没理解客户端应该怎么处理。
盲区三：不知道迁移过程中的真实影响。很多人以为扩缩容就是把槽挪一挪，完全没想过大 key 迁移会阻塞、迁移期间访问正在迁移的 key 会怎样、配置了cluster-require-full-coverage后单节点宕机为什么会让整个集群拒绝写入。
1.3 回答的上限，往往决定面试的结果
结合我看到的通过率，回答分片集群问题是有明显层次的：
- 及格线：能说清楚单机、主从、哨兵、分片各自解决什么问题；
- 进阶线：能讲出哈希槽的计算、Gossip 交互、MOVED/ASK 的流程；
- 高分线：能结合生产实践，说出扩缩容细节、故障转移过程、客户端兼容性、迁移期性能抖动这些普通文档里不会写的东西。
如果面试官愿意多追问，通常就是因为候选人已经讲到了进阶线。后面会详细展开每一层怎么答。
2. 主从复制和哨兵模式撑不住的时候，分片集群才登场
很多人对 Redis 分片集群有误解，以为它是主从复制的替代品。实际上它们解决的是完全不同的两类问题。搞清楚这一点，面试中就已经赢了一半。
2.1 主从复制治的是“读”的病
先看主从复制解决了什么。单机 Redis 读写全在一个进程里，读请求越来越多时，单实例的 CPU、网卡都会成为瓶颈。主从复制把一个 master 的数据复制到多个 replica，读请求可以分摊到从节点上，主节点专心处理写。
复制的机制大致是这样：从节点首次连接主节点时，主节点会生成 RDB 快照发给从节点，从节点加载后再追赶增量数据；后续增量通过复制缓冲区（repl_backlog）持续同步。这里有个很容易被追问的点：如果同步期间从节点没有及时消费，复制缓冲区被覆盖了，从节点只能全量重同步，代价就比较高。
主从复制的问题也很明确：它只扩展了“读”，没有改变“写”。所有的写入仍然要到同一个 master 上完成。写 QPS 一旦触及单实例上限，加从节点一点用都没有。
2.2 哨兵模式补上高可用，但写入仍然单点
哨兵（Sentinel）在主从复制之上加了自动故障检测和切换。当一个主节点不可达，哨兵集群会先标记主观下线，多个哨兵确认后转成客观下线，然后通过投票选出一个新哨兵来执行故障转移，把某个从节点提升为新主节点。
这套机制让 Redis 在高可用上迈了一大步：主节点挂了，业务能自动恢复。但仔细看，哨兵模式的管理对象仍然只有一个主节点、若干从节点。数据整体还是放在一份主数据上，写入仍然是单点。
真正的问题出现在两个场景：
一是数据量逼近单机内存上限。比如一个实例分配 64GB 内存，实际用了 55GB，RDB 持久化、内存碎片、fork 时机一叠加，实例随时可能因为内存不足或 fork 耗时过长而抖动。主从复制不能把一份数据拆开，加从节点只会让内存成本翻倍。
二是写并发超过单实例处理上限。Redis 主线程是单线程模型，一个实例能支撑的写 QPS 是有天花板的。当业务需要高速写入大量计数、订单状态、实时数据时，单主节点再怎么调优也扛不住。
2.3 分片不是替代，是在主从之上再切一刀
正确理解分片集群的方式是：集群里每一个分片，本质上仍然是“一个主节点 + 若干从节点”的复制组。分片只是把整个 key 空间切成了多段，每段由一个分片负责，每个分片的内部照样做主从复制和高可用。
所以对比就很清晰了：
| 维度 | 单机 / 主从复制 | 主从复制 + 哨兵 | Redis 分片集群 |
|---|---|---|---|
| 数据容量 | 受单机内存限制 | 受单机内存限制 | 随分片横向扩展 |
| 写能力 | 单点写入 | 单点写入 | 多个分片并行写入 |
| 读能力 | 可从节点扩展 | 可从节点扩展 | 可从节点扩展，也可跨分片 |
| 高可用 | 无自动切换 | 哨兵自动切换 | 集群内部自动 failover |
| 复杂度 | 低 | 中 | 高，需要处理槽位与客户端 |
很多生产环境给出的答案其实就是这样一道分水岭：当单节点内存逼近上限，或者写 QPS 已经无法靠优化实例参数解决，就应该认真考虑上分片集群；如果只是读多写少，主从加哨兵通常够用。这个判断本身就是面试官想听到的思维方式。
3. Redis Cluster 核心机制：从槽位计算到节点间通信
聊到具体机制，面试就进入高潮了。Redis Cluster 最核心的三件事：数据怎么分、节点之间怎么互相通信、客户端怎么找到数据。这三件事都离不开哈希槽和 Gossip 协议。
3.1 16384 个哈希槽是怎么来的
Redis Cluster 不分 key 本身，而是把 key 空间划分成 16384 个哈希槽，每个主节点负责一部分槽位。计算方式是CRC16(key) % 16384。
为什么是 16384 而不是更大的数字？这个问题面试里被问得很多。简化版理解是：槽位数量得足够多，才能让数据分布均匀，多到不会让某个节点成为明显热点；但同时不能太大，因为节点之间要通过位图（bitmap）交换槽位信息，槽位越多，心跳包携带的数据就越大。16384 约等效于 2KB 的位图，在均匀性和通信成本之间取了平衡点。
槽位的分配不是自动完成的。新建集群时，redis-cli --cluster create会把 16384 个槽尽量平均分给每个主节点。如果想手动指定，也可以用命令：
redis-cli -p 7001 CLUSTER ADDSLOTS 0 1 2 3 4 5这句命令的意思是把槽 0 到 5 分配给当前节点。
客户端访问时，流程是这样的：客户端对 key 做一次 CRC16 取模，算出目标槽位，再查本地槽位映射表去找对应节点。如果不知道怎么映射，可以随便连一个节点，Redis 会给出重定向。用-c参数的客户端会自动处理这些重定向：
redis-cli -c -p 7001 127.0.0.1:7001> set name chris -> Redirected to slot [5798] located at 127.0.0.1:7003 OK同时要注意，Cluster 模式下多 key 操作有限制。mget、sinter、事务、Lua 脚本涉及的所有 key 必须落在同一个槽位，否则集群会直接报错。解决办法是使用哈希标签（hash tag），让同一组 key 只对着花括号里的内容计算槽位：
set user:1001:name chris set user:1001:age 18这两个 key 不会落在同一槽位，因为user:1001:name和user:1001:age整体 CRC16 结果不同。但如果改成：
set {user:1001}:name chris set {user:1001}:age 18花括号内的user:1001会被作为槽位计算依据，两个 key 就能强行分到同一个槽位。这是生产里非常常用的设计技巧。
3.2 Gossip 协议与 Cluster Bus：信息和状态是怎么互相传递的
每个 Redis Cluster 节点除了监听客户端端口，还会开放一个 Cluster Bus 端口（默认是客户端端口加 10000）。节点之间用这个端口互相通信，交换的不只是槽位信息，还有节点的状态、故障信息、配置纪元等。
通信方式不是每次都全网广播，而是采用 Gossip 协议。大致流程是：每隔 100ms，节点会从集群内随机挑一个节点发送 PING；收到 PING 的节点回应 PONG，并附上自己已知的其他节点状态。这样经过一段时间，所有节点最终都会知道其他节点的状态。
这种随机传播的好处是省带宽，不是每次消息都发给所有人。坏处也显而易见：消息是“最终一致”的，节点之间对某个节点是否故障的判断可能短暂不一致。
判断故障的过程是这样的：如果 A 节点长时间没有回应 B 节点的 PING，超过cluster-node-timeout（默认 15 秒），B 会把 A 标记为疑似下线（PFAIL）。A 的 PFAIL 状态会通过 Gossip 传播给其他节点。当集群中过半数的节点都认为 A 疑似下线，A 就被正式标记为下线（FAIL），并把 FAIL 消息广播出去。
“过半数确认”这个机制防止了单节点的误判带走一个健康节点。这也是分布式系统里很典型的少数服从多数思路。
3.3 MOVED 与 ASK：两次重定向背后的不同语义
客户端访问某个 key 时，如果连接的不是负责该槽位的节点，Redis 会返回一个重定向错误。最常见的两个就是 MOVED 和 ASK。
MOVED 表示槽位已经确定在别的节点上。比如当前节点返回：
MOVED 5798 127.0.0.1:7003意思是：这个槽不在我这，在 7003 节点上，你以后直接找它。客户端收到 MOVED 后，不仅会重新发起请求，还会更新本地的槽位映射缓存，后续计算同一槽位的请求直接走新节点。
ASK 则出现在槽位迁移过程中。如果某个槽正在从源节点迁往目标节点，迁移到一半，客户端访问该槽下的 key，可能遇到两种情况：key 若还没被迁走，源节点直接处理；key 若已经迁走了，源节点返回：
ASK 5798 127.0.0.1:7003这里微妙的区别在于：ASK 只表示“这一次请求请到 7003 试试”，客户端不能更新缓存，因为槽位还没有正式完成迁移，迁移完成后仍可能发生变化。所以 ASK 之后，客户端还要先发一条ASKING命令，目标节点确认后才执行真正的读或写操作。
MOVED 是永久搬家，ASK 是临时借道。把这两个概念理解到这一层，答出来基本就能超过大多数候选人。
3.4 Redis Cluster 对操作类型的“连带限制”
分布式环境下，跨节点操作的成本极高，Redis 干脆从设计上做了限制。面试中如果能主动说出这些限制，会显得对组织架构理解很透。
比如事务和 Lua 脚本要求所有 key 必须落在同一槽位。为什么不支持跨槽事务？因为 Redis 事务和执行 Lua 脚本都希望整个操作在一个节点内原子完成。跨节点意味着需要分布式事务，成本高得多，Redis 选择不去做。
又比如RENAME、BRPOPLPUSH、SINTERSTORE这类涉及多个 key 的命令，同样要求同槽。如果线上业务大量使用这类操作，分片集群反而会带来兼容性问题，这也是很多老系统不敢轻易迁移到 Cluster 的原因之一。面试官问到“为什么有些场景不适合上集群”，能说出这一点就很有分量。
4. 从搭建到扩缩容：这些细节才是真正的分水岭
原理讲得再顺，没有亲手搭过集群，一到面试追问细节还是会露馅。尤其是扩缩容、故障转移、配置项这些真实运维里天天发生的事，才是面试官区分“背过文档”和“真正用过”的地方。
4.1 本地六节点集群快速搭建的关键参数
推荐用 3 主 3 从的规模做练习。准备 6 个配置文件，比如 7001 到 7006，每个配置内容大致如下：
port 7001 cluster-enabled yes cluster-config-file nodes-7001.conf cluster-node-timeout 15000 appendonly yes daemonize yes重点解释几个参数：
cluster-enabled yes：开启集群模式，不开这个参数，后面的 redis-cli 集群命令全部无效。cluster-config-file：每个节点有自己的配置文件路径，这个文件由 Redis 自动生成和维护，里面记录了节点的 ID、槽位分配、伙伴节点等。多个节点不能共用同一个文件。cluster-node-timeout：超过这个时间没收到 PING 回应，就开始走疑似下线流程。
启动 6 个节点后，用一行命令创建集群：
redis-cli --cluster create \ 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \ 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \ --cluster-replicas 1--cluster-replicas 1的意思是每个主节点分配 1 个从节点。Redis 会自动分配槽位，尽量不要让主节点集中在同一台机器上，这是生产部署的经验，本地测试则可以放宽。
创建后验证：
redis-cli -p 7001 CLUSTER INFO看到cluster_state:ok和cluster_slots_assigned:16384，说明槽位全部派完，集群已经可用。
4.2 在线扩缩容：reshard 到底做了什么
要往集群里加新节点，一般是先CLUSTER MEET让新节点加入，再用redis-cli --cluster reshard从旧节点分一部分槽过去。
redis-cli --cluster reshard 127.0.0.1:7001 \ --cluster-from <old-node-id> \ --cluster-to <new-node-id> \ --cluster-slots 100 \ --cluster-yes这里有个关键认知：槽位迁移的最小单位是槽，但实际迁移数据时是一个 key 一个 key 地用MIGRATE命令从源节点搬到目标节点。
迁移过程中访问 key 的表现需要特别关注。一个 key 在迁移时，客户端可能在源节点或目标节点都找不到它，也可能先遇到 ASK 再遇到 MOVED，表现是一次请求在多个节点之间转了一圈。这对业务来说通常是透明的，因为客户端会自动重定向，但延时确实会比平时高一些。
生产环境做 reshard 时务必注意：
- 避开业务高峰，建议在低峰期执行；
- 不要一次迁移太多槽位，迁移本质上是在批量搬运数据，会消耗实例的 CPU、网络和内存；
- 如果有超大 key，迁移时源节点可能明显卡顿。因为单个 key 的迁移是同步操作，大 key 一次搬运很耗时，期间源节点无法处理其他请求。Redis 单线程模型下，这个阻塞尤其明显。
4.3 故障转移：从节点晋升与配置纪元
节点宕机后，集群不会让对应槽位一直空转。只要该主节点有从节点，从节点就会发起选举，争取成为新主节点。
选举不是随机的。从节点需要满足条件才敢参选：本节点复制的主节点已经被标记为 FAIL；本节点的复制偏移量比较新，不能落后主节点太多；从节点会向集群内发起投票请求，需要获得过半数的有效主节点投票，最终胜出的从节点把自己的配置纪元（configEpoch）递增，执行SLAVEOF NO ONE，接管原主节点的所有槽位，并广播消息。
配置纪元这个字段很有意思。每一轮关键的配置变更都会带上一个单调递增的 number，类似分布式系统里的任期。当两个节点对同一槽位的主从归属有争议时，配置纪元更大的节点说了算。这从机制上降低了“脑裂”后两个节点都认为自己是主节点的冲突概率。
手动演练的话可以这样做：往 7001 写几个 key，然后用kill -9干掉 7001 进程，过十几秒再执行：
redis-cli -p 7002 CLUSTER NODES你会看到原 7001 对应的从节点已经变成 master，角色列从slave变为master。
4.4 生产环境最容易踩的坑
这些年帮别人排查 Redis Cluster 问题，有几个坑反复撞到。
坑一：cluster-require-full-coverage。这个配置默认是 yes，意思是集群中一旦有槽位没有节点负责，整个集群就不会再对外提供读写服务。听起来很安全，但在生产环境里是个隐患：如果主节点宕机且它的从节点由于某些原因没能及时顶上，会出现“明明大部分节点是健康的，集群却直接拒绝写入”的线上事故。很多团队会把这项改成 no，让只有缺失槽位的数据受影响，尽量保住其他分片的服务。具体采用哪种，取决于业务对“部分不可用”和“全部不可用”的取舍。
坑二：客户端槽位缓存过期。很多客户端库会在本地缓存槽位到节点的映射。如果集群发生重分配，缓存没及时更新，客户端会一直请求已经不再持有该槽位的节点。成功的重定向逻辑会自动刷新缓存，但如果客户端实现有问题，就可能反复收到 MOVED 却一直访问旧节点，表现为访问不稳定。
坑三：Cluster 下从节点默认不直接提供读服务。从节点在故障转移后负责写流量，但在平时如果客户端直连从节点读，通常会被重定向到主节点，需要先发READONLY命令才允许从节点响应读请求。这意味着，分片集群并不能简单地把读流量挂到从节点上分担主节点压力，读写分离的玩法在 Cluster 里要谨慎设计。
坑四：扩容时槽位转移不均。如果只把新节点加入集群，不主动 reshard，新节点的槽位数是 0，不会收到任何数据。所以扩完之后记得做数据均衡，否则新节点白白占资源。
5. 面试现场，怎么把 Redis 分片集群答出层次感
知道答案和能把答案讲得让面试官点头，是两回事。面试不是背材料，而是在短时间内证明“我真的搞明白了”。分片集群这种知识点尤其适合用三层结构来回答。
5.1 一个万能的“三层回答”模板
不管你被问到“Redis Cluster 怎么样”“分片集群遇到过什么问题”，都可以用这个结构：
- 第一层，说场景：阐述在什么情况下需要分片，和主从、哨兵的区别；
- 第二层，说原理：讲哈希槽、Gossip、MOVED/ASK 这些核心机制；
- 第三层，说实操：讲迁移、故障转移、配置项、客户端兼容性。
用这个模板组织一个示例回答：
“我在单机 Redis 碰到过两个问题，一是内存逼近上限，二是写 QPS 打到单实例瓶颈。主从复制能分摊读压力，哨兵能解决主节点故障，但它们都不解决数据装不下和写不动的核心矛盾。所以我后来会考虑 Redis Cluster。它把 key 空间按 CRC16 取模分成 16384 个槽，槽均匀分布在多个主节点上，每个主节点再挂从节点做高可用。节点之间用 Gossip 协议同步状态。客户端访问时如果不命中当前节点，会收到 MOVED 或 ASK 重定向。迁移槽位时我一般放低峰做，而且特别小心大 key 迁移，因为它会阻塞源节点。之前我遇到过 cluster-require-full-coverage 导致单点故障拖垮整个集群写入的情况，后来改成按业务权衡部分可用和全部不可用。”
这段回答从场景到原理再到真实操作，已经覆盖了大部分面试官接下来想追问的方向。
5.2 面试官最爱的连环追问和参考思路
如果回答够好，面试官会往下追几个经典问题。提前准备这些追问绝对不亏。
追问一：为什么是 16384 个槽，不是更多？
参考思路：槽位数量在分布均匀性和节点通信开销之间取平衡。槽太少，数据容易挤在一起，扩容时单次迁移数据量太大；槽太多，节点之间同步槽位位图会占用更多带宽，16384 大约对应 2KB 的 bitmap，比较合适。
但要补充一句：这只是一个工程上的权衡，不是严格的最优解。能说出这层“工程权衡”的意思，比背数字要加分。
追问二：MOVED 和 ASK 有什么区别？
参考思路：MOVED 是槽已经完成迁移，客户端需要更新本地缓存并直接访问新节点；ASK 是槽还在迁移中，客户端只能在本次请求内临时跳转到目标节点，不能更新缓存。
追问三：迁移过程正在访问一个 key 会发生什么？
参考思路：如果 key 还在源节点，源节点直接处理；如果 key 已经迁走，源节点返回 ASK，客户端带上 ASKING 请求目标节点。整个过程对用户是透明的，但延时可能增加。
追问四：主节点挂了之后多久能恢复？
参考思路：由 cluster-node-timeout 决定，默认 15 秒。如果主节点失联超过这个时间，从节点才会进入选举。所以把这个参数调小可以加快切换，但太小会增加误判风险。
追问五：分片集群能解决热点 key 吗？
参考思路：不能直接解决。如果某个 key 被大量请求，它只会落在一个槽位、一个节点上，其他节点帮不上忙。常规做法是加本地缓存、对热点 key 做二级拆分，或者配合多级缓存。
追问六：集群在故障切换时可能丢数据吗？
参考思路：要考虑实际。Redis 的故障转移不是强同步复制，从节点复制到的最新数据可能落后于主节点。极端情况下，主节点刚写入还没来得及同步就宕机，新主节点上就没有这条数据。这也引出另一个话题：是否要开启 wait 或强制同步策略，在性能和数据安全之间取舍。
5.3 别给自己挖的三个坑
- 不要说“Redis Cluster 支持跨槽事务”。它只是同槽事务。这句话说错，面试官立刻知道你没真正用过。
- 不要把主从复制当成分片集群。主从只有一份数据，分片有 16384 个槽分配给不同节点。能区分“复制”和“分片”是前提。
- 不要回避“没在生产环境用过”。与其硬编，不如说“我本地搭过，也做过故障转移演练，但生产环境大规模治理还没经历过，希望能了解你们在迁移和扩容上的做法”。诚实加好奇心，通常比编造经验更有价值。
6. 没有生产环境，这些实验足够你补出“实战手感”
技术和面试最残酷的地方在于：如果只是看文档，细节不会长在肌肉记忆里。以下三组实验可以在本地快速完成，练完之后面对追问会踏实很多。
6.1 用 Docker 起一套最小集群
用 Docker 是最省事的方式。先创建自定义网络再启动容器，注意每个容器要显式开启集群模式：
docker network create redis-cluster-net for port in 7001 7002 7003 7004 7005 7006; do docker run -d --name redis-$port \ --network redis-cluster-net \ -p $port:$port \ -p $((port+10000)):$((port+10000)) \ redis:7.2 redis-server \ --port $port \ --cluster-enabled yes \ --cluster-config-file nodes-$port.conf \ --appendonly yes done如果你只是想快速看效果，不推荐把 6 个容器都手动挂目录，关键是把 Cluster bus 端口（10000+命令端口）也映射出来。很多新手在这里踩坑：只开放了命令端口，节点之间无法互相通信，集群建好之后一路报错。
然后执行创建命令：
docker exec -it redis-7001 \ redis-cli --cluster create \ 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \ 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \ --cluster-replicas 1注意容器内的 127.0.0.1 地址实际指向各自容器自身，所以在真正的多机环境中要把 IP 换成宿主机内网地址；本地实验这样能跑通即可。
6.2 故障转移和重定向的完整演练流程
集群起来后，先做一组故障转移演练。
第一步，往 7001 节点写入若干 key：
redis-cli -c -p 7001 > set order:10001 paid > set order:10002 paid第二步，强制杀掉 7001 进程：
docker stop redis-7001第三步，等待十几秒后查看节点状态：
redis-cli -p 7002 CLUSTER NODES你会看到原 7001 对应的从节点已经切换成主节点，角色从 slave 变成 master。
第四步，恢复旧 7001 容器：
docker start redis-7001这时它应该作为从节点重新加入集群，跟着新主节点复制数据。
再练重定向。用redis-cli --cluster reshard把某个槽从 7001 迁到 7002，迁徙过程中反复读取该槽下的 key，观察-c客户端如何自动处理 ASK 和 MOVED：
redis-cli -c -p 7001 CLUSTER GETKEYSINSLOT 5798 10如果读到一个正在迁移的 key，客户端可能报出 ASK 重定向，下一跳再自动处理。这种细微的交互不亲手跑一遍很难建立直觉。
6.3 运行观测指标和常见错误信息
最后说几个我平时看集群必看的指标。执行CLUSTER INFO时，重点关注：
cluster_state:ok：集群是否可用；cluster_slots_assigned:16384：槽位是否派发完毕；cluster_known_nodes：节点数是否符合预期；cluster_epoch：配置纪元，故障切换后这个值会变化。
日志里也有几个高频报错，遇到时别慌：
CLUSTERDOWN The cluster is down：通常和cluster-require-full-coverage配置有关，说明有槽位无人负责；MOVED ...：客户端连接到的节点不是槽位负责人，多出现在客户端槽位缓存过期时；ASK ...：槽正在迁移，临时跳转；READONLY You can't write against a read only slave：客户端连接的是从节点且没发 READONLY。
这几类报错排查的路径基本一致：先看CLUSTER NODES确认节点角色，再看CLUSTER INFO确认槽位状态，再回客户端侧看缓存刷新逻辑。
最后分享一点个人体会：Redis 分片集群的知识点看着多，真正形成体系只需要抓住“槽位分配、节点通信、重定向、故障转移、扩缩容”这五条线。面试中被问倒不可怕，可怕的是答到一半自己都没想清楚。如果看完这篇之后能动手搭一套最小集群，亲手杀一次节点，再重新拉起旧节点，很多原本靠背的细节会变得特别自然。后面的面试再遇到这类问题，你说话的状态会和现在完全不同。
