【Redis分布式缓存实战】第12章 基础业务缓存落地实战
热点数据缓存商品、用户、配置信息缓存方案针对商品、用户、配置三类核心热点数据结合其数据特性、访问频率、一致性要求的差异设计分层缓存、差异化策略、高可用防护的完整方案核心目标降低数据库压力、提升接口响应速度、保证业务可用性。一、三类数据核心特性决定缓存策略表格数据类型访问特点数据规模一致性要求变更频率商品数据读多写少热点集中爆款 / 秒杀大最终一致中价格 / 库存 / 上下架用户数据读多写少单用户高频访问中最终一致低信息修改配置数据读极多写极少全局共享小强一致极低后台修改二、分场景专项缓存方案方案 1商品数据缓存核心热点最复杂覆盖商品基础信息、库存、详情、热点榜单适配电商首页、详情页、秒杀场景。Key 规范设计redis# 商品基础信息id、名称、价格、封面、状态 product:base:{spu_id} # 商品库存秒杀核心 product:stock:{sku_id} # 商品详情富文本、参数、图片 product:detail:{spu_id} # 热点商品榜单 product:hot:listRedis 数据结构选型表格数据模块结构优势基础信息Hash节省内存支持单字段更新仅改价格不刷新全量商品库存String支持原子操作INCR/DECR秒杀防超卖商品详情String(JSON)简单直接适配富文本大字段热点榜单ZSet天然排序实时更新热度排名过期 更新策略普通商品缓存 24 小时 随机偏移1-10 分钟避免缓存雪崩热点 / 秒杀商品永不过期后台修改后主动更新缓存商品库存不设过期Redis 原子操作 异步同步 DB更新模式Cache Aside读缓存→命中返回→未命中查 DB 并写缓存写 DB→删除 / 更新缓存。热点优化多级缓存本地缓存 (Caffeine)缓存热点商品TTL 1~5s扛住 90% 流量大 Key 拆分商品详情 10KB 时拆分字段避免 Redis 大 Key 阻塞热点识别监控 QPS 自动标记热点单独缓存分片隔离。方案 2用户数据缓存高频访问隐私优先覆盖用户基础信息、登录会话 (Token)、个性化配置适配登录、个人中心、权限校验。Key 规范设计redis# 用户基础信息 user:base:{uid} # 登录Token会话核心 user:token:{token_string} # 用户个性化配置 user:config:{uid}Redis 数据结构选型基础信息 / 个性化配置Hash支持单字段修改登录 TokenString存储用户 ID、权限、过期时间。过期 更新策略登录 Token严格 TTL如 2 小时到期自动登出不主动更新用户基础信息缓存 7 天 随机偏移信息修改后主动删除缓存隐私处理手机号、身份证脱敏存储Token 加盐加密。优化点批量查询用户信息用MGET减少 Redis IO登录态仅存在 Redis不依赖数据库提升登录校验速度。方案 3配置信息缓存全局共享强一致覆盖系统全局配置、业务开关、模块参数适配后端管理、前端动态配置。Key 规范设计redis# 全局系统配置 config:system:{config_key} # 业务模块配置 config:business:{module}:{config_key} # 全量配置哈希 config:all:hashRedis 数据结构选型单配置项String全量配置Hash集中管理批量读取。过期 更新策略核心规则永不过期配置变更极少避免缓存失效击穿 DB更新方式后台修改配置 → 更新 DB →主动推送更新 Redis预热机制服务启动时全量加载配置到 Redis。强一致优化本地缓存 Redis 发布订阅配置变更时Redis Pub/Sub 通知所有服务刷新本地缓存配置版本号每次变更版本 1服务通过版本判断是否刷新缓存。三、通用核心缓存高可用防护必解决 4 大问题针对热点数据缓存的穿透、击穿、雪崩、一致性问题提供落地解决方案缓存穿透查询不存在的数据击穿数据库场景查询已删除商品、不存在的用户 ID方案缓存空值TTL 5 分钟避免长期无效缓存布隆过滤器提前预热商品 ID / 用户 ID过滤非法请求。缓存击穿热点 Key 过期瞬间流量打 DB场景爆款商品缓存过期、热门用户信息失效方案热点 Key永不过期分布式互斥锁Redisson仅一个请求重建缓存本地缓存兜底。缓存雪崩大量 Key 同时过期 / Redis 宕机方案过期时间加随机偏移量避免集中失效Redis 集群部署主从 哨兵 / 集群多级缓存 熔断降级Redis 宕机时降级读本地缓存 / 默认配置。数据一致性DB 与缓存不一致商品 / 用户容忍最终一致采用延迟双删写 DB→删缓存→延迟 500ms 再删配置强一致采用主动推送更新 版本号控制进阶Canal 监听 MySQL Binlog异步自动更新缓存。四、落地最佳实践缓存分层架构本地缓存Caffeine→ Redis 分布式缓存 → 数据库热点数据优先走本地缓存大 Key 治理禁止存储 10KB 的缓存值商品详情、富文本拆分字段存储缓存预热秒杀商品、新活动商品、系统配置提前加载到 Redis避免冷启动压力监控告警监控缓存命中率目标 95%、热 Key、大 Key、过期 Key 数量、Redis 内存技术选型分布式锁Redisson解决缓存击穿数据同步CanalBinlog 异步更新本地缓存Caffeine性能远超 Guava。总结商品数据HashStringZSet热点永不过期多级缓存扛量用户数据Hash存储信息String 管理 Token隐私脱敏配置数据永不过期 主动更新发布订阅保证强一致核心防护解决穿透 / 击穿 / 雪崩保证缓存高可用与数据一致性。分页缓存、列表缓存、详情页缓存最佳实践结合电商 / 后台系统最常用的三大缓存场景详情页、列表、分页给你一套可直接落地、无坑、高性能的 Redis 最佳实践完全适配商品、用户、配置业务解决大 Key、缓存失效、性能差、数据不一致核心问题。Redis 三大缓存场景 最佳实践核心总原则贯穿所有场景小 Key 优先列表 / 分页只存 ID不存全量对象杜绝大 Key读写分离详情查单 Key 缓存列表 / 分页查 ID 集合再批量查详情删缓存不更新缓存数据变更删除缓存不直接更新避免并发不一致热点兜底热点数据永不过期 本地缓存。一、详情页缓存单条数据商品 / 用户 / 配置详情适用场景商品详情、用户信息、系统配置详情、订单详情等单条高频查询数据。最佳实践Key 设计规范redis# 商品详情 detail:product:{spuId} # 用户详情 detail:user:{userId} # 配置详情 detail:config:{configKey}数据结构选型唯一首选HashredisHSET detail:product:1001 name iPhone16 price 5999 stock 100 status 1✅ 优势支持单字段更新改价格不用刷新全量详情内存占用比 JSON String 低 30%批量获取字段HMGET性能极高。过期 更新策略普通详情TTL 24h 随机偏移1-10 分钟防雪崩热点详情爆款商品永不过期更新逻辑Cache Aside 最优plaintext写数据库 → 删除Redis缓存 → 可选延迟500ms再删一次防双写不一致高可用防护防击穿热点 Key 永不过期 分布式锁Redisson防穿透不存在的 ID 缓存空值TTL 5min大 Key 治理详情 10KB 拆分如详情图、富文本单独存 Key。二、列表缓存无分页首页榜单、分类列表、热门数据适用场景首页热门商品、分类下商品列表、用户收藏列表、系统配置列表无需翻页的固定列表。核心金规列表只存 ID不存全量对象内存节省 90%更新零成本最佳实践数据结构选型按业务选表格场景结构示例 Key优势固定顺序列表订单 / 收藏Listlist:user:1001:collect左进右出顺序固定排序类列表热度 / 价格 / 时间ZSetlist:product:hot自动排序支持范围查询静态列表分类 / 配置Setlist:config:all去重快速判断存在Key 设计规范redis# 热门商品列表ZSetscore热度值 list:product:hot # 分类商品列表 list:product:category:{categoryId} # 用户收藏列表 list:user:{userId}:collect写入 查询逻辑plaintext1. 写入DB查询ID集合 → 存入Redis列表设置TTL 2. 查询Redis查ID列表 → 批量查详情缓存MGET/HMGET → 组装返回过期 更新策略TTL1~6h根据更新频率 随机偏移更新数据新增 / 修改 / 删除 →直接删除整个列表缓存最简单、最稳定热点优化首页列表用本地缓存Caffeine兜底TTL 1~5s。三、分页缓存带页码商品分页、订单分页、后台列表核心痛点90% 的人踩坑页码越多缓存命中率越低没人翻到第 100 页数据增删后分页数据错位 / 重复 / 漏数据大偏移量limit 10000,10DB 性能极差缓存每一页数据内存爆炸、更新困难。分场景最佳实践业界标准方案场景 1浅分页用户端前 3 页99% 流量适用商品列表、订单列表用户只看前几页只缓存前 3 页第 4 页及以后直接查 DB列表依然只存 ID不存对象Key 设计redispage:product:category:{categoryId}:1 # 第1页 page:product:category:{categoryId}:2 # 第2页策略缓存 TTL 10~30min数据变更删除所有分页缓存。场景 2深分页后台管理第 100 页 ✅绝对不做 Redis 缓存原因偏移量越大Redis/DB 性能越差缓存无意义方案直接查数据库加索引、优化 SQL。场景 3滚动分页APP / 小程序上拉加载最优解适用电商 APP、短视频无页码用游标滚动用游标cursor代替页码如最后一个商品 ID / 时间戳Redis 用ZSet存储排序 ID按游标范围查询redis# 热门商品ZSetscore创建时间 ZREVRANGEBYSCORE list:product:hot inf (1712345678 LIMIT 0 20优势无数据错位、缓存永久有效、性能极致。分页缓存终极总结用户端缓存前 3 页 只存 IDAPP 端用游标分页淘汰普通页码后台端不缓存直接查 DB更新数据变动 → 删除全部分页 Key。四、三者通用 顶级优化必做批量查询优化性能提升 10 倍详情页 列表组合时用Redis 批量命令减少 IOredis# 批量查商品详情Hash HMGET detail:product:1001 name price HMGET detail:product:1002 name price缓存一致性保障列表 / 分页删缓存不更新变更直接删整个列表详情页延迟双删写 DB→删缓存→500ms 后再删强一致需求用 Canal 监听 Binlog自动删缓存。高可用三防防雪崩所有缓存 TTL 加随机偏移防击穿热点列表 / 详情永不过期防穿透空结果缓存TTL 5min 布隆过滤器。大 Key 绝对禁止详情页10KB 拆分字段列表 / 分页只存 ID不存 JSON 对象一个 List/ZSet 最多存1000 条 ID超过拆分。极简落地口诀好记好用详情用 Hash单字段更新热点永不过期列表存 IDZSet 做排序变更删全量分页只缓存前 3 页APP 用游标后台不缓存批量查、删缓存、随机 TTL大 Key 全拆分。这套方案是电商大厂标准方案兼顾性能、内存、一致性直接复制到项目中即可使用缓存预热、缓存更新、缓存失效标准化流程这三大流程是Redis 缓存治理的核心标准核心目标提升缓存命中率、保证缓存与 DB 数据最终一致性、彻底杜绝缓存雪崩 / 击穿 / 穿透三大故障是互联网企业生产环境的通用规范。一、缓存预热Cache Preload定义系统冷启动、流量高峰前主动将热点数据提前加载到 Redis避免首次请求直接击穿到数据库导致 DB 压力激增。适用场景系统重启、大促 / 活动流量高峰、核心热点数据首页、商品详情、配置表初始化。标准化流程预热数据规划筛选热点数据通过访问日志 / 监控禁止全量预热定义统一规则Key 命名、数据结构、基础 TTL、淘汰策略优先级核心业务数据优先非核心数据懒加载。数据源校验从从库 / 只读库拉取数据避免主库压力校验数据完整性过滤脏数据、无效数据。批量异步加载分批加载每次 100~1000 条防止 DB/Redis 阻塞批量写入使用Redis Pipeline提升写入性能减少 IO异步执行线程池 / MQ 异步预热不阻塞主线程。预热校验与标记抽查验证Key 存在性、值与 DB 一致性、TTL 正确性写入预热完成标记如cache:preload:finish:order1防止重复预热。兜底与告警预热失败自动降级为「懒加载」请求直接查 DB异常告警预热超时、失败率过高触发即时告警。最佳实践开启手动预热开关大促前主动触发仅预热热点数据不做全量预热。二、缓存更新Cache Update核心标准方案企业唯一生产级方案Cache Aside 旁路缓存模式 → 先更新数据库再删除缓存❌ 严禁使用先删缓存再更 DB、直接更新缓存必然导致数据不一致。定义DB 数据发生增删改时同步清理 Redis 缓存保证缓存与 DB最终一致性。标准化基础流程接收业务更新请求订单修改、商品信息更新等DB 事务更新开启事务执行增删改提交成功则继续回滚直接返回失败删除 Redis 缓存核心数据同步删除非核心异步删除不影响主流程失败重试本地重试 3 次 → 仍失败则投递 MQ 死信队列定时重试 告警一致性兜底定时任务校验 DB 与缓存数据不一致自动修复。进阶方案延迟双删强一致性场景解决并发读写导致的短暂数据不一致流程第一次删除 Redis 缓存更新数据库延迟 500ms等待并发请求写入旧缓存完成第二次删除 Redis 缓存。方案对比为什么选「先更 DB再删缓存」表格方案核心问题先删缓存 → 再更 DB并发查询会写入旧缓存数据永久不一致先更 DB → 再更缓存并发写覆盖缓存脏数据性能浪费先更 DB → 再删缓存最优方案最终一致无脏数据风险三、缓存失效Cache Invalidation定义缓存因TTL 过期、主动删除、内存淘汰失效核心解决三大缓存故障雪崩、击穿、穿透。分类被动失效Redis TTL 自动过期、内存淘汰主动失效业务更新时手动删除缓存。标准化流程分场景解决三大故障缓存雪崩大量 Key 同时过期 / Redis 宕机现象海量请求同时访问 DB导致 DB 崩溃标准解决方案过期时间打散TTL 基础时间 随机值(1~300s)杜绝集体过期高可用部署主从 哨兵 / Redis Cluster避免单节点故障互斥锁重建缓存过期时仅允许一个线程查 DB 重建缓存降级熔断Redis 宕机时返回默认值禁止访问 DB。缓存击穿热点 Key 过期大量请求打 DB现象单个热点 Key 过期请求直接击穿到 DB标准解决方案热点 Key永不过期不设置 Redis TTL用「逻辑过期」存储时间戳后台定时刷新分布式锁重建缓存时加锁防止 DB 压垮主动刷新流量高峰前手动刷新热点 Key。缓存穿透查询不存在的数据绕过缓存现象恶意请求查询无效数据缓存 / DB 均无数据持续打 DB标准解决方案缓存空值DB 无结果 → 写入空值到 Redis设置短 TTL1~5min布隆过滤器预热时存入合法 Key请求先过过滤器不存在直接返回参数校验接口层拦截非法 ID、恶意请求。通用失效标准步骤请求查询 Redis → 命中直接返回未命中校验是否穿透布隆过滤器 / 空值→ 是则返回默认值非穿透加分布式锁 → 查询 DB → 写入 RedisTTL 随机值淘汰策略Redis 配置volatile-lru只淘汰过期 Key业务缓存最优。四、企业级统一标准化规范Key 规范命名规则业务线:模块:功能:id例mall:product:detail:1001禁止无意义命名、特殊字符、超长 Key。过期规范必设 TTL禁止永久缓存热点 Key 除外TTL 必须加随机值防止雪崩热点数据使用逻辑过期不依赖 Redis 自动过期。操作规范更新 DB →必须删除缓存严禁直接更新缓存批量写入用 Pipeline禁止循环单条写入预热必须异步分批禁止同步全量加载。监控核心指标缓存命中率 ≥ 99%低于 95% 告警缓存删除失败率 ≤ 0.1%穿透 / 击穿 / 雪崩请求量 0Redis 内存使用率、响应时间、连接数实时监控。五、标准化异常处理流程缓存删除失败本地重试 → MQ 死信重试 → 人工告警预热失败自动降级懒加载 → 告警雪崩 / 击穿触发限流 熔断 → 兜底返回 → 告警数据不一致定时任务自动修复 → 日志排查。总结缓存预热异步分批加载热点数据提前初始化避免冷启动压力缓存更新严格遵循「先更 DB再删缓存」保证数据最终一致缓存失效通过打散 TTL、逻辑过期、布隆过滤器彻底解决雪崩 / 击穿 / 穿透整套流程是企业生产环境的标准最佳实践可直接落地使用。