Redis Cluster 切片集群：16384 个槽如何把数据分到多台机器

主从复制和哨兵解决的是副本和故障切换问题，但它们没有从根上解决单机容量问题。一个主库再配几个从库，写入入口仍然主要集中在这个主库上。数据量继续增长，内存放不下，或者单个主节点的读写压力已经太高，就需要把数据拆到多台机器上。

资料 在哨兵之后讲 Redis 切片集群，开头说得很明确：当数据量大到一台服务器无法承载时，需要使用 Redis 切片集群方案。它会将数据分布在不同服务器上，降低系统对单主节点的依赖，提高 Redis 服务的读写性能。

这句话里有两个重点。第一，切片集群解决的是数据分布，不只是备份。第二，它降低的是单主节点依赖，不是让每台机器都保存全部数据。理解这一点，后面再看 slot、客户端路由、节点通信，逻辑就顺了。

Redis Cluster 不是直接把 key 平均扔到几台机器上。文中写到，切片集群会把整个数据集划分为 16384 个槽，也就是 slot。每个槽对应一个整数值，每个节点负责管理其中一部分槽的数据。

可以把 slot 理解成 key 和节点之间的一层中间映射。客户端写入一个 key，不是先问“这台机器忙不忙”，而是先算这个 key 属于哪个槽，再找到负责这个槽的节点。节点扩容、迁移、故障切换时，调整的是槽和节点的对应关系，而不是把每个 key 的路由规则都重新设计一遍。

这个设计让集群管理更有边界。假设有三个主节点，可以把 0 到 5460 分给 A，5461 到 10922 分给 B，10923 到 16383 分给 C。后面增加节点时，也可以迁移一部分槽过去。业务看见的是 key，集群内部管理的是槽。

文中说，当新的键值对被添加到切片集群时，会根据 key 的 CRC16 哈希值确定它属于哪个槽，然后把数据存储到负责该槽的节点上。客户端连接集群时，也会通过计算 key 的 CRC16 哈希值确定槽位，再把请求发到负责该槽的节点。

这条路径可以写成：key 经过 CRC16 计算，结果再对 16384 取模，得到 slot 编号。slot 编号落在哪个范围，请求就发给哪个主节点。比如某个 key 算出来属于 9387 号槽，而 9387 号槽由 Master B 负责，那么读写请求就应该到 Master B。

这也是 Redis Cluster 和一些代理式方案不同的地方。已有内容提到客户端可以直接与负责相应数据的节点通信，无需中间代理。客户端要理解集群槽位信息，知道请求该去哪里；节点返回重定向信息时，客户端也要能更新自己的路由缓存。

一个集群有多个节点，节点之间必须知道彼此是否还活着、负责哪些槽、拓扑有没有变化。文中写到，切片集群中的节点通过 gossip 协议相互通信，分享节点信息和集群状态。节点使用 PING、PONG 等消息保持通信，并通过定期的信息交换保持一致性。

gossip 的特点是分散传播。它不像一个中心配置服务把所有状态推给每个节点，而是节点之间不断交换自己知道的信息。随着 PING、PONG 消息在集群里传播，每个节点逐渐知道其他节点的状态变化。

这类机制的好处是去中心化，集群不用把所有判断都压在一个管理节点上。代价是状态传播不是瞬间完成的，异常检测和拓扑收敛需要时间。因此在故障、网络抖动、节点迁移时，短时间内出现路由变化、重试或重定向，都属于集群模式下需要接受和处理的现实。

切片集群把数据分到多个主节点，但每份数据仍然要考虑副本。文中说，切片集群使用主从复制机制，每个槽都有一个主节点和若干个从节点。数据在主节点写入后，会异步复制到从节点上，保证数据持久性和高可用性。

这里的“每个槽都有主节点和从节点”可以理解成：某个槽当前由某个主节点负责，这个主节点可以有自己的副本。当主节点正常时，它处理该槽的写入，并把数据变化复制给从节点。当主节点不可用时，从节点有机会被提升，继续承接这部分槽的数据。

所以 Redis Cluster 不是抛弃主从复制，而是在分片基础上继续使用主从复制。分片解决横向拆数据，主从解决副本和故障接管。两层机制叠在一起，集群才既能扩容量，也能提高可用性。

文中提到故障检测：当一个节点不可用时，其他节点会发起故障检测流程，重新分配槽到可用节点，并选举一个新的主节点。这里要注意，故障处理不只是“找一台机器顶上来”，还要让集群知道原来那些槽现在由谁负责。

如果 Master B 挂了，负责 5461 到 10922 的槽就没有入口。它的从节点被提升为新主节点后，集群里的槽所有权也要更新。客户端再访问这些槽时，应该路由到新的主节点，而不是继续找已经不可用的旧节点。

