建站
咨詢
售后
建站咨詢
新聞中心
前幾天，一個讀者去面試，面試官就問了他關(guān)于Redis讀寫分離是怎么做的？本來腦子里也有不少知識要講，不過猛的被面試官一問給當場干懵逼了........。
贊皇ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！
成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設,界首企業(yè)網(wǎng)站建設,界首品牌網(wǎng)站建設,網(wǎng)站定制,界首網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,界首網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
這不，昨天晚上他在微信上問我，所以，今天給大家分享一下這方面的知識點。
背景
Redis 不管主從版還是集群規(guī)格，replica作為備庫不對外提供服務，只有在發(fā)生HA的時候，replica提升為master后才承擔讀寫流量。 這種架構(gòu)讀寫請求都在master上完成，一致性較高，但性能受到master數(shù)量的限制 。經(jīng)常有用戶數(shù)據(jù)較少，但因為流量或者并發(fā)太高而不得不升級到更大的集群規(guī)格。
為滿足讀多寫少的業(yè)務場景，最大化節(jié)約用戶成本，云數(shù)據(jù)庫Redis版推出了讀寫分離規(guī)格，為用戶提供透明、高可用、高性能、高靈活的讀寫分離服務
架構(gòu)
Redis集群模式有redis-proxy、master、replica、HA等幾個角色。在讀寫分離實例中，新增read-only replica角色來承擔讀流量，replica作為熱備不提供服務，架構(gòu)上保持對現(xiàn)有集群規(guī)格的兼容性。redis-proxy按權(quán)重將讀寫請求轉(zhuǎn)發(fā)到master或者某個read-only replica上；HA負責監(jiān)控DB節(jié)點的健康狀態(tài)，異常時發(fā)起主從切換或重搭read-only replica，并更新路由。
一般來說，根據(jù)master和read-only replica的數(shù)據(jù)同步方式，可以分為兩種架構(gòu)：星型復制和鏈式復制。
星型復制
星型復制就是將所有的read-only replica直接和master保持同步，每個read-only replica之間相互獨立，任何一個節(jié)點異常不影響到其他節(jié)點，同時因為復制鏈比較短，read-only replica上的復制延遲比較小。
Redis是單進程單線程模型，主從之間的數(shù)據(jù)復制也在主線程中處理，read-only replica數(shù)量越多，數(shù)據(jù)同步對master的CPU消耗就越嚴重，集群的寫入性能會隨著read-only replica的增加而降低。此外，星型架構(gòu)會讓master的出口帶寬隨著read-only replica的增加而成倍增長。Master上較高的CPU和網(wǎng)絡負載會抵消掉星型復制延遲較低的優(yōu)勢，因此，星型復制架構(gòu)會帶來比較嚴重的擴展問題，整個集群的性能會受限于master。
鏈式復制
鏈式復制將所有的read-only replica組織成一個復制鏈，如下圖所示，master只需要將數(shù)據(jù)同步給replica和復制鏈上的第一個read-only replica。
鏈式復制解決了星型復制的擴展問題，理論上可以無限增加read-only replica的數(shù)量，隨著節(jié)點的增加整個集群的性能也可以基本上呈線性增長。
鏈式復制的架構(gòu)下，復制鏈越長，復制鏈末端的read-only replica和master之間的同步延遲就越大，考慮到讀寫分離主要使用在對一致性要求不高的場景下，這個缺點一般可以接受。但是如果復制鏈中的某個節(jié)點異常，會導致下游的所有節(jié)點數(shù)據(jù)都會大幅滯后。更加嚴重的是這可能帶來全量同步，并且全量同步將一直傳遞到復制鏈的末端，這會對服務帶來一定的影響。為了解決這個問題，讀寫分離的Redis都使用阿里云優(yōu)化后的binlog復制版本，最大程度的降低全量同步的概率。
更多關(guān)于Redis技術(shù)棧的學習，可以關(guān)注民工哥技術(shù)之路公眾號，在Redis專欄中查看相關(guān)的技術(shù)文章、面試題及答案，非常詳細，持續(xù)更新中。
Redis讀寫分離優(yōu)勢
透明兼容
讀寫分離和普通集群規(guī)格一樣，都使用了redis-proxy做請求轉(zhuǎn)發(fā)，多分片令使用存在一定的限制，但從主從升級單分片讀寫分離，或者從集群升級到多分片的讀寫分離集群可以做到完全兼容。
用戶和redis-proxy建立連接，redis-proxy會識別出客戶端連接發(fā)送過來的請求是讀還是寫，然后按照權(quán)重作負載均衡，將請求轉(zhuǎn)發(fā)到后端不同的DB節(jié)點中，寫請求轉(zhuǎn)發(fā)給master，讀操作轉(zhuǎn)發(fā)給read-only replica（master默認也提供讀，可以通過權(quán)重控制）。
用戶只需要購買讀寫分離規(guī)格的實例，直接使用任何客戶端即可直接使用，業(yè)務不用做任何修改就可以開始享受讀寫分離服務帶來的巨大性能提升，接入成本幾乎為0。
高可用
高可用模塊（HA）監(jiān)控所有DB節(jié)點的健康狀態(tài)，為整個實例的可用性保駕護航。master宕機時自動切換到新主。如果某個read-only replica宕機，HA也能及時感知，然后重搭一個新的read-only replica，下線宕機節(jié)點。
除HA之外，redis-proxy也能實時感知每個read-only replica的狀態(tài)。在某個read-only replica異常期間，redis-proxy會自動降低這個節(jié)點的權(quán)重，如果發(fā)現(xiàn)某個read-only replica連續(xù)失敗超過一定次數(shù)以后，會暫時屏蔽異常節(jié)點，直到異常消失以后才會恢復其正常權(quán)重。
redis-proxy和HA一起做到盡量減少業(yè)務對后端異常的感知，提高服務可用性。
高性能
對于讀多寫少的業(yè)務場景，直接使用集群版本往往不是最合適的方案 ，現(xiàn)在讀寫分離提供了更多的選擇，業(yè)務可以根據(jù)場景選擇最適合的規(guī)格，充分利用每一個read-only replica的資源。
目前單shard對外售賣1 master + 1/3/5 read-only replica多種規(guī)格（如果有更大的需求可以提工單反饋），提供60萬QPS和192 MB/s的服務能力，在完全兼容所有命令的情況下突破單機的資源限制。后續(xù)將去掉規(guī)格限制，讓用戶根據(jù)業(yè)務流量隨時自由的增加或減少read-only replica數(shù)量。
Redis主從異步復制，從read-only replica中可能讀到舊的數(shù)據(jù)，使用讀寫分離需要業(yè)務可以容忍一定程度的數(shù)據(jù)不一致，后續(xù)將會給客戶更靈活的配置和更大的自由，例如配置可以容忍的最大延遲時間。
本文名稱：面試官：你的Redis怎么做讀寫分離的？
URL分享：http://m.fisionsoft.com.cn/article/dpijhjs.html
