Redis Cluster數(shù)據(jù)分片機制

Redis 集群簡介

Redis Cluster 是 Redis 的分布式解決方案，在 3.0 版本正式推出，有效地解決了 Redis 分布式方面的需求。

Redis Cluster 一般由多個節(jié)點組成，節(jié)點數(shù)量至少為 6 個才能保證組成完整高可用的集群，其中三個為主節(jié)點，三個為從節(jié)點。三個主節(jié)點會分配槽，處理客戶端的命令請求，而從節(jié)點可用在主節(jié)點故障后，頂替主節(jié)點。

如上圖所示，該集群中包含 6 個 Redis 節(jié)點，3主3從，分別為M1，M2，M3，S1，S2，S3。除了主從 Redis 節(jié)點之間進行數(shù)據(jù)復(fù)制外，所有 Redis 節(jié)點之間采用 Gossip 協(xié)議進行通信，交換維護節(jié)點元數(shù)據(jù)信息。

一般來說，主 Redis 節(jié)點會處理 Clients 的讀寫操作，而從節(jié)點只處理讀操作。

數(shù)據(jù)分片策略

分布式數(shù)據(jù)存儲方案中最為重要的一點就是數(shù)據(jù)分片，也就是所謂的 Sharding。

為了使得集群能夠水平擴展，首要解決的問題就是如何將整個數(shù)據(jù)集按照一定的規(guī)則分配到多個節(jié)點上，常用的數(shù)據(jù)分片的方法有：范圍分片，哈希分片，一致性哈希算法和虛擬哈希槽等。

范圍分片假設(shè)數(shù)據(jù)集是有序，將順序相臨近的數(shù)據(jù)放在一起，可以很好的支持遍歷操作。范圍分片的缺點是面對順序?qū)憰r，會存在熱點。比如日志類型的寫入，一般日志的順序都是和時間相關(guān)的，時間是單調(diào)遞增的，因此寫入的熱點永遠在最后一個分片。

對于關(guān)系型的數(shù)據(jù)庫，因為經(jīng)常性的需要表掃描或者索引掃描，基本上都會使用范圍的分片策略。

Redis Cluster 采用虛擬哈希槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到 0 ~ 16383 整數(shù)槽內(nèi)，計算公式：slot = CRC16(key) 16383。每一個節(jié)點負責維護一部分槽以及槽所映射的鍵值數(shù)據(jù)。

Redis 虛擬槽分區(qū)的特點：

解耦數(shù)據(jù)和節(jié)點之間的關(guān)系，簡化了節(jié)點擴容和收縮難度。節(jié)點自身維護槽的映射關(guān)系，不需要客戶端或者代理服務(wù)維護槽分區(qū)元數(shù)據(jù)支持節(jié)點、槽和鍵之間的映射查詢，用于數(shù)據(jù)路由，在線集群伸縮等場景。

Redis 集群提供了靈活的節(jié)點擴容和收縮方案。在不影響集群對外服務(wù)的情況下，可以為集群添加節(jié)點進行擴容也可以下線部分節(jié)點進行縮容。可以說，槽是 Redis 集群管理數(shù)據(jù)的基本單位，集群伸縮就是槽和數(shù)據(jù)在節(jié)點之間的移動。

下面我們就先來看一下 Redis 集群伸縮的原理。然后再了解當 Redis 節(jié)點數(shù)據(jù)遷移過程中或者故障恢復(fù)時如何保證集群可用。

擴容集群

為了讓讀者更好的理解上線節(jié)點時的擴容操作，我們通過 Redis Cluster 的命令來模擬整個過程。

當一個 Redis 新節(jié)點運行并加入現(xiàn)有集群后，我們需要為其遷移槽和數(shù)據(jù)。首先要為新節(jié)點指定槽的遷移計劃，確保遷移后每個節(jié)點負責相似數(shù)量的槽，從而保證這些節(jié)點的數(shù)據(jù)均勻。

1) 首先啟動一個 Redis 節(jié)點，記為 M4。

2) 使用 cluster meet 命令，讓新 Redis 節(jié)點加入到集群中。新節(jié)點剛開始都是主節(jié)點狀態(tài)，由于沒有負責的>槽，所以不能接受任何讀寫操作，后續(xù)我們就給他遷移槽和填充數(shù)據(jù)。

3) 對 M4 節(jié)點發(fā)送 cluster setslot { slot } importing { sourceNodeId } 命令，讓目標節(jié)點準備導(dǎo)入槽的數(shù)據(jù)。

4) 對源節(jié)點，也就是 M1，M2，M3 節(jié)點發(fā)送 cluster setslot { slot } migrating { targetNodeId } 命令，讓源節(jié)>點準備遷出槽的數(shù)據(jù)。

5) 源節(jié)點執(zhí)行 cluster getkeysinslot { slot } { count } 命令，獲取 count 個屬于槽 { slot } 的鍵，然后執(zhí)行步驟>六的操作進行遷移鍵值數(shù)據(jù)。

6) 在源節(jié)點上執(zhí)行 migrate { targetNodeIp} " " 0 { timeout } keys { key... } 命令，把獲取的鍵通過 pipeline 機制>批量遷移到目標節(jié)點，批量遷移版本的 migrate 命令在 Redis 3.0.6 以上版本提供。

7) 重復(fù)執(zhí)行步驟 5 和步驟 6 直到槽下所有的鍵值數(shù)據(jù)遷移到目標節(jié)點。

8) 向集群內(nèi)所有主節(jié)點發(fā)送 cluster setslot { slot } node { targetNodeId } 命令，通知槽分配給目標節(jié)點。為了>保證槽節(jié)點映射變更及時傳播，需要遍歷發(fā)送給所有主節(jié)點更新被遷移的槽執(zhí)行新節(jié)點。

