【Redis】Cluster

Redis Cluster

Redis Cluster 是 Redis 官方推出的分布式集群解决方案，旨在解决单机 Redis 的内存限制、性能瓶颈和单点故障问题。它通过数据分片（Sharding）、主从复制（Replication） 和自动故障转移（Failover） 实现高可用性与水平扩展。以下从核心架构、工作机制、特性及限制四个维度展开详解：

🔍 核心架构设计

数据分片（Hash Slot 机制）
- 16384 个哈希槽：所有数据通过 CRC16(key) % 16384 计算槽位，分散到不同节点1,5,7。
- 槽位分配：每个主节点负责部分槽位（如节点 A 管理槽 0-5000），集群通过槽位映射表快速定位数据节点1,6。
- 动态迁移：扩容/缩容时，槽位可在线迁移（redis-cli --cluster reshard），过程中通过 ASK 重定向保证数据一致性2,6。
节点角色
- 主节点（Master）：处理读写请求，参与故障检测与槽位管理。
- 从节点（Slave）：异步复制主节点数据，主节点故障时通过选举升主（Raft 算法）1,5,6。
- 最小集群配置：3 主 + 3 从，确保半数以上节点可投票完成故障转移1,2。
去中心化通信（Gossip 协议）
- 节点间通过 TCP 通道定期交换状态（Ping/Pong 消息），端口号为服务端口 +10000（如 6379 → 16379）5,7。
- 消息类型：
  - MEET：新节点加入集群；
  - FAIL：节点故障广播；
  - PING/PONG：心跳检测与元数据同步5,7。

⚙️ 关键工作机制

客户端请求路由
- 智能重定向：客户端连接任意节点，若 Key 不属于当前节点，返回 MOVED 错误并携带正确节点地址，客户端自动重试1,6,7。
- 迁移中的请求处理：槽位迁移期间，源节点返回 ASK 重定向，客户端临时访问目标节点6,7。
故障转移（Failover）
- 故障检测：半数以上主节点标记某节点为 PFAIL（疑似下线）后，升级为 FAIL（已下线）5,6。
- 从节点选举：从节点发起投票（FAILOVER_AUTH_REQUEST），获多数主节点同意后升主，并接管原主槽位5,6。
- 数据一致性：异步复制可能导致故障期间少量数据丢失（非强一致性）2,6。
集群扩容/缩容
- 扩容：
  1. 添加新节点：redis-cli --cluster add-node；
迁移槽位：redis-cli --cluster reshard2,5。

缩容：
1. 迁移待删节点的槽位；

删除节点：redis-cli --cluster del-node5。

⚡️ 核心特性与优势

高可用性
- 主从切换在秒级完成（默认节点超时时间 15 秒），服务不间断1,6。
- 支持读负载均衡：客户端可配置从节点处理读请求（FAILOVER_DISTRIBUTE 策略）4。
水平扩展能力
- 理论支持 ≤1000 个节点，数据分布均匀时可线性提升吞吐量1,5。
- 性能接近单机 Redis，单节点 QPS 可达 10 万+3,4。
无中心架构
- 无代理层，客户端直连节点，降低延迟与复杂性1,7。

⚠️ 限制与应对策略

功能限制
- 跨槽位操作：事务（MULTI）、Lua 脚本、MGET/MSET 等需所有 Key 位于同一槽位（可用 {hash_tag}强制路由，如 {user}:1）1,3,6。
- 仅支持 db0：无法使用 SELECT 切换数据库2,5。
数据一致性风险
- 异步复制导致主节点写入成功后，从节点可能未同步（故障时丢失数据）2,6。
- 应对方案：对强一致性场景，需业务层补偿（如异步队列重试）6。
运维复杂度
- 扩缩容需手动迁移槽位，可能引发性能波动2,5。
- 优化建议：启用槽位缓存（如 phpredis 的 redis.clusters.cache_slots=1），减少重定向4。

💎 典型应用场景

