全部產品
Search
文件中心

Tair (Redis® OSS-Compatible):讀寫分離功能

更新時間:Sep 13, 2025

針對超高讀寫比的業務情境,Tair (Redis OSS-compatible)支援動態開啟或關閉讀寫分離功能,提供高可用、高效能、靈活的讀寫分離服務,滿足熱點資料集中及高並發讀取的業務需求。讀寫分離執行個體由阿里雲Tair團隊自研的Proxy組件進行全自動智能識別讀寫請求及路由、故障切換等服務。您無需處理與讀寫分離相關的業務代碼,也無需考慮故障切換的業務層處理,本功能將顯著降低接入複雜度。

標準架構開啟讀寫分離

標準架構開啟讀寫分離功能的執行個體主要由主節點、唯讀節點、代理節點(Proxy)和高可用系統等組成,架構圖如下。

圖 1. 雲原生版

圖 2. 經典版(已停售)

組件

雲原生版讀寫分離執行個體

經典版讀寫分離執行個體(已停售)

主節點(Master node)

承擔寫請求的處理,同時和唯讀節點共同承擔讀請求的處理。

唯讀節點(Read replicas)

承擔讀請求的處理,特點如下:

  • 所有隻讀節點均具備容災功能,可作為備節點進行資料備份。

  • 唯讀節點均從主節點同步資料,為星型複製架構,資料同步延遲遠小於經典版鏈式複製架構。

  • 支援自訂唯讀節點數量,叢集架構每分區1 ~ 4個,標準架構1 ~ 9個。

承擔讀請求的處理,特點如下:

  • 唯讀節點採取鏈式複製架構,當唯讀節點數越多,靠近鏈路末端的唯讀節點資料延遲越大。

  • 提供1個、3個、5個唯讀節點配置。

備節點(Replica node)

任一隻讀節點均可作為備節點。當主節點發生異常時,高可用系統將選擇資料最完整的唯讀節點作為新的主節點,並在切換完成後立即補充一個新的唯讀節點。

由於無需該組件,在同樣效能下,雲原生讀寫分離執行個體的價格更低。

冷備節點,作為資料備份使用,不對外提供服務。當主節點發生異常時,會將請求切換至該節點。

Proxy 伺服器(Proxy Server)

用戶端和Proxy 伺服器建立串連後,Proxy 伺服器會自動識別用戶端發起的請求類型,按照權重分發流量(各節點權重相同,且不支援自訂權重),將請求轉寄到不同的資料節點中。例如將寫請求轉寄給主節點,將讀請求轉寄給主節點和唯讀節點。

說明
  • 用戶端只會與Proxy 伺服器建立串連,不支援和各節點直接建立串連。

  • Proxy 伺服器會將讀請求平均分配到主節點和唯讀節點,暫不支援自訂控制。例如3個唯讀節點的執行個體,主節點和3個唯讀節點的讀權重均為25%。

高可用系統(HA system)

  • 自動監控各節點的健康狀態:當各節點異常時,高可用系統將發起主備切換或重建唯讀節點,並更新相應的路由及權重資訊。

  • 故障時選主節點邏輯:資料優先,高可用系統將選取資料最完整的唯讀節點作為新的主節點。

關於雙可用性區域讀寫分離執行個體的說明

雲原生讀寫分離執行個體(推薦)

經典讀寫分離執行個體(已停售)

主、備可用性區域都提供服務,最小配置:

  • 主可用性區域:1個主節點、1個唯讀節點。

  • 備可用性區域:1個唯讀節點。

將分別提供主、備可用性區域的串連地址,均支援讀、寫操作。主可用性區域的讀請求僅會路由至主可用性區域的主節點或唯讀節點,備可用性區域的讀請求也僅會路由至備可用性區域的唯讀節點,實現就近訪問;而所有的寫請求均會路由到主可用性區域的主節點中。架構圖如下:

說明

推薦主、備可用性區域均配置2節點以上:

  • 主可用性區域:1個主節點、1個唯讀節點。

  • 備可用性區域:2個唯讀節點。

主節點與唯讀節點都部署在主可用性區域,僅將冷備節點部署在備可用性區域,作為資料備份,不對外提供服務。當主節點發生異常時,會將請求切換至該節點。

特點:

  • 動態開關、簡單易用

    標準架構能夠直接開啟讀寫分離功能。由於用戶端請求的讀寫類型是通過Proxy智能識別與轉寄,在開啟該功能後,您可以直接使用任何支援Redis的用戶端訪問讀寫分離執行個體,從而實現讀效能的提升,且無需進行業務改造。讀寫分離執行個體相容Redis協議命令,但存在代理節點的命令限制,更多資訊請參見讀寫分離執行個體的命令限制

  • 高可用

    • 通過阿里雲自研的高可用系統自動監控所有資料節點的健康狀態,為整個執行個體的可用性保駕護航。主節點不可用時自動選擇新的主節點並重新搭建複寫拓撲。某個唯讀節點異常時,高可用系統能夠自動探知並重新啟動新節點完成資料同步,下線異常節點。

    • 代理節點會即時感知每個唯讀節點的服務狀態。在某個唯讀執行個體異常期間,代理節點會自動降低該節點的服務權重,發現唯讀節點連續失敗超過一定次數以後,會停止異常節點的服務權利,並具備繼續監控後續重新啟動節點服務的能力。

  • 高效能

    讀寫分離執行個體可以通過擴充唯讀執行個體個數使整體執行個體效能呈線性增長,同時基於源碼層面對Redis複製流程的定製最佳化,可以最大程度地提升線性複製的系統穩定性,充分利用每一個唯讀節點的實體資源。

