歡迎光臨
每天分享高質量文章

這可能是目前最全的Redis高可用技術解決方案

來自:CRUG(ID:rediscn)

作者:張冬洪,極數雲舟資料庫架構師、極數學院聯合創始人、前新浪微博高階DBA、Redis中國使用者組主席、阿裡雲MVP。

本文主要針對 Redis 常見的幾種使用方式及其優缺點展開分析。

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

  • Redis 單副本

  • Redis 多副本(主從)

  • Redis Sentinel(哨兵)

  • Redis Cluster

  • Redis 自研

Redis各種使用方式的優缺點:

1
Redis單副本

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

優點:

1、架構簡單、部署方便

2、高價效比,當快取使用時無需備用節點(單實體可用性可以用supervisor或crontab保證),當然為了滿足業務的高可用性,也可以犧牲一個備用節點,但同時刻只有一個實體對外提供服務。

3、高效能

缺點:

1、不保證資料的可靠性

2、當快取使用,行程重啟後,資料丟失,即使有備用的節點解決高可用性,但是仍然不能解決快取預熱問題,因此不適用於資料可靠性要求高的業務。

3、高效能受限於單核CPU的處理能力(Redis是單執行緒機制),CPU為主要瓶頸,所以適合操作命令簡單,排序、計算較少的場景。也可以考慮用memcached替代。

2
Redis多副本(主從)

Redis 多副本,採用主從(replication)部署結構,相較於單副本而言最大的特點就是主從實體間資料實時同步,並且提供資料持久化和備份策略。主從實體部署在不同的物理伺服器上,根據公司的基礎環境配置,可以實現同時對外提供服務和讀寫分離策略。

優點:

1、高可靠性,一方面,採用雙機主備架構,能夠在主庫出現故障時自動進行主備切換,從庫提升為主庫提供服務,保證服務平穩執行。另一方面,開啟資料持久化功能和配置合理的備份策略,能有效的解決資料誤操作和資料異常丟失的問題。

2、讀寫分離策略,從節點可以擴充套件主庫節點的讀能力,有效應對大併發量的讀操作。

缺點:

1、故障恢複復雜,如果沒有RedisHA系統(需要開發),當主庫節點出現故障時,需要手動將一個從節點晉升為主節點,同時需要通知業務方變更配置,並且需要讓其他從庫節點去複製新主庫節點,整個過程需要人為幹預,比較繁瑣。

2、主庫的寫能力受到單機的限制,可以考慮分片

3、主庫的儲存能力受到單機的限制,可以考慮Pika

4、原生複製的弊端在早期的版本也會比較突出,如:Redis複製中斷後,Slave會發起psync,此時如果同步不成功,則會進行全量同步,主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓;又由於COW機制,導致極端情況下的主庫記憶體上限溢位,程式異常退出或宕機;主庫節點生成備份檔案導致伺服器磁碟IO和CPU(壓縮)資源消耗;傳送GB大小的備份檔案導致伺服器出口頻寬暴增,阻塞請求。建議升級到最新版本。

3
Redis Sentinel(哨兵)

Redis Sentinel是社群版本推出的原生高可用解決方案,Redis Sentinel部署架構主要包括兩部分:Redis Sentinel叢集和Redis資料叢集,其中Redis Sentinel叢集是由若干Sentinel節點組成的分散式叢集。可以實現故障發現、故障自動轉移、配置中心和客戶端通知。Redis Sentinel的節點數量要滿足2n+1(n>=1)的奇數個。

優點:

1、Redis Sentinel叢集部署簡單

2、能夠解決Redis主從樣式下的高可用切換問題

3、很方便實現Redis資料節點的線形擴充套件,輕鬆突破Redis自身單執行緒瓶頸,可極大滿足對Redis大容量或高效能的業務需求。

4、可以實現一套Sentinel監控一組Redis資料節點或多組資料節點

缺點:

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

2、資源浪費,Redis資料節點中slave節點作為備份節點不提供服務

3、Redis Sentinel主要是針對Redis資料節點中的主節點的高可用切換,對Redis的資料節點做失敗判定分為主觀下線和客觀下線兩種,對於Redis的從節點有對節點做主觀下線操作,並不執行故障轉移。

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

建議:

