哪些數據可以放進緩存？記錄生產環境一次緩存評估的過程

點點這個鏈接免費獲取：本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分散式等教程，一共30G，需要自己領取。傳送門：https://mp.weixin.qq.com/s/osB-BOl6W-ZLT ...

點點這個鏈接免費獲取：本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分散式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/osB-BOl6W-ZLTSttTkqMPQ

當項目中引入了 Redis 做分散式緩存，那麼就會面臨這樣的問題：

哪些數據應該放到緩存中？依據是什麼？
緩存數據是採用主動刷新還是過期自動失效？
如果採用過期自動失效，那麼失效時間如何制定？

正好這兩周我們項目做了相關的評估，把過程記錄下來和大家分享分享；當然過程中用到了很多“笨辦法”，如果你有更好的辦法，也希望能分享給我。

項目背景

我們的項目是一個純服務平臺，也就是只提供介面服務，並沒有操作頁面的，項目的介面日調用量大約在 200 萬次，高峰期也就 1000 萬出頭，因為大部分介面是面向內部系統的，所以大部分請求集中在工作日的 9 點到 21 點，高峰期的時候系統的 QPS 在 300-400 之間。

因為我們項目數據存儲使用的是 MongoDB，理論上支撐這個量級的 QPS 應該是綽綽有餘，但是我有這麼幾點觀察和考慮：

MongoDB 中雖然是整合好的數據，但是很多場景也不是單條查詢，誇張的時候一個介面可能會返回上百條數據，回參報文就有兩萬多行（不要問我能不能分頁返回......明確告訴你不能）；

MongoDB 中雖然是整合好的數據，但是很多場景也不是單條查詢，誇張的時候一個介面可能會返回上百條數據，回參報文就有兩萬多行（不要問我能不能分頁返回......明確告訴你不能）；
目前項目 99.95% 的介面響應時間都在幾十到幾百毫秒，基本可以滿足業務的需要，但是還是有 0.05% 的請求會超過 1s 響應，偶爾甚至會達到 5s、10s；
觀察這些響應時間長的請求，大部分時間消耗在查詢 MongoDB 上，但是當我將請求報文取出，再次手動調用介面的時候，依然是毫秒級返回；MongoDB 的配置一般，時刻都有數據更新，而且我觀察過，響應時間長的這些介面，那個時間點請求量特別大；
MongoDB 查詢偶爾會慢的原因我我還在確認，我現在能想到的原因比如：大量寫操作影響讀操作、鎖表、記憶體小於索引大小等等，暫時就認為是當時那一刻 MongoDB 有壓力；我觀察過，響應時間長的這些介面，那個時間點請求量特別大，這一點就不在這裡具體分析了。

雖然一萬次的請求只有四五次響應時間異常，但是隨著項目接入的請求越來越大，保不齊以後量變產生質變，所以還是儘量將危機扼殺在搖籃里，所以果斷上了 Redis 做分散式緩存。

介面梳理

下一步就是對生產環境現有介面進行統計和梳理，確定哪些介面是可以放到緩存中的，所以首先要對每一個介面的調用量有大概的統計，因為沒有接入日誌平臺，所以我採用了最笨的辦法，一個一個介面的數嘛。

把工作日某一天全天的日誌拉下來，我們四台應用伺服器，每天的日誌大概 1 個G，還好還好；
通過 EditPlus 這個工具的【在文件中查找】的功能，查詢每個介面當天的調用量，已上線 30 個介面，有幾分鐘就統計出來了，反正是一次性的工作，索性就手動統計了；
一天也調不了幾次的介面，就直接忽略掉了，我基本上只把日調用量上萬的介面都留下來，進行下一步的分析。

字典表、配置類的數據

這一類的數據是最適合放在緩存中的，因為更新頻率特別低，甚至有時候 insert 了之後就再也不做 update ，如果這類數據的調用量比較大，是一定要放到 Redis 中的；

至於緩存策略，可以在更新的時候雙寫資料庫和 Redis，也可以採用自動失效的方式，當然這個失效時間可以放得比較長一些；針對我們項目，我採用的是半夜 12 點統一失效的策略，第一因為我們系統這類數據，是夜間通過 ETL 抽取過來的，每天同步一次，第二就是我們不怕緩存雪崩，沒有那麼大的訪問量，夜間更沒有什麼訪問量了。

明顯是熱點數據的數據

有一類數據，很明顯就是熱點數據；

