1. 首頁 > 云知道 > >

自定義PubSub,pubsub

云知道

如何評估數據適不適合放入Redis中？

自定義PubSub,pubsub


當項目中引入了 Redis 做分布式緩存 ， 那么就會面臨這樣的問題：哪些數據應該放到緩存中？依據是什么？緩存數據是采用主動刷新還是過期自動失效？如果采用過期自動失效 ， 那么失效時間如何制定？正好這兩周我們項目做了相關的評估 ， 把過程記錄下來和大家分享分享；當然過程中用到了很多“笨辦法” ， 如果你有更好的辦法 ， 也希望能分享給我 。
【自定義PubSub,pubsub】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 個接口 ， 有幾分鐘就統計出來了 ， 反正是一次性的工作 ， 索性就手動統計了；一天也調不了幾次的接口 ， 就直接忽略掉了 ， 我基本上只把日調用量上萬的接口都留下來 ， 進行下一步的分析 。

推薦閱讀