一文讀懂 Redis 分散式部署方案

木石頭發表於2020-07-01

為什麼要分散式

Redis是一款開源的基於記憶體的K-V型資料庫,因為記憶體訪問速度快,一般被用來做系統的快取。

Redis作為單機部署能夠支援業務簡單,資料量不大的系統需求,但在實際應用中,一旦系統規模上來,單機的Redis就會遇到下面的挑戰:

  • 伸縮性。系統隨著長期執行與業務增長,對Redis儲存的資料量需求也越來越大,單機必然受限於伺服器的記憶體與磁碟大小。
  • 高效能。系統規模變大後,對Redis的吞吐量需求也會提高,而單機的吞吐量必然有限,這種情況會影響整體系統的效能。
  • 高可用。Redis持久化機制一定程度上能緩解單點問題,但是需要花費時間去恢復,在恢復的過程中服務可能不可用,或者資料會有丟失。

分散式解決方案

分散式的解決方案對於業內是通用的:

  • 水平拆分。單點的一個重要挑戰就是資料量大的時候單點儲存不夠。直接的想法就是部署多個例項,將需要儲存的資料分散儲存到各個例項中。當例項儲存空間不夠時,繼續擴大例項個數就可以解決資料伸縮性問題。同時這種資料水平拆分的方法也可以解決單機效能問題,因為不同的資料讀寫可以分配到不同的例項。
  • 主從複製。如果只有水平拆分,如果其中一個例項出現了問題,那該例項上儲存的資料都不可訪問,還是存在可用問題。為此可以進行所有資料的主備複製,同一份資料可以有多個副本,當某個例項出現問題時,可以啟用該例項的副本,達到高可用的目的。同時副本也可以幫助提高系統的吞吐能力,因為對資料的訪問也可以分發到副本上。

儲存的分散式解決方案大抵如上,不同的是各種系統的實現方法不同。下面我們來看下Redis的分散式解決方案是怎樣的。

歷史發展

分散式解決方案不是一蹴而就的,也有個發展的過程,不同歷史時期提供的方案可能不同,最新的解決方案也可能在不遠的將來被替換。

主從複製(replication)是Redis分散式的基礎。Redis中包含兩種節點:master節點與slave節點。同一份資料存放在master與多個slave節點上,
master對外提供讀寫,slave不對外提供寫操作。當master當機時,slave節點還能繼續提供服務。主從複製中最重要的就是主從資料如何同步。

Redis的主從同步分為全量同步與增量同步,在下面的章節會詳細介紹。

如果只有主從複製,當master當機時,需要運維人工將slave節點切換成master。這在生產環境是不可接受的,在這過程中系統可能無法使用。所以需要有一個機制,當master當機時能自動進行主從切換,應用程式無感知,繼續提供服務。於是Redis官方提供了一種方案: Redis Sentinel(哨兵模式)。

簡單的說,哨兵模式就是在主從基礎上增加了哨兵節點,哨兵節點不儲存業務資料,它負責監控主從節點的健康,當主節點當機時,它能及時發現,並自動選擇一個從節點,將其切換成主節點。為了避免哨兵本身成為單點,哨兵一般也由多個節點組成。

主從複製與哨兵模式解決了高可用問題,但資料的伸縮性還不行,還需要進行水平拆分。而這個時期大資料高併發的需求在快速增長,哪裡有需求,哪裡就有市場。在Redis官方自己的叢集方案出來之前,Codis應運而生並得到快速發展。

Codis是中國人開發並開源的,來自前豌豆莢中介軟體團隊。Codis和後面的Redis Cluster相似,將特定的key分發到特定的Redis例項上,預設將key化為1024個槽位;另外Codis採用zookeeper來維護節點間資料的一致性;更方便的是Codis提供了非常友好的後臺管理介面。更深入的大家可以自行去了解。但是當Redis官方的叢集方案 Redis Cluster 釋出後,Codis的境遇就有些尷尬了。畢竟不是親生的,很多新的特性總比Redis官方慢一拍。

正是因為分散式是剛需,所以Redis官方在3.0版本推出了自己的分散式方案,這就是Redis Cluster。這個名詞可能有些歧義,它不是簡單地代表Redis叢集,而是Redis的一種分散式方案,該方案的名稱就叫Redis Cluster。下面我們就重點介紹下該方案。

Redis Cluster

