今天抽時間和大家聊聊redis的雪崩以及redis集羣的演變過程。
首先來說說什麼是redis的緩存雪崩。
如圖是一個比較常見的業務流程圖，先去看緩存是否存在，如果存在返回，如果不存在直接查數據庫，並更新緩存。
一般在設置緩存的時候，都會去設置一個失效時間，防止無用緩存佔用大量內存。
常見的緩存雪崩分爲兩種：
1，就是在某一時刻，大量緩存失效，導致大量查詢直接落在數據庫上，壓垮數據庫。
2，緩存數據庫宕機了，導致所有的查詢請求全部落在了數據庫上
當然應對兩種情況都有不同的解決方法，第一種就比較簡單了，我針對不同的key設置不同的緩存失效時間即可，也是很容易想到的，這邊不做過多討論。
今天主要來說說這第二種。要知道在早期的緩存數據庫大都是單機部署的，從單機到現在的大規模集羣是經歷了很長的一個發展週期的。關於redis的演變過程，大致可以分爲如下幾個歷程：
如圖，關於redis的發展歷程大概可以分爲如上幾個階段：單機 - 主從 - 哨兵 - 高可用集羣：
現在成熟企業的redis主要都是基於一個大規模的redis集羣，這也是爲了解決redis的單點故障，保障了整個緩存系統的高可用性，關於redis高可用集羣相關的詳細介紹可以參考我的另一篇博文：redis高可用集羣詳細介紹
這篇文章詳細介紹了redis的高可用集羣的相關原理，搭建以及相關配置的詳細介紹。有興趣的可以瞭解下。
當redis高可用集羣也是應對緩存單點故障導致緩存雪崩的主要解決方式。
