主从复制仅解决读扩展与冷备，不提供自动高可用；适用QPS5分钟手动故障恢复的场景。
直接说结论：不能只看数据类型选架构，得先锁定写负载、读一致性要求、故障容忍窗口这三项硬指标；否则容易把 zset 用成单点瓶颈，或为 string 热点强行上 Cluster 白烧机器。
主从复制适合什么场景？别被“高可用”三个字骗了
主从不是自动高可用，它只解决两个问题：读扩展和冷备。一旦主节点挂了，你得手动执行 SLAVEOF NO ONE，再改客户端配置——这个过程通常 >5 分钟。
- 适用条件：QPS
- 关键配置必须调：把
repl-backlog-size设到至少64mb，否则从节点断连重连大概率触发全量同步，带宽和 CPU 都会飙高 - 陷阱：别在从节点开
AOF。主从链路本身已是持久化保障，从节点再刷磁盘日志，只会拖慢同步速度，还可能因磁盘 IO 拉垮整个复制流
哨兵模式下，为什么你的故障转移总卡在“选举新主”这一步？
哨兵选举失败不是偶然，是配置没对齐。它依赖三个参数形成闭环：quorum、down-after-milliseconds 和 failover-timeout。其中最容易被忽略的是 min-replicas-to-write 和 min-replicas-max-lag。
-
min-replicas-to-write 2表示主节点必须有至少 2 个从节点在线才允许写入，否则直接拒绝请求——这能防脑裂，但也会让集群在部分从节点失联时变只读 -
min-replicas-max-lag 10是指从节点延迟不能超过 10 秒，超时即剔除出候选名单。如果业务写入节奏不均（比如批量导入），这个值设太小会导致每次故障都只剩一个候选节点，选举失败 - 哨兵节点数必须是奇数（3 或 5），且部署在不同物理机/可用区。同机房部署 3 个哨兵，等于把单点故障从 Redis 转移到网络交换机
Cluster 模式真能无限扩容？小心槽迁移时的“静默卡顿”
Cluster 的分片能力是真的，但它的代价是：所有跨槽操作（如 MGET、KEYS、事务）都不支持。更隐蔽的问题是槽迁移期间的性能抖动——不是报错，而是响应时间从 1ms 突然跳到 80ms，且持续几十秒。
- 迁移卡顿根源在
ASK重定向：客户端收到ASK后要先连目标节点发ASKING命令，再重试原请求。很多 SDK 默认不处理这个流程，直接报错 - 大 key（>1MB）必须在迁移前清理。Cluster 不会拆分大 key，迁移时整个 key 锁住，阻塞该槽所有请求
- 别用
client-output-buffer-limit slave默认值。集群内节点互为 master/slave，这个 buffer 控制着复制积压，设太小会导致频繁断连重同步
真正难的不是选哪种模式，而是识别哪些数据该进哪种模式——比如用户 session 用 string 存在哨兵集群，订单排行榜用 zset 单独跑一个 Cluster 子集，而商品库存这种强一致性场景，干脆绕过 Redis 直连数据库加行锁。架构成本永远藏在边界判断里，不在命令行里。
