Redis缓存预热需“主动、可控、安全”：聚焦热点数据，应用层驱动分批加载（每批1000–5000 key），配合TTL兜底与CDC增量同步，确保一致性与系统稳定。

系统上线前批量加载 Redis 缓存数据，核心是“主动、可控、安全”地把数据库里的热点数据灌进 Redis，而不是等第一个用户请求才去查库。重点不是“能不能写进去”，而是“怎么写得稳、写得准、写得不拖垮系统”。

明确预热范围：只加真正需要的热点数据

全量表数据（比如几千万用户）没必要、也不该全塞进 Redis。预热必须聚焦高频访问、低变更率、影响面大的数据，例如：

• 商品中心的热销商品基础信息（id、标题、价格、库存状态）
• 用户服务中的 VIP 用户配置或常用地址
• 配置类数据（开关项、地区字典、支付渠道参数）

建议结合历史访问日志或监控（如 SkyWalking、APM）统计 top 1000 / top 5000 的 key 模式，再反查数据库生成预热清单，避免凭经验拍脑袋。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

选择合适的数据加载方式

不推荐在启动脚本里直接用 redis-cli 一把梭——Redis 可能还没 ready，网络不通、认证失败、连接数超限都可能导致启动卡死或静默失败。

• 应用层驱动更可靠：用业务代码（Spring Boot 的 @PostConstruct + RedisTemplate、Go 的 redis-go、Python 的 redis-py）执行预热，天然支持重试、超时、日志、健康检查（如先 PING 再写入）
• 结构简单用 mset：全是 string 类型且 TTL 相同，mset 一次写千级 key，速度快、原子性强
• 结构复杂或需差异化过期时间用 pipeline：可混合 SET + EXPIRE + HSET，灵活控制每个 key 的生命周期和序列化格式

控制节奏，防止 Redis 崩溃

一次性写入几十万 key 容易触发 Redis 内存暴涨、客户端缓冲区堆积、甚至 OOM。必须分批+降速：

• 每批控制在 1000–5000 个 key，写完 sleep 50–100ms，给 Redis 主动释放内存和执行后台任务的时间
• 提前估算内存占用：抽样测几个典型 key 的 MEMORY USAGE，乘以总量，确保不超过 maxmemory 的 70%
• 禁用 RDB/AOF 重写或临时调大 repl-backlog-size，避免预热期间叠加复制压力

保障一致性与可维护性

预热不是“写完就完”，后续数据变更必须跟上，否则缓存很快变脏：

• 预热完成后，立即启用 Canal 或 Debezium 等 CDC 工具监听数据库变更，实时同步增删改到 Redis（即增量预热）
• 所有预热 key 必须设置合理 TTL（比如 24h），作为兜底机制；不要依赖永久 key，否则无法自动容错
• 把预热逻辑封装成独立模块，支持开关控制（如通过 lua_shared_dict 或配置中心动态启停），方便灰度、回滚、二次触发