高并发读写：如电商秒杀系统，分散请求至多节点1,3。
海量数据存储：突破单机内存限制，支持 PB 级数据1,7。
会话共享：在 PHP 等环境中存储分布式会话（需配置压缩与超时）4。

💎 总结

Redis Cluster 通过 分片机制 解决单机瓶颈，以 去中心化架构 确保高可用性，是 Redis 大规模部署的核心方案。尽管存在跨节点操作限制和数据一致性风险，其线性扩展能力和毫秒级故障转移仍使其成为高并发、大数据场景的首选。 实践建议：

✅ 生产环境采用 6 节点（3 主 3 从）起步；
⚠️ 避免热点 Key 与跨槽事务；
🔧 使用客户端优化（如 Jedis/phpredis 的槽位缓存）提升性能1,4,7。

异步复制

Redis主从节点的异步数据复制是其高可用架构的核心机制，通过非阻塞式数据同步在保证主节点高性能的同时实现数据冗余。以下从核心原理、流程、问题及优化四个维度展开详解：

🔧 异步复制的核心原理

非阻塞设计
- 主节点处理写命令后立即响应客户端，异步将数据同步到从节点，避免因等待从节点确认而阻塞主节点性能1,3。
- 数据流向：主节点 → 复制缓冲区 → 从节点（单向流动，不可反向）3,6。
关键数据结构
- Replication Buffer：主节点为每个从节点独立分配的缓冲区，临时存储待同步的写命令。若从节点处理慢或网络延迟，缓冲区积压可能导致主节点内存压力8。
- Repl-Backlog Buffer：全局环形缓冲区（默认1MB），存储最近写命令。用于网络闪断后的增量同步，避免全量复制4,8。示例：若从节点断开后重连，主节点检查其复制偏移量（offset）是否在积压缓冲区范围内，是则发送缺失数据，否则触发全量同步8。

⚙️ 异步复制流程

全量复制（初始化同步）

触发场景：从节点首次连接主节点，或复制偏移量不连续（如网络中断过久导致积压缓冲区数据被覆盖）6,8。
步骤：
1. 从节点发送PSYNC ? -1命令请求同步8。
2. 主节点执行BGSAVE生成RDB快照，同时缓存新写命令至Replication Buffer1,6。
3. RDB文件传输至从节点，从节点清空旧数据并加载RDB。
4. 主节点发送积压的写命令，使从节点数据与主节点一致4,9。

增量复制（命令传播）

持续同步：全量复制完成后，主节点将新写命令实时推送至从节点6。
断点续传：
- 网络中断期间，主节点写命令存入Repl-Backlog Buffer（环形队列）8。
- 网络恢复后，从节点发送PSYNC <runid> <offset>，主节点校验偏移量有效性后发送缺失数据4,8。

心跳维持

从节点每秒发送REPLCONF ACK <offset>报告自身复制偏移量7。
主节点通过偏移量监控从节点延迟，超时（默认60秒）则断开连接6。

⚠️ 异步复制的风险与挑战

数据不一致风险
- 延迟问题：主节点写入成功后，从节点可能未同步即宕机，导致数据丢失（尤其短时间高并发写入）1,3。
- 监控手段：通过INFO replication查看master_repl_offset与slave_repl_offset差值，延迟超过阈值需告警1。
脑裂问题（Split-Brain）
- 场景：网络分区时，原主节点和提升的新主节点同时写入，恢复后数据冲突1,5。
- 规避方案：
  - 配置min-slaves-to-write 1和min-slaves-max-lag 10，要求至少1个从节点延迟≤10秒，否则主节点拒绝写入1,5。
资源消耗
- 内存压力：全量复制时BGSAVE的fork操作可能阻塞主线程（尤其内存过大时）1。
- 网络带宽：RDB文件传输占用带宽，影响其他服务（建议低峰期扩容）6。

🛠️ 生产级优化方案

减少全量复制