使用情境:

讀取請求QPS(Queries Per Second)壓力較大的情境。如果業務為讀多寫少的情境,標準架構可能無法滿足較高的QPS需求。在這種情況下,您可以通過部署多個唯讀節點來突破單節點的效能瓶頸。開啟讀寫分離後執行個體可承載的讀QPS最高提升9倍。

說明

由於Redis非同步同步機制,在寫入量較大的情況下可能會發生資料同步延遲。選用此架構時,業務需要能接受一定程度的髒資料。

叢集架構開啟讀寫分離

叢集架構中,僅雲原生版、代理模式支援開啟讀寫分離功能,服務架構樣本如下。

組件說明

組件

說明

Proxy 伺服器(Proxy Server)

當用戶端與Proxy 伺服器(Proxy Server)建立串連後,Proxy會自動識別用戶端發起的請求,將請求轉寄到各資料分區以及對應的讀寫節點上。例如將寫請求轉寄給主節點,將讀請求均衡地轉寄給主節點和唯讀節點。

資料分區(Data Shards)

每個資料分區由1個主節點(Master)、最多4個唯讀節點(Read Replicas)組成。

  • 主節點:承擔寫請求的處理,同時和唯讀節點共同承擔讀請求的處理。固定部署在主可用性區域。

  • 唯讀節點:承擔讀請求的處理,唯讀節點均從主節點同步資料(星型複製架構)。唯讀節點的數量範圍為1 ~ 4,並且支援動態調整。您也可以選擇部署唯讀節點在備可用性區域,所以唯讀節點均具備容災功能。

高可用服務(HA)

  • 自動監控各節點的健康狀態:當各節點異常時,高可用系統將發起主備切換或重建唯讀節點,並更新相應的路由及權重資訊。

  • 故障時選主節點邏輯:資料優先,高可用系統將選取資料最完整的唯讀節點作為新的主節點。

說明
  • 若執行個體為單可用性區域,則所有節點均在主可用性區域,執行個體僅提供主可用性區域的串連地址。

  • 若執行個體為雙可用性區域,則執行個體將分別提供主、備可用性區域的串連地址,均支援讀、寫操作。主可用性區域的讀請求會路由至主可用性區域的主節點或唯讀節點中,備可用性區域的讀請求也僅會路由至備可用性區域的唯讀節點,實現就近訪問。而所有的寫請求均會路由到主可用性區域的主節點中。若發生極端情況,備可用性區域的所有隻讀節點都不可用,備可用性區域的讀請求也會路由到主節點中,不會影響業務運行。

建議與使用須知

  • 當一個唯讀節點發生故障時,請求會轉寄到其他節點;如果所有隻讀節點均不可用,請求會全部轉寄到主節點。唯讀節點異常可能導致主節點負載提高、回應時間變長,因此在讀負載高的業務情境建議使用多個唯讀節點。

  • 唯讀節點發生異常時,高可用系統會暫停異常節點的服務,重新掛載一個可用的唯讀節點。該過程涉及資源分派、執行個體建立資料同步以及服務載入,消耗的時間與業務負載及資料量有關。雲資料庫 Tair(相容 Redis)不承諾唯讀節點的恢復指標。

  • 由於多可用性區域讀寫分離的最低要求是主可用性區域必須具備1個主節點和1個唯讀節點,當為多可用性區域標準架構(主可用性區域1個主節點、備可用性區域1個備節點)執行個體開啟讀寫分離時,請您先為主可用性區域增加1個備節點,確保主可用性區域有2個節點,再開啟讀寫分離。

  • 某些情境會觸發唯讀節點的全量同步,例如在主節點觸發高可用切換後。全量同步期間唯讀節點不提供服務並返回-LOADING Redis is loading the dataset in memory\r\n資訊。

  • 更多關於路由轉寄的規則,請參見Tair Proxy特性說明

前提條件

  • 部署模式為雲原生

  • 執行個體為Redis開源版Tair(企業版)記憶體型、持久記憶體型。

  • 執行個體規格為1 GB及以上。

  • 執行個體類型為高可用。

操作指南

常見問題

  • Q:標準架構開啟讀寫分離後能提升執行個體整體頻寬嗎?

    A:可以。開啟讀寫分離後,執行個體的整體頻寬理論上可達執行個體規格的頻寬 * 總節點數(例如96 MB/s * 3節點 = 288 MB/s )。同時,新增的代理節點會將大部分讀請求轉寄到唯讀節點上,降低主節點的頻寬壓力。然而,實際頻寬受業務請求和用戶端等因素的影響,實際頻寬以壓測結果為準。

  • Q:標準架構開啟讀寫分離後還能變更配置至叢集架構嗎?

    A:可以,請先關閉讀寫分離,再變更配置執行個體架構。

  • Q:如何確認讀寫分離是否已啟用?

    A:您可以訪問執行個體的節點管理頁面,查看讀寫分離選項是否已啟用。

  • Q:為什麼唯讀節點沒有收到讀請求?

    A:在雙可用性區域讀寫分離架構中,主、備可用性區域均有獨立的串連地址,且讀請求僅會路由至本可用性區域的主節點或唯讀節點。若您僅使用主可用性區域串連地址,所有讀請求都不會被路由至備可用性區域的唯讀節點。因此,需要在業務代碼中主動區分主、備可用性區域串連地址,並將備可用性區域的請求指向備可用性區域串連地址,以實現就近訪問和負載平衡。