我們就有一個介面，雖然是業務數據，不過數據總量只有幾千條，但是每天的調用量大約在 40 萬，而且更新頻率不是很高，這類數據放入 Redis 中也就再適合不過了；至於緩存策略麽，因為數據也是從其他系統同步過來的，根據數據同步的時間，我們最終採用一個小時的失效時間。

其餘數據的評估

其實前兩種數據很容易就能評估出來，關鍵是這類數據的評估：

我們有一個介面日調用量 20-30 萬，量不大，但是查詢和處理邏輯比較複雜；
基礎數據量太大，無法把所有數據都放入 Redis 中；
無法把基礎數據直接放入 Redis 中，因為有多重查詢維度（條件）；
無法確定每條數據的調用頻率是怎麼樣的，最悲觀的結果，每條數據當天只調用一次，這樣就沒有緩存的必要了。

但是咱也不能一拍腦袋就說：“調用量挺大的，直接放到 Redis 中吧”，或者“不好評估，算了吧，別放緩存了”，做任何一個決定還是需要有依據的，於是我是這樣做的：

Step 1.

把該介面當天的所有日誌都找出來

幾十個日誌文件肯定不能一個一個翻，要麼就自己寫個程式把需要的數據扒出來，但是考慮到這個工作可能只做一次，我還是儘量節省一些時間吧。

依然使用 EditPlus 這個工具的【在文件中查找】的功能，在查詢結果框中【複製所有內容】，花了兩分鐘，就把 24 萬條日誌找出來了。

o 該介面查詢到 24 萬條數據

Step 2.

把數據導入到資料庫中進行下一步分析

每一條日誌大概是這樣的：

XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.類名 : 請求參數:args1={"欄位1":"XXX","欄位2":"YYY"}

日誌裡面我只需要三個內容：請求報文中的欄位 1 和欄位 2，以及調用時間；怎麼摘出來？寫個程式？當然沒問題，但是我懶呀，幾分鐘能做好的事情為什麼話花幾十分鐘呢？而且這工作是一次性的，於是：

全文替換：[ 2020-3-17 ] 替換成 [ /t2020-3-17 ] ，也就是在時間戳前面加一個 tab；
全文替換：[ {"欄位1":" ] 替換成 [ /t ] ;
全文替換：[ ","欄位2":" ] 替換成 [ /t ] ;
全文替換：[ "} ] 替換成 [ ]，也就是替換成空 ;
全選複製，粘貼到 excel 中，excel 自動按照 tab 換列；
刪除不需要的列，只留欄位 1 和欄位 2 的內容，以及時間戳；

這幾步操作用不了一分鐘。

o 從日誌拆出來的三個欄位

Step 3.

調用頻率分析

當把數據進入到資料庫中，就根據我們的需要進行分析了；我們主要想知道，相同的入參會不會重覆調用？每次調用間隔的時間是多少？一個 SQL 搞定：

select 欄位1 , 欄位2, count(1) 調用次數, (MIDNIGHT_SECONDS(max(UPDATETIME)) - MIDNIGHT_SECONDS(min(UPDATETIME)))/60  調用間隔時間，處理成了分鐘from TABLEgroup by 欄位1 , 欄位2having count(1) > 2with ur ;

當然調用間隔時間的統計，這裡統計的不精確，具體我不解釋了，你們細品...

總之吧，全天 24 萬的調用量，其中 10 萬隻調用了一次，14 萬的數據會在短時間內重覆調用，有一些數據甚至會在幾分鐘之內重覆查詢幾十次，所以這個介面還是比較適合放入到 Redis 中的。

Step 4.

數據怎麼存？

再說說我們的數據用什麼格式保存到 Redis 中，一圖勝千言：

o 將加工結果保存到 Redis 中

至於緩存更新策略嘛，我們依然使用設置失效時間的方式，根據數據同步的時間和調用統計結果，這個時間設置成 15 分鐘比較合適。

可以看到在這個評估過程中，我所有操作都保持了“能偷懶就偷懶”這個好習慣，保持高效，善用工具，節約不必要的時間，全部過程花了兩個小時，其中大部分時間是在數據導入，幾乎用了一個半小時，還好在這個過程中我還能做其他的工作。

哪些數據可以放進緩存？記錄生產環境一次緩存評估的過程

點點這個鏈接免費獲取：本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分散式等教程，一共30G，需要自己領取。傳送門：https://mp.weixin.qq.com/s/osB-BOl6W-ZLTSttTkqMPQ

點點這個鏈接免費獲取：本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分散式等教程，一共30G，需要自己領取。
傳送門：https://mp.weixin.qq.com/s/osB-BOl6W-ZLTSttTkqMPQ