Redis系列之分布式快取

由於原有快取失效，新快取未到期間所有原本應該訪問快取的請求都去查詢資料庫了，而對資料庫 cpu 和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。

快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢），將會嚴重浪費資料庫資源甚至導致資料庫宕機。

它是由乙個很長的二進位制向量和一系列隨機對映函式組成

能夠迅速判斷乙個元素是否在乙個集合中，當乙個查詢請求過來時，先經過布隆過濾器進行查，如果判斷請求查詢值存在，則繼續查；如果判斷請求查詢不存在，直接丟棄

內部維護乙個全為0的bit（二進位制）陣列，需要說明的是，布隆過濾器有乙個誤判率的概念，誤判率越低，則陣列越長，所佔空間越大。誤判率越高則陣列越小，所佔的空間越小。

布隆過濾器只能判斷資料是否一定不存在，而無法判斷資料是否一定存在。

優點：由於存放的不是完整的資料，所以占用的記憶體很少，而且新增，查詢速度夠快；

缺點：隨著資料的增加，誤判率隨之增加；無法做到刪除資料；只能判斷資料是否一定不存在，而無法判斷資料是否一定存在。

當乙個元素被加入集合時，通過 k 個hash函式將這個元素對映成乙個位陣列（bit array）中的 k 個點，把它們置為1。檢索時，我們只要看看這些點是不是都是 1 就（大約）知道集合中有沒有它了：

bloomfilter:把內容通過多個hash演算法，轉換成多個陣列下標，下標對應的值只存放乙個bit 0或1 ，0不存在 1存在。判斷過濾時多個下標對應的值都為1，則可能存在，只要有乙個值為0，則一定不存在

快取預熱就是系統上線後，提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！

快取更新除了快取伺服器自帶的快取失效策略之外（redis 預設的有 6 中策略可供選擇），我們還可以根據具體的業務需求進行自定義的快取淘汰，常見的策略有兩種：

（1）定時去清理過期的快取；

（2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

服務降級的目的，是為了防止redis服務故障，導致資料庫跟著一起發生雪崩問題。

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；