Redis 缓存方案设计提示词（缓存穿透、击穿、雪崩，以及缓存与数据库一致性）
接口太慢想加缓存、或者已经加了缓存却出现数据不一致、缓存失效时数据库被打垮时用：让 AI 根据数据的读写特点决定缓不缓、怎么缓，给出键设计、过期策略、更新方式，并逐一处理穿透、击穿、雪崩三类问题。
通用大模型 对话模型通用
你是一名高并发系统的后端架构师。请为下面的场景设计缓存方案。 场景信息： - 要缓存的数据：[如商品详情、用户权限、首页推荐] - 读写比例与访问量：[如每秒读 5000 次，每天修改几十次] - 对数据新鲜度的要求：[对数据新鲜度的要求]（例：价格修改后 1 秒内必须生效、推荐内容延迟几分钟没关系） - 数据大小：[如单条 2KB，共 50 万条] - 技术栈：[技术栈]（例：Java + Spring + Redis 集群） - 当前遇到的问题：[当前遇到的问题]（例：缓存过期瞬间数据库 CPU 飙升，没有就写无） 请依次给出： 1. 判断：这份数据适不适合缓存，适合放在进程内缓存、Redis，还是两级都要；说明理由。 2. 键设计：键的命名格式（带业务前缀和版本号）、值的序列化方式、是否需要拆分大键。 3. 读写策略： - 读：先查缓存，未命中再查数据库并回填； - 写：推荐「先更新数据库，再删除缓存」，说明为什么不推荐「先删缓存再更新数据库」或「更新缓存」； - 对一致性要求高的情况，补充延迟双删、订阅数据库变更日志删除缓存等手段，并说明它们能保证到什么程度。 4. 三类问题的应对： - 穿透（查询不存在的数据）：缓存空值并设置较短过期时间、布隆过滤器、参数校验； - 击穿（热点键过期瞬间大量请求打到数据库）：互斥锁重建、逻辑过期后台刷新； - 雪崩（大量键同时过期或 Redis 不可用）：过期时间加随机值、多级缓存、熔断降级。 对我的场景，说明哪些是必须做的，哪些可以暂时不做。 5. 写出核心代码（读取、回填、删除、防击穿）。 6. 监控与运维：需要关注的指标（命中率、慢命令、内存与淘汰数、大键与热键）以及内存淘汰策略的选择。 不要把所有手段都堆上，按场景取舍，并说明取舍理由。
高亮处换成你自己的内容：[如商品详情、用户权限、首页推荐]、[如每秒读 5000 次，每天修改几十次]、[对数据新鲜度的要求]、[如单条 2KB，共 50 万条]、[技术栈]、[当前遇到的问题]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[对数据新鲜度的要求] 决定了方案的复杂度。能接受几分钟延迟的数据，简单的过期时间就够了；价格、库存、权限这类要求实时的数据，要么慎用缓存，要么配合主动删除和变更订阅。[读写比例与访问量] 用来判断缓存是否值得——写多读少的数据加缓存几乎没有收益。
常见坑：
- 用「更新数据库后同时更新缓存」，并发写时两个请求的执行顺序可能交错，缓存里留下的是旧值。删除缓存比更新缓存更安全。
- 所有键设置相同的过期时间，比如统一 1 小时，结果每到整点数据库压力暴涨。过期时间要加随机偏移。
- 把整张大表、大列表塞进一个键，读取一次就传输几 MB，阻塞 Redis。大键要拆分。
追问技巧：追问「列出这个方案里所有可能读到旧数据的时间窗口，分别有多长」，可以帮你判断方案是否满足业务要求。
示例输出
示例，仅供参考（商品详情，节选）
键设计：product:detail:v2:{商品ID}，值为 JSON；版本号用于数据结构变化时整体切换。
过期时间：30 分钟加 0 到 5 分钟的随机值，防止集中过期。
| 问题 | 本场景是否必须处理 | 做法 |
|---|---|---|
| 穿透 | 是（商品 ID 会被遍历） | 不存在的 ID 缓存空值 60 秒，接口层校验 ID 格式 |
| 击穿 | 是（爆款商品） | 未命中时用 SET NX 加短期锁，只允许一个请求回源 |
| 雪崩 | 部分 | 随机过期时间；Redis 故障时降级为进程内缓存加限流 |
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～