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

當項目中引入了 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 萬條日誌找出來了。

 該接口查詢到 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 的內容，以及時間戳；

「這幾步操做用不了一分鐘。」

從日誌拆出來的三個字段

Step 3. 調用頻率分析

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

select 字段1 , 字段2, count(1) 調用次數, (MIDNIGHT_SECONDS(max(UPDATETIME)) - MIDNIGHT_SECONDS(min(UPDATETIME)))/60  調用間隔時間，處理成了分鐘
    from TABLE
    group by 字段1 , 字段2 
    having count(1) > 2
with ur ;
複製代碼

固然調用間隔時間的統計，這裏統計的不精確，具體我不解釋了，大家細品...

總之吧，全天 24 萬的調用量，其中 10 萬隻調用了一次，14 萬的數據會在短期內重複調用，有一些數據甚至會在幾分鐘以內重複查詢幾十次，因此這個接口仍是比較適合放入到 Redis 中的。

Step 4. 數據怎麼存？

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

將加工結果保存到 Redis 中

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

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

❝

會點代碼的大叔 | 文【原創】

❞

---

會點代碼的大叔

本文使用 mdnice 排版