哨兵模式不支持数据分片，仅负责监控与故障切换；写qps超3000或内存超16gb时主节点易饱和，扩容从节点无法缓解写瓶颈；redis cluster需客户端实现slot路由与重定向，未适配将触发crossslot错误；架构选型应前置评估key可分片性、写流量趋势及跨key事务依赖。
哨兵模式根本没做数据分片
哨兵只是个“监控+切换”组件，它不碰数据分布逻辑。所有写请求仍全部打到单个主节点上，INFO replication里看到的master_repl_offset持续飙升、从节点slave_repl_offset长期落后超50万，就是主节点复制压力已饱和的明确信号。这不是配置能调出来的，是架构层面的硬约束。
写QPS超过3000或内存常驻超16GB时，哨兵会失效
主节点要同时扛住：客户端写入、fork()生成RDB、AOF rewrite、向所有从节点广播命令——这四件事在大内存或高写入下会互相卡死。常见现象包括：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主线程周期性卡顿（
latency monitor显示command或fork事件延迟突增） -
repl_backlog频繁溢出，导致从节点反复全量同步 - 加从节点反而让主节点网络和CPU更吃紧
集群模式要求客户端承担路由职责，哨兵不改变这一事实
Redis Cluster强制客户端计算slot（CRC16(key) % 16384）、处理MOVED/ASK重定向、保证多key操作落在同一slot。如果你还在用StrictRedis或没启用RedisCluster类，哪怕后端搭了Cluster，客户端发出去的MGET key1 key2 key3也会直接报CROSSSLOT错误。很多线上故障不是集群挂了，而是客户端压根没切到集群模式。
真正容易被忽略的是业务增长早期的数据特征
选哨兵还是集群，从来不是看当前QPS或内存用量，而是看key的分布是否天然可分片、写流量曲线是否在爬升、有没有跨key事务强依赖。等写压真上来再拆分，往往要动业务逻辑、改数据模型、停机迁移——这时候才发现，当初没埋好哈希标签（如user:{123}:profile），已经没法平滑过渡了。
