Redis如何實現多可用區？
在如今的業務場景下，高可用性要求越來越高，核心業務跨可用區已然成為標配。騰訊雲資料庫高階工程師劉家文結合騰訊雲資料庫的核心實戰經驗，給大家分享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高可用，核心開發有著豐富的經驗。