哨兵模式仅解决高可用，不解决写压力瓶颈；qps>3000或内存>16gb时必须用redis cluster，因其通过16384槽分片实现写负载分散与水平扩展。
写请求 QPS 超过 3000，或单实例内存常驻 >16GB，哨兵模式就撑不住了——这不是配置调优能解决的，是架构瓶颈。
哨兵模式只解决「主挂了谁来顶上」，不解决「主太忙怎么办」
哨兵本质是监控 + 自动故障转移组件，它不改变「所有写都在一个 Redis 进程里」的事实。主节点要同时处理：客户端写请求、全量 RDB fork、AOF rewrite、向所有从节点广播增量命令。当写压力大时，fork() 会卡住主线程（尤其在大内存场景），repl_backlog 缓冲区容易溢出，从节点 offset 落后越来越多。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 典型现象：
INFO replication中master_repl_offset和从节点的slave_repl_offset差值长期 >50 万 - 常见误判：以为是网络抖动，其实是主节点 CPU 或内存已饱和
- 扩容无效：加再多从节点，只会让主节点的网络和复制压力线性上升
集群模式强制要求客户端支持 slot 路由与重定向
Redis Cluster 不是“换套配置就能跑”，它改变了客户端必须承担的职责：计算 key 对应的 slot（CRC16(key) % 16384）、处理 MOVED / ASK 错误、保证多 key 操作落在同一 slot。很多线上故障不是集群本身出问题，而是客户端没切到集群模式。
- 必须确认你用的客户端库是否提供
RedisCluster类（如redis-py的from redis.cluster import RedisCluster），而非继续用StrictRedis -
MGET key1 key2 key3在集群中会直接报错CROSSSLOT，除非三个 key 都带相同哈希标签，例如user:{123}:profile、user:{123}:settings - Lua 脚本里多个 key 必须显式用
{}包裹，否则执行失败；且脚本不能跨 slot 读写
中小业务别硬上集群，哨兵+读从节点足够扛住 90% 场景
日均 PV 85%、QPS 写
- 部署成本低：3 个哨兵进程 + 1 主 2 从，6 个端口，配置项少于 20 行
- 客户端兼容好：多数语言驱动原生支持
Sentinel构造器，自动获取主节点地址 - 升级路径平滑：先用哨兵保高可用，等写压真上来再拆分业务数据、逐步迁移到集群
真正难的从来不是选哨兵还是集群，而是能不能在业务增长早期就看清写流量曲线和 key 分布特征——这些决定了你是在修一条高速公路，还是在搭一座跨海大桥。
