Java中使用Redis缓存热点数据的核心是“何时存、如何存、保一致、防异常”：识别读多写少的热点数据（如爆款商品），通过先查缓存再查库回填、设置合理TTL与随机过期时间，结合空值缓存、布隆过滤器、分布式锁分别应对穿透、击穿、雪崩，并采用先删后更或延迟双删保障一致性。
Java 中使用 Redis 缓存热点数据，核心是让高频读取的数据“绕过数据库”，直接从内存中快速返回。关键不在“能不能存”，而在“什么时候存、怎么存、怎么保一致、怎么防异常”。下面分四块说清楚。
识别并标记热点数据
不是所有数据都值得缓存，重点盯住“读多写少+访问集中”的数据。比如电商的爆款商品、新闻 App 的头条文章、登录态中的用户基础信息。
- 可通过业务日志、SQL 慢查日志、监控平台（如 SkyWalking）统计访问频次，筛选出每分钟被查超百次的 key
- 在 DAO 层或 Service 方法上加业务标识，例如用 @Cacheable(value = "hotProduct", key = "#id")（Spring Cache）或手动拼 key 如 "product:hot:" + productId
- 避免缓存全量表数据——只缓存字段精简后的 DTO，比如商品只需缓存 id、name、price、stock，不缓存描述富文本或历史变更记录
实现“先查缓存、再查库、回填缓存”流程
这是最基础也最关键的读路径逻辑，必须保证原子性和可维护性。
- 用 Jedis 或 Lettuce 连接 Redis，优先推荐 Lettuce（支持异步、线程安全、响应式）
- 查询时先 get(key)，命中则直接反序列化返回；未命中则查数据库，成功后 set(key, value, "EX", 300) —— TTL 建议设为 5~30 分钟，避免永久缓存导致脏数据
- 不要在 catch 块里静默吞掉 Redis 异常，应降级为直连数据库，并打告警日志，防止缓存组件故障时雪崩
应对三大典型风险：击穿、穿透、雪崩
光存取还不够，得守住边界条件。
立即学习“Java免费学习笔记（深入）”；
- 缓存击穿（单个热点 key 过期瞬间大量请求涌向 DB）：对关键 key 加分布式锁（如 Redis 的 SET key value NX EX 10），只放行一个线程查库写缓存，其余等待后重试读缓存
- 缓存穿透（查一个数据库根本不存在的 id，比如 -1 或随机字符串）：对空结果也缓存，如 set("product:hot:-1", "", "EX", 60)，配合布隆过滤器前置拦截非法 key
- 缓存雪崩（大量 key 同一时间过期）：TTL 加随机偏移，例如 baseTTL = 300 + ThreadLocalRandom.current().nextInt(60)
配合预热与更新策略保障可用性
缓存不是“设完就完”，要主动管理生命周期。
- 系统启动时执行预热任务，把已知热点数据（如首页轮播位、分类导航）提前 load 到 Redis，避免冷启动冲击 DB
- 数据更新时，采用“先删缓存，再改 DB”或“先改 DB，再删缓存”（推荐后者，配合延迟双删：删一次 → 改 DB → sleep 100ms → 再删一次，覆盖主从延迟窗口）
- 对强一致性要求高的场景（如库存扣减），可结合 Redis 的 Lua 脚本做原子操作，或改用 Redis Streams + 消费者组异步更新缓存
