1. 首頁 > 云知道 > >

自定義PubSub,pubsub( 二 )

云知道


03. 字典表、配置類的數據這一類的數據是最適合放在緩存中的 ， 因為更新頻率特別低 ， 甚至有時候 insert 了之后就再也不做 update  ， 如果這類數據的調用量比較大 ， 是一定要放到 Redis 中的；至于緩存策略 ， 可以在更新的時候雙寫數據庫和 Redis ， 也可以采用自動失效的方式 ， 當然這個失效時間可以放得比較長一些；針對我們項目 ， 我采用的是半夜 12 點統一失效的策略 ， 第一因為我們系統這類數據 ， 是夜間通過 ETL 抽取過來的 ， 每天同步一次 ， 第二就是我們不怕緩存雪崩 ， 沒有那么大的訪問量 ， 夜間更沒有什么訪問量了 。
04. 明顯是熱點數據的數據有一類數據 ， 很明顯就是熱點數據；我們就有一個接口 ， 雖然是業務數據 ， 不過數據總量只有幾千條 ， 但是每天的調用量大約在 40 萬 ， 而且更新頻率不是很高 ， 這類數據放入 Redis 中也就再適合不過了；至于緩存策略么 ， 因為數據也是從其他系統同步過來的 ， 根據數據同步的時間 ， 我們最終采用一個小時的失效時間 。
05. 其余數據的評估其實前兩種數據很容易就能評估出來 ， 關鍵是這類數據的評估：我們有一個接口日調用量 20-30 萬 ， 量不大 ， 但是查詢和處理邏輯比較復雜；基礎數據量太大 ， 無法把所有數據都放入 Redis 中；無法把基礎數據直接放入 Redis 中 ， 因為有多重查詢維度（條件）；無法確定每條數據的調用頻率是怎么樣的 ， 最悲觀的結果 ， 每條數據當天只調用一次 ， 這樣就沒有緩存的必要了 。
但是咱也不能一拍腦袋就說：“調用量挺大的 ， 直接放到 Redis 中吧” ， 或者“不好評估 ， 算了吧 ， 別放緩存了” ， 做任何一個決定還是需要有依據的 ， 于是我是這樣做的：Step 1. 把該接口當天的所有日志都找出來幾十個日志文件肯定不能一個一個翻 ， 要么就自己寫個程序把需要的數據扒出來 ， 但是考慮到這個工作可能只做一次 ， 我還是盡量節省一些時間吧 。
依然使用 EditPlus 這個工具的【在文件中查找】的功能 ， 在查詢結果框中【復制所有內容】 ， 花了兩分鐘 ， 就把 24 萬條日志找出來了 。Step 2. 把數據導入到數據庫中進行下一步分析每一條日志大概是這樣的：XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.類名 : 請求參數:args1={"字段1":"XXX 。

推薦閱讀