这也是为什么节点间 gossip 和客户端路由都重要。节点需要传播新的拓扑，客户端需要感知新的槽位映射。故障恢复不是单个 Redis 进程自己的事，而是集群里节点、客户端、复制关系一起完成的一次状态切换。

在普通单机 Redis 里，客户端只要连一个地址就可以。到了 Redis Cluster，客户端必须知道请求属于哪个槽，以及哪个节点负责这个槽。文中写到，客户端通过计算 key 的 CRC16 哈希值确定它所属的槽，然后把请求发送到负责该槽的节点上。

这意味着客户端驱动要支持 Cluster 模式。它不能把所有命令都盲目发给任意节点，然后等集群内部帮它转发。实际使用时，客户端通常会缓存 slot 到节点的映射关系；如果收到重定向响应，再刷新本地缓存。

对使用者来说，最容易踩的坑是把 Cluster 当成“多个 Redis 地址随便连一个”。正确理解是：每个 key 有自己的槽，每个槽有自己的负责节点。命令发错节点时，系统会提示你去正确节点，但高频业务不能长期靠错误路由和重定向过日子。

资料 在切片集群后面专门讲了集群脑裂。场景是这样的：主节点网络突然出问题，和所有从节点失联，但它和客户端之间的网络仍然正常。客户端不知道集群内部已经异常，还继续往这个失联主节点写数据。

另一边，哨兵或集群故障检测发现主节点失联，会在从节点中选出一个新的主节点。于是系统里短时间可能有两个主节点：旧主节点仍在接受客户端写入，新主节点也开始承接集群里的请求。等网络恢复后，旧主节点会被降级，向新主节点请求同步。

问题就在这里。旧主节点第一次向新主节点同步时，可能走全量同步，它会清空自己的本地数据再加载新主库数据。故障期间客户端写到旧主节点的那部分数据，没有进入新主库，就可能丢掉。所以脑裂不是一个抽象名词，它对应的是实实在在的数据丢失窗口。

已有的处理方向很清楚：当主节点发现从节点下线，或者通信超时的数量达到条件时，禁止主节点继续写数据，直接把错误返回给客户端。也就是说，如果主库发现自己已经和足够多的从库失去联系，就不要再假装一切正常。

配置上可以设置主节点至少连接 N 个从节点，并且主节点进行数据复制时的 ACK 延迟不能超过 T 秒。否则，主节点就不再接收客户端写请求。这样做的意义是把风险前移：宁可让客户端收到错误，也不要让旧主库在孤岛里继续写入一批将来可能被清空的数据。

等新主节点上线后，只有新主节点能接收和处理请求。原主节点被降级为从节点，即使它的数据被清空，也不会再丢失新的写入。这个策略不是让故障完全无感，而是在可用性和数据安全之间做更稳的选择。

不是所有 Redis 都需要上 Cluster。如果数据量不大，单机加主从和哨兵已经能满足容量、读压力和故障转移，切片集群反而会增加运维和客户端复杂度。分片意味着客户端要懂路由，节点扩缩容要迁移槽，故障恢复要处理更多拓扑状态。

当数据量已经超过单机可承载范围，或者单个主节点写入压力太大，才更适合考虑切片集群。相关的判断标准很朴素：一台服务器无法缓存时，用 Redis Cluster 把数据分布到不同服务器上，降低单主依赖，提高读写性能。

做选型时可以按顺序问：数据是不是可以拆？热点 key 会不会集中在少数槽？客户端是否支持 Cluster？是否能接受节点迁移和故障恢复期间的重定向？有没有监控 slot 分布、节点状态、复制延迟和失败重试？这些问题没想清楚，上 Cluster 也只是把单机问题变成集群问题。

如果被问 Redis Cluster 的工作原理，可以先说场景：当单机 Redis 无法承载数据量或读写压力时，使用切片集群把数据分散到多台服务器，降低对单主节点的依赖。

然后讲数据怎么分：Redis Cluster 把整个数据集划分为 16384 个槽，每个节点负责一部分槽。客户端根据 key 的 CRC16 哈希值计算 slot，再把请求发到负责该槽的节点。节点之间通过 gossip 协议，用 PING、PONG 等消息交换节点信息和集群状态。

最后补高可用：每个槽背后可以有主从复制，主节点写入后异步复制到从节点；节点故障后，集群会检测异常，提升从节点并更新槽归属。再说风险：网络分区可能造成脑裂，旧主库继续接收写入后被降级清空，就会丢数据，所以需要通过最小从节点数量、复制 ACK 延迟限制、监控和报警来降低风险。