缓存雪崩发生后，最紧迫的任务就是如何快速恢复数据。许多开发者第一反应是编写循环，逐个对热 key 调用 setex——但 10 万条数据执行下来，仅网络往返就耗费了 100 多秒。更糟糕的是，如果所有 key 都使用相同的 3600 秒 TTL，一小时后将再次集体过期。那么，哪种恢复方案最高效？
最佳方案是：使用 pipeline 批量预热，并结合 TTL 随机化。如果不添加随机 TTL，刚刚热完的数据就会集体过期，相当于白费功夫。
为什么 mset 和单条 setex 都不可靠
先来看看最常见的两个错误选择。
mset只能处理纯字符串键值对，不支持带过期时间、哈希结构或列表等常见缓存类型；而且它本身不提供 TTL 参数——需要额外调用expire命令，反而更慢。- 单条
setex在 redis-py 中默认采用同步 I/O，导致客户端线程阻塞，吞吐量仅数百 QPS。假设 RTT 为 1ms，单线程每秒最多推送不到 1000 条，10 万条数据需要超过 100 秒。 - 更为致命的是：如果所有 key 设置相同的 TTL，恢复后一小时将再次迎来雪崩。
pipeline + setex 的正确操作指南
核心不在于“能否发送批量命令”，而在于“如何发送才能避免翻车”。redis-py 的 pipeline 默认开启了事务模式（transaction=True），但预热场景根本不需要事务的原子性——关闭它，可以省去一层 MULTI/EXEC 的封装开销。
具体参数应如何设置？
- 显式关闭事务：
r.pipeline(transaction=False)，连一点延迟都不要。 - 每批 500–2000 条：批次太小无法抵消网络开销；批次太大可能触发 Redis 的
client-output-buffer-limit限制，或导致客户端内存溢出。 - 每个 key 独立计算随机 TTL：推荐写法是
ttl = base_ttl + random.randint(0, 300)，不要偷懒在外面统一计算一个值然后复用。 - 示例代码片段：
pipe = r.pipeline(transaction=False)
for key, value in hot_data.items():
# 每个 key 的抖动独立计算
jittered_ttl = 3600 + random.randint(0, 300)
pipe.setex(key, jittered_ttl, json.dumps(value))
pipe.execute()
三个最容易被忽视的陷阱
许多团队虽然跑通了 pipeline，上线后却发现预热速度仍然缓慢，或者缓存再次崩溃——问题往往出在这些细节上。
- 没有禁用
decode_responses=True：如果原始数据中混有二进制或非 UTF-8 字符，该选项会对json.dumps后的结果再次解码，导致报错并静默失败。预热阶段建议临时关闭。 - 连接池配置过于保守：默认
max_connections=10在并发预热时是瓶颈。临时调整到 50 以上，预热完成后改回，不会影响线上运行。 - 没有进行分片预热：将所有热 key 塞进一个 pipeline，一旦某条 key 超长或格式异常导致 execute 报错，整批都会失败。应该按业务维度分组（例如按 user_id 取模），失败只影响局部，重试成本低得多。
真正拖慢预热效率的，从来不是 Redis 本身，而是客户端缓冲策略、TTL 设计和连接资源分配。批量操作并非“堆砌命令”，而是对网络、内存、服务端承载力的协同调度。
