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 條評論
還沒有評論，來搶沙發～