兄弟們，今天咱來嘮嘮緩存界的 "神雕俠侶"——Redis 和 Caffeine。這倆貨要是組起 CP 來，那性能簡直能讓你的系統(tǒng)原地起飛。先別急著問原理，咱先從程序員的日常痛點(diǎn)說起：有沒有試過凌晨三點(diǎn)被監(jiān)控報(bào)警吵醒，發(fā)現(xiàn)是緩存雪崩把數(shù)據(jù)庫搞掛了？有沒有遇到過熱點(diǎn)數(shù)據(jù)把 Redis 壓得喘不過氣，網(wǎng)絡(luò)延遲比你摸魚時(shí)的網(wǎng)速還慢？別慌，這對 CP 就是來救場的。

一、為啥非得組 CP？單飛不香嗎？

先說說 Redis 這位老大哥，作為分布式緩存的扛把子，它就像一個(gè)超大的倉庫，能存海量數(shù)據(jù)，還支持各種復(fù)雜操作。但倉庫嘛，畢竟離你的工位有點(diǎn)遠(yuǎn)（網(wǎng)絡(luò)延遲），每次取東西都得跑一趟，要是趕上倉庫管理員忙（高并發(fā)），還得排隊(duì)。再看 Caffeine，這就是你桌上的抽屜，存的都是你最近常用的東西，伸手就能夠到，速度那叫一個(gè)快。但抽屜容量有限，裝不了太多東西，而且要是停電了（進(jìn)程重啟），里面的東西就沒了。

1. Redis 的煩惱：遠(yuǎn)水解不了近渴

• 網(wǎng)絡(luò)延遲：哪怕是 1ms 的延遲，在百萬級并發(fā)下也能積少成多，就像你每天多花 1 分鐘找東西，一年下來能少寫多少代碼？
• 帶寬壓力：每次從 Redis 取大對象，帶寬就像被堵在晚高峰的馬路，尤其是熱點(diǎn)數(shù)據(jù)，能把帶寬吃到撐。
• 集群瓶頸：Redis 集群雖然能擴(kuò)容，但分片鍵要是沒設(shè)計(jì)好，就像把東西亂堆在倉庫，找起來更麻煩。

2. Caffeine 的無奈：抽屜雖快但太小

• 容量限制：再大的抽屜也裝不下整個(gè)倉庫的東西，存太多就會(huì)被擠出去（淘汰策略）。
• 數(shù)據(jù)不一致：本地緩存和遠(yuǎn)程緩存的數(shù)據(jù)要是沒同步好，就像你記了兩套賬，遲早得出問題。
• 進(jìn)程隔離：每個(gè)服務(wù)實(shí)例都有自己的抽屜，數(shù)據(jù)不能共享，就像團(tuán)隊(duì)成員各自藏私貨，協(xié)作起來費(fèi)勁。

3. 最佳拍檔：冷熱數(shù)據(jù)分層

就像食堂打飯，常用的菜（熱數(shù)據(jù)）放在窗口附近，不常用的（冷數(shù)據(jù)）放在倉庫。Caffeine 負(fù)責(zé)存最熱的數(shù)據(jù)，讓你秒??；Redis 作為二級緩存，存次熱的數(shù)據(jù)；數(shù)據(jù)庫作為保底。這樣一來，大部分請求都能在本地解決，少部分去 Redis，極少部分才去數(shù)據(jù)庫，系統(tǒng)壓力直接砍半。

二、CP 合體指南：從牽手到洞房的全過程

1. 基礎(chǔ)架構(gòu)：兩層緩存怎么搭？

// 偽代碼示意
public Object get(String key) {
    // 先查本地緩存，就像先翻抽屜
    Object value = caffeineCache.get(key);
    if (value != null) {
        return value;
    }
    // 抽屜沒有再查Redis，就像去倉庫找
    value = redisTemplate.get(key);
    if (value != null) {
        // 把倉庫的東西放進(jìn)抽屜，下次直接拿
        caffeineCache.put(key, value);
    } else {
        // 倉庫也沒有，就得去數(shù)據(jù)庫搬了
        value = database.query(key);
        if (value != null) {
            redisTemplate.set(key, value);
            caffeineCache.put(key, value);
        }
    }
    return value;
}

