緩存成神路：Redis讀寫分離難以理解？一文解析Redis讀寫分離技術

背景
云數據庫Redis版不管主從版還是集群規格，replica作為備庫不對外提供服務，只有在發生HA的時候，replica提升為master后才承擔讀寫流量。這種架構讀寫請求都在master上完成，一致性較高，但性能受到master數量的限制。經常有用戶數據較少，但因為流量或者并發太高而不得不升級到更大的集群規格。

為滿足讀多寫少的業務場景，最大化節約用戶成本，云數據庫Redis版推出了讀寫分離規格，為用戶提供透明、高可用、高性能、高靈活的讀寫分離服務。

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

一般來說，根據master和read-only replica的數據同步方式，可以分為兩種架構：星型復制和鏈式復制。

星型復制

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

Redis是單進程單線程模型，主從之間的數據復制也在主線程中處理，read-only replica數量越多，數據同步對master的CPU消耗就越嚴重，集群的寫入性能會隨著read-only replica的增加而降低。此外，星型架構會讓master的出口帶寬隨著read-only replica的增加而成倍增長。Master上較高的CPU和網絡負載會抵消掉星型復制延遲較低的優勢，因此，星型復制架構會帶來比較嚴重的擴展問題，整個集群的性能會受限于master。

?

鏈式復制

鏈式復制將所有的read-only replica組織成一個復制鏈，如下圖所示，master只需要將數據同步給replica和復制鏈上的第一個read-only replica。

鏈式復制解決了星型復制的擴展問題，理論上可以無限增加read-only replica的數量，隨著節點的增加整個集群的性能也可以基本上呈線性增長。

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

?

結合上述的討論和比較，Redis讀寫分離選擇鏈式復制的架構。

Redis讀寫分離優勢
透明兼容

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

用戶和redis-proxy建立連接，redis-proxy會識別出客戶端連接發送過來的請求是讀還是寫，然后按照權重作負載均衡，將請求轉發到后端不同的DB節點中，寫請求轉發給master，讀操作轉發給read-only replica（master默認也提供讀，可以通過權重控制）。

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

高可用

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

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

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

高性能

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

目前單shard對外售賣1 master + 1/3/5 read-only replica多種規格（如果有更大的需求可以提工單反饋），提供60萬QPS和192 MB/s的服務能力，在完全兼容所有命令的情況下突破單機的資源限制。后續將去掉規格限制，讓用戶根據業務流量隨時自由的增加或減少read-only replica數量。

?

后續
Redis主從異步復制，從read-only replica中可能讀到舊的數據，使用讀寫分離需要業務可以容忍一定程度的數據不一致，后續將會給客戶更靈活的配置和更大的自由，比如配置可以容忍的最大延遲時間。

剛剛入駐頭條，有不對的地方可以在評論區留言，覺得不錯的朋友希望能得到您的轉發支持，同時可以持續關注我，每周定期會分享3到4篇精選干貨！歡迎工作一到五年的Java工程師朋友們加入JavaQQ群：×××，群內提供免費的Java架構學習資料（里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
————————————————
版權聲明：本文為CSDN博主「于憶」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_45074063/article/details/102589101