做者：z小趙
web
★一枚用心堅持寫原創的「無趣」程序猿，在自身受益的同時也讓朋友們在技術上有所提高。算法
上篇文章分析比較了生產環境中常見的幾種緩存，本文接着來分析分析緩存如何作到高可用，大白話解釋下就是緩存到底該怎麼作才能儘量的避免緩存不可用的狀況發生。後端
什麼狀況會致使緩存不可用？緩存
-
單點問題：
什麼是單點問題呢？就是咱們在使用緩存時，有時候因爲 QPS、內存容量只須要一個端口（此處的一個端口是指一主一從）就能夠扛住全部讀寫請求時，好比寫 QPS 5k，讀 QPS 30k，內存 5G；根據這個數據規模，DBA 在部署資源時會選擇只部署一個節點。當緩存資源因爲某些狀況致使服務器宕機或服務不可用時，因爲只部署了一個端口，從而致使當前整個應用服務不可用（這種狀況以前在實際生產環境中真實發生過，直接炸裂），這就是所謂的單點問題；其實在分佈式架構中，爲了作到服務的高可用，要儘可能去避免單點問題，作到雞蛋儘可能不放在一個籃子裏來儘可能保證服務的可用性。服務器
-
緩存穿透/緩存擊穿
緩存穿透/緩存擊穿是指某些時刻因爲有些熱 key 失效或者是過時，致使在一瞬間大量請求繞過緩存直接打到 DB 上，因爲 DB 的讀寫 qps 並不高，從而致使 DB 直接瞬間被打掛，尤爲是在微博這種應用上，突發熱點流量加上緩存設計不合理致使熱 key 過時，就會發生緩存擊穿的狀況。微信
-
緩存雪崩
緩存雪崩是指因爲緩存過時時間設計不合理，緩存數據過時時間集中，致使在某一時刻緩存中數據大面積過時，從而致使緩存的 miss 率大大增長，因爲緩存沒有攔住請求致使大量請求落到 DB 上，最終致使後端 DB 資源被完全打掛，即便重啓 DB 也會被大量請求瞬間再次打掛。架構
如何設計高可用的緩存？app
-
單點問題解決方案
首先，單端口在資源申請階段部署爲多端口的（大於一個端口），同時每一個端口至少部署爲一主一從且分佈在不一樣的節點上；經過此種部署方式，會有以下幾個好處：編輯器
-
假設某個從節點服務不可用時，將讀請求轉移到主節點上可繼續提供服務，當從節點恢復後再加入到集羣中繼續提供服務。 -
假設集羣中某幾個節點服務不可用時，此時最壞的狀況也只是影響部分用戶的功能使用。
其次，在多端口部署的基礎上，在機房層面作到多機房災備；此種緩存的作法是：假設一個緩存部署兩份，而這兩份緩存部署在不一樣的機房中，這樣的話，即便其中一個機房發生極端狀況，能夠將流量切換到另一個機房中，從而作到機房層面的高可用。分佈式
最後，可使用一致性 hash 算法，使用機器的 ip 或者域名作 hash 操做，分佈在一個虛擬的環上，一樣對於 key 也作相同的 hash 操做，當 key 獲得一個 hash 值後，順時針移動直到遇到第一個節點，而後將 key 對應的 value 存儲到該節點上；此種作法是節點動態上下線的時候只須要對部分 key 作 rehash 操做，可是此種方案的缺點是：節點動態上下線後，key 通過 rehash 操做後致使各個節點數據分佈不均，也就致使各個節點的服務承載的壓力不均不可控。
-
緩存穿透/緩存擊穿的解決方案
緩存擊穿是因爲熱 key 失效致使的，因此第一種方案是：能夠根據業務場景，選擇能夠將熱 key 直接所有緩存到緩存中而且永遠不過時，經過此種方式來避免熱 key 由於過時的問題致使緩存擊穿；第二種方案是：因爲熱 key 通常狀況下並非不少，因此咱們能夠考慮使用 localCache，在系統啓動時，預先將熱點數據所有加載到內存中，只要服務器不發生宕機就能夠一直正常提供服務。
-
緩存雪崩的解決方案
緩存雪崩是在某一時刻，緩存中數據大量集中過時致使緩存不可用，對於此種狀況，通常是在緩存 key 設計時，對 key 增長一個必定時間範圍內的隨機時間戳，使得 key 過時分散開來，從而避免全部 key 同時過時的尷尬狀況。
總結
本文主要介紹了實際生產環境中緩存該如何作到高可用，從而避免因爲緩存不可用而致使整個系統崩潰。
關於 Redis 系列文章總計 8 篇，從 Redis 基礎命令使用，到 Redis 基礎集合及經常使用命令的底層實現，而後到集羣搭建實戰，而後到 Redis 的線程模型，最後到線上緩存方案設計及緩存高可用的方案，到此關於 Redis 專題暫時告一段落，但後續還會繼續更新關於緩存相關的文章，朋友們有對緩存相關知識感興趣的話題能夠和做者交流，後續會持續更新更多精彩的緩存文章。好了，下篇文章開始咱們來說講 MySQL，不知道你會不會感興趣呢？盡情期待哈。
往期推薦
本文分享自微信公衆號 - z小趙（Id_Bean）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。