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

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

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

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

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

2. Caffeine 的無(wú)奈：抽屜雖快但太小

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

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

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

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

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

// 偽代碼示意
public Object get(String key) {
    // 先查本地緩存，就像先翻抽屜
    Object value = caffeineCache.get(key);
    if (value != null) {
        return value;
    }
    // 抽屜沒(méi)有再查Redis，就像去倉(cāng)庫(kù)找
    value = redisTemplate.get(key);
    if (value != null) {
        // 把倉(cāng)庫(kù)的東西放進(jìn)抽屜，下次直接拿
        caffeineCache.put(key, value);
    } else {
        // 倉(cāng)庫(kù)也沒(méi)有，就得去數(shù)據(jù)庫(kù)搬了
        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ù)更新頻率。如果是讀多寫少，比如商品詳情頁(yè)，沒(méi)問(wèn)題；如果是寫頻繁，比如訂單狀態(tài)，就得考慮更新策略了。

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

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

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

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

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

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

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

3. 淘汰策略：抽屜滿了該扔誰(shuí)？

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

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

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

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

• 序列化方式：Caffeine 存的是 Java 對(duì)象，直接存內(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ī)制：?jiǎn)?dòng)時(shí)提前加載熱點(diǎn)數(shù)據(jù)到 Caffeine，就像早上提前把常用工具放進(jìn)抽屜，避免第一個(gè)請(qǐng)求進(jìn)來(lái)時(shí)冷啟動(dòng)。

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

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

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

解決方案：

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

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

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

解決方案：

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

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

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

解決方案：

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

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

這是個(gè)經(jīng)典問(wèn)題，沒(méi)有絕對(duì)正確的答案，得看具體場(chǎng)景：

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

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

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

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

1. 單 Redis vs 雙緩存對(duì)比

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

2. 不同淘汰策略對(duì)比

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

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

1. Caffeine 配置模板

Caffeine.newBuilder()
    .maximumSize(10_000) // 最大容量，根據(jù)內(nèi)存大小調(diào)整，一般不超過(guò)可用內(nèi)存的1/4
    .expireAfterAccess(10, TimeUnit.MINUTES) // 最后一次訪問(wèn)后10分鐘過(guò)期
    .expireAfterWrite(5, TimeUnit.MINUTES) // 寫入后5分鐘過(guò)期，二者取早
    .initialCapacity(2_000) // 初始容量，避免頻繁擴(kuò)容
    .concurrencyLevel(Runtime.getRuntime().availableProcessors()) // 并發(fā)級(jí)別，等于CPU核心數(shù)
    .recordStats() // 開(kāi)啟統(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)存占用超過(guò)設(shè)定值的 80% 時(shí)報(bào)警，考慮擴(kuò)容或調(diào)整容量。
• 更新失敗率：數(shù)據(jù)同步失敗次數(shù)超過(guò)一定閾值時(shí)報(bào)警，比如每分鐘超過(guò) 10 次，可能是網(wǎng)絡(luò)問(wèn)題或數(shù)據(jù)庫(kù)壓力大。

六、哪些場(chǎng)景適合這對(duì) CP？

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

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

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ù)庫(kù)存全量數(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ù)庫(kù)，減少數(shù)據(jù)庫(kù)壓力。

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

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

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