增大积压缓冲区：调整repl-backlog-size（建议512MB以上），避免网络抖动触发全量复制6,8。
无盘复制：Redis 6.0+支持repl-diskless-sync yes，主节点直接通过Socket发送RDB，避免磁盘IO6。

增强一致性

WAIT命令：强制等待N个从节点同步完成（如WAIT 2 5000等待2个从节点或超时5秒），但牺牲性能换取强一致性1,3。

从节点配置：

replica-serve-stale-data no  # 同步中断时拒绝读请求，避免脏数据[1](@ref)

高可用架构

哨兵模式：自动监控主节点状态并故障转移，需部署奇数个Sentinel节点5。
集群模式：数据分片到多主节点，每个主节点配从节点，规避单点故障5。

关键参数配置参考

参数	推荐值	作用
`repl-backlog-size`	512mb	扩大积压缓冲区，支持更长中断恢复
`repl-timeout`	60	复制超时时间（秒）
`min-slaves-to-write`	1	至少需同步的从节点数
`min-slaves-max-lag`	10	从节点最大延迟（秒）

💎 总结

Redis异步复制通过非阻塞设计平衡性能与数据冗余，但需警惕数据延迟和脑裂风险。生产建议：

✅ 监控延迟：定期检查INFO replication的偏移量差值1；
✅ 优化配置：增大repl-backlog-size、启用无盘复制6,8；
✅ 容灾设计：结合哨兵/集群模式，并通过min-slaves-*限制写入条件1,5。

异步复制是Redis高性能的基石，理解其机制与局限，方能构建稳定可靠的分布式缓存系统。

哈希槽

Redis Cluster 中客户端实现负载均衡和数据定位的核心机制是哈希槽（Hash Slot）分配与智能重定向。以下是详细流程及原理：

🔍 哈希槽机制与数据定位

哈希槽分配
- Redis Cluster 将数据划分为 16384 个固定槽位（Slots），每个主节点负责一部分槽位（如节点 A 管理 0-5000，节点 B 管理 5001-10000）1,3,6。
- 键值映射规则：客户端对 Key 执行 CRC16(key) % 16384 计算槽位号，例如 user:123 的 CRC16 值为 9876，则归属槽位 98763,6。
客户端槽位缓存
- 客户端首次连接集群时，随机选择一个节点获取槽位映射表（Slot-Node Mapping），记录每个槽位对应的节点 IP 和端口6,8。
- 后续请求直接根据本地映射表路由到目标节点，避免重复查询6。

⚙️ 客户端请求路由与重定向

正常路由流程
- 客户端计算 Key 的槽位号，查询本地映射表，直接发送请求至负责该槽位的节点6。
- 示例：若槽位 5001 由节点 B 管理，请求 SET order:100 "data" 会直接发送至节点 B3。
重定向机制
- MOVED 重定向：若请求发送到错误节点（如槽位 5001 的请求发到节点 A），节点 A 返回 MOVED 5001 192.168.1.2:7001，客户端更新本地映射表并重试3,6。
- ASK 重定向：在数据迁移过程中，若槽位正在从节点 A 迁移到节点 B：
  - 节点 A 若仍存有数据，则直接响应。
  - 若数据已迁移，返回 ASK 5001 192.168.1.3:7002，客户端向节点 B 发送 ASKING 命令后重新执行原请求6,8。

⚖️ 负载均衡实现方式

数据分片均衡
- 集群启动时槽位平均分配到主节点（如 3 节点时各占 5461 个槽位）3,8。
- 动态再平衡：新增节点时，集群自动从其他节点迁移部分槽位到新节点；节点下线时，其槽位重新分配给存活节点1,6。
请求分散
- 客户端通过本地槽位映射表将请求均匀分发到不同主节点，避免单点压力6,8。
- 读写操作均在主节点完成，从节点仅作备份（故障时提升为主节点）3,4。
客户端库优化
- 如 Jedis Cluster、Lettuce 等库自动维护槽位映射表，处理重定向逻辑，对业务透明5,6。
- 支持连接池复用和故障节点自动排除，减少网络开销5。

