项目的 Redis 缓存用于哪些业务,如何实现?

考查重点:业务缓存键与失效流程。商品详情以键/TTL缓存,未中回源、写后失效,权威数据在库并监测旧读

本题目录

参考答案

核心回答

下面以电商商品目录服务为参考示例,具体业务和参数可按项目调整。

Redis 主要缓存商品展示详情和分类字典。这类数据会被重复读取,更新相对少,适合减少数据库查询;MySQL 保存权威数据,Redis 中的内容可以从数据库重建。

  • 缓存内容:商品详情按商品 ID 存,value 是页面需要的名称、图片、分类 ID、展示价格等字段;分类字典单独缓存。使用业务前缀和结构版本区分键,避免不同数据混用。
  • 读取流程:先查 Redis,命中直接返回;未命中再查 MySQL,查询成功后把结果和 TTL 一起写入缓存。数据库确认不存在时,可短期缓存空值标记。
  • 更新流程:后台修改商品并提交数据库事务后,删除对应缓存,下次读取时重建;删除失败进入可靠重试。TTL 负责兜底,并加随机偏移,分散集中过期。
  • 异常与效果:热点重建合并请求,Redis 故障时限时、限量回源或降级,避免压垮数据库。效果看业务缓存命中率、回源量、接口延迟与内存使用,同时检查数据新鲜度。

商品展示允许的陈旧程度,与下单校验不同;实际成交价、库存是否可扣,要在权威业务链路中确认。

键、值和 TTL 怎样落到业务上?

示例商品详情键可设计为 shop:product:v1:{productId},分类键为 shop:category:v1:{categoryId},value 都先采用易于整体读取的 JSON 字符串。商品详情只保存展示所需字段和分类 ID,分类名称由分类缓存提供,减少分类改名时需要批量删除商品详情的范围。

v1 表示缓存结构版本,便于字段或序列化方式调整时平滑切换,和业务数据的新旧版本不是一回事。多租户场景还要把可信的租户标识放入键;如果结果随地区、语言或用户权限变化,也要体现相关维度,避免不同请求错误复用同一个结果。

TTL 应由业务新鲜度和回源成本共同决定。比如,商品展示详情可以先试用 5 分钟加 0~30 秒随机偏移,分类字典设得更长,查无结果的空值只保留 30 秒。这些是方案示例参数,需要根据更新频率、可接受的陈旧时间和实际负载调整;库存校验等关键决策不能直接沿用展示缓存的策略。

写入字符串值时,使用客户端支持的带过期时间写入操作,让值和 TTL 在同一条 Redis 操作中生效,避免先写值、再设 TTL 中途失败留下无过期时间的条目。覆盖已有值时也要明确重新设置还是保留 TTL,不能假定普通覆盖会自动沿用原过期时间。

命中、回源和更新失效怎样实现?

读取时先校验参数,再从缓存读取并反序列化。命中正常对象就返回;命中“无此商品”的标记则返回不存在;真正未命中时才回源。数据库查询失败不能当成商品不存在,也不能把超时结果写成空值。

对热点商品,同一个 key 的重建可以通过请求合并或互斥控制,获得重建资格后再查一次缓存。其他请求有限等待后重新读取,或者采用业务允许的旧值和降级结果。多实例下,本地锁只能合并各自进程内的请求;跨实例还需协调,并限制整个服务的回源并发。

更新时先提交数据库,再删除受影响的缓存;创建商品时也要清掉此前的空值缓存。删除失败要能够持久化重试;如果存在批量导入、其他服务写库等路径,还需让这些变更也触发失效,必要时接入 CDC。该流程仍有短暂旧读和迟到回填的可能,具体见如何保证 Redis 和 MySQL 的数据一致性?。

Redis 读取超时后,可以按容量预算回源;超出预算则快速降级,不让所有请求一起转向 MySQL。回填缓存失败时,已成功取得的数据库结果仍可返回,同时记录失败。若采用逻辑过期、异步刷新,要额外约定旧值能使用多久。穿透、击穿和雪崩的条件与治理见缓存穿透、击穿和雪崩分别是什么,如何治理?。

怎样判断缓存有效,而不是只多加了一层 Redis?

先按商品详情、分类字典等业务分别看命中率和回源次数,再比较相同负载下的接口延迟与数据库压力。低命中可能是数据复用不足、键维度过细、TTL 过短,或者更新频繁造成反复失效;不能只通过延长 TTL 提高数字。

