背景

目前的阿里雲redis不管主從版還是叢集規格，slave作為備庫不對外提供服務，只有在發生HA，slave提升為master後才承擔讀寫。這種架構讀寫請求都在master上完成，一致性較高，但效能受到master數量的限制。經常有使用者資料較少，但因為流量或者併發太高而不得不升級到更大的叢集規格。

為滿足讀多寫少的業務場景，最大化節約使用者成本，阿里雲redis推出了讀寫分離規格，為使用者提供透明、高可用、高效能、高靈活的讀寫分離服務。

架構

目前的redis叢集模式有redis-proxy, master,slave, HA等幾個角色，在讀寫分離中，新增readonly slave角色承擔讀流量，slave作為熱備不提供服務，架構上保持對現有叢集規格的相容性。redis-proxy按權重將讀寫請求轉發到master或者某個readonly slave上；HA負責監控DB節點的健康狀態，異常時發起主從切換或重搭readonly slave，並更新路由。

一般來說，根據master和readonly slave的資料同步方式，可以有兩種架構：星型複製，鏈式複製。

星型複製

星型複製就是將所有的readonly slave直接和master保持同步，每個readonly slave之間相互獨立，任何一個節點異常不影響到其他節點，同時因為複製鏈比較短，readonly slave上的複製延遲比較小。

redis是單程序單執行緒模型，主從之間的資料複製也在主執行緒中處理，readonly slave數量越多，資料同步對master的cpu消耗就越嚴重，叢集的寫入效能會隨著readonly slave的增加而降低。此外，星型架構會讓master的出口頻寬隨著readonly slave的增加而成倍增長。master上較高的CPU和網路負載又會抵消掉星型複製延遲較低的優勢。可以看出，星型複製架構會帶來比較嚴重的擴充套件問題，整個叢集的效能會受限於master。

鏈式複製

鏈式複製將所有的readonly slave組織成一個複製鏈，如下圖所示，master只需要將資料同步給slave和複製鏈上的第一個readonly slave。

鏈式複製解決了星型複製的擴充套件問題，理論上可以無限增加readonly slave的數量，隨著節點的增加整個叢集的效能也可以基本上呈線性增長。

鏈式複製的架構下，複製鏈越長，複製鏈末端的readonly slave和master之間的同步延遲就越大，考慮到讀寫分離主要使用在對一致性要求不高的場景下，這個缺點一般可以接受。但是如果複製鏈中的某個節點異常，會導致下游的所有節點資料都會大幅滯後，更加嚴重的是這可能帶來全量同步，並且全量同步將一直傳遞到複製鏈的末端，這會對服務帶來一定的影響，為了解決這個問題，讀寫分離的redis都使用阿里雲優化後的binlog複製版本，最大程度的降低全量同步的概率。

結合上述的討論和比較，redis的讀寫分離選擇鏈式複製的架構。

透明、相容

讀寫分離和普通叢集規格一樣，都使用了redis-proxy做請求轉發，多shard時部分命令使用存在一定的限制，但從主從升級單分片讀寫分離，或者從叢集升級到多分片的讀寫分離叢集可以做到完全相容。

在叢集模式下，有部分命令使用必須限制所有key在同一個slot中。

使用者和redis-proxy建立連線，redis-proxy會識別出客戶端連線傳送過來的請求是讀還是寫，然後按照權重作負載均衡，將請求轉發到後端不同的DB節點中，寫請求轉發給master，讀操作轉發給readonly slave（master預設也提供讀，可以通過權重控制）。

使用者只需要購買讀寫分離規格的例項，直接使用任何客戶端即可直接使用，業務不用做任何修改就可以開始享受讀寫分離服務帶來的巨大效能提升，接入成本幾乎為0。

高可用

高可用模組（HA）監控所有DB節點的健康狀態，為整個例項的可用性保駕護航，master宕機時自動切換到新主。如果某個readonly slave宕機，HA也能及時感知，然後重搭一個新的readonly slave，下線宕機節點。

除HA之外，redis-proxy也能實時感知每個readonly slave的狀態。在某個readonly slave異常期間，redis-proxy會自動降低這個節點的權重，如果發現某個readonly slave連續失敗超過一定次數以後，會暫時遮蔽異常節點，直到異常消失以後才會恢復其正常權重。

redis-proxy和HA一起做到儘量減少業務對後端異常的感知，提高服務可用性。

效能

對於讀多寫少的業務場景，直接使用叢集版本往往不是最合適的方案，現在讀寫分離提供了更多的選擇，業務可以根據場景選擇最適合的規格，充分利用每一個readonly slave的資源。

目前單shard對外售賣1master + 1/3/5 readonly slave多種規格（如果有更大的需求可以提工單反饋給我們），提供60W qps 和 192MByte/s的服務能力，在完全相容所有命令的情況下突破單機的資源限制。後續將去掉規格限制，讓使用者根據業務流量隨時自由的增加或減少readonly slave數量。

其他

redis主從非同步複製，從readonly slave中可能讀到舊的資料，使用讀寫分離需要業務可以容忍一定程度的資料不一致，後續將會給客戶更靈活的配置和更大的自由，比如配置可以容忍的最大延遲時間。