這里有個(gè)小細(xì)節(jié)：從 Redis 拿到數(shù)據(jù)后，要不要立即更新 Caffeine？要看你的數(shù)據(jù)更新頻率。如果是讀多寫少，比如商品詳情頁，沒問題；如果是寫頻繁，比如訂單狀態(tài)，就得考慮更新策略了。

2. 數(shù)據(jù)同步：如何避免 "抽屜" 和 "倉庫" 鬧別扭？

（1）失效模式（Cache-Aside）

• 讀：先查 Caffeine，沒有查 Redis，再?zèng)]有查數(shù)據(jù)庫，然后更新兩級緩存。
• 寫：先更新數(shù)據(jù)庫，再刪除 Caffeine 和 Redis 的緩存。注意，這里刪除順序很重要，要是先刪 Redis，可能會(huì)有并發(fā)問題，導(dǎo)致臟數(shù)據(jù)。

（2）異步更新（Write-Behind）

適合對數(shù)據(jù)一致性要求不高的場景，比如日志記錄。寫操作先把數(shù)據(jù)扔進(jìn)隊(duì)列，后臺(tái)異步更新兩級緩存。但風(fēng)險(xiǎn)也不小，要是服務(wù)掛了，隊(duì)列里的數(shù)據(jù)就沒了，得配合持久化隊(duì)列使用。

（3）訂閱發(fā)布（Pub/Sub）

利用 Redis 的發(fā)布訂閱功能，當(dāng)數(shù)據(jù)更新時(shí)，發(fā)布一個(gè)事件，所有訂閱的服務(wù)實(shí)例收到事件后，刪除本地緩存。就像班長通知全班交作業(yè)，每個(gè)人收到通知后把自己的舊作業(yè)刪掉，下次重新拿新的。

3. 淘汰策略：抽屜滿了該扔誰？

Caffeine 支持三種淘汰策略，就像收拾抽屜時(shí)決定先扔哪個(gè)舊東西：

• LRU（最近最少使用）：很久沒用過的東西，先扔掉，比如你去年用過一次的計(jì)算器。
• LFU（最不常用）：用得少的東西，先扔掉，比如你抽屜里積灰的 U 盤。
• TTL（生存時(shí)間）：不管用沒用，到期就扔，比如過期的零食。

實(shí)際使用中，推薦 LRU+TTL 組合，比如熱點(diǎn)數(shù)據(jù)設(shè)置較長的 TTL，普通數(shù)據(jù)用 LRU 淘汰。Redis 這邊也可以配置淘汰策略，比如 allkeys-lru，和 Caffeine 形成互補(bǔ)。

4. 性能優(yōu)化：這些細(xì)節(jié)能讓速度再提 20%

• 序列化方式：Caffeine 存的是 Java 對象，直接存內(nèi)存，不需要序列化；Redis 存的是字節(jié)數(shù)組，推薦用 Protostuff 或 Kryo 替代默認(rèn)的 JDK 序列化，體積更小，速度更快。
• 并發(fā)控制：Caffeine 本身是線程安全的，底層用了 Java 8 的 ConcurrentHashMap 結(jié)構(gòu)；Redis 操作需要考慮分布式鎖，比如用 Redisson 的分布式可重入鎖，避免多個(gè)實(shí)例同時(shí)更新緩存。
• 預(yù)熱機(jī)制：啟動(dòng)時(shí)提前加載熱點(diǎn)數(shù)據(jù)到 Caffeine，就像早上提前把常用工具放進(jìn)抽屜，避免第一個(gè)請求進(jìn)來時(shí)冷啟動(dòng)。

三、實(shí)戰(zhàn)踩坑指南：這幾個(gè)坑差點(diǎn)讓我丟了飯碗

1. 緩存穿透：黑客拿不存在的 key 瘋狂攻擊

場景：用戶用一個(gè)不存在的商品 ID 瘋狂請求，每次都得查數(shù)據(jù)庫，就像有人天天敲你家門問 "有人嗎"，但其實(shí)沒人住。

解決方案：

