Redis缓存预热核心目标是系统启动或数据变更时提前加载热点数据，避免缓存穿透与数据库压力；分为全量预热（分批异步加载）和增量预热（Canal监听实时同步），强调非阻塞、分批、幂等与过期兜底。
Java 批量数据库操作结合 Redis 缓存预热，核心目标是：在应用启动或数据更新后，**一次性从数据库高效拉取全量热点数据，并批量写入 Redis**，避免逐条加载的网络与序列化开销，提升预热速度和系统就绪效率。关键不在“能不能做”，而在于“怎么做才稳、快、可控”。
选对批量读取方式，避免拖垮数据库
全量加载不等于全表扫——必须有明确范围和节奏：
- 按业务域分批查：比如用户基础信息、商品类目、配置字典等各自独立加载，用不同 Service 分离逻辑，失败互不影响；
-
启用分页+游标式查询：对大表（如订单历史、日志）禁用 OFFSET LIMIT，改用主键/时间戳游标（如
WHERE create_time > ? ORDER BY create_time LIMIT 1000），防止深分页性能衰减； -
加读锁或只读事务：若数据一致性要求高，可在预热期间对源表加
SELECT ... FOR SHARE（PostgreSQL/MySQL 8.0+），避免被长事务阻塞； -
跳过冷数据：通过访问日志分析或业务规则过滤（如
status = 'ACTIVE'、last_access_time > DATE_SUB(NOW(), INTERVAL 30 DAY)），不加载已归档或长期未用的数据。
批量写入 Redis，拒绝逐 key set
单条 SET 会带来 N 次网络往返和序列化开销。应使用原子化批量操作：
-
RedisTemplate + pipeline（推荐）：Spring Data Redis 提供
executePipelined()，将数百上千个写命令打包发送，一次 RTT 完成； -
Jedis/Lettuce 原生 pipeline：Lettuce 支持异步 pipeline，Jedis 需手动调用
pipelined().set(...).set(...).sync()； - 慎用 MSET：仅适用于纯 String 类型且 key-value 结构扁平的场景（如配置项），不支持过期时间、Hash/ZSet 等复杂结构；
-
大 Value 拆分或压缩：单条记录超 10KB 时，考虑 JSON 字段精简、启用
GZIP序列化（需客户端统一解压），或拆为 Hash 多字段存储（HSET user:1001 name "Alice" age 28）。
控制加载节奏，防打满 Redis 和 DB 连接池
全量预热不是“越快越好”，而是“够用即停、可中断、可重试”：
立即学习“Java免费学习笔记（深入）”；
-
限流加载：每批次处理 500–2000 条，间隔 50–200ms，用
Thread.sleep()或RateLimiter控制节奏； -
连接池隔离：为预热专用配置独立的
HikariCP数据源（最小空闲=1，最大=3）和LettuceClientResources，避免挤占业务连接； - 失败自动降级：某批次出错（如 Redis 拒绝写入、DB 查询超时），记录错误日志 + 当前 offset，跳过继续下一批，最后汇总失败 key 后续人工补漏；
-
提供手动触发入口：暴露 HTTP 接口（如
POST /cache/preload?module=users）或 Actuator 端点，支持灰度发布后按模块分批预热。
保证数据一致性与可观测性
预热不是“写完就完”，要能验证、能回滚、能追踪：
-
写入后校验数量：对比 DB 查询总数 vs Redis
KEYS user:* | wc -l（仅开发环境）或用SCAN游标统计（生产环境）； -
设置合理过期策略：静态数据（如省市区）可永不过期（
EXPIRE不设）；动态但低频变更数据（如商品类目）设 24h；严禁全量数据共用一个超长 TTL 导致脏数据滞留； -
记录预热元数据：将本次预热的模块名、起始时间、总条数、成功数、耗时写入 Redis 的 Hash（如
HSET cache:preload:summary users "{'ts':1726450000,'total':12450,'ok':12448,'costMs':8420}"），便于监控大盘； -
关闭时清理（可选）：若为单机测试环境，可通过
@PreDestroy调用redisTemplate.delete("user:*")清理，但生产环境禁止此操作。
