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