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

Redis 集群簡(jiǎn)介

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

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

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

一般來(lái)說(shuō)，主 Redis 節(jié)點(diǎn)會(huì)處理 Clients 的讀寫(xiě)操作，而從節(jié)點(diǎn)只處理讀操作。

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

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

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

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

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

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

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

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

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

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

擴(kuò)容集群

為了讓讀者更好的理解上線節(jié)點(diǎn)時(shí)的擴(kuò)容操作，我們通過(guò) Redis Cluster 的命令來(lái)模擬整個(gè)過(guò)程。

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

1) 首先啟動(dòng)一個(gè) Redis 節(jié)點(diǎn)，記為 M4。

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

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

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

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

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

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

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

收縮集群

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

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

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

下線節(jié)點(diǎn)需要將節(jié)點(diǎn)自己負(fù)責(zé)的槽遷移到其他節(jié)點(diǎn)，原理與之前節(jié)點(diǎn)擴(kuò)容的遷移槽過(guò)程一致。

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

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

客戶端路由

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

需要注意的是 Redis 計(jì)算槽時(shí)并非只簡(jiǎn)單的計(jì)算鍵值內(nèi)容，當(dāng)鍵值內(nèi)容包括大括號(hào)時(shí)，則只計(jì)算括號(hào)內(nèi)的內(nèi)容。比如說(shuō)，key 為 user:{10000}:books時(shí)，計(jì)算哈希值只計(jì)算10000。

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

codeclass="hljs">/code>

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

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

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

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

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

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

故障轉(zhuǎn)移

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

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

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

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。