親愛的同學(xué)們，你是否使用過Redis集群呢？那Redis集群的原理又是什么呢？記住下面兩句話：

• Redis Sentinal著眼于高可用，在master宕機(jī)時(shí)會自動將slave提升為master，繼續(xù)提供服務(wù)。
• Redis Cluster著眼于擴(kuò)展性，在單個(gè)redis內(nèi)存不足時(shí)，使用Cluster進(jìn)行分片存儲。

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

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

范圍分片假設(shè)數(shù)據(jù)集是有序，將順序相臨近的數(shù)據(jù)放在一起，可以很好的支持遍歷操作。范圍分片的缺點(diǎn)是面對順序?qū)憰r(shí)，會存在熱點(diǎn)。比如日志類型的寫入，一般日志的順序都是和時(shí)間相關(guān)的，時(shí)間是單調(diào)遞增的，因此寫入的熱點(diǎn)永遠(yuǎn)在最后一個(gè)分片。對于關(guān)系型的數(shù)據(jù)庫，因?yàn)榻?jīng)常性的需要表掃描或者索引掃描，基本上都會使用范圍的分片策略。

我們?yōu)榱藢⒉煌?key 分散放置到不同的 redis 節(jié)點(diǎn)，通常的做法是獲取 key 的哈希值，然后根據(jù)節(jié)點(diǎn)數(shù)來求模，但這種做法有其明顯的弊端，當(dāng)我們需要增加或減少一個(gè)節(jié)點(diǎn)時(shí)，會造成大量的 key 無法命中，這種比例是相當(dāng)高的，所以就有人提出了一致性哈希的概念。

一致性哈希有四個(gè)重要特征：

• 均衡性：也有人把它定義為平衡性，是指哈希的結(jié)果能夠盡可能分布到所有的節(jié)點(diǎn)中去，這樣可以有效的利用每個(gè)節(jié)點(diǎn)上的資源。
• 單調(diào)性：當(dāng)節(jié)點(diǎn)數(shù)量變化時(shí)哈希的結(jié)果應(yīng)盡可能的保護(hù)已分配的內(nèi)容不會被重新分派到新的節(jié)點(diǎn)。
• 分散性和負(fù)載：這兩個(gè)其實(shí)是差不多的意思，就是要求一致性哈希算法對 key 哈希應(yīng)盡可能的避免重復(fù)。

二、Redis的分片機(jī)制

但是：Redis 集群沒有使用一致性hash, 而是引入了哈希槽的概念。

Redis Cluster 采用虛擬哈希槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到 0 ~ 16383 整數(shù)槽內(nèi)，每個(gè)key通過CRC16校驗(yàn)后對16384取模來決定放置哪個(gè)槽(Slot)，每一個(gè)節(jié)點(diǎn)負(fù)責(zé)維護(hù)一部分槽以及槽所映射的鍵值數(shù)據(jù)。

計(jì)算公式：slot = CRC16(key) & 16383。

這種結(jié)構(gòu)很容易添加或者刪除節(jié)點(diǎn)，并且無論是添加刪除或者修改某一個(gè)節(jié)點(diǎn)，都不會造成集群不可用的狀態(tài)。使用哈希槽的好處就在于可以方便的添加或移除節(jié)點(diǎn)。

• 當(dāng)需要增加節(jié)點(diǎn)時(shí)，只需要把其他節(jié)點(diǎn)的某些哈希槽挪到新節(jié)點(diǎn)就可以了；
• 當(dāng)需要移除節(jié)點(diǎn)時(shí)，只需要把移除節(jié)點(diǎn)上的哈希槽挪到其他節(jié)點(diǎn)就行了。

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

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

四、 Redis 集群伸縮的原理

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

1.集群擴(kuò)容

當(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ù)均勻。

• 首先啟動一個(gè) Redis 節(jié)點(diǎn)，記為 M4。
• 使用 cluster meet 命令，讓新 Redis 節(jié)點(diǎn)加入到集群中。新節(jié)點(diǎn)剛開始都是主節(jié)點(diǎn)狀態(tài)，由于沒有負(fù)責(zé)的>槽，所以不能接受任何讀寫操作，后續(xù)我們就給他遷移槽和填充數(shù)據(jù)。
• 對 M4 節(jié)點(diǎn)發(fā)送 cluster setslot { slot } importing { sourceNodeId } 命令，讓目標(biāo)節(jié)點(diǎn)準(zhǔn)備導(dǎo)入槽的數(shù)據(jù)。 >4) 對源節(jié)點(diǎn)，也就是 M1，M2，M3 節(jié)點(diǎn)發(fā)送 cluster setslot { slot } migrating { targetNodeId } 命令，讓源節(jié)>點(diǎn)準(zhǔn)備遷出槽的數(shù)據(jù)。
• 源節(jié)點(diǎn)執(zhí)行 cluster getkeysinslot { slot } { count } 命令，獲取 count 個(gè)屬于槽 { slot } 的鍵，然后執(zhí)行步驟>六的操作進(jìn)行遷移鍵值數(shù)據(jù)。
• 在源節(jié)點(diǎn)上執(zhí)行 migrate { targetNodeIp} " " 0 { timeout } keys { key... } 命令，把獲取的鍵通過 pipeline 機(jī)制>批量遷移到目標(biāo)節(jié)點(diǎn)，批量遷移版本的 migrate 命令在 Redis 3.0.6 以上版本提供。
• 重復(fù)執(zhí)行步驟 5 和步驟 6 直到槽下所有的鍵值數(shù)據(jù)遷移到目標(biāo)節(jié)點(diǎn)。
• 向集群內(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)。

