Redis高可用技術解決方案總結

標籤：實現   不成功   雜湊函數   環境配置   節點   運行   共用   動態添加   pika   

一、常見使用方式

Redis的幾種常見使用方式包括：

• Redis單副本；

• Redis多副本（主從）；

• Redis Sentinel（哨兵）；

• Redis Cluster；

• Redis自研。

二、各種使用方式的優缺點

1、Redis單副本

Redis單副本，採用單個Redis節點部署架構，沒有備用節點即時同步資料，不提供資料持久化和備份策略，適用於資料可靠性要求不高的純緩衝業務情境。

優點：

• 架構簡單，部署方便；

• 高性價比：緩衝使用時無需備用節點（單一實例可用性可以用supervisor或crontab保證），當然為了滿足業務的高可用性，也可以犧牲一個備用節點，但同時刻只有一個執行個體對外提供服務；

• 高效能。

缺點：

• 不保證資料的可靠性；

• 在緩衝使用，進程重啟後，資料丟失，即使有備用的節點解決高可用性，但是仍然不能解決緩衝預熱問題，因此不適用於資料可靠性要求高的業務；

• 高效能受限於單核CPU的處理能力（Redis是單線程機制），CPU為主要瓶頸，所以適合操作命令簡單，排序、計算較少的情境。也可以考慮用Memcached替代。

2、Redis多副本（主從）

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

優點：

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

• 讀寫分離策略：從節點可以擴充主庫節點的讀能力，有效應對大並發量的讀操作。

缺點：

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

• 主庫的寫能力受到單機的限制，可以考慮分區；

• 主庫的儲存能力受到單機的限制，可以考慮Pika；

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

3、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）。

• 合理設定參數，防止誤切，控制切換靈敏度控制：

  a. quorum

  b. down-after-milliseconds 30000

  c. failover-timeout 180000

  d. maxclient

  e. timeout

• 部署的各個節點伺服器時間盡量要同步，否則日誌的時序性會混亂。

• Redis建議使用pipeline和multi-keys操作，減少RTT次數，提高請求效率。

• 自行搞定配置中心（zookeeper），方便用戶端對執行個體的連結訪問。

4、Redis Cluster

Redis Cluster是社區版推出的Redis分布式叢集解決方案，主要解決Redis分布式方面的需求，比如，當遇到單機記憶體，並發和流量等瓶頸的時候，Redis Cluster能起到很好的負載平衡的目的。

Redis Cluster叢集節點最小配置6個節點以上（3主3從），其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為容錯移轉使用。

Redis Cluster採用虛擬槽分區，所有的鍵根據雜湊函數映射到0～16383個整數槽內，每個節點負責維護一部分槽以及槽所印映射的索引值資料。

優點：

• 無中心架構；

• 資料按照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，導致網卡撐爆、慢查詢等。

• 重試時間應該大於cluster-node-time時間。

• Redis Cluster不建議使用pipeline和multi-keys操作，減少max redirect產生的情境。

5、Redis自研

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

優點：

• 高可靠性、高可用性；

• 自主可控性高；

• 貼切業務實際需求，可縮性好，相容性好。

缺點：

• 實現複雜，開發成本高；

• 需要建立配套的周邊設施，如監控，網域名稱服務 (DNS)，儲存中繼資料資訊的資料庫等；

• 維護成本高。

Redis高可用技術解決方案總結