应优先使用 pipeline 批量发命令替代单条轮询，避免高 rtt 开销；对计数类操作用 incr/decr 原子增减；设值带过期统一用 set 的 ex/px/nx 参数；高频读不变 key 应加客户端本地缓存。
用 pipeline 批量发命令，别单条轮询
Redis 单次网络往返（RTT）开销远大于命令执行本身，相同 Key 频繁读写时，反复 GET 或 SET 就是把延迟拉满。直接改用 pipeline，一次 TCP 包塞进多条命令，服务端顺序执行、批量回包。
常见错误现象：for i in range(100): redis.get("user:123") 导致 100 次 RTT，实测可能比 pipeline 慢 5–10 倍。
- Python redis-py 中，用
redis.pipeline()获取管道对象，链式调用get()/set()后统一execute() - 注意：pipeline 不是事务，默认不保证原子性；如需隔离，得显式加
transaction=True - 别在 pipeline 里混用会改变连接状态的命令（比如
SELECT切库），容易出错
INCR / DECR 替代读-改-写三步操作
对计数类 Key（如访问次数、库存余量）做增减，千万别先 GET 再 SET——这中间有竞态窗口，高并发下必丢数据。
使用场景：用户点赞数 +1、秒杀库存扣减、限流计数器更新。
-
INCR key原子加 1，返回新值；DECRBY key 5可指定步长 - 如果初始值不确定，
INCR自动初始化为 0，不用提前SETNX - 注意：这些命令只支持整数，浮点数得换
INCRBYFLOAT，但精度和性能略低
用 EXPIRE + SET 原子设值带过期，避免 SET + EXPIRE 分两步
频繁设置带过期时间的 Key（比如缓存结果），分开调用 SET key val 和 EXPIRE key 60 有风险：万一第一条成功、第二条失败或超时，Key 就变成永不过期。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Redis 2.6.12+ 支持 SETEX，但更推荐统一用 SET 的扩展参数：
-
SET key value EX 60—— 设置字符串值并指定秒级过期 -
SET key value PX 60000—— 毫秒级，适合短时锁或临时标记 -
SET key value NX EX 30—— 仅当 Key 不存在时才设（分布式锁常用） - 老版本 Redis 不支持这些参数？别硬扛，升级或换
SETEX/PSETEX
高频读同个 Key 时，客户端本地缓存比反复查 Redis 更稳
不是所有“频繁调用”都该压给 Redis。比如配置项、开关状态这类几乎不变的 Key，每毫秒都 GET 一次，既浪费连接又放大 Redis 压力。
性能影响：本地内存访问比 Redis 网络调用快 2–3 个数量级；兼容性上，任何语言都能做简单缓存。
- 加一层轻量缓存，比如 Python 用
@lru_cache(maxsize=128)，Java 用Caffeine - 缓存失效策略要匹配业务：配置变更少？设个固定 TTL（如 5 分钟）；变更频繁？配合 Redis 的
PUB/SUB主动通知清缓存 - 别缓存大对象（如整个用户详情），容易撑爆内存；优先缓存布尔值、枚举、小字符串
真正难的是权衡：缓存一致性、失效时机、降级逻辑——这些没法靠一个命令解决，得结合监控看实际命中率和延迟分布。