• 布隆過濾器：在入口處加一個(gè)過濾器，先判斷 key 是否存在，不存在直接返回。就像在門口裝個(gè)貓眼，先看看是不是熟人。
• 空值緩存：查數(shù)據(jù)庫后，即使沒數(shù)據(jù)，也在兩級緩存存一個(gè)空值，設(shè)置短 TTL，比如 5 分鐘。

2. 緩存雪崩：大面積緩存同時(shí)失效

場景：凌晨三點(diǎn)，大量緩存同時(shí)過期，請求像潮水一樣涌到數(shù)據(jù)庫，就像全班同學(xué)同時(shí)找老師問問題，老師直接忙暈。

解決方案：

• 隨機(jī) TTL：給緩存過期時(shí)間加一個(gè)隨機(jī)值，比如 10-15 分鐘，避免集中失效。
• 本地鎖：當(dāng)緩存失效時(shí)，用 synchronized 先鎖住本地線程，只讓一個(gè)線程去更新緩存，其他線程等待。注意，這只能解決單個(gè)實(shí)例的問題，分布式場景得用 Redis 分布式鎖。

3. 數(shù)據(jù)傾斜：熱點(diǎn)數(shù)據(jù)把 Caffeine 撐爆

場景：雙 11 時(shí)，某個(gè)爆款商品的訪問量是其他商品的 100 倍，Caffeine 里全是這個(gè)商品的數(shù)據(jù)，其他數(shù)據(jù)被擠出去了。

解決方案：

• 分片處理：把熱點(diǎn)數(shù)據(jù)拆分成多個(gè) key，比如 "product:123:1"、"product:123:2"，分散到不同的 Caffeine 實(shí)例中。
• 二級緩存限流：給 Caffeine 設(shè)置最大容量，超過后按淘汰策略刪除，同時(shí)記錄熱點(diǎn)數(shù)據(jù)，動(dòng)態(tài)調(diào)整容量。

4. 一致性難題：先更新數(shù)據(jù)庫還是先刪緩存？

這是個(gè)經(jīng)典問題，沒有絕對正確的答案，得看具體場景：

• 讀多寫少：先更新數(shù)據(jù)庫，再刪緩存。如果先刪緩存，此時(shí)有讀請求進(jìn)來，會(huì)從數(shù)據(jù)庫查舊數(shù)據(jù)并更新緩存，導(dǎo)致臟數(shù)據(jù)。但先更新數(shù)據(jù)庫后刪緩存，如果刪緩存失敗，下次讀會(huì)讀到舊數(shù)據(jù)，不過可以通過異步任務(wù)補(bǔ)償。
• 寫多讀少：直接更新數(shù)據(jù)庫，不維護(hù)緩存，讀的時(shí)候再重新加載。比如后臺(tái)管理系統(tǒng)，寫操作多，讀操作少，沒必要維護(hù)緩存。

四、性能測試：這數(shù)據(jù)看得我熱血沸騰

為了驗(yàn)證這對 CP 的威力，我做了一組性能測試，環(huán)境如下：

• 服務(wù)器：4 核 8G，帶寬 1Gbps
• 客戶端：JMeter，1000 并發(fā)，10 萬次請求
• 數(shù)據(jù)：1KB 的字符串，熱點(diǎn)數(shù)據(jù)占比 20%

1. 單 Redis vs 雙緩存對比

可以看到，加上 Caffeine 后，響應(yīng)時(shí)間直接降到原來的 1/6，吞吐量翻了 4 倍多，數(shù)據(jù)庫基本沒壓力了。這就是本地緩存的威力，把大部分請求都在內(nèi)存里解決了。

2. 不同淘汰策略對比

實(shí)測發(fā)現(xiàn)，TTL+LRU 組合命中率最高，因?yàn)榧瓤紤]了數(shù)據(jù)的使用頻率，又避免了長期不用的數(shù)據(jù)占用空間。不過復(fù)雜度也更高，需要合理設(shè)置 TTL 和容量。

五、最佳實(shí)踐：這幾個(gè)配置讓你的 CP 更穩(wěn)

1. Caffeine 配置模板

