歡迎star、fork、follow素質三連
8.1.1 收益
8.1.2 成本
8.1.3 使用場景快取更新常用的三種策略： 策略
一致性維護成本
lru、lfu、fifo最差低
超時剔除
較差較低
主動更新強高
快取更新策略使用建議：
通常情況下，都是使用redis去保護底層mysql，但是這也涉及到快取資料粒度控制問題：到底是快取資料的全量資料好，還是快取資料的部分幾個重要的屬性更好？
建議：
實際開發中，雖然全量資料快取有利於業務的拓展性，考慮業務的拓展性也是非常好的思想，但是真實業務很多情況下業務需求不會發生變化，此時直接快取部分重要資料即可。
快取存在的意義是為了保護底層mysql等儲存層，但是如果有大量請求發生不命中情況，即所有請求都直接穿透到mysql儲存層，那麼快取存在就沒有意義，此時就是快取穿透。
產生原因：
解決方案：
bloom過濾器：在快取層增加一層bloom filter，如果bloom filter認為對應的key不存在，那麼就一定不存在，直接返回；如果bloom filter認為存在，則可能存在，就去資料層查詢並回寫。
當節點數量很多少，網路io時間的消耗就必須考慮，因為redis本身而言絕大多數命令非常快，當節點數量非常大時，網路io消耗時間的常數項就必須考慮：
優化io的幾種方案：
如果某個key在快取中沒有命中，但是從資料庫中獲取到了，需要對key進行會寫重建。如果該key是乙個熱點key，同時重建時間較長，那麼就會有熱點key重建問題。
熱點key重建的目標：
兩個解決方法：
8.3.1 互斥鎖
將熱點key重建的過程加鎖互斥，讓其它執行緒只能夠等待，可以保證資料的強一致性問題。
// 偽**
string get
(string key)
else
}return value;
}
// 偽**
string get
(final string key)})
;}}return value;
}
方案優點
缺點互斥鎖
思路簡單
保證一致性
**複雜度增加
存在死鎖風險
永不過期
基本杜絕熱點key重建問題
不保證一致性
邏輯過期時間增減維護成本和記憶體時間
Redis學習筆記（八）Redis快取穿透和雪崩
概念 在預設情況下，使用者請求資料時，會先在快取 redis 中查詢，若沒找到即快取未命中，再在資料庫中進行查詢，數量少可能問題不大，可是一旦大量的請求資料 例如秒殺場景 快取都沒有命中的話，就會全部轉移到資料庫上，造成資料庫極大的壓力，就有可能導致資料庫崩潰。網路安全中也有人惡意使用這種手段進行攻...
快取設計學習筆記
最近在 redis 開發與運維 這是在看11章時候記得筆記 先放個最簡單的圖，這裡面每一層都可以有快取 總之，請求的任何乙個環節都可以根據需要做快取 剔除演算法 lru lfu fifo 超時剔除 主動更新這個實際上就是快取內容的選擇問題，假設mongo裡有一條完整的記錄，我們是選擇全部資料都快取還...
Redis 學習筆記（八）事務
更多的資料型別命令可在redis中文官網中查詢和學習，下面學習redis的事務。原子性是指乙個操作或者多個操作，要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。事務是指一系列操作，這些操作要麼同時成功，要麼同時失敗，它是一種原子操作。事務沒有隔離級別的概念。redis的單條命令都具有原...