受益
通過快取加速讀寫速度：cpu l1/l2/l3 cache、linux page cache加速硬碟讀寫、瀏覽器快取、ehcache快取資料庫結果。
後端伺服器通過前端快取降低負載：業務端使用redis降低後端mysql負載等。
成本
使用場景
策略一致性
維護成本
lru/lirs演算法剔除最差低
超時剔除較差低
主動更新強高
1、從mysql獲取使用者資訊：
select * from user where id=
2、設定使用者資訊快取：
set user: `select * from user where id=`
3、快取粒度：
全部屬性：set user: `select * from user where id=`
部分重要屬性：set user: `select importcolumn1...importcolumnk from user where id=`
三個角度
正常情況下，當訪問到cache，它會把結果返回給request，如果cache沒有命中的話，它就會把流量往下引到儲存層，如果儲存層正常的話，儲存層拿到結果，回寫到cache，返回給request，當下次request再次訪問的時候，就可以直接從cache中獲取，那麼就不需要訪問到儲存層了。
但是如果儲存層的資料根本就不存在，那會有什麼問題？
即它會返回給request為空的結果，當下次再來request請求，再訪問cache層，cache層還是沒有，還要再訪問儲存層，所有的流量都被匯入到儲存層，這就是快取穿透的乙個基本過程，實際上這就已經失去了快取的意義。
產生的原因
如何發現
解決方法1-快取空物件
即如果儲存層返回的結果為空，那麼就把它當作乙個結果，儲存到cache中。
兩個問題
1、需要儲存更多的鍵（更多無效的鍵）。
2、快取層和儲存層資料「短期」不一致。
示例**
public string getpassthrough(string key)
}else
return null;
}
將所有可能存在的資料雜湊到乙個足夠大的 bitmap 中，乙個一定不存在的資料會被這個 bitmap 攔截掉，從而避免了對底層儲存系統的查詢壓力。
由於cache服務承載大量請求，當cache服務異常/離線，流量直接壓向後端元件（例如db），造成級聯故障。
快取雪崩-優化方案
1、保證快取高可用：個別節點、個別機器、甚至是機房。
2、依賴隔離元件為後端限流。
3、提前演練：例如壓力測試。
問題描述：
無底洞問題關鍵點
Redis學習筆記（八） 快取設計與優化
歡迎star fork follow素質三連 8.1.1 收益 8.1.2 成本 8.1.3 使用場景快取更新常用的三種策略 策略 一致性維護成本 lru lfu fifo最差低 超時剔除 較差較低 主動更新強高 快取更新策略使用建議 通常情況下，都是使用redis去保護底層mysql，但是這也涉及...
redis 快取設計和優化
加速讀寫 降低後端負載 資料不一致 維護成本更高 多了一層快取邏輯 運維成本 redis cluster 降低後端負載 對高消耗的運算結果進行快取 加速請求響應 i 0 大量寫合併為批量寫 先累計在db持久化 lru lfu fifo演算法剔除 maxmemory policy 超時剔除 expir...
快取設計 一致性優化
一致性是指資料庫和快取裡的資料是一樣的，如果出現兩者不一樣，就說出現了一致性問題。一致性優化是指怎麼消除一致性問題，或者出現了一致性問題怎麼去發現並解決。如果資料庫和快取不一致，會導致系統出現bug，尤其是一些關鍵性的資料，比如餘額。所以在一些不能容忍不一致的場景，是一定要消除不一致的問題。為什麼會...