大家好，我是小米，31 歲，寫代碼快十年了。如果你問我：
後端面試裏，被問得最多、但被答得最爛的問題是什麼？
我一定投 “緩存” 一票。尤其是這道看起來人畜無害的題：
“什麼是熱點數據？什麼是冷數據？哪些數據適合緩存？”
很多同學第一反應是：熱點數據訪問多，冷數據訪問少。這話沒錯，但也幾乎等於沒説。
先講個故事：倉庫裏的“黃金貨架”
我先不講技術，先講一個倉庫的故事。假設你開了一家大型連鎖超市，後面有一個總倉庫。
- 倉庫空間有限
- 揀貨員每天要跑來跑去拿貨
- 離門口越近的貨架，拿貨越快
這時候，你會怎麼擺貨？答案很簡單：
- 每天被拿幾萬次的礦泉水、泡麪、可樂，放在門口
- 一年賣不了幾次的高端禮盒，放最裏面，甚至放分倉
在這個故事裏：
緩存，本質上就是“黃金貨架”。不是所有貨都配得上黃金貨架。
熱點數據：緩存才有價值
我們先下一個非常重要的結論：只有熱點數據，緩存才有價值。
什麼是熱點數據？一句話版本：
在一段時間內，被大量重複訪問的數據。
注意兩個關鍵詞：
- 一段時間內
- 重複訪問
1. IM 產品裏的“生日祝福”故事
我之前參與過一個 IM 產品。有一天，產品經理跑過來，眼睛放光：“我們要做一個生日祝福功能！”
邏輯很簡單：
- 每天凌晨，統計今天過生日的用户
- 首頁展示“今日壽星”
- 點進去可以一鍵祝福
技術同學一開始的實現是這樣的：
然後：
- 每次打開首頁查一次
- 每次點開模塊查一次
- 每次下拉刷新再查一次
上線第一天就炸了。為什麼？因為這是一個典型的熱點數據：
- 數據 一天只變一次
- 但 一天會被訪問幾十萬次
這時候，如果你還每次都查數據庫，相當於：
倉庫門口空着揀貨員天天跑到最裏面搬礦泉水
2. 正確姿勢：熱點數據 + 緩存
正確的做法是：
這一刀下去，數據庫直接鬆了一口氣。
3、為什麼這個緩存有價值？
冷數據：緩存不僅沒用，還浪費內存
接下來講 冷數據。冷數據的定義也很簡單：訪問頻率極低，甚至只訪問一次的數據。
1. 冷數據為什麼不適合緩存？
很多同學有個誤區：“反正 Redis 很快，放進去也沒啥壞處。”這是一個非常危險的想法。
冷數據放緩存，問題有三個：
- 還沒再次訪問，就被擠出內存
- 佔用寶貴的緩存空間
- 增加系統複雜度，卻沒有收益
2. 一個真實翻車案例
有一次我們排查 Redis 命中率異常低。一看 Key：
這些是什麼？
- 歷史訂單詳情
- 用户只會點開一次
- 點完就再也不看
結果就是：
- 寫入 Redis
- 沒命中
- 被 LRU 淘汰
- 緩存命中率低到 5%
這時候緩存的角色是什麼？高價垃圾桶。
3. 冷數據的正確姿勢
頻繁修改的數據，要不要緩存？
這是面試裏最容易拉開差距的一問。很多同學會直接説：“頻繁修改的數據不適合緩存。”
這句話 對一半，錯一半。
一個最基礎的緩存判斷策略：
數據在更新前，至少被讀取兩次，緩存才有意義。
為什麼？
- 第一次：寫緩存
- 第二次：命中緩存
- 如果只有一次，那緩存等於白寫
如果一個 Key：
- 剛寫進去
- 立刻被更新或刪除
那這個緩存 幾乎沒有任何價值。
但真的不存在“高頻修改 + 必須緩存”的場景嗎？
答案是：存在，而且非常常見。
1. 助手產品裏的點贊數
我們做過一個助手類產品，有幾個核心指標：
- 點贊數
- 收藏數
- 分享數
特點非常明顯：
如果你説：“修改頻繁，不緩存。”那數據庫會第一個不同意。
2. 這類數據的本質是什麼？
它們是：
- 熱點數據
- 計數型數據
- 允許短暫不一
3. 正確解法：Redis 扛讀寫，DB 兜底
常見方案：
定時任務落庫：
這樣做的好處：
- 99% 請求不打 DB
- DB 壓力驟降
- 用户體驗極好
4. 面試官真正想聽的點
你需要説清楚：
- 為什麼要緩存
- 接受什麼程度的不一致
- 如何保證最終一致
熱點數據與冷數據對照表（面試必背）
總結一句“面試金句”
如果你時間不夠，面試時可以直接甩這一段：
緩存的核心價值在於服務熱點數據。
冷數據即使放入緩存，也很可能在再次訪問前就被淘汰，既浪費內存，又增加系統複雜度。
對於高頻讀取的數據，只要在更新前能被讀取多次，緩存就是有意義的；
對於高頻修改但又是熱點的數據，需要通過 Redis 扛住讀寫壓力，再通過異步或定時方式保證最終一致性。
END
好朋友們，我們下篇見~
我是小米，一個喜歡分享技術的31歲程序員。如果你喜歡我的文章，歡迎關注我的微信公眾號“軟件求生”，獲取更多技術乾貨！
