【獨家】終生受用的Redis高可用技術解決方案大全

最近不少朋友向我諮詢關於高可用的方案的優缺點以及如何選擇合適的方案線上使用，恰好最近在給宜人貸，光大銀行作企業內訓的時候也詳細講過，這裏我再整理髮出來，供你們參考，若有不妥之處，歡迎批評指正，也歡迎推薦更好的技術方案。不廢話了，來看看方案吧～

總綱

Redis常見的幾種主要使用方式：

Redis 單副本

Redis 多副本（主從）

Redis Sentinel（哨兵）

Redis Cluster

Redis 自研

Redis各類使用方式的優缺點：

一、Redis單副本

Redis 單副本，採用單個Redis節點部署架構，沒有備用節點實時同步數據，不提供數據持久化和備份策略，適用於數據可靠性要求不高的純緩存業務場景。

優勢：

一、架構簡單、部署方便

二、高性價比，當緩存使用時無需備用節點（單實例可用性能夠用supervisor或crontab保證），固然爲了知足業務的高可用性，也能夠犧牲一個備用節點，但同時刻只有一個實例對外提供服務。

三、高性能

缺點：

一、不保證數據的可靠性

二、當緩存使用，進程重啓後，數據丟失，即便有備用的節點解決高可用性，可是仍然不能解決緩存預熱問題，所以不適用於數據可靠性要求高的業務。

三、高性能受限於單核CPU的處理能力（Redis是單線程機制），CPU爲主要瓶頸，因此適合操做命令簡單，排序、計算較少的場景。也能夠考慮用memcached替代。

二、Redis多副本（主從）

Redis 多副本，採用主從（replication）部署結構，相較於單副本而言最大的特色就是主從實例間數據實時同步，而且提供數據持久化和備份策略。主從實例部署在不一樣的物理服務器上，根據公司的基礎環境配置，能夠實現同時對外提供服務和讀寫分離策略。

優勢：

一、高可靠性，一方面，採用雙機主備架構，可以在主庫出現故障時自動進行主備切換，從庫提高爲主庫提供服務，保證服務平穩運行。另外一方面，開啓數據持久化功能和配置合理的備份策略，能有效的解決數據誤操做和數據異常丟失的問題。

二、讀寫分離策略，從節點能夠擴展主庫節點的讀能力，有效應對大併發量的讀操做。

缺點：

一、故障恢復複雜，若是沒有RedisHA系統（須要開發），當主庫節點出現故障時，須要手動將一個從節點晉升爲主節點，同時須要通知業務方變動配置，而且須要讓其餘從庫節點去複製新主庫節點，整個過程須要人爲干預，比較繁瑣。

二、主庫的寫能力受到單機的限制，能夠考慮分片

三、主庫的存儲能力受到單機的限制，能夠考慮Pika

四、原生複製的弊端在早期的版本也會比較突出，如：Redis複製中斷後，Slave會發起psync，此時若是同步不成功，則會進行全量同步，主庫執行全量備份的同時可能會形成毫秒或秒級的卡頓；又因爲COW機制，致使極端狀況下的主庫內存溢出，程序異常退出或宕機；主庫節點生成備份文件致使服務器磁盤IO和CPU（壓縮）資源消耗；發送數GB大小的備份文件致使服務器出口帶寬暴增，阻塞請求。建議升級到最新版本。

三、Redis Sentinel（哨兵）

Redis Sentinel是社區版本推出的原生高可用解決方案，Redis Sentinel部署架構主要包括兩部分：Redis Sentinel集羣和Redis數據集羣，其中Redis Sentinel集羣是由若干Sentinel節點組成的分佈式集羣。能夠實現故障發現、故障自動轉移、配置中心和客戶端通知。Redis Sentinel的節點數量要知足2n+1（n>=1）的奇數個。

優勢：

一、Redis Sentinel集羣部署簡單

二、可以解決Redis主從模式下的高可用切換問題

三、很方便實現Redis數據節點的線形擴展，輕鬆突破Redis自身單線程瓶頸，可極大知足對Redis大容量或高性能的業務需求。

四、能夠實現一套Sentinel監控一組Redis數據節點或多組數據節點

缺點：

一、部署相對Redis 主從模式要複雜一些，原理理解更繁瑣

二、資源浪費，Redis數據節點中slave節點做爲備份節點不提供服務

三、Redis Sentinel主要是針對Redis數據節點中的主節點的高可用切換，對Redis的數據節點作失敗斷定分爲主觀下線和客觀下線兩種，對於Redis的從節點有對節點作主觀下線操做，並不執行故障轉移。