1、如果監控同一業務,可以選擇一套Sentinel叢集監控多組Redis資料節點的方案,反之選擇一套Sentinel監控一組Redis資料節點的方案

2、sentinel monitor 配置中的建議設定成Sentinel節點的一半加1,當Sentinel部署在多個IDC的時候,單個IDC部署的Sentinel數量不建議超過(Sentinel數量 – quorum)。

3、合理設定引數,防止誤切,控制切換靈敏度控制

  1. quorum

  2. down-after-milliseconds 30000

  3. failover-timeout 180000

  4. maxclient

  5. timeout

4、部署的各個節點伺服器時間儘量要同步,否則日誌的時序性會混亂

5、Redis建議使用pipeline和multi-keys操作,減少RTT次數,提高請求效率

6、自行搞定配置中心(zookeeper),方便客戶端對實體的連結訪問

4
Redis Cluster

Redis Cluster是社群版推出的Redis分散式叢集解決方案,主要解決Redis分散式方面的需求,比如,當遇到單機記憶體,併發和流量等瓶頸的時候,Redis Cluster能起到很好的負載均衡的目的。Redis Cluster叢集節點最小配置6個節點以上(3主3從),其中主節點提供讀寫操作,從節點作為備用節點,不提供請求,只作為故障轉移使用。Redis Cluster採用虛擬槽分割槽,所有的鍵根據雜湊函式對映到0~16383個整數槽內,每個節點負責維護一部分槽以及槽所印對映的鍵值資料。

優點:

1、無中心架構

2、資料按照slot儲存分佈在多個節點,節點間資料共享,可動態調整資料分佈。

3、可擴充套件性,可線性擴充套件到1000多個節點,節點可動態新增或刪除。

4、高可用性,部分節點不可用時,叢集仍可用。透過增加Slave做standby資料副本,能夠實現故障自動failover,節點之間透過gossip協議交換狀態資訊,用投票機制完成Slave到Master的角色提升。

5、降低運維成本,提高系統的擴充套件性和可用性。

缺點:

1、Client實現複雜,驅動要求實現Smart Client,快取slots mapping資訊並及時更新,提高了開發難度,客戶端的不成熟影響業務的穩定性。目前僅JedisCluster相對成熟,異常處理部分還不完善,比如常見的“max redirect exception”。

2、節點會因為某些原因發生阻塞(阻塞時間大於clutser-node-timeout),被判斷下線,這種failover是沒有必要的。

3、資料透過非同步複製,不保證資料的強一致性。

4、多個業務使用同一套叢集時,無法根據統計區分冷熱資料,資源隔離性較差,容易出現相互影響的情況。

5、Slave在叢集中充當“冷備”,不能緩解讀壓力,當然可以透過SDK的合理設計來提高Slave資源的利用率。

6、key批次操作限制,如使用mset、mget目前只支援具有相同slot值的key執行批次操作。對於對映為不同slot值的key由於keys 不支援跨slot查詢,所以執行mset、mget、sunion等操作支援不友好。

7、key事務操作支援有限,只支援多key在同一節點上的事務操作,當多個key分佈於不同的節點上時無法使用事務功能。

8、key作為資料分割槽的最小粒度,因此不能將一個很大的鍵值物件如hash、list等對映到不同的節點。

9、不支援多資料庫空間,單機下的redis可以支援到16個資料庫,叢集樣式下只能使用1個資料庫空間,即db 0。

10、複製結構只支援一層,從節點只能複製主節點,不支援巢狀樹狀複製結構。

11、避免產生hot-key,導致主庫節點成為系統的短板。

12、避免產生big-key,導致網絡卡撐爆、慢查詢等。

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

14、Redis Cluster不建議使用pipeline和multi-keys操作,減少max redirect產生的場景。

5
Redis自研 – 推薦

Redis 自研的高可用解決方案,主要體現在配置中心、故障探測和failover的處理機制上,通常需要根據企業業務的實際線上環境來定製化。

優點:

1、高可靠性、高可用性

2、自主可控性高

3、貼切業務實際需求,可縮性好,相容性好

缺點:

1、實現複雜,開發成本高

2、需要建立配套的周邊設施,如監控,域名服務,儲存元資料資訊的資料庫等。

3、維護成本高


●編號393,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

Web開發

更多推薦18個技術類微信公眾號

涵蓋:程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

贊(0)

分享創造快樂