Redis Cluster 提供了一種去中心化的分散式方案,該方案可以實現水平拆分,故障轉移等需求。

拓撲結構

一個Redis Cluster由多個Redis節點組成,這裡的節點指的是Redis例項,一臺伺服器上可能有多個例項。這些節點可按節點組劃分,每個節點組裡的節點存放相同的資料,裡面有且只有一個是master節點,同時有0到多個slave節點。不同節點組存放的資料沒有交集,而所有節點組的資料組成這個Redis Cluster的全部資料集合。

一文讀懂 Redis 分散式部署方案

如圖所示,這裡有3臺伺服器,每臺伺服器上有2個 Redis 例項。標號相同的節點組成一個節點組,他們存放相同的資料,如標號為1的2個節點組成一個節點組,其中深色的為master節點,另外一個為slave節點。也就是全量資料被劃分為3份,分別標號1/2/3。每份資料又有1個 slave 節點,他們通過主從複製儲存和 master 節點相同的資料。這裡主要有兩方面:一是主從複製,二是資料橫向劃分,在 Redis 中稱為分片 Sharding。

主從複製 Replication

主從節點最重要的是如何保證主從節點資料的一致性。只有 master 節點提供資料的寫操作,資料被寫到 master 節點後,再同步到 slave 節點。

主從之間的資料同步可以分為全量同步與增量同步。

全量同步

全量同步也稱為快照同步,主節點上進行一次 bgsave 操作,將當前記憶體的資料全部快照寫到磁碟檔案中,然後將檔案同步給從節點。從節點清空當前記憶體全部資料後全量載入該檔案,這樣達到與主節點資料同步的目的。

但是在從節點載入快照檔案的過程中,主節點還在對外提供寫服務。所以當從節點載入完快照後,依舊可能與主節點資料不一致,這時就需要增量同步上場了。

增量同步

增量同步的不是資料,而是指令流。主節點會將對當前資料狀態產生修改的指令記錄在記憶體的一個buffer中,然後非同步地將buffer同步到從節點,從節點通過執行buffer中的指令,達到與主節點資料一致的目的。

一文讀懂 Redis 分散式部署方案

Redis的buffer是一個定長的環形結構,當指令流滿的時候,會覆蓋最前面的內容。所以當從節點上次增量同步由於各種原因,導致花費時間較長時,再次同步指令流時,就有可能前面沒有同步的指令被覆蓋掉了。這種情況就需要進行全量同步了。

所以全量同步與增量同步是相輔相成的關係。全量同步時一個很耗資源與時間的操作,如果單靠全量同步,同步操作會很重,在同步的長時間過程中不能提供服務。而增量同步有buffer容量限制,僅僅靠增量同步可能造成資料丟失,導致主從資料不一致。

分片 Sharding

所謂分片,就是將資料集按照一定規則,分散儲存在各個節點上。這裡涉及兩個問題:

1.分片規則是什麼?

2.如何儲存在各個節點上?

Redis將所有資料分為16384個hash slot(槽),每條資料(key-value)根據key值通過演算法對映到其中一個slot上,這條資料就儲存在該slot中。對映演算法是:

slotId=crc16(key)%16384

Redis的每個key都會基於該分片規則,落到特定的slot上。而在叢集部署完成時,slot的分佈就已經確定了。

172.16.190.78:7001> cluster nodes
08a5e808d2e6f6b231d73519bd4f05f74614c2a2 172.16.190.77:7000@17000 master - 0 1592218859545 3 connected 10923-16383
2c75029ab638a48537a4c02ed0ca77a19fc4106b 172.16.190.78:7000@17000 master - 0 1592218860448 1 connected 0-5460
50884e234c5f1ccf03f5a6d1cc4e6e6dc4779752 172.16.242.36:7000@17000 master - 0 1592218860000 2 connected 5461-10922
d0381ef4aad364c42e08bf1c2d78168f4901bd90 172.16.190.78:7001@17001 myself,slave 08a5e808d2e6f6b231d73519bd4f05f74614c2a2 0 1592218859000 4 connected
e5c154dcf02526b807c67bebf0a63b4c98118ffe 172.16.190.77:7001@17001 slave 50884e234c5f1ccf03f5a6d1cc4e6e6dc4779752 0 1592218861048 6 connected
4a1b49cd77dbd18eba677663777f211be6f68dae 172.16.242.36:7001@17001 slave 2c75029ab638a48537a4c02ed0ca77a19fc4106b 0 1592218860000 5 connected

