Redis集群读多写少场景下性能最佳配置是主从+读写分离而非盲目堆从节点，因Cluster不支持自动读从、需手动路由易出错，而主从架构配合客户端读写分离（如Lettuce的REPLICA_PREFERRED）更可靠。

Redis集群在读多写少场景下，性能最佳的配置不是盲目堆从节点，而是要分清「用的是 Redis Cluster 还是主从+读写分离」——这两者底层机制、客户端行为、一致性保障完全不同。直接套用 Cluster 的默认配置去扛纯读流量，反而容易踩坑。

Redis Cluster 本身不支持读写分离

很多人误以为 Redis Cluster 天然能读从节点，其实不然：redis-cli 或大多数客户端（如 Jedis、Lettuce 默认模式）只连主节点，所有读请求仍发往主节点；从节点默认不对外提供读服务，READONLY 命令也仅对直连的从节点生效，且 Cluster 模式下客户端无法自动发现并路由到从节点。

• Cluster 节点间通过 Gossip 同步拓扑，但不暴露从节点地址给客户端
• CLUSTER REPLICAS <node-id> 只供运维查状态，不能用于读路由
• 强行让客户端手动连从节点读，会绕过槽路由逻辑，导致 Moved/Ask 错误或数据错位

读多写少应优先选主从复制 + 客户端/代理层读写分离

真正适合读多写少的，是明确区分角色的主从架构（非 Cluster），再配合读路由策略。关键不是“能不能读从”，而是“读哪台从、怎么避免读到延迟数据”：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 确认从节点延迟：监控 info replication 中的 master_repl_offset - slave_repl_offset，差值 > 10000 命令建议跳过该从节点
• 避免全量同步卡顿：调大主节点 repl-backlog-size（例如 64mb），防止从节点断连重连时触发全量同步
• 从节点必须显式开启 replica-read-only yes（默认值，但别注释掉）
• 密码需双向配置：requirepass（主） + masterauth（从），否则从节点无法完成握手

Lettuce / Jedis 客户端读写分离实操要点

以 Java 生态最常用的 Lettuce 为例，它原生支持读写分离，但默认关闭：

• 启用读操作分发到从节点：ReadFrom.REPLICA_PREFERRED（推荐），而非 ReadFrom.MASTER
• 不要设 ReadFrom.REPLICA：一旦某个从节点宕机，Lettuce 默认不自动剔除，可能持续失败
• 连接池需区分：主节点用 MasterReplica.connect()，传入主地址 + 多个从地址，而非多个 RedisURI 手动拼接
• Spring Boot 配置示例：spring.redis.lettuce.read-from=replica-preferred，但必须确保配置里已声明从节点地址（spring.redis.url 只写主地址是不够的）

容易被忽略的三个硬伤

即使配置全对，以下三点仍常导致性能不升反降：

• 网络 RTT > 1ms 时，读从节点带来的延迟可能抵消吞吐增益，尤其跨机房部署
• 从节点内存碎片率高（mem_fragmentation_ratio > 1.5）会导致 get 延迟毛刺，比主节点更明显
• 大 key（>10KB）在从节点上执行 hgetall 等命令，会阻塞整个从节点事件循环，影响其他读请求