主从复制不够用，它仅分摊读请求，无法解决写瓶颈；当写qps超2万或单key高频更新时，主节点cpu或带宽会打满，导致同步延迟、连接被拒等问题。
主从复制够不够用？别只看“能用”，要看写瓶颈在哪
主从复制本身不解决写扩展问题，它只是把读请求分摊出去。如果你的业务写入 QPS 超过 2 万，或者单 key 写频次极高（比如计数器每秒更新上千次），replicaof 配置再稳也扛不住主节点 CPU 或网络带宽打满。
常见错误现象：INFO replication 显示 master_last_io_seconds_ago 持续大于 5，说明从节点同步延迟严重；redis-cli -p 6379 INFO stats 中 rejected_connections 上涨，代表主节点已拒绝新连接。
- 主节点必须开启
tcp-keepalive（默认 0，建议设为 60），否则中间网络设备可能静默断连 - 从节点配置里
repl-backlog-size至少设为 100mb（默认 1mb），避免网络抖动触发全量同步 - 禁止在从节点上执行
CONFIG SET或DEBUG类命令，否则会中断复制流
哨兵模式下 failover 为什么卡 30 秒以上？
哨兵判定主节点宕机不是靠一次 ping 失败，而是多数哨兵达成共识。默认 quorum 是 2，但实际生效需满足：哨兵总数 ≥ 2×quorum−1。比如你只部署 2 个哨兵，哪怕 down-after-milliseconds 设为 5000，只要其中一个哨兵短暂失联，failover 就会卡住。
典型配置陷阱：sentinel monitor mymaster 127.0.0.1 6379 2 看似合理，但如果哨兵进程跑在同一台机器上，这台机器一挂，整个高可用就失效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 哨兵必须跨物理机或 AZ 部署，至少 3 个且互不共享故障域
-
sentinel failover-timeout不是超时时间，而是两次 failover 的最小间隔，别误设成 5000 当作“快速切换” - 客户端必须监听
+switch-master事件并主动重连，不能依赖 DNS 缓存或静态 IP
Redis Cluster 的 slot 迁移真能无缝吗？
迁移过程中，目标 slot 的写请求会被 MOVED 重定向，但客户端若没正确处理该响应（比如老版本 Jedis 或 StackExchange.Redis 未开启 EnableCommandRedirection），就会直接报错而不是重试。
更隐蔽的问题是：slot 迁移期间，如果恰好有 bigkey 正在被 SCAN 或 HGETALL，迁移会暂停直到操作完成——这时 CLUSTER NODES 显示 migration status 卡在 importing 或 migrating，但无任何错误日志。
- 迁移前用
redis-cli --cluster check验证集群状态，别跳过 - bigkey 必须提前拆分，
redis-cli --bigkeys只能发现，不能自动处理 - 客户端 SDK 版本必须 ≥ Redis 4.0 对应的最低兼容版本，否则
ASK重定向逻辑缺失
maxmemory 设置多少才不算浪费也不爆内存？
设成 80% 物理内存看似稳妥，但 Redis 实际内存占用 = 数据 + 复制缓冲区 + AOF rewrite 进程 + fork 子进程 COW 开销。某次 bgsave 触发时，主进程 fork 出的子进程会瞬间多占一份内存镜像，如果此时刚好接近 maxmemory，OOM killer 可能直接 kill 掉 redis-server。
真实案例：一台 32GB 内存机器，maxmemory 设为 25gb，但高峰期 INFO memory 显示 mem_used_human 仅 20gb，却频繁被系统 kill——查 /var/log/messages 发现是 fork 失败后 fallback 到 save，阻塞主线程导致超时。
- 生产环境
maxmemory建议 ≤ 60% 总内存，预留空间给 OS 和 Redis 自身开销 - 淘汰策略优先选
allkeys-lru而非volatile-lru，后者在没设 TTL 的 key 上完全失效 - 务必配合
vm.overcommit_memory = 1，否则 fork 概率失败
