加速讀寫
降低後端負載
資料不一致
**維護成本更高：多了一層快取邏輯
運維成本：redis cluster
降低後端負載： 對高消耗的運算結果進行快取
加速請求響應 i/0
大量寫合併為批量寫：先累計在db持久化
lru/lfu/fifo演算法剔除： maxmemory-policy
超時剔除：expire
主動更新：開發控制生命週期
一致性：3>2>1通用性：全量屬性更好低一致性要求時：最大記憶體和淘汰策略
高一致性要求時：超時剔除和主動更新結合，最大記憶體和淘汰策略兜底
占用空間：部分屬性更好
**維護：表面上全量屬性更好
當大量請求無法命中快取時，db壓力瞬間暴增。訪問根本不存在的資料會一直訪問db。原因：1. 業務**自身問題 2. 惡意攻擊，爬蟲，排查：業務的響應時間、業務本身問題、相關指標：總呼叫數、快取命中數、儲存層命中數布隆過濾器攔截：詳細處理解決辦法：
加了硬體效能不公升反降優化命令本身 慢查詢 keys hgetall bigkey
減少網路通訊次數
降低接入成本：客戶端長連線、連線池、nio
todo
三個目標
兩個解決
Redis快取設計
策略 一致性維護成本 lru lrf fifo最差低 超時剔除 較差較低 主動更新強高 低一致性業務 最大記憶體和淘汰策略的方式，maxmemory policy 高一致性業務 超時剔除和主動更新 解決快取穿透 適用場景 維護成本 快取空物件 資料命中不高，資料頻繁變化實時性高 維護簡單，需要過多的...
redis 快取設計
1 快取穿透 查詢乙個不存在的key 資料,快取層和儲存層都不會命中，將導致不存在的資料每次請求都要到儲存層去查詢，失去快取保護db 的意義。解決方案 有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器 不了解的可以看這裡 將所有可能存在的資料雜湊到乙個足夠大的bitmap中，乙個一...
Redis學習筆記（八） 快取設計與優化
歡迎star fork follow素質三連 8.1.1 收益 8.1.2 成本 8.1.3 使用場景快取更新常用的三種策略 策略 一致性維護成本 lru lfu fifo最差低 超時剔除 較差較低 主動更新強高 快取更新策略使用建議 通常情況下，都是使用redis去保護底層mysql，但是這也涉及...