Golang中的分布式缓存预热方案 Go语言微服务启动时的缓存同步

微服务启动时应使用 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语言免费学习笔记（深入）”；

• 真正要防的是同一 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/配置中心）任何一个环节抖动，都可能让整个预热无声失效。