Redis集群不提升单key写入速度，反而可能因路由、重定向和Gossip开销变慢；仅当key均匀分布且总吞吐逼近单节点瓶颈时才体现扩容价值。
为什么 Redis 集群写入不一定更快
直接上结论：Redis 集群本身不自动提升单 key 写入速度，反而可能因哈希槽路由、跨节点重定向、Gossip 通信开销而变慢。只有当写入请求天然分散（key 分布均匀）、且总吞吐量逼近单节点瓶颈时，集群才体现写入扩容价值。盲目扩节点却不调整参数，反而会放大 MOVED 重定向延迟或 ASK 迁移抖动。
cluster-require-full-coverage no 避免写入中断
默认情况下，只要集群中任意一个哈希槽不可用（比如某个主节点宕机且无从节点接管），整个集群拒绝所有写入，报错 CLUSTERDOWN Hash slot not served。这对写入连续性是致命打击。
实操建议：
- 生产环境务必设为
cluster-require-full-coverage no，让集群在部分槽不可用时仍可写入其余可用槽 - 该配置需在每个节点的
redis.conf中设置，并重启或用CONFIG SET cluster-require-full-coverage no热生效 - 注意：这要求客户端能正确处理
MOVED和ASK响应，推荐使用支持集群自动重试的客户端（如redis-py-cluster或 Lettuce）
禁用 AOF + 调整 save 策略减少 fork 延迟
集群中每个节点独立做 RDB/AOF，fork() 子进程时若主进程内存大（>10GB），一次 fork 可达数百毫秒，直接卡住所有写请求。查看延迟用 INFO STATS 中的 latest_fork_usec。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键调整点：
- 若业务可接受秒级数据丢失，关闭 AOF：
appendonly no；或改用appendfsync everysec（不选always） - 禁用 RDB 自动保存：
save ""，改由外部定时触发（如每天低峰期SAVE或BGSAVE） - 调高
vm.overcommit_memory=1，避免 fork 因内存申请失败而卡死 - 确保使用 SSD —— AOF rewrite 或 RDB dump 时磁盘 IO 是主要瓶颈
客户端必须启用 pipeline + hash-tag 控制分片粒度
集群写入提速的核心不在服务端参数，而在客户端如何发请求。没 pipeline 的逐条 SET 在集群下等于多次 TCP 往返 + 多次槽计算 + 多次连接切换。
两个硬性要求：
- 所有批量写必须走 pipeline：Python 示例中
pipeline.execute()之前塞入上百个命令，比 100 次单独SET快 5–10 倍 - 批量操作的 key 必须落在同一节点，否则 pipeline 会失败。用 hash-tag（花括号包裹公共前缀）强制分片，例如
user:{123}:name、user:{123}:email保证同属一个槽 - 避免在 pipeline 中混用不同 tag 的 key，否则客户端会拆成多个 pipeline 请求，失去批量意义
真正卡集群写入的，从来不是“加了几个节点”，而是 fork 延迟没控住、AOF fsync 没调对、客户端没 pipeline、key 没打 tag —— 这四点漏掉任一，集群反而比单节点更慢。