如上圖,3個master節點,172.16.190.77:7000節點存放10923-16383 slot,172.16.190.78:7000節點存放0-5460 slot,172.16.242.36:7000存放5461-10922 slot。

對於一個穩定的叢集,slot的分佈也是固定的。但在一些情況下,slot的分佈需要發生改變:

  • 新的master加入
  • 節點分組退出叢集
  • slot分佈不均勻

這些情況下就需要進行slot的遷移。slot遷移的觸發與過程控制都是由外部系統完成,Redis只提供能力,但不自動進行slot遷移。

MOVE & ASKING

MOVED/ASKING 類似http的重定向碼3xx,是操作的一種錯誤返回。

當客戶端向某個節點發出指令,該節點發現指令的key對應的slot不在當前節點上,這時Redis會向客戶端傳送一個MOVED指令,告訴它正確的節點,然後客戶端去連這個正確的節點並進行再次操作。如下,15495為key a所在的slot id。

172.16.190.78:7001> get a
(error) MOVED 15495 172.16.190.77:7000

ASKING 是在slot遷移過程中的一種錯誤返回。當某個slot在遷移過程中,客戶端發了一個位於該slot的某個key的操作請求,請求被路由到舊的節點。此時該key如果在舊節點上存在,則正常操作;如果在舊的節點上找不到,那麼可能該key已被遷移到新的節點上,也可能就沒有該key,此時會返回ASKING,讓客戶端跳轉到新的節點上去執行。

MOVED 與 ASKING 的共同點是兩者都是重定向,區別在於 MOVED 是永久重定向,下次對同樣的key
進行操作,客戶端就將請求傳送到正確的節點,而 ASKING 是臨時重定向,它只對這次操作起作用,不會更新客戶端的槽位關係表。

故障恢復

前面提到Redis Cluster是一個去中心化的叢集方案。比如Codis採用zookeeper來維護節點間狀態一致性,Redis哨兵模式是哨兵來管理節點的狀態,這些都是中心化的例子。Redis Cluster沒有專門用於維護節點狀態的節點,而是所有節點通過Gossip協議相互通訊,廣播自己的狀態以及自己對整個叢集認知的改變。

如果一個節點宕掉了,其他節點和它進行通訊時,會發現改節點失聯。當某個節點發現其他節點失聯時,會將這個失聯節點狀態變成PFail(possible fail),並廣播給其他節點。當一個節點收到某個節點PFail的數量達到了主節點的大多數,就標記該節點為Fail,並進行廣播,通過這種方式確認節點故障。

當slave發現其master狀態為Fail後,它會發起選舉,如果其他master節點都同意,則該slave進行從主切換,變成master節點。同時會將自己的狀態廣播給其他節點,達到大家資訊一致性。

根據上面的原理,下面情況下是無法自動從主切換,達到叢集繼續可用目的的,在實際部署時應避免:

  • 如果一個節點組中的master與slave部署在同一伺服器上,當伺服器發生故障時,master與salve同時Fail。
  • 比如總共3個master,其中2個master部署在同一伺服器上,當伺服器發生故障時,這兩個master同時Fail,slave無法完成從主切換,因為PFail的數量無法達到主節點的大多數。

當叢集節點發生變化時,需要將變化同步到客戶端,客戶端才能根據新的叢集拓撲來向正確的節點傳送請求。

比如Redis客戶端Lettuce,在連線配置中配置了多個節點,Lettuce會選擇其中一個可用節點進行連線。在連線斷開之前,如果該節點掛掉,Lettuce不會自動進行節點切換,此時會不斷地拋連線異常,無法繼續讀寫。Lettuce提供了在連線過程中自適應重新整理叢集拓撲,即在連線失敗時自動重新整理,也可以設計定時重新整理。

ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
    .enablePeriodicRefresh(Duration.ofMinutes(10))
    .enableAllAdaptiveRefreshTriggers()
    .adaptiveRefreshTriggersTimeout(Duration.ofSeconds(30)).build();

參考:

1.《深入分散式快取 從原理到實戰》於君澤 曹洪偉 邱碩等著

2.《Redis 深度歷險:核心原理與應用實踐》老錢

3.Redis官網:https://lettuce.io/core/release/reference/index.html


更多分享,? 

相關文章