同时关注缓存容量、过期与淘汰数量、热点 key、重建耗时和错误率。缓存未命中时数据库能否承受回源,以及修改后多久能读到新值,也应纳入验证。这样才能把性能收益与数据新鲜度、故障代价一起评估。

常见追问

为什么不用本地 Map 就够了? 本地缓存能省去网络访问,适合小而稳定的数据;多实例各有副本,容量和失效管理也分散。Redis 便于多个实例共享缓存,但增加网络与运维成本。只有热点和访问量确实需要时,才进一步考虑两级缓存。

会话、分布式锁、消息队列也算缓存吗? 它们是 Redis 的不同用途。查询缓存保存可重建副本;会话历史可能是需要保留的业务状态;锁协调并发;消息队列处理任务投递与消费。是否允许丢失、如何恢复和过期,不能用同一套缓存策略回答。

如果缓存的是菜单权限,TTL 也这么设吗? 需要重新评估。要讲清权限的权威来源、权限变更如何失效以及撤权多久生效;安全判断不能只照搬商品展示允许陈旧的条件。

对应教程

参考资料

  • 国内:JavaGuide:缓存基础常见面试题总结:参考本地、分布式与多级缓存的说明,解释正文中共享范围、容量、失效管理与是否引入 Redis 的取舍。
  • 国内:advanced-java:缓存的使用方式:借鉴重复读取、重建成本和缓存副作用的分析,说明正文商品目录示例的收益及新增维护成本。
  • 国内:JavaGuide:3 种常用的缓存读写策略详解:旁路缓存的读取回填与提交后失效流程,说明示例中请求怎样经过缓存和数据库,以及为什么不能只靠 TTL。
  • 国外:Redis:SET:过期参数和覆盖已有键的官方约定,说明如何让字符串值与 TTL 一起写入,以及覆盖时为什么需要明确 TTL 策略。
  • 国外:AWS:Caching challenges and strategies:借鉴过期与容量选择、请求合并和缓存不可用的处理,说明正文的热点保护、回源上限与效果验证。

相关面经

18 篇

科大讯飞

AI 应用开发工程师
一面
查看原面经 →
项目追问
Guava / Tair 两级缓存和 JVM 本地缓存解决什么业务问题,为什么需要?

靖安科技

后端工程师(RAG/Agent 项目)
秋招一面
查看原面经 →
追问
Redis 里具体存了什么

蚂蚁集团

面经合集
查看原面经 →
项目追问
项目中redis的作用

去哪儿

测试开发工程师
一面
查看原面经 →
你对Redis有了解吗?(追问:有没有实际使用或测试过)

阿里巴巴(淘天)

AI 应用开发工程师
校招秋招一面
查看原面经 →
项目中有没有使用 Redis,用来解决什么场景问题
展开剩余 13 篇面经

广电数科

Java 开发工程师
实习
查看原面经 →
讲一下你们项目中怎么使用redis的

广东元海

Java 后端开发工程师
实习一面
查看原面经 →
4,你的项目的缓存优化怎么做的

要务科技

AI 应用开发工程师
实习一面
查看原面经 →
Redis缓存用来做什么业务?

金山办公

数据分析师
日常实习一面
查看原面经 →
Redis怎么缓存数据?

百度

Go 后端开发工程师
二面
查看原面经 →
项目追问
Redis 在这个项目里主要用来做什么?

去哪儿

AI 测试开发工程师
秋招
查看原面经 →
Redis缓存机制及冷key内存处理

亚信科技

后端开发工程师
实习二面
查看原面经 →
数据库的使用(mysql,redis),redis用来解决过什么问题在项目里面

京东

后端开发工程师(智能运维)
实习暑期一面
查看原面经 →
24 Redis热点数据是哪些部分

阿里巴巴

Java 开发工程师
一面
查看原面经 →
Redis 是存短期内容吗?是用于做缓存还是其他用途?

重庆远见

Java 开发工程师
暑期实习
查看原面经 →
项目中,redis你主要用来做什么?

京东

后端开发工程师(Agent)
实习一面
查看原面经 →
Redis你用在什么场景下了?

蚂蚁集团

Agent 开发工程师
实习一面
查看原面经 →
Redis你使用了哪些场景?怎么实现的?

蚂蚁国际

AI 应用 / Agent 开发
暑期实习一面
查看原面经 →
Redis你使用了哪些场景?怎么实现的?

相关题目

4 题