今天抽時間和大家聊聊redis的雪崩以及redis集群的演變過程。
首先來說說什麼是redis的快取雪崩。
如圖是乙個比較常見的業務流程圖，先去看快取是否存在，如果存在返回，如果不存在直接查資料庫，並更新快取。
一般在設定快取的時候，都會去設定乙個失效時間，防止無用快取占用大量記憶體。
常見的快取雪崩分為兩種：
1，就是在某一時刻，大量快取失效，導致大量查詢直接落在資料庫上，壓垮資料庫。
2，快取資料庫宕機了，導致所有的查詢請求全部落在了資料庫上
當然應對兩種情況都有不同的解決方法，第一種就比較簡單了，我針對不同的key設定不同的快取失效時間即可，也是很容易想到的，這邊不做過多討論。
今天主要來說說這第二種。要知道在早期的快取資料庫大都是單機部署的，從單機到現在的大規模集群是經歷了很長的乙個發展週期的。關於redis的演變過程，大致可以分為如下幾個歷程：
如圖，關於redis的發展歷程大概可以分為如上幾個階段：單機 - 主從 - 哨兵 - 高可用集群：
現在成熟企業的redis主要都是基於乙個大規模的redis集群，這也是為了解決redis的單點故障，保障了整個快取系統的高可用性，關於redis高可用集群相關的詳細介紹可以參考我的另一篇博文：redis高可用集群詳細介紹
當redis高可用集群也是應對快取單點故障導致快取雪崩的主要解決方式。
Redis快取三大問題解析
通俗來講，快取粒度問題就是我們在使用快取時，是將所有資料快取還是快取部分資料？快取粒度問題是乙個容易被忽視的問題，如果使用不當，可能會造成很多無用空間的浪費，可能會造成網路頻寬的浪費，可能會造成 通用性較差等情況，必須學會綜合資料通用性 空間占用比 維護性 三點評估取捨因素權衡使用。快取穿透是指查詢...
Redis三大問題 快取穿透 快取擊穿 快取雪崩
快取擊穿 快取雪崩 前台請求，後台先從快取中取資料，取到直接返回結果，取不到時從資料庫中取，資料庫取到更新快取，並返回結果，資料庫也沒取到，直接返回空結果。快取穿透就是當使用者訪問一條資料時，快取和資料庫中都不存在，就會不斷的發起請求。如果使用者是攻擊者，會導致資料庫壓力過大。解決方案 快取空物件 ...
快取常見三大問題
之前常聽人說，但是沒有仔細想過這些問題。最近看 可伸縮服務架構 架構與中介軟體 中這些問題解釋的很好，也給出了一般解決方案，記錄一下。快取穿透 快取併發 快取雪崩常見的由於併發量大而導致。說明 快取穿透指的是使用不存在的key進行大量的高併發查詢，這導致快取無法命中，每次請求都要穿透到後端資料庫系統...