四、不能解決讀寫分離問題，實現起來相對複雜

建議：

一、若是監控同一業務，能夠選擇一套Sentinel集羣監控多組Redis數據節點的方案，反之選擇一套Sentinel監控一組Redis數據節點的方案

二、sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建議設置成Sentinel節點的一半加1，當Sentinel部署在多個IDC的時候，單個IDC部署的Sentinel數量不建議超過（Sentinel數量 – quorum）。

三、合理設置參數，防止誤切，控制切換靈敏度控制

quorum

down-after-milliseconds 30000

failover-timeout 180000

maxclient

timeout

四、部署的各個節點服務器時間儘可能要同步，不然日誌的時序性會混亂

五、Redis建議使用pipeline和multi-keys操做，減小RTT次數，提升請求效率

六、自行搞定配置中心（zookeeper），方便客戶端對實例的連接訪問

四、Redis Cluster

Redis Cluster是社區版推出的Redis分佈式集羣解決方案，主要解決Redis分佈式方面的需求，好比，當遇到單機內存，併發和流量等瓶頸的時候，Redis Cluster能起到很好的負載均衡的目的。Redis Cluster集羣節點最小配置6個節點以上（3主3從），其中主節點提供讀寫操做，從節點做爲備用節點，不提供請求，只做爲故障轉移使用。Redis Cluster採用虛擬槽分區，全部的鍵根據哈希函數映射到0～16383個整數槽內，每一個節點負責維護一部分槽以及槽所印映射的鍵值數據。

文章寫到這裏，也給你們送一個福利，給你們推薦一個Java架構方面的交流學習羣：650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源。文章開頭的總綱就是在羣裏面獲取的，相信對於已經工做和遇到技術瓶頸的碼友，在這個羣裏必定有你須要的內容。

優勢：

一、無中心架構

二、數據按照slot存儲分佈在多個節點，節點間數據共享，可動態調整數據分佈。

三、可擴展性，可線性擴展到1000多個節點，節點可動態添加或刪除。

四、高可用性，部分節點不可用時，集羣仍可用。經過增長Slave作standby數據副本，可以實現故障自動failover，節點之間經過gossip協議交換狀態信息，用投票機制完成Slave到Master的角色提高。

五、下降運維成本，提升系統的擴展性和可用性。

缺點：

一、Client實現複雜，驅動要求實現Smart Client，緩存slots mapping信息並及時更新，提升了開發難度，客戶端的不成熟影響業務的穩定性。目前僅JedisCluster相對成熟，異常處理部分還不完善，好比常見的「max redirect exception」。

二、節點會由於某些緣由發生阻塞（阻塞時間大於clutser-node-timeout），被判斷下線，這種failover是沒有必要的。

三、數據經過異步複製,不保證數據的強一致性。

四、多個業務使用同一套集羣時，沒法根據統計區分冷熱數據，資源隔離性較差，容易出現相互影響的狀況。

五、Slave在集羣中充當「冷備」，不能緩解讀壓力，固然能夠經過SDK的合理設計來提升Slave資源的利用率。

六、key批量操做限制，如使用mset、mget目前只支持具備相同slot值的key執行批量操做。對於映射爲不一樣slot值的key因爲keys 不支持跨slot查詢，因此執行mset、mget、sunion等操做支持不友好。

七、key事務操做支持有限，只支持多key在同一節點上的事務操做，當多個key分佈於不一樣的節點上時沒法使用事務功能。

八、key做爲數據分區的最小粒度，所以不能將一個很大的鍵值對象如hash、list等映射到不一樣的節點。

九、不支持多數據庫空間，單機下的redis能夠支持到16個數據庫，集羣模式下只能使用1個數據庫空間，即db 0。

十、複製結構只支持一層，從節點只能複製主節點，不支持嵌套樹狀複製結構。

十一、避免產生hot-key，致使主庫節點成爲系統的短板。

十二、避免產生big-key，致使網卡撐爆、慢查詢等。

1三、重試時間應該大於cluster-node-time時間

1四、Redis Cluster不建議使用pipeline和multi-keys操做，減小max redirect產生的場景。

五、Redis自研 - 推薦推薦

Redis 自研的高可用解決方案，主要體如今配置中心、故障探測和failover的處理機制上，一般須要根據企業業務的實際線上環境來定製化。

優勢：

一、高可靠性、高可用性

二、自主可控性高

三、貼切業務實際需求，可縮性好，兼容性好

缺點：

一、實現複雜，開發成本高

二、須要創建配套的周邊設施，如監控，域名服務，存儲元數據信息的數據庫等。

三、維護成本高