Redis（3）：研发一定要知道Redis集群的那几个问题

本文将深入剖析 Redis 集群的原理、数据分布算法、请求重定向、节点通信机制，以及在扩缩容和带宽管理方面的要点，全面理解和掌握 Redis 集群。

一、Redis 集群是什么、为什么？

Redis 自 3.0 版本引入集群模式，成功实现了数据的分布式存储。它通过对数据进行分片，将不同的数据存储在各个 master 节点上，有效解决了海量数据的存储难题。

Redis 集群秉持去中心化理念，不存在中心节点。对客户端而言，整个集群如同一个单一的 Redis 实例，可连接任意节点进行操作，无需额外的代理中间件。当客户端操作的 key 未分配到当前连接的 node 时，Redis 会返回转向指令，指引客户端找到正确的 node。

此外，Redis 集群内置高可用机制，支持多个 master 节点，每个 master 节点可挂载多个 slave 节点。一旦 master 节点出现故障，集群会自动提升某个 slave 节点成为新的 master 节点，确保服务的连续性。

二、Redis 集群的数据分布算法：哈希槽算法

在将数据拆分到不同 Redis 服务器的众多算法中，常见的有普通 hash 算法、一致性 hash 算法，而 Redis 集群采用的是哈希槽分区算法。

普通 hash 算法

普通 hash 算法通过对 key 进行 hash 计算后，按照节点数量取余（hash (key)% N）来决定数据存储位置。此算法简单直接，但在扩容或摘除节点时，需重新计算映射关系，导致数据大量迁移，成本较高。

一致性 hash 算法

一致性 hash 算法为每个节点分配一个 token，形成哈希环。查找数据时，先计算 key 的 hash 值，然后在环上顺时针寻找第一个大于等于该哈希值的 token 对应的节点。该算法在增减节点时仅影响相邻两个节点，但可能造成部分数据无法命中，常用于缓存场景，且在节点较多时，通常通过增加一倍节点来保障数据负载均衡。

哈希槽分区算法

Redis 集群设有 16384 个哈希槽（范围是 0 - 16383），不同的哈希槽分布在各个 Redis 节点进行管理，即每个节点负责部分哈希槽。操作数据时，集群利用 CRC16 算法对 key 计算并对 16384 取模（slot = CRC16 (key)%16383），所得结果即为 Key - Value 应放入的槽位，据此找到对应的 Redis 节点进行存取。哈希槽算法的优势在于方便节点的添加与移除，无论对单个节点进行何种操作，都不会致使集群不可用。增减节点时，只需在节点间挪动相应的哈希槽即可。

三、集群的请求重定向

Redis 客户端可通过任意节点路由到目标节点。客户端通过 CRC16 (key)%16383 算出 Slot 值，若发现需操作的 “缓存节点 1” 的数据已迁移至 “缓存节点 2”，客户端虽无法从 “缓存节点 1” 获取数据，但 “缓存节点 1” 因保存所有集群节点信息，会向客户端发送 MOVED 重定向请求，告知 “缓存节点 2” 的地址，客户端便可继续访问并获取数据。

为减少频繁重定向带来的网络开销，可使用 smart 客户端。它在本地维护一份 hashslot => node 的映射表缓存，多数情况下，直接查询本地缓存就能找到目标节点，无需依赖节点的 MOVED 重定向。

四、Redis 集群的节点通信机制

当集群状态发生改变，如节点加入、slot 迁移、节点宕机或 slave 提升为新 Master 等情况，为使各节点尽快知晓，Redis 集群采用 gossip 协议进行通信，以此维护节点间的元数据信息，最终实现数据一致性。

gossip 协议原理

gossip 协议基于流行病传播方式，实现节点或进程间的信息交换。不同节点持续通信交换信息，一段时间后，所有节点将拥有整个集群的完整信息，且状态达成一致。即便节点仅知晓部分邻居节点，只要网络连通，最终状态也会统一。该协议的显著优势是，即便集群节点数量增加，每个节点的负载增长也极为有限，基本保持恒定。

Redis 集群的通信过程

• 集群中每个节点都会开辟一个独立的 TCP 通道用于节点间通信。
• 每个节点按固定周期，依据特定规则挑选几个节点发送 ping 消息。
• 接收到 ping 消息的节点以 pong 消息作为回应。

不过，gossip 协议也存在一些缺点。一方面，元数据更新存在延时，可能导致集群操作滞后；另一方面，它对服务器时间要求较高，时间戳不准确会影响节点对消息有效性的判断。此外，节点数量增多会增加网络开销，达到最终一致性的时间也会变长，因此官方建议最大节点数约为 1000 个。在 Redis cluster 架构下，每个 Redis 需开放两个端口号，如 6379 和 16379（6379 + 10000）。

五、Redis 扩缩容数据迁移问题

在 Redis 集群进行扩缩容时，数据迁移必不可少。为确保迁移的一致性，Redis 采用同步操作，但这会使两端的 Redis 在迁移时进入阻塞状态。对于小 Key，阻塞时间可忽略不计；然而，若 Key 占用内存过大，严重时可能触发集群内的故障转移，引发不必要的主从切换。

六、Redis 带宽问题及应对策略

集群带宽消耗主要来自读写命令和 gossip 消息。gossip 协议虽能协同自动化修复集群状态，但存在消息延时和冗余问题。在集群节点过多时，会消耗大量带宽，主要体现在以下方面：

• 消息发送频率：与 cluster - node - timeout 紧密相关，当节点发现与其他节点的最后通信时间超过 cluster - node - timeout/2 时，会立即发送 ping 消息。
• 节点部署的机器规模：机器带宽上限固定，相同规模的集群分布在越多机器上，且每台机器划分的节点越均匀，整个集群的可用带宽就越高。
• 消息数据量：每个消息主要包含 slots 槽数组（2kb）以及整个集群 1/10 的状态数据。

搭建 Redis 集群时，需结合业务数据规模和消息通信成本合理规划：

在满足业务需求前提下，尽量避免构建大集群，可针对不同业务场景拆分使用多个集群。

适度提高cluster-node-timeout降低消息发送频率，但需兼顾故障转移速度，根据业务场景平衡。

尽量将节点均匀部署在更多机器上，避免集中部署。例如，60 个节点的集群若集中部署在 3 台机器上，每台 20 个节点，机器的带宽消耗将极为严重。

综上所述，深入理解 Redis 集群的架构、算法、通信机制以及常见问题要点，对于构建高效、稳定的分布式系统至关重要。

资料：Redis集群原理详解-腾讯云开发者社区-腾讯云