收縮集群

收縮節(jié)點就是將 Redis 節(jié)點下線，整個流程需要如下操作流程。

1) 首先需要確認下線節(jié)點是否有負責的槽，如果是，需要把槽遷移到其他節(jié)點，保證節(jié)點下線后整個集群槽節(jié)點映射的完整性。

2) 當下線節(jié)點不再負責槽或者本身是從節(jié)點時，就可以通知集群內(nèi)其他節(jié)點忘記下線節(jié)點，當所有的節(jié)點忘記改節(jié)點后可以正常關(guān)閉。

下線節(jié)點需要將節(jié)點自己負責的槽遷移到其他節(jié)點，原理與之前節(jié)點擴容的遷移槽過程一致。

遷移完槽后，還需要通知集群內(nèi)所有節(jié)點忘記下線的節(jié)點，也就是說讓其他節(jié)點不再與要下線的節(jié)點進行 Gossip 消息交換。

Redis 集群使用 cluster forget { downNodeId } 命令來講指定的節(jié)點加入到禁用列表中，在禁用列表內(nèi)的節(jié)點不再發(fā)送 Gossip 消息。

客戶端路由

在集群模式下，Redis 節(jié)點接收任何鍵相關(guān)命令時首先計算鍵對應(yīng)的槽，在根據(jù)槽找出所對應(yīng)的節(jié)點，如果節(jié)點是自身，則處理鍵命令；否則回復(fù) MOVED 重定向錯誤，通知客戶端請求正確的節(jié)點。這個過程稱為 MOVED 重定向。

需要注意的是 Redis 計算槽時并非只簡單的計算鍵值內(nèi)容，當鍵值內(nèi)容包括大括號時，則只計算括號內(nèi)的內(nèi)容。比如說，key 為 user:{10000}:books時，計算哈希值只計算10000。

MOVED 錯誤示例顯示的信息如下，鍵 x 所屬的哈希槽 3999 ，以及負責處理這個槽的節(jié)點的 IP 和端口號 127.0.0.1:6381 。 客戶端需要根據(jù)這個 IP 和端口號， 向所屬的節(jié)點重新發(fā)送一次 GET 命令請求。

codeclass="hljs">/code>

由于請求重定向會增加 IO 開銷，這不是 Redis 集群高效的使用方式，而是要使用 Smart 集群客戶端。Smart 客戶端通過在內(nèi)部維護 slot 到 Redis 節(jié)點的映射關(guān)系，本地就可以實現(xiàn)鍵到節(jié)點的查找，從而保證 IO 效率的最大化，而 MOVED 重定向負責協(xié)助客戶端更新映射關(guān)系。

Redis 集群支持在線遷移槽( slot ) 和數(shù)據(jù)來完成水平伸縮，當 slot 對應(yīng)的數(shù)據(jù)從源節(jié)點到目標節(jié)點遷移過程中，客戶端需要做到智能遷移，保證鍵命令可正常執(zhí)行。例如當 slot 數(shù)據(jù)從源節(jié)點遷移到目標節(jié)點時，期間可能出現(xiàn)一部分數(shù)據(jù)在源節(jié)點，而另一部分在目標節(jié)點。

所以，綜合上述情況，客戶端命令執(zhí)行流程如下所示：

• 客戶端根據(jù)本地 slot 緩存發(fā)送命令到源節(jié)點，如果存在鍵對應(yīng)則直接執(zhí)行并返回結(jié)果給客戶端。
• 如果節(jié)點返回 MOVED 錯誤，更新本地的 slot 到 Redis 節(jié)點的映射關(guān)系，然后重新發(fā)起請求。
• 如果數(shù)據(jù)正在遷移中，節(jié)點會回復(fù) ASK 重定向異常。格式如下: ( error ) ASK { slot } { targetIP } : { targetPort }

客戶端從 ASK 重定向異常提取出目標節(jié)點信息，發(fā)送 asking 命令到目標節(jié)點打開客戶端連接標識，再執(zhí)行鍵命令。

ASK 和 MOVED 雖然都是對客戶端的重定向控制，但是有著本質(zhì)區(qū)別。ASK 重定向說明集群正在進行 slot 數(shù)據(jù)遷移，客戶端無法知道什么時候遷移完成，因此只能是臨時性的重定向，客戶端不會更新 slot 到 Redis 節(jié)點的映射緩存。但是 MOVED 重定向說明鍵對應(yīng)的槽已經(jīng)明確指定到新的節(jié)點，因此需要更新 slot 到 Redis 節(jié)點的映射緩存。

故障轉(zhuǎn)移

當 Redis 集群內(nèi)少量節(jié)點出現(xiàn)故障時通過自動故障轉(zhuǎn)移保證集群可以正常對外提供服務(wù)。

當某一個 Redis 節(jié)點客觀下線時，Redis 集群會從其從節(jié)點中通過選主選出一個替代它，從而保證集群的高可用性。這塊內(nèi)容并不是本文的核心內(nèi)容，感興趣的同學可以自己學習。

但是，有一點要注意。默認情況下，當集群 16384 個槽任何一個沒有指派到節(jié)點時整個集群不可用。執(zhí)行任何鍵命令返回 CLUSTERDOWN Hash slot not served 命令。當持有槽的主節(jié)點下線時，從故障發(fā)現(xiàn)到自動完成轉(zhuǎn)移期間整個集群是不可用狀態(tài)，對于大多數(shù)業(yè)務(wù)無法忍受這情況，因此建議將參數(shù) cluster-require-full-coverage 配置為 no ，當主節(jié)點故障時只影響它負責槽的相關(guān)命令執(zhí)行，不會影響其他主節(jié)點的可用性。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。