🛠️ 客户端库的优化实践

启动初始化
- 客户端连接集群时，通过 CLUSTER SLOTS 命令获取全量槽位映射，并缓存节点连接池6,8。
重定向处理优化
- 对 MOVED 响应更新本地映射表；对 ASK 响应仅临时跳转，不更新缓存6。
- 限制重试次数，避免网络环路5。
容错与高可用
- 节点故障时，客户端收到 ConnectionError 后随机选择其他节点重试，并由新节点通过 MOVED 响应纠正路由6。
- 集群主从切换期间，客户端自动切换到新主节点3,4。

💎 总结

Redis Cluster 的负载均衡和数据定位依赖 16384 哈希槽的精细分片和客户端智能路由机制：

✅ 定位效率：通过槽位计算和本地缓存实现快速定位。
✅ 负载均衡：数据均匀分布 + 动态迁移 + 客户端直连分发请求。
✅ 容错性：MOVED/ASK 重定向保障请求可达性。
✅ 客户端优化：主流库（如 Jedis Cluster）封装复杂性，开发者无需关注底层细节。

生产建议：使用支持 Cluster 的客户端库（如 Lettuce），并配置合理的连接池大小；避免跨槽位操作（如多 Key 事务），以规避性能损耗5,6。

哈希槽 & 一致性哈希

哈希槽（Hash Slot）和一致性哈希（Consistent Hashing）是两种不同的分布式数据分片算法，它们在设计目标、实现机制和适用场景上存在显著差异。以下是核心对比：

🔍 核心区别总结

维度	哈希槽（Hash Slot）	一致性哈希（Consistent Hashing）
数据结构	固定 16384 个槽位（Redis Cluster）1,7	虚拟环状结构（范围 0~2³²-1）9,10
数据定位逻辑	键 → CRC16取模 → 槽位 → 节点7,8	键哈希 → 环上位置 → 顺时针首个节点9,10
动态扩缩容	需手动迁移整槽数据（如 `CLUSTER ADDSLOTS`）2,4	自动迁移相邻数据，影响局部3,9
负载均衡	强制槽位均匀分配，天然均衡1,4	依赖虚拟节点优化，否则易倾斜2,10
实现复杂度	简单（槽位映射表+固定计算）4,8	复杂（需维护环+虚拟节点映射）2,9
典型应用	Redis Cluster、强一致性数据库8,7	Memcached、Cassandra、CDN9,10

⚙️ 关键差异详解

数据分布机制
- 哈希槽：
  - 数据通过 CRC16(key) % 16384 映射到固定槽位，槽位与节点绑定7,8。
  - 优势：槽位分配可控（如高性能节点分配更多槽位），避免数据倾斜4,5。
- 一致性哈希：
  - 数据哈希后定位到环上，由顺时针方向的第一个节点管理9,10。
- 问题：节点较少时易倾斜，需虚拟节点（如1物理节点=1000虚拟节点）分散数据3,9。
动态扩缩容效率

哈希槽：
- 扩容时需迁移整槽数据（如从节点A迁移1000个槽到节点B），迁移粒度大但操作集中2,4。
  - 代价：迁移期间网络带宽压力大，但数据路由不变（客户端缓存槽位映射）4,8。
- 一致性哈希：
  - 增减节点时仅影响相邻数据（约 1/N 数据迁移，N为节点数）9,10。
- 代价：需重新计算虚拟节点分布，可能引发临时缓存穿透4,10。

元数据管理开销
- 哈希槽：
  - 槽位分配信息仅需 2KB（16384槽用bitmap压缩）4,5。
  - 适合大规模集群（如1000节点），心跳包轻量5,8。
- 一致性哈希：
  - 虚拟节点元数据庞大（1000节点×1000虚拟节点=百万级条目），心跳包可达8KB4,9。

🏗️ 设计哲学对比

