當項目中引入了 Redis 做分佈式緩存，那麼就會面臨這樣的問題：
- 哪些數據應該放到緩存中？依據是什麼？
- 緩存數據是採用主動刷新還是過期自動失效？
- 如果採用過期自動失效，那麼失效時間如何制定？
正好這兩週我們項目做了相關的評估，把過程記錄下來和大家分享分享；當然過程中用到了很多“笨辦法”，如果你有更好的辦法，也希望能分享給我。
01
項目背景
我們的項目是一個純服務平臺，也就是隻提供接口服務，並沒有操作頁面的，項目的接口日調用量大約在 200 萬次，高峰期也就 1000 萬出頭，因為大部分接口是面向內部系統的，所以大部分請求集中在工作日的 9 點到 21 點，高峰期的時候系統的 QPS 在 300-400 之間。
因為我們項目數據存儲使用的是 MongoDB，理論上支撐這個量級的 QPS 應該是綽綽有餘，但是我有這麼幾點觀察和考慮：
MongoDB 中雖然是整合好的數據，但是很多場景也不是單條查詢，誇張的時候一個接口可能會返回上百條數據，回參報文就有兩萬多行（不要問我能不能分頁返回......明確告訴你不能）；
- MongoDB 中雖然是整合好的數據，但是很多場景也不是單條查詢，誇張的時候一個接口可能會返回上百條數據，回參報文就有兩萬多行（不要問我能不能分頁返回......明確告訴你不能）；
- 目前項目 99.95% 的接口響應時間都在幾十到幾百毫秒，基本可以滿足業務的需要，但是還是有 0.05% 的請求會超過 1s 響應，偶爾甚至會達到 5s、10s；
- 觀察這些響應時間長的請求，大部分時間消耗在查詢 MongoDB 上，但是當我將請求報文取出，再次手動調用接口的時候，依然是毫秒級返回；MongoDB 的配置一般，時刻都有數據更新，而且我觀察過，響應時間長的這些接口，那個時間點請求量特別大；
- MongoDB 查詢偶爾會慢的原因我我還在確認，我現在能想到的原因比如：大量寫操作影響讀操作、鎖表、內存小於索引大小等等，暫時就認為是當時那一刻 MongoDB 有壓力；我觀察過，響應時間長的這些接口，那個時間點請求量特別大，這一點就不在這裡具體分析了。
雖然一萬次的請求只有四五次響應時間異常，但是隨著項目接入的請求越來越大，保不齊以後量變產生質變，所以還是儘量將危機扼殺在搖籃裡，所以果斷上了 Redis 做分佈式緩存。
02
接口梳理
下一步就是對生產環境現有接口進行統計和梳理，確定哪些接口是可以放到緩存中的，所以首先要對每一個接口的調用量有大概的統計，因為沒有接入日誌平臺，所以我採用了最笨的辦法，一個一個接口的數嘛。
- 把工作日某一天全天的日誌拉下來，我們四臺應用服務器，每天的日誌大概 1 個G，還好還好；
- 通過 EditPlus 這個工具的【在文件中查找】的功能，查詢每個接口當天的調用量，已上線 30 個接口，有幾分鐘就統計出來了，反正是一次性的工作，索性就手動統計了；
- 一天也調不了幾次的接口，就直接忽略掉了，我基本上只把日調用量上萬的接口都留下來，進行下一步的分析。
03
字典表、配置類的數據
這一類的數據是最適合放在緩存中的，因為更新頻率特別低，甚至有時候 insert 了之後就再也不做 update ，如果這類數據的調用量比較大，是一定要放到 Redis 中的；
至於緩存策略，可以在更新的時候雙寫數據庫和 Redis，也可以採用自動失效的方式，當然這個失效時間可以放得比較長一些；針對我們項目，我採用的是半夜 12 點統一失效的策略，第一因為我們系統這類數據，是夜間通過 ETL 抽取過來的，每天同步一次，第二就是我們不怕緩存雪崩，沒有那麼大的訪問量，夜間更沒有什麼訪問量了。
04
明顯是熱點數據的數據
有一類數據，很明顯就是熱點數據；
我們就有一個接口，雖然是業務數據，不過數據總量只有幾千條，但是每天的調用量大約在 40 萬，而且更新頻率不是很高，這類數據放入 Redis 中也就再適合不過了；至於緩存策略麼，因為數據也是從其他系統同步過來的，根據數據同步的時間，我們最終採用一個小時的失效時間。
05
其餘數據的評估
其實前兩種數據很容易就能評估出來，關鍵是這類數據的評估：
- 我們有一個接口日調用量 20-30 萬，量不大，但是查詢和處理邏輯比較複雜；
- 基礎數據量太大，無法把所有數據都放入 Redis 中；
- 無法把基礎數據直接放入 Redis 中，因為有多重查詢維度（條件）；
- 無法確定每條數據的調用頻率是怎麼樣的，最悲觀的結果，每條數據當天只調用一次，這樣就沒有緩存的必要了。
但是咱也不能一拍腦袋就說：“調用量挺大的，直接放到 Redis 中吧”，或者“不好評估，算了吧，別放緩存了”，做任何一個決定還是需要有依據的，於是我是這樣做的：
Step 1.
把該接口當天的所有日誌都找出來
幾十個日誌文件肯定不能一個一個翻，要麼就自己寫個程序把需要的數據扒出來，但是考慮到這個工作可能只做一次，我還是儘量節省一些時間吧。
依然使用 EditPlus 這個工具的【在文件中查找】的功能，在查詢結果框中【複製所有內容】，花了兩分鐘，就把 24 萬條日誌找出來了。
o 該接口查詢到 24 萬條數據
Step 2.
把數據導入到數據庫中進行下一步分析
每一條日誌大概是這樣的：
<code>XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.類名 : 請求參數:args1={"字段1":"XXX","字段2":"YYY"}/<code>日誌裡面我只需要三個內容：請求報文中的字段 1 和字段 2，以及調用時間；怎麼摘出來？寫個程序？當然沒問題，但是我懶呀，幾分鐘能做好的事情為什麼話花幾十分鐘呢？而且這工作是一次性的，於是：
- 全文替換：[ 2020-3-17 ] 替換成 [ /t2020-3-17 ] ，也就是在時間戳前面加一個 tab；
- 全文替換：[ {"字段1":" ] 替換成 [ /t ] ;
- 全文替換：[ ","字段2":" ] 替換成 [ /t ] ;
- 全文替換：[ "} ] 替換成 [ ]，也就是替換成空 ;
- 全選複製，粘貼到 excel 中，excel 自動按照 tab 換列；
- 刪除不需要的列，只留字段 1 和字段 2 的內容，以及時間戳；
這幾步操作用不了一分鐘。
o 從日誌拆出來的三個字段
Step 3.
調用頻率分析
當把數據進入到數據庫中，就根據我們的需要進行分析了；我們主要想知道，相同的入參會不會重複調用？每次調用間隔的時間是多少？一個 SQL 搞定：
<code>select 字段1 , 字段2, count(1) 調用次數, (MIDNIGHT_SECONDS(max(UPDATETIME)) - MIDNIGHT_SECONDS(min(UPDATETIME)))/60 調用間隔時間，處理成了分鐘from TABLEgroup by 字段1 , 字段2having count(1) > 2with ur ;/<code>
當然調用間隔時間的統計，這裡統計的不精確，具體我不解釋了，你們細品...
總之吧，全天 24 萬的調用量，其中 10 萬隻調用了一次，14 萬的數據會在短時間內重複調用，有一些數據甚至會在幾分鐘之內重複查詢幾十次，所以這個接口還是比較適合放入到 Redis 中的。
Step 4.
數據怎麼存？
再說說我們的數據用什麼格式保存到 Redis 中，一圖勝千言：
o 將加工結果保存到 Redis 中
至於緩存更新策略嘛，我們依然使用設置失效時間的方式，根據數據同步的時間和調用統計結果，這個時間設置成 15 分鐘比較合適。
可以看到在這個評估過程中，我所有操作都保持了“能偷懶就偷懶”這個好習慣，保持高效，善用工具，節約不必要的時間，全部過程花了兩個小時，其中大部分時間是在數據導入，幾乎用了一個半小時，還好在這個過程中我還能做其他的工作。
閱讀更多 Java桔煙 的文章
