Tair (Redis OSS-compatible)支援多複本集群版執行個體,同時也支援叢集版開啟讀寫分離功能。可輕鬆突破Redis自身單線程瓶頸,滿足大容量、高效能的業務需求。叢集版支援代理和直連兩種串連模式,您可以根據本章節的說明,選擇適合業務需求的串連模式。
注意事項
雲原生版叢集架構不支援同時使用代理模式和直連模式,但僅雲原生版叢集架構(代理模式)支援開啟讀寫分離功能。
經典版叢集架構僅支援雙副本。
代理模式(推薦)
代理(Proxy)模式能夠大大簡化叢集架構執行個體的使用方式,使之與標準架構(主備)的串連方式相同。Proxy 伺服器會自動實現路由轉寄,將用戶端的請求轉寄到各資料分區,同時代理節點還提供了緩衝熱點Key、容錯移轉等進階特性。更多資訊請參見Tair Proxy特性說明。
代理模式的服務架構圖和組件說明如下。
多副本
表 1. 叢集版代理模式組件說明
組件 | 說明 |
Proxy 伺服器(Proxy Server) | 負責將用戶端的請求轉寄到各資料分區。叢集版架構中由多個Proxy組成。 |
資料分區(Data Shards) | 每個資料分區均為一主多備(分別部署在不同機器上)的高可用架構。備節點的數量範圍為1 ~ 4,可以選擇部署在備可用性區域。多個備節點可以提高容災能力,減少資料丟失的可能性。 |
高可用服務(HA) | 主節點(Master)發生故障後,系統會自動在30秒內切換至備節點(Replica),以保證服務高可用和資料高可靠。如果執行個體為雙可用性區域部署,當主可用性區域存在備節點時,主備切換會優先選擇主可用性區域的備節點進行切換,避免業務跨可用性區域訪問。 |
各組件的數量和配置由執行個體的規格決定。使用經典部署模式時不支援自訂修改,但您可以通過變更執行個體配置調整叢集的大小,或者將執行個體調整為其他架構;使用雲原生部署模式時支援以1分區為單位對分區數量進行自訂修改,支援區間為2~256,在調整時Proxy數量會自動同步增減,修改分區數量操作詳見調整執行個體的分區數量。
開啟讀寫分離
圖 2. 叢集版(開啟讀寫分離)服務架構樣本
表 2. 叢集版(開啟讀寫分離)組件說明
組件 | 說明 |
Proxy 伺服器(Proxy Server) | 當用戶端與Proxy 伺服器(Proxy Server)建立串連後,Proxy會自動識別用戶端發起的請求,將請求轉寄到各資料分區以及對應的讀寫節點上。例如將寫請求轉寄給主節點,將讀請求均衡地轉寄給主節點和唯讀節點。 |
資料分區(Data Shards) | 每個資料分區由1個主節點(Master)、最多4個唯讀節點(Read Replicas)組成。
|
高可用服務(HA) | 當主節點(或唯讀節點)異常時,執行個體將自動進行主備切換或重搭唯讀節點,並更新相應的路由資訊,保證服務高可用和資料高可靠。 |
若執行個體為單可用性區域,則所有節點均在主可用性區域,執行個體僅提供主可用性區域的串連地址。
若執行個體為雙可用性區域,則執行個體將分別提供主、備可用性區域的串連地址,均支援讀、寫操作。寫請求均會路由到主可用性區域的主節點中;每個可用性區域的讀請求會路由到本可用性區域的主節點或唯讀節點中,實現就近訪問。若發生極端情況,備可用性區域的所有隻讀節點都不可用,備可用性區域的讀請求也會路由到主節點中,不會影響業務運行。
直連模式
直連模式為類似串連原生Redis Cluster的方式串連叢集。用戶端首次串連時會通過DNS將直連位址解析為一個隨機資料分區的虛擬IP(VIP)地址,之後即可通過Redis Cluster協議訪問各資料分區。直連模式的服務架構和說明如下。
直連模式與代理模式的串連方式區別較大,相關注意事項和串連樣本請參見使用直連模式串連執行個體。
雲原生版叢集架構(直連模式)也支援多副本。
使用情境
資料量較大
相比標準版,叢集版可以有效地擴充儲存量,最大可達16 TB(64 GB * 256分區),能有效滿足業務擴充的需求。
請求負載較大
標準版無法支撐較大的請求負載,需要採用多分區的部署方式來突破Redis單線程的效能瓶頸。
當讀請求流量非常大,超過主節點效能上限時,您可以開啟叢集架構的讀寫分類功能。
說明由於僅雲原生版叢集架構(代理模式)執行個體支援開啟讀寫分離,您可以通過建立執行個體、使用DTS同步資料的方式將其他版本的執行個體遷移至叢集版(開啟讀寫分離)執行個體。
吞吐密集型應用
相比標準版,叢集版的內網輸送量可通過增加分區數量線性擴充,可以更好地支援熱點資料讀取、大吞吐類業務。
多KEY操作較少的應用
由於叢集為分布式架構,在一次操作多個KEY時需要確保所有KEY均在同一slot中,因此會對多KEY操作帶來一些限制。詳情請參見叢集架構與讀寫分離架構執行個體的命令限制。
延遲敏感應用
雙可用性區域執行個體可以在主可用性區域增加備節點,例如主可用性區域1個主節點、1個備節點,備可用性區域1個備節點。既提高了容災的可靠性,同時也能避免由主備切換後應用跨可用性區域訪問帶來延遲升高的問題。
相關文檔
如需查詢記憶體中資料的分布情況請參見離線全量Key分析。