特性	哈希槽	一致性哈希
核心目标	强数据一致性 + 集群管理便捷8	高动态扩展性 + 最小化数据迁移9
数据控制	支持手动分配槽位（如按硬件性能调整）5	依赖哈希函数分布，人工干预难10
故障恢复	槽位整体切换（主宕机时从节点接管槽位）7	数据自动迁移到相邻节点，但可能引发连锁故障10

⚠️ 适用场景建议

选择哈希槽的场景： ✅ Redis Cluster：需强一致性、事务支持（尽管有限）及运维简化7,8。 ✅ 金融交易系统：要求毫秒级定位，避免环查找延迟4。 ✅ 中小规模集群：节点数≤1000，避免元数据膨胀5,8。
选择一致性哈希的场景： ✅ 分布式缓存（如Memcached）：节点频繁变动，需最小化迁移成本9,10。 ✅ 超大规模系统：节点数＞1000，灵活性优于管理成本2,4。 ✅ CDN负载均衡：请求按地理位置路由，动态调整节点10。

💎 总结

哈希槽是 空间分区策略，以固定槽位为中介解耦数据与节点，适合需强管控的场景4,8。
一致性哈希是 拓扑路由算法，通过环形虚拟空间实现动态伸缩，适合高流动性场景9,10。

二者本质是 分治思想 的不同实践：哈希槽以“分槽治之”优先管理效率，一致性哈希以“动态寻址”优先弹性，无绝对优劣，只有适用与否2,4。

CRC16

CRC16是一种校验算法，属于哈希算法（Hash Algorithm）的范畴，但其设计目标和技术特性与加密级哈希算法（如SHA-256、MD5）存在显著差异。以下是详细分析：

🔍 CRC16的本质：哈希算法的子类

哈希算法的核心特征
- 固定长度输出：将任意长度输入映射为固定长度的散列值（如CRC16输出16位）8,10。
- 确定性：相同输入始终产生相同输出9。
- 高效性：计算速度快，适合实时处理6,9。 CRC16完全满足上述特征，因此属于哈希算法的一种1,6。
CRC16的哈希属性
- 生成数据摘要：通过多项式除法生成16位校验码，作为数据的“指纹”4,5。
- 雪崩效应：输入数据的微小变化（如1比特翻转）会导致输出校验码大幅变化10,6。

⚠️ CRC16与加密哈希算法的关键区别

尽管CRC16是哈希算法，但不具备加密级安全性，主要差异如下：

特性	CRC16	加密哈希（如SHA-256）
设计目标	错误检测（数据完整性）	数据安全（防篡改、抗碰撞）
碰撞风险	较高，可能被故意构造碰撞10	极低（强抗碰撞性）9
不可逆性	弱（可被逆向工程破解）6	强（无法从哈希值还原输入）8
安全场景适用	❌ 不适用于密码存储、数字签名	✅ 专为安全场景设计

具体差异分析：

抗碰撞性不足 CRC16的16位输出仅支持65,536种组合，碰撞概率远高于SHA-256（2²⁵⁶种组合）9。攻击者可轻易找到不同数据生成相同CRC16值，无法用于防伪造10。
无加密特性
- 非单向性：CRC16可通过数学推导或查表反向逼近原始数据6，而加密哈希是单向函数8。
- 无盐值支持：CRC16计算无需盐值（Salt），无法抵御彩虹表攻击9。

⚙️ CRC16的核心应用场景

CRC16的定位是高效检错，而非加密，主要应用于：

通信协议校验
- 串口通信（如Modbus）、以太网帧校验，检测传输中的比特错误4,7。
- 例如Modbus RTU使用CRC16-IBM（多项式0x8005）验证数据帧完整性7。
存储介质校验
- SD卡、Flash存储器用CRC16确保读写数据无物理损坏5,7。
嵌入式系统优化
- 硬件加速实现（如STM32的CRC外设），满足实时性要求6,4。
- 查表法优化计算速度，减少CPU开销5,6。

💎 总结：CRC16的定位

