在如今的業務場景下，高可用性要求越來越高，核心業務跨可用區已然成為標配。騰訊雲資料庫高級工程師劉家文結合騰訊雲資料庫的內核實戰經驗，給大家分享Redis是如何實現多可用區，內容包含Redis主從版、集群版原生架構，騰訊雲Redis集群模式主從版、多AZ架構實現以及多AZ關鍵技術點，具體可分為以下四個部分：

第一部分：介紹Redis的原生架構，包含主從版及集群版；

第二部分：介紹騰訊雲Redis架構，為瞭解決主從架構存在的問題，騰訊雲使用了集群模式的主從版。其次為了更好的適應雲上的Redis架構，引入了Proxy；

第三部分：分析原生Redis為何不能實現多AZ架構的高可用以及騰訊雲是如何實現多可用區；

第四部分：分享實現多可用區的幾個關鍵技術點，包含節點部署、就近接入及節點的選主機制。

點擊觀看視頻

Redis原生架構

Redis的原生架構包含主從版及集群版。主從版是由一個master，多個slave組成。主從的高可用一般採用哨兵模式。哨兵模式在節點故障後，能自動把相應的節點進行下線處理，但是哨兵模式無法補節點。為了配合補從，需要管控組件進行協助，因此一般會將監控組件和管控組件配合完成主從版的一個高可用。無論是哪種方式，主從版的可用性依賴外部的仲裁組件，存在恢復時間長及組件本身的高可用問題。其次主從版還會導致雙寫的問題及提主有損的功能缺陷。

Redis的集群版中的每一個節點相互獨立，節點之間通過Gossip協議來進行通信，每一個節點都保存了集群中所有節點的一個信息。集群版的數據基於slot進行分片管理，slot總共有16384個，節點的 slot並不是固定的，可以通過搬遷key的方案來完成slot的遷移，有了slot的搬遷功能，集群版可以實現數據均衡及分片的動態調整。

Redis集群版內部集成了Gossip協議，通過Gossip協議能完成節點的自動發現和自動成災的功能。自動發現是指一個節點要加入到集群中，只需要加入集群中的任何一個節點，加入後，新節點的信息會通過Gossip推廣到集群中的所有的節點。同理，當一個節點故障後，所有節點都會把故障信息發送給集群其它節點，通過一定的判死邏輯，它會讓這個節點進行自動下線，這個也就是Redis集群版的自動容災功能。

為了說明單可用區是如何部署的，我們需要進一步瞭解Redis集群版的自動容災。自動容災總共分為兩個步驟，第一個就是我們的判死邏輯，當超過一半的主節點認為該節點故障，集群就會認為這個節點已經故障。此時從節點會發起投票，超過一半的主節點授權該節點為主節點時，它會將角色變為主節點，同時廣播角色信息。

根據上面這兩點分析，不難發現Redis集群版有兩個部署要求，一個是主從不能同機，當主從同機的機器故障後，整個分片就相當於已經故障了，集群也就變為一個不可用的狀態。其次是我們的節點數不能超過分片數的一半，這裡要註意的是節點數，而不是只限制主節點數。

上圖的右邊部分是錯誤部署方式，在集群節點狀態沒有變化的情況下，是能夠滿足高可用的，但集群的主從發生切換後，一個機器上的主節點已經超過大多數，而這個大多數機器故障後，集群無法自動恢復。因此三分三從的集群版，要滿足高可用總共需要六台機器。

騰訊雲Redis架構

為瞭解決雙主的問題及支持無損提主的操作，騰訊雲上使用了集群模式的主從版。實現集群模式的主從版，先要解決三個問題：

第一個是集群模式需要至少3個投票（仲裁）節點的問題，由於主從版本只有一個Master，為了達到3個仲裁節點，我們引入了兩個Arbiter節點，Arbiter只有投票權，不存儲數據，通過這個改造後，就能夠滿足了集群版的高可用。

第二個是多DB問題，由於騰訊雲上引入了Proxy，減少了對多DB管理的複雜，因此可以放開單DB限制。

最後一個是需要啟用跨slot訪問，在主從版中，所有的slot都在一個節點上面，不存在跨節點問題，因此可以取消跨slot限制。

解決完這幾個主要問題後，集群模式可以達到完全相容主從版，同時擁有集群版的自動容災、無損提主及可以在業務支持的情況下，無縫升級為集群版。

由於Client版本比較多，為了相容不同的Client，騰訊雲引入了Proxy。Proxy除了屏蔽Client的差異外，也屏蔽的後端Redis的版本差異，業務可以使用主從版的Client去使用後端的集群版。Proxy也補齊了Redis缺少的流量隔離及支持更豐富的指標監控，還能將多個連接的請求轉換為pipeline請求轉發到後端，提升Redis的性能。

