真正起效的是命令聚合、连接复用、结构精简和规避阻塞操作；pipeline批量写降低rtt，控制50–200条/批；禁用keys/flush等阻塞命令；优先hset存对象、字段名缩短；连接池需合理配置并开启健康检测。
直接结论：单靠“换机器”或“加Redis实例”解决不了写入吞吐瓶颈；真正起效的是命令聚合、连接复用、结构精简和规避阻塞操作这四类实操动作。
用 Pipeline 批量写代替逐条 SET
高频小写入（比如每秒 5000 次 SET user:1001 name "Alice"）走默认模式，实际会卡在 TCP 往返上。Pipeline 把多个命令打包发一次，服务端顺序执行后统一回包，RTT 从 N 次降到 1 次。
- 批量大小控制在 50–200 条/批较稳，超 500 条容易触发 Redis 单次执行超时（默认
timeout是 0，但大 batch 仍可能被客户端或中间件中断） - Go 客户端用
r.Pipeline()，Python 用pipe.execute()，Java 用pipeline.sync()，别漏掉execute()或sync()否则命令根本不发 - 注意：Pipeline 不保证原子性，失败需整体重试；若业务要求强一致性，得配合 Lua 脚本或事务
避免在写路径里用 KEYS、FLUSH*、SLOWLOG 等阻塞命令
这些命令会独占主线程，哪怕只执行 200ms，所有后续写请求都会排队——高并发下等于“全服卡顿”。线上必须禁用 KEYS *，改用 SCAN 分片遍历；FLUSHDB 改成按前缀 DEL 清理。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
SCAN的count参数不是精确条数，而是“每次扫描的槽位上限”，设为 100–500 更平衡速度与压力 - 监控项重点关注
redis_commandstats_cmd_get_calls和redis_blocked_clients，一旦后者持续 > 0 就要查是否有阻塞命令残留 - 开发环境跑的 Lua 脚本，上线前务必检查是否含
redis.call("KEYS", ...)或长循环，这类脚本在高并发下等同于自毁
写入前压缩结构，少存冗余字段
Redis 写入耗时和序列化/反序列化成本正相关。一个 2KB 的 JSON 字符串写入，比拆成 5 个 HSET user:1001 name "A" age "25" ... 多花 3–5 倍时间（实测 Go + redis-go v9.0）。
- 优先用
HSET存对象，不用SET存 JSON；用ZADD存带权重的列表，不用LPUSH + SORT - 字段名尽量短：
n代替name，ts代替timestamp，节省内存也降低网络传输量 - 值里别存 base64 图片、HTML 片段等大 Value；超过 1KB 的数据，考虑写 MySQL 或对象存储，Redis 只存 ID 引用
连接池配置不当会让吞吐量腰斩
连接池太小（如 maxIdle=5），高并发时大量请求在等连接；太大（如 maxTotal=1000）又浪费 fd 和内存，还可能触发 Linux 的 epoll 性能拐点。
- 推荐起始值：
maxTotal=200、maxIdle=50、minIdle=10，再根据redis_connected_clients监控指标动态调优 - 务必开
testOnBorrow=true（或对应客户端的健康检测），否则连接断连后请求会卡死在 borrow 阶段 - Go 的
redis.NewClient默认不带连接池，要用&redis.Options{PoolSize: 200}显式设置；Python 的redis.ConnectionPool也需手动传入，不能只靠redis.Redis()默认构造
最常被忽略的一点：写入吞吐不是纯 Redis 参数问题，它和上游应用的批量节奏、下游 MySQL 的消费能力、甚至网络 MTU 都耦合。压测时如果只看 Redis QPS，很可能掩盖了 BRPOP 阻塞超时、Goroutine 泄漏或 GORM 批量插入锁表这些真实瓶颈。