✅ 是哈希算法：符合固定输出、确定性、高效性等基本特征。
❌ 非加密哈希：缺乏抗碰撞性、不可逆性等安全属性，不能用于加密场景。
适用场景建议：
- 选择CRC16 → 通信错误检测、存储校验等非安全领域4,6。
选择SHA-256 → 密码存储、数字签名等安全敏感领域9,10。

简言之：CRC16是哈希家族的“实用派”，专攻效率与检错；而加密哈希是“安全专家”，专攻防破解与抗冲突。二者各司其职，不可互换。

槽数

Redis 集群选择 16384（2¹⁴） 个哈希槽（Hash Slot）作为分片数量，是综合考量网络开销、集群规模、数据分布效率等因素后的工程最优解。以下是核心原因及详细分析：

⚙️ 心跳包大小优化（核心因素）

槽位信息存储方式： Redis 节点通过心跳包（PING/PONG）交换集群状态信息，其中包含节点负责的槽位分配信息。该信息以 位图（bitmap） 存储，每个槽位占 1 比特（bit）。
16384 槽位的空间占用： 16384 bits / 8 = 2048 字节 = 2KB1,3,4。
若采用 65536 槽位： 65536 bits / 8 = 8192 字节 = 8KB，是 16384 方案的 4 倍。
影响：心跳包默认每秒发送多次，若槽位信息占用 8KB，会显著消耗网络带宽，尤其在节点数多时可能引发网络拥堵1,4,6。

💡 类比：如同快递员每日汇报包裹位置，精简的清单（2KB）比冗长清单（8KB）更高效4。

📏 集群规模限制（1000节点原则）

Redis 官方建议集群主节点数量 不超过 1000 个1,4,6，原因如下：

节点数量与心跳包负载：节点越多，心跳包中携带的节点状态信息（如槽位、地址）越多，超过 1000 节点易导致网络拥堵。
槽位分配的合理性：

16384 槽位：在 1000 节点时，平均每个节点负责约 16 个槽位（16384 ÷ 1000），分布均匀且易于管理4,7。
- 若槽位过少（如 1000）：每个节点仅分到 1 个槽位，哈希算法退化为简单取模，失去灵活扩缩容能力4。

数据迁移粒度：槽位作为数据迁移的最小单位，16384 的细粒度支持更平滑的扩容（如新节点从多个老节点各迁移少量槽位）5,8。

📦 数据压缩效率

槽位信息压缩机制：心跳包中的槽位位图（bitmap）在传输前会进行压缩（如 zlib）。
压缩率与填充率的关系：压缩率取决于 填充率（slots / N，N 为节点数）。填充率越低（即槽位稀疏），压缩效果越好3,4。
16384 的优势：在节点较少（如 10 节点）时，16384 槽位的填充率较低（约 0.06%），压缩后体积远小于 65536 槽位方案3,7。

⚡️ 对比：16384 槽位在小型集群中压缩率更高，传输效率提升明显4。

⚖️ 工程实践权衡

计算效率： 16384 = 2¹⁴ 是 2 的幂次方，取模运算（CRC16(key) % 16384）可通过位操作（& 0x3FFF）优化，比通用取模快 3-5 倍7,8。
运维友好性：固定槽位数简化了集群管理工具的设计，如槽位迁移命令 CLUSTER ADDSLOTS 可直接操作槽位编号5,6。
避免极端数据倾斜： 16384 的槽位数远大于典型集群规模（如 100 节点），结合 CRC16 的均匀分布特性，有效规避了数据热点问题4,8。

💎 总结：16384 的合理性

维度	16384 槽位方案	65536 槽位方案
心跳包大小	2KB（带宽占用低）	8KB（易引发拥堵）
千节点负载	每节点约 16 槽（均衡）	每节点约 65 槽（仍可行）
压缩效率	填充率低，压缩率高	填充率高，压缩率低
计算效率	位运算优化，速度快	标准取模，速度慢
运维复杂度	工具链成熟，易操作	管理成本高