2.集群收縮

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

• 首先需要確認(rèn)下線節(jié)點(diǎn)是否有負(fù)責(zé)的槽，如果是，需要把槽遷移到其他節(jié)點(diǎn)，保證節(jié)點(diǎn)下線后整個(gè)集群槽節(jié)點(diǎn)映射的完整性。
• 當(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ò)容的遷移槽過程一致。

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

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

五、總結(jié)

Redis Cluster 是Redis的集群實(shí)現(xiàn)，內(nèi)置數(shù)據(jù)自動分片機(jī)制，集群內(nèi)部將所有的key映射到16384個(gè)Slot中，集群中的每個(gè)Redis Instance負(fù)責(zé)其中的一部分的Slot的讀寫。集群客戶端連接集群中任一Redis Instance即可發(fā)送命令，當(dāng)Redis Instance收到自己不負(fù)責(zé)的Slot的請求時(shí)，會將負(fù)責(zé)請求Key所在Slot的Redis Instance地址返回給客戶端，客戶端收到后自動將原請求重新發(fā)往這個(gè)地址，對外部透明。一個(gè)Key到底屬于哪個(gè)Slot由crc16(key) % 16384 決定。

面試問題：為什么RedisCluster會設(shè)計(jì)成16384個(gè)槽呢?

這個(gè)問題，作者是給出了回答的！

地址如下:https://github.com/antirez/redis/issues/2576

作者原版回答如下: The reason is:

Normal heartbeat packets carry the full configuration of a node, that can be replaced in an idempotent way with the old in order to update an old config. This means they contain the slots configuration for a node, in raw form, that uses 2k of space with16k slots, but would use a prohibitive 8k of space using 65k slots.At the same time it is unlikely that Redis Cluster would scale to more than 1000 mater nodes because of other design tradeoffs.

So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.

1.如果槽位為65536，發(fā)送心跳信息的消息頭達(dá)8k，發(fā)送的心跳包過于龐大。

如上所述，在消息頭中，最占空間的是myslots[CLUSTER_SLOTS/8]。 當(dāng)槽位為65536時(shí)，這塊的大小是:65536÷8÷1024=8kb因?yàn)槊棵腌?，redis節(jié)點(diǎn)需要發(fā)送一定數(shù)量的ping消息作為心跳包，如果槽位為65536，這個(gè)ping消息的消息頭太大了，浪費(fèi)帶寬。

2.redis的集群主節(jié)點(diǎn)數(shù)量基本不可能超過1000個(gè)。

如上所述，集群節(jié)點(diǎn)越多，心跳包的消息體內(nèi)攜帶的數(shù)據(jù)越多。如果節(jié)點(diǎn)過1000個(gè)，也會導(dǎo)致網(wǎng)絡(luò)擁堵。因此redis作者，不建議redis cluster節(jié)點(diǎn)數(shù)量超過1000個(gè)。 那么，對于節(jié)點(diǎn)數(shù)在1000以內(nèi)的redis cluster集群，16384個(gè)槽位夠用了。沒有必要拓展到65536個(gè)。

3.槽位越小，節(jié)點(diǎn)少的情況下，壓縮率高

Redis主節(jié)點(diǎn)的配置信息中，它所負(fù)責(zé)的哈希槽是通過一張bitmap的形式來保存的，在傳輸過程中，會對bitmap進(jìn)行壓縮，但是如果bitmap的填充率slots / N很高的話(N表示節(jié)點(diǎn)數(shù))，bitmap的壓縮率就很低。 如果節(jié)點(diǎn)數(shù)很少，而哈希槽數(shù)量很多的話，bitmap的壓縮率就很低。

而16384÷8÷1024=2kb，怎么樣，神奇不！

綜上所述，作者決定取16384個(gè)槽，不多不少，剛剛好！

到此這篇關(guān)于為什么RedisCluster設(shè)計(jì)成16384個(gè)槽的文章就介紹到這了,更多相關(guān)RedisCluster 16384槽內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！