Redis的多AZ架構

部署高可用的多可用區架構，需要至少滿足兩個條件：

主從不能部署到同一個可用區；

一個可用區的節點數不能超過分片數的一半。

如果我們部署一個三分片的實例，那應該需要個6個可用區才能真正保證它的高可用。即使可用區充足，它也會有性能的抖動，訪問本可用區，性能和單可用區相同，但如果跨可用區訪問，至少出現2ms延遲，因此原生的Redis是不適合多可用區的部署，為了實現高可用的部署，我們需要更深入的分析它的問題所在。這種場景的高可用不滿足主要是由於主節點漂移，而投票權和主節點又是綁定關係。當投票權在不同可用區間切換後，導致超過大多數投票節點在該可用區，此時該可用區故障後就會出現集群無法恢復的情況。

從上面分析可以看出，高可用的問題是由於投票權發生漂移導致的。假如能把投票權固定在某些節點上面，這樣投票權就可以不再漂移。當然這裡無法將投票權固定在從或者主節點上，對於多可用區，最好的方式就是引入了一個ZoneArbiter節點，它只做節點的判死及選主，不存儲任何數據。這樣投票權就從存儲節點中分離出來。在投票權分離後，即使數據節點的Master可以位於一個可用區，從位於不同的可用區也能滿足高可用。業務在主可用區中訪問和單可用區訪問性能是相同的。

多AZ的關鍵技術

保證高可用後，接下來介紹多可用區的三個關鍵的點：高可用如何部署、性能如何達到最優、可用區故障後保證集群自動恢復。

節點部署同樣需要滿足兩個點：第一是主從不能同可用區，這個比較容易滿足，只要有2個可用區即可，第二點是至少三個ZoneArbiter節點位於不同的可用區，第二個條件需要三個可用區，如果沒有三個可用區的地域也可以將ZoneArbiter部署於就近的地域，因為數據節點和仲裁節點是分離的，位於其它可用區的節點只會出現判死及提主有毫秒級延遲，對性能和高可用不會有任何影響。

分析完部署後，再來看下數據的存儲鏈路，存儲鏈路分為讀和寫鏈路，寫鏈路是從client到LB，再到Proxy，最後將數據寫入到相應的Master。在讀的時候，開啟就近讀的特性後，鏈路從client到LB，再到Proxy，最後選擇一個就近的節點讀取數據。就近路徑選擇包含LB的就近選擇及Proxy的就近選擇，LB要根據Client的地址選擇相對應的Proxy。如果是讀，Proxy要跟據自身所在可用區信息選擇同可用區的節點進行讀訪問。如果是寫，Proxy需要訪問主可用區的Master節點。能實現就近訪問，最關鍵的一個點就是要LB及Proxy要存儲相關後端的可用區信息，有這些信息後，就能實現就近的路由選擇。

單可用區和多可用區故障的最大區別是：首先多可用區的某一節點故障後，主節點有可能切到其它可用區會導致性能波動。其次對於多可用區的實例，整個可用區故障後，需要投票的節點比單可用區的節點多。在多節點故障的場景測試中，128分片，63節點同時故障，99%以上都無法正常恢復集群。而無法恢復的關鍵就是Redis的選主機制導致。因此我們需要更深入的理解Redis的選主機制。

首先看下選主機制的授權機制，當主節點收到一個failover信息後，核對自身節點為Master，然後檢查投票的這個節點集群的epoch是不是最新的，並且在這個epoch，並沒有投票任何的節點，為了防止一個節點的多個從節點重覆發起投票，這裡在30s內不允許重覆發起。最後再核對這個slot的歸屬權是否屬於發起failover的這個節點，如果都沒有問題，那麼就會投票給該節點。

綜上，允許該主節點投票的條件是：

• 發起投票的節點的集群信息是最新的；
• 一個epoch只能授權一個節點；
• 30s內同一分片只能授權一次；
• slot的歸屬權正確。

看完主節點的授權機制後，再看下從節點發起投票的機制。發起投票的流程是先核對1分鐘內沒有發起過投票，再核對該節點數據是否有效（不能和主斷開160s）。從節點是有效的，就開始計算發起投票的時間，當投票時間到後，將集群的epoch+1，然後再發起failover，如果主節點的授權超過分片數的一半，則自身提為主節點，並廣播節點信息。這裡從節點投票有兩個關鍵的點，一分鐘只能重試一次投票，最大重試160s，從節點最多可以投票3次。當超過一半的master授權提主，提主成功，否則超時。