Caffeine.newBuilder()
    .maximumSize(10_000) // 最大容量，根據(jù)內(nèi)存大小調(diào)整，一般不超過可用內(nèi)存的1/4
    .expireAfterAccess(10, TimeUnit.MINUTES) // 最后一次訪問后10分鐘過期
    .expireAfterWrite(5, TimeUnit.MINUTES) // 寫入后5分鐘過期，二者取早
    .initialCapacity(2_000) // 初始容量，避免頻繁擴(kuò)容
    .concurrencyLevel(Runtime.getRuntime().availableProcessors()) // 并發(fā)級別，等于CPU核心數(shù)
    .recordStats() // 開啟統(tǒng)計(jì)，方便監(jiān)控命中率、淘汰次數(shù)等
    .build();

2. Redis 配置關(guān)鍵點(diǎn)

• 連接池：使用 Jedis 或 Lettuce，推薦 Lettuce，支持異步 IO，高并發(fā)下表現(xiàn)更好。
• 序列化：配置 spring.redis.serializer 為 GenericJackson2JsonRedisSerializer，比默認(rèn)的 JDK 序列化更高效。
• 監(jiān)控：定期查看 info stats 里的 keyspace 命中情況，比如 keyspace_hits/keyspace_misses，命中率低于 90% 就要考慮優(yōu)化了。

3. 監(jiān)控報(bào)警體系

• 緩存命中率：低于 80% 時(shí)報(bào)警，可能是淘汰策略不合理或熱點(diǎn)數(shù)據(jù)變化。
• 內(nèi)存使用率：Caffeine 內(nèi)存占用超過設(shè)定值的 80% 時(shí)報(bào)警，考慮擴(kuò)容或調(diào)整容量。
• 更新失敗率：數(shù)據(jù)同步失敗次數(shù)超過一定閾值時(shí)報(bào)警，比如每分鐘超過 10 次，可能是網(wǎng)絡(luò)問題或數(shù)據(jù)庫壓力大。

六、哪些場景適合這對 CP？

1. 電商秒殺：熱點(diǎn)商品的庫存查詢

秒殺時(shí)，熱點(diǎn)商品的庫存查詢請求量極大，用 Caffeine 存最新的庫存數(shù)據(jù)，Redis 存歷史庫存變化，既能保證速度，又能防止庫存超賣。

2. 新聞 Feed：用戶個(gè)性化推薦

每個(gè)用戶的推薦列表都是熱點(diǎn)數(shù)據(jù)，存在 Caffeine 里，快速返回；Redis 存全局的熱點(diǎn)文章，當(dāng)用戶的推薦列表更新時(shí)，異步同步到 Redis。

3. 金融風(fēng)控：實(shí)時(shí)風(fēng)險(xiǎn)數(shù)據(jù)

風(fēng)控系統(tǒng)需要實(shí)時(shí)獲取用戶的交易數(shù)據(jù)，Caffeine 存最近 10 分鐘的交易記錄，Redis 存最近 1 小時(shí)的，數(shù)據(jù)庫存全量數(shù)據(jù)，分層處理，保證風(fēng)控規(guī)則的實(shí)時(shí)性。

4. 日志分析：實(shí)時(shí)統(tǒng)計(jì)指標(biāo)

比如實(shí)時(shí) PV、UV 統(tǒng)計(jì)，Caffeine 存當(dāng)前分鐘的統(tǒng)計(jì)數(shù)據(jù)，每分鐘結(jié)束后同步到 Redis，Redis 按小時(shí)匯總，最后寫入數(shù)據(jù)庫，減少數(shù)據(jù)庫壓力。

結(jié)語：是時(shí)候給你的系統(tǒng)找個(gè) CP 了

Redis 和 Caffeine 的組合，就像程序員的左右手，左手快速處理日常任務(wù)（本地?zé)狳c(diǎn)），右手搞定復(fù)雜問題（分布式存儲(chǔ)）。別再讓你的系統(tǒng)單打獨(dú)斗了，趕緊組個(gè) CP，讓性能飛起來。

不過，緩存雖好，可不要貪杯哦。一定要根據(jù)業(yè)務(wù)場景選擇合適的策略，做好監(jiān)控和容災(zāi)，畢竟再厲害的 CP 也需要用心維護(hù)。