針對讀多寫少的業務情境，雲原生記憶體資料庫Tair推出了讀寫分離架構，提供高可用、高效能、靈活的讀寫分離服務，滿足熱點資料集中及高並發讀取的業務需求。同時，讀寫分離架構執行個體由阿里雲Tair團隊自研的Proxy組件進行資料分發、故障切換等服務，為您降低了營運成本。
組件介紹
讀寫分離架構主要由主節點、唯讀節點、代理節點（Proxy）和高可用系統等組成，架構圖如下。
圖 1. 雲原生版讀寫分離架構
圖 2. 經典版讀寫分離架構（已停售）
組件 | 雲原生版讀寫分離架構（推薦） | 經典版讀寫分離架構 |
主節點（Master node） | 承擔寫請求的處理，同時和唯讀節點共同承擔讀請求的處理。 | |
唯讀節點（Read replicas） | 承擔讀請求的處理，特點如下：
| 承擔讀請求的處理，特點如下：
|
備節點（Replica node） | 無冷備節點，任一隻讀節點均可作為備節點。當主節點發生異常時，可以將請求切換至任一隻讀節點。 由於無需該組件，在同樣效能下，雲原生讀寫分離架構的價格更低。 | 冷備節點，作為資料備份使用，不對外提供服務。當主節點發生異常時，會將請求切換至該節點。 |
代理節點（Proxy server） | 用戶端和代理節點建立串連後，代理節點會自動識別用戶端發起的請求類型，按照權重分發流量（各節點權重相同，且不支援自訂權重），將請求轉寄到不同的資料節點中。例如將寫請求轉寄給主節點，將讀請求轉寄給主節點和唯讀節點。 說明
| |
高可用系統（HA system） | 自動監控各節點的健康狀態，異常時發起主備切換或重搭唯讀節點，並更新相應的路由及權重資訊。 | |
特點
透明相容
標準架構可以直接升級到讀寫分離架構，由於讀寫分離架構使用Proxy server進行轉寄，在升級後，您可以直接使用支援Redis的任何用戶端訪問讀寫分離架構執行個體，無需進行業務改造。讀寫分離架構完全相容Redis協議命令，但部分命令存在一些限制，更多資訊請參見讀寫分離架構命令限制。
高可用
通過阿里雲自研的高可用系統自動監控所有資料節點的健康狀態，為整個執行個體的可用性保駕護航。主節點不可用時自動選擇新的主節點並重新搭建複寫拓撲。某個唯讀節點異常時，高可用系統能夠自動探知並重新啟動新節點完成資料同步，下線異常節點。
代理節點會即時感知每個唯讀節點的服務狀態。在某個唯讀執行個體異常期間，代理節點會自動降低該節點的服務權重，發現唯讀節點連續失敗超過一定次數以後，會停止異常節點的服務權利，並具備繼續監控後續重新啟動節點服務的能力。
高效能
讀寫分離架構可以通過擴充唯讀執行個體個數使整體執行個體效能呈線性增長，同時基於源碼層面對Redis複製流程的定製最佳化，可以最大程度地提升線性複製的系統穩定性，充分利用每一個唯讀節點的實體資源。
使用情境
讀取請求QPS（Queries Per Second）壓力較大的情境。
Tair標準架構無法支撐較大的QPS，如果業務類型是讀多寫少類型，需要採用多個唯讀節點的部署方式來突破單節點的效能瓶頸，相比標準版最高可以將QPS提升近9倍。
由於資料同步至唯讀節點存在一定延遲，選用此架構時，業務需要能接受一定程度的髒資料。如果對資料一致性要求較高，推薦選用叢集架構。
建議與使用須知
當一個唯讀節點發生故障時，請求會轉寄到其他節點；如果所有隻讀節點均不可用，請求會全部轉寄到主節點。唯讀節點異常可能導致主節點負載提高、回應時間變長，因此在讀負載高的業務情境建議使用多個唯讀節點。
唯讀節點發生異常時，高可用系統會暫停異常節點的服務，重新掛載一個可用的唯讀節點。該過程涉及資源分派、執行個體建立資料同步以及服務載入，消耗的時間與業務負載及資料量有關。雲原生記憶體資料庫Tair不承諾唯讀節點的恢復指標。
某些情境會觸發唯讀節點的全量同步，例如在主節點觸發高可用切換後。全量同步期間唯讀節點不提供服務並返回
-LOADING Redis is loading the dataset in memory\r\n資訊。更多關於路由轉寄的規則，請參見Tair Proxy特性說明。