在某一主節點故障後，集群的選主儘量在同可用區中選擇。一個分片不同從節點之間的選主時間由節點的offset排名及的500ms的隨機時間決定。在寫少讀多情況下，offset排名大多時間是相同的。在單可用區場景下，隨機選擇一個節點本身無任何影響，但多可用區就會出現性能的抖動。因此這個就需要在排名中引入同可用區的排名。而同可用區的排名就需要要每個節點都知道所有節點的可用區信息。在Gossip中剛好有一個預留欄位，我們將可用區信息存儲在這個預留欄位中，然後將這個節點的可用區信息會廣播到所有節點中，這樣每個節點都有所有節點的可用區信息。在投票的時候我們按照offset和可用區信息排名綜合考慮來保證同可用區優先提主。

一個節點的選主分析完後，我們來分析下多節點故障的投票時機。多個節點發起投票時，會隨機選擇500毫秒內的一個時間點，然後發起投票。假如集群有100個主節點，500毫秒發起完投票，每個節點投票時間是5毫秒，5毫秒肯定是不夠一個投票周期。在之前的多節點故障投票成功率測試結果也就證明瞭這種情況幾乎不能成功。

投票不能成功的關機是集群不同節點投票是隨機發起導致的，既然隨機存在衝突，最直接的解決辦法就是按順序來投票。按順序投票可以簡單分為兩種，一種是依賴外部的控制，引入外部依賴就需要保證它的高可用，一般情況下，存儲鏈路的高可用最好不要依賴外部組件，否則會導致整體的可用性受外部組件加存儲節點的高可用的影響。那再考慮下集群內部實現順序投票，集群內部實現順序投票也有兩種方式，一個是仲裁節點按順序來授權。但是這種方式很容易打破一個epoch投一個從節點的原則，打破後可能會導致投票結果不符合預期。還有一種解決辦法是由從節點來順序發起投票。

從節點要保證順序發起投票，那就需要每個節點的排名是保證相同的，而節點ID在生命周期中是唯一的，且每個節點都有其它節點的ID信息，因此這裡選擇節點ID的排名是比較好的一種方案，每個從節點ID發起投票前，首先核對自己的節點ID是不是第一名，如果是就發起投票，如果不是就等待500ms。這個500ms是為了防止隊頭投票失敗的場景。按這種方式優化後，投票都可以成功。由於本身是分散式的，這裡還是存在著小概率失敗，在失敗後就需要外部監控，強行提主，保證集群的儘快恢復。

專家答疑

1.通過sentinel連接redis也會出現雙寫麽？

答：雙寫是對存量的連接來說的，如果存量的連接沒有斷開，它會寫入到之前的master節點，而新的連接會寫入到新的master節點，此時就是雙寫。而集群模式出現雙寫最多15s（判死時間），因為15s後發現自身已經脫離大多數，會將節點切換為集群Fail，此時寫入及讀取出錯，而規避了雙寫的問題。

2. 固定節點投票，這幾個節點會不會成為單點

答：單點是不可規避的，比如1主1從，主掛了，那麼從提主後，這個節點就是單點，出現單點是需要我們進行補從操作。而這裡仲裁節點出現故障，補充一個節點即可，只要保證大多數仲裁節點正常工作即可，由於仲裁和數據訪問是分離的，故障及補節點對數據訪問無任何影響。

3. 整個可用區故障和可用區內節點故障failover的處理策略是什麼？

答：不管是整個可用區故障還是單機故障導致的多節點故障，都應該採用順序投票來完成，減少衝突，而如果同可用區有從節點，該節點應該優先提主。

4.想問下寫請求，要同步等從複製完嗎？

答：Redis不是強同步，Redis強同步需要使用wait命令來完成。

5.最大支持多少redis分片呢，節點多了使用gossip有會不會有性能問題？

答：最好不要超過500個，超過500個節點會出現ping導致的性能抖動，此時只能通過調大cluster_node_timeout來降低性能抖動

6.多區主節點，寫同步如何實現？

答：可能想問的是全球多活實例，多活實例一般需要數據先落盤，然後再同步給其它節點，同步的時候要保證從節點先收到數據後，才能發送給多活的其它節點。還需要解決數據同步環路，數據衝突等問題。

7.當前選主邏輯和raft選主有大的區別嗎？

答：相同的點都需要滿足大多數授權，都有一個隨機選擇時間，不同的點Redis是主節點有投票權（針對多分片情況），而raft可認為是所有節點（針對單分片情況）。Raft數據寫入要超一半節點成功才返回成。Redis使用弱同步機制（可以使用wait強勢主從同步完返回），寫完主節點立即返回，在主故障後，需要數據越新的節點優先提主（數據偏移值由Gossip通知給其它節點），但不保證它一定成功。

關於作者

劉家文，騰訊雲資料庫高級工程師，先後負責Linux內核及redis相關研發工作，目前主要負責騰訊雲資料庫Redis的開發和架構設計，對Redis高可用，內核開發有著豐富的經驗。