🔑 设计本质：16384 是 工程最优解（而非理论最优），在心跳开销、集群规模、计算效率三者间取得平衡4,6,7。正如 Redis 作者 Antirez 所述：“16384 足以覆盖 1000 节点集群的需求，同时避免心跳包过大”5。

redisson

Redisson 是一个高级的 Java 客户端库，它既支持单节点 Redis，也支持 Redis Cluster 集群模式。其核心设计是抽象底层 Redis 的部署架构，开发者可通过同一套 API 操作不同部署模式的 Redis，无需关注底层差异。以下是详细解析：

🔍 Redisson 与 Redis/Redis Cluster 的关系

基础定位
- Redis：是开源的内存键值数据库，提供数据结构存储能力（如字符串、哈希、列表等）5。
- Redisson：是 Java 客户端库，封装 Redis 的操作并提供分布式高级功能（如锁、队列、集合），同时适配单节点和集群模式4,5。
支持模式
- 单节点 Redis：通过 useSingleServer() 配置连接单个 Redis 实例2,7。
- Redis Cluster：通过 useClusterServers() 配置，自动处理集群节点发现、数据分片、故障转移等复杂性6,8。
- 其他模式：还支持哨兵（Sentinel）、主从（Master/Slave）等部署架构1,4。

⚙️ Redisson 如何适配不同模式

单节点 Redis 的适配

配置示例：

Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient client = Redisson.create(config);

特点：所有操作直接发送到单一节点，无需处理分片或路由逻辑7。

Redis Cluster 的适配

配置示例：

Config config = new Config();
config.useClusterServers()
      .addNodeAddress("redis://node1:7001", "redis://node2:7002");
RedissonClient client = Redisson.create(config);

关键技术机制：
- 节点发现：通过 CLUSTER NODES 命令自动获取集群拓扑，维护节点状态表6。
数据路由：基于 哈希槽（Hash Slot） 计算键的归属节点（如 CRC16(key) % 16384），将请求发送到正确节点6。
- 故障转移：监控节点心跳，主节点故障时自动切换到从节点，并更新本地路由表6,8。
命令批处理：跨槽位操作自动拆分为批量命令，发送到多个节点执行6。

📊 关键功能在不同模式下的行为对比

功能	单节点 Redis	Redis Cluster
分布式锁（RLock）	直接通过 `SETNX` 命令实现锁	通过红锁（RedLock）算法跨多节点协商锁7
分布式集合（RMap）	所有数据存储在单一节点	数据按键分片存储到不同节点6
事务支持	单节点事务（`MULTI/EXEC`）	仅支持同一槽位内的键的事务6
跨节点操作	天然支持（无分片）	需通过 `RBatch` 批量处理跨节点命令6

⚠️ 使用注意事项

集群限制
- 跨槽位事务：Redis Cluster 不支持跨槽位事务，需确保事务内的键属于同一槽位6。
- 多键操作：如 RMap.getAll(keys) 需所有键在同一节点，否则需遍历多个节点6。
性能优化
- 连接池配置：集群模式下需增大连接池，避免节点过多导致连接不足2。
- 本地缓存：对热点数据启用 RMapCache 本地缓存，减少网络请求4。
运维建议
- 动态扩缩容：集群扩容时，Redisson 自动感知新节点并更新路由，但迁移期间可能有短暂重定向（MOVED 响应）6。
- 监控：通过 CLUSTER INFO 监控集群状态，结合 Redisson 日志排查路由异常6,8。

💎 总结

核心结论： Redisson 同时支持单节点 Redis 和 Redis Cluster，通过统一 API 屏蔽底层差异，开发者只需调整配置即可切换模式4,6。
选型建议：
中小规模应用 → 单节点模式（简单高效）。
- 高并发/大数据量 → Redis Cluster 模式（水平扩展、高可用）1,5。
设计价值： Redisson 的本质是 Redis 的智能客户端，无论底层是单节点还是集群，它都提供一致的分布式编程体验，大幅降低分布式系统复杂度8。