微服务启动时应使用 redis.Pipeline 批量预热缓存，需在 Redis 客户端初始化后、HTTP server 启动前执行，每批≤1000 条，用 SETNX 加锁防多 Pod 重复写入，配合结构化日志与失败告警。
启动时调用 redis.Pipeline 批量写入预热数据
微服务启动瞬间直接塞几万条缓存，用单条 SET 会拖慢启动时间，甚至触发 Redis 连接超时。必须走 pipeline 减少网络往返。
常见错误是把预热逻辑塞在 init() 里——这时 Redis 客户端可能还没初始化完成，redis.Client 是 nil，panic 直接卡死进程。
- 预热代码必须放在
main()中、Redis 客户端成功 Dial 之后，且早于 HTTP server 启动 - 用
client.Pipeline()而非client.TxPipeline()：预热不需事务原子性，TxPipeline 会额外加锁、阻塞其他 goroutine - 每批不超过 1000 条：太大会触发 Redis 的
client-output-buffer-limit溢出，返回ERR Client sent AUTH, but no password is set这类误导性错误（实际是缓冲区满） - 记得调用
pipe.Exec()，漏掉这句等于白写
sync.Once 包裹预热逻辑，防止多实例并发重复加载
K8s 下一个服务起多个 Pod，每个都去拉数据库再写 Redis，不仅浪费资源，还可能因写入顺序不一致导致缓存脏读。
但 sync.Once 只在单进程内生效，跨 Pod 不起作用——别指望它解决分布式重复问题。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 真正要防的是同一 Pod 内多次 reload（比如热配置触发重启逻辑），这时
sync.Once有效 - 跨实例去重得靠外部协调：启动前先用
SETNX cache_warmup_lock 1 EX 30尝试抢锁，成功才执行预热，失败就 sleep 后重试或跳过 - 别用
time.Sleep(5 * time.Second)等别人写完——没锁机制的话，纯靠猜时序必踩坑
预热数据从 MySQL 读取时，避免 SELECT * 和全表扫描
缓存预热不是“把库倒进 Redis”，而是按业务真实访问模式选子集。一上来 SELECT * FROM product，几十 GB 表直接 OOM。
更隐蔽的问题是：MySQL 查询没加 FOR UPDATE 或隔离级别太低，预热中途有人改数据，缓存和 DB 瞬间不一致。
- 只查必要字段：比如缓存只需要
id,name,price，就明确写SELECT id,name,price FROM product WHERE status = 1 - 用覆盖索引：WHERE 条件和 SELECT 字段都在同一个索引里，避免回表
- 分页拉取加
ORDER BY id LIMIT 1000 OFFSET ?，别用OFFSET大值（如 100000），改用游标式查询：WHERE id > last_id ORDER BY id LIMIT 1000 - 读之前显式设置
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ，确保预热期间看到的数据快照一致
预热失败时，日志要带上下文，别只打 "warm up failed"
线上出问题，第一反应是看日志。如果只记 warm up failed，等于没记。
最常被忽略的是错误传播链断掉：DB 查询报错 → 预热跳过 → 缓存空击 → 接口大量慢查询，但日志里找不到源头。
- 每一步都打结构化日志：例如
log.Printf("warmup: load from mysql failed, sql=%s, err=%v", sql, err) - 关键参数打出来：
cache_key_prefix="prod:", batch_size=1000, redis_addr="redis:6379" - 失败后别静默降级：至少记录 “跳过预热，后续请求将穿透 DB”，否则运维完全不知道缓存根本没生效
预热不是“启动时跑一遍就完事”的功能，它的健壮性取决于你是否把每一步的失败路径都当成主流程来设计。尤其是跨服务依赖（DB/Redis/配置中心）任何一个环节抖动，都可能让整个预热无声失效。
