综合伊人,久久国产综合,久久成人人人人精品欧

redis cluster

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

自動(dòng)將數(shù)據(jù)進(jìn)行分片，每個(gè)master上放一部分?jǐn)?shù)據(jù)

提供內(nèi)置的高可用支持，部分master不可用時(shí)，還是可以繼續(xù)工作的

支撐N個(gè)redis master node，每個(gè)master node都可以掛載多個(gè)slave node

高可用，因?yàn)槊總€(gè)master都有salve節(jié)點(diǎn)，那么如果mater掛掉，redis cluster這套機(jī)制，就會(huì)自動(dòng)將某個(gè)slave切換成master

Redis cluster集群模式的原理解析

redis cluster vs. replication + sentinal

如果你的數(shù)據(jù)量很少，主要是承載高并發(fā)高性能的場景，比如你的緩存一般就幾個(gè)G，單機(jī)足夠了

replication，一個(gè)mater，多個(gè)slave，要幾個(gè)slave跟你的要求的讀吞吐量有關(guān)系，然后自己搭建一個(gè)sentinal集群，去保證redis主從架構(gòu)的高可用性，就可以了

redis cluster，主要是針對海量數(shù)據(jù)+高并發(fā)+高可用的場景，海量數(shù)據(jù)，如果你的數(shù)據(jù)量很大，那么建議就用redis cluster

數(shù)據(jù)分布算法

hash算法

比如你有 N 個(gè) redis實(shí)例，那么如何將一個(gè)key映射到redis上呢，你很可能會(huì)采用類似下面的通用方法計(jì)算 key的 hash 值，然后均勻的映射到到 N 個(gè) redis上：

hash(key)%N

如果增加一個(gè)redis，映射公式變成了 hash(key)%(N+1)

如果一個(gè)redis宕機(jī)了，映射公式變成了 hash(key)%(N-1)

在這兩種情況下，幾乎所有的緩存都失效了。會(huì)導(dǎo)致數(shù)據(jù)庫訪問的壓力陡增，嚴(yán)重情況，還可能導(dǎo)致數(shù)據(jù)庫宕機(jī)。

一致性hash算法

Redis cluster集群模式的原理解析

一個(gè)master宕機(jī)不會(huì)導(dǎo)致大部分緩存失效，可能存在緩存熱點(diǎn)問題

用虛擬節(jié)點(diǎn)改進(jìn)

Redis cluster集群模式的原理解析

redis cluster的hash slot算法

redis cluster有固定的16384個(gè)hash slot，對每個(gè)key計(jì)算CRC16值，然后對16384取模，可以獲取key對應(yīng)的hash slot

redis cluster中每個(gè)master都會(huì)持有部分slot，比如有3個(gè)master，那么可能每個(gè)master持有5000多個(gè)hash slot

hash slot讓node的增加和移除很簡單，增加一個(gè)master，就將其他master的hash slot移動(dòng)部分過去，減少一個(gè)master，就將它的hash slot移動(dòng)到其他master上去

移動(dòng)hash slot的成本是非常低的

客戶端的api，可以對指定的數(shù)據(jù)，讓他們走同一個(gè)hash slot，通過hash tag來實(shí)現(xiàn)

127.0.0.1:7000>CLUSTER ADDSLOTS 0 1 2 3 4 ... 5000 可以將槽0-5000指派給節(jié)點(diǎn)7000負(fù)責(zé)。

每個(gè)節(jié)點(diǎn)都會(huì)記錄哪些槽指派給了自己，哪些槽指派給了其他節(jié)點(diǎn)。

客戶端向節(jié)點(diǎn)發(fā)送鍵命令，節(jié)點(diǎn)要計(jì)算這個(gè)鍵屬于哪個(gè)槽。

如果是自己負(fù)責(zé)這個(gè)槽，那么直接執(zhí)行命令，如果不是，向客戶端返回一個(gè)MOVED錯(cuò)誤，指引客戶端轉(zhuǎn)向正確的節(jié)點(diǎn)。

redis cluster 多master的寫入

在redis cluster寫入數(shù)據(jù)的時(shí)候，其實(shí)是你可以將請求發(fā)送到任意一個(gè)master上去執(zhí)行

但是，每個(gè)master都會(huì)計(jì)算這個(gè)key對應(yīng)的CRC16值，然后對16384個(gè)hashslot取模，找到key對應(yīng)的hashslot，找到hashslot對應(yīng)的master

如果對應(yīng)的master就在自己本地的話，set mykey1 v1，mykey1這個(gè)key對應(yīng)的hashslot就在自己本地，那么自己就處理掉了

但是如果計(jì)算出來的hashslot在其他master上，那么就會(huì)給客戶端返回一個(gè)moved error，告訴你，你得到哪個(gè)master上去執(zhí)行這條寫入的命令

什么叫做多master的寫入，就是每條數(shù)據(jù)只能存在于一個(gè)master上，不同的master負(fù)責(zé)存儲不同的數(shù)據(jù)，分布式的數(shù)據(jù)存儲

100w條數(shù)據(jù)，5個(gè)master，每個(gè)master就負(fù)責(zé)存儲20w條數(shù)據(jù)，分布式數(shù)據(jù)存儲

默認(rèn)情況下，redis cluster的核心的理念，主要是用slave做高可用的，每個(gè)master掛一兩個(gè)slave，主要是做數(shù)據(jù)的熱備，還有master故障時(shí)的主備切換，實(shí)現(xiàn)高可用的

redis cluster默認(rèn)是不支持slave節(jié)點(diǎn)讀或者寫的，跟我們手動(dòng)基于replication搭建的主從架構(gòu)不一樣的

jedis客戶端，對redis cluster的讀寫分離支持不太好的

默認(rèn)的話就是讀和寫都到master上去執(zhí)行的

如果你要讓最流行的jedis做redis cluster的讀寫分離的訪問，那可能還得自己修改一點(diǎn)jedis的源碼，成本比較高

讀寫分離，是為了什么，主要是因?yàn)橐⒁恢鞫鄰牡募軜?gòu)，才能橫向任意擴(kuò)展slave node去支撐更大的讀吞吐量

redis cluster的架構(gòu)下，實(shí)際上本身master就是可以任意擴(kuò)展的，你如果要支撐更大的讀吞吐量，或者寫吞吐量，或者數(shù)據(jù)量，都可以直接對master進(jìn)行橫向擴(kuò)展就可以了

節(jié)點(diǎn)間的內(nèi)部通信機(jī)制

1、基礎(chǔ)通信原理

（1）redis cluster節(jié)點(diǎn)間采取gossip協(xié)議進(jìn)行通信

跟集中式不同，不是將集群元數(shù)據(jù)（節(jié)點(diǎn)信息，故障，等等）集中存儲在某個(gè)節(jié)點(diǎn)上，而是互相之間不斷通信，保持整個(gè)集群所有節(jié)點(diǎn)的數(shù)據(jù)是完整的

集中式：好處在于，元數(shù)據(jù)的更新和讀取，時(shí)效性非常好，一旦元數(shù)據(jù)出現(xiàn)了變更，立即就更新到集中式的存儲中，其他節(jié)點(diǎn)讀取的時(shí)候立即就可以感知到; 不好在于，所有的元數(shù)據(jù)的跟新壓力全部集中在一個(gè)地方，可能會(huì)導(dǎo)致元數(shù)據(jù)的存儲有壓力

gossip：好處在于，元數(shù)據(jù)的更新比較分散，不是集中在一個(gè)地方，更新請求會(huì)陸陸續(xù)續(xù)，打到所有節(jié)點(diǎn)上去更新，有一定的延時(shí)，降低了壓力; 缺點(diǎn)，元數(shù)據(jù)更新有延時(shí)，可能導(dǎo)致集群的一些操作會(huì)有一些滯后

（2）10000端口

每個(gè)節(jié)點(diǎn)都有一個(gè)專門用于節(jié)點(diǎn)間通信的端口，就是自己提供服務(wù)的端口號+10000，比如7001，那么用于節(jié)點(diǎn)間通信的就是17001端口

每隔節(jié)點(diǎn)每隔一段時(shí)間都會(huì)往另外幾個(gè)節(jié)點(diǎn)發(fā)送ping消息，同時(shí)其他幾點(diǎn)接收到ping之后返回pong

（3）交換的信息

故障信息，節(jié)點(diǎn)的增加和移除，hash slot信息，等等

2、gossip協(xié)議

gossip協(xié)議包含多種消息，包括ping，pong，meet，fail，等等

meet: 某個(gè)節(jié)點(diǎn)發(fā)送meet給新加入的節(jié)點(diǎn)，讓新節(jié)點(diǎn)加入集群中，然后新節(jié)點(diǎn)就會(huì)開始與其他節(jié)點(diǎn)進(jìn)行通信

redis-trib.rb add-node

其實(shí)內(nèi)部就是發(fā)送了一個(gè)gossip meet消息，給新加入的節(jié)點(diǎn)，通知那個(gè)節(jié)點(diǎn)去加入我們的集群

ping: 每個(gè)節(jié)點(diǎn)都會(huì)頻繁給其他節(jié)點(diǎn)發(fā)送ping，其中包含自己的狀態(tài)還有自己維護(hù)的集群元數(shù)據(jù)，互相通過ping交換元數(shù)據(jù)

每個(gè)節(jié)點(diǎn)每秒都會(huì)頻繁發(fā)送ping給其他的集群，ping，頻繁的互相之間交換數(shù)據(jù)，互相進(jìn)行元數(shù)據(jù)的更新

pong: 返回ping和meet，包含自己的狀態(tài)和其他信息，也可以用于信息廣播和更新

fail: 某個(gè)節(jié)點(diǎn)判斷另一個(gè)節(jié)點(diǎn)fail之后，就發(fā)送fail給其他節(jié)點(diǎn)，通知其他節(jié)點(diǎn)，指定的節(jié)點(diǎn)宕機(jī)了

3、ping消息深入

ping很頻繁，而且要攜帶一些元數(shù)據(jù)，所以可能會(huì)加重網(wǎng)絡(luò)負(fù)擔(dān)

每個(gè)節(jié)點(diǎn)每秒會(huì)執(zhí)行10次ping，每次會(huì)選擇5個(gè)最久沒有通信的其他節(jié)點(diǎn)

當(dāng)然如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)通信延時(shí)達(dá)到了cluster_node_timeout / 2，那么立即發(fā)送ping，避免數(shù)據(jù)交換延時(shí)過長，落后的時(shí)間太長了

比如說，兩個(gè)節(jié)點(diǎn)之間都10分鐘沒有交換數(shù)據(jù)了，那么整個(gè)集群處于嚴(yán)重的元數(shù)據(jù)不一致的情況，就會(huì)有問題

所以cluster_node_timeout可以調(diào)節(jié)，如果調(diào)節(jié)比較大，那么會(huì)降低發(fā)送的頻率

每次ping，一個(gè)是帶上自己節(jié)點(diǎn)的信息，還有就是帶上1/10其他節(jié)點(diǎn)的信息，發(fā)送出去，進(jìn)行數(shù)據(jù)交換

至少包含3個(gè)其他節(jié)點(diǎn)的信息，最多包含總節(jié)點(diǎn)-2個(gè)其他節(jié)點(diǎn)的信息

基于重定向的客戶端

（1）請求重定向

客戶端可能會(huì)挑選任意一個(gè)redis實(shí)例去發(fā)送命令，每個(gè)redis實(shí)例接收到命令，都會(huì)計(jì)算key對應(yīng)的hash slot

如果在本地就在本地處理，否則返回moved給客戶端，讓客戶端進(jìn)行重定向

cluster keyslot mykey，可以查看一個(gè)key對應(yīng)的hash slot是什么

用redis-cli的時(shí)候，可以加入-c參數(shù)，支持自動(dòng)的請求重定向，redis-cli接收到moved之后，會(huì)自動(dòng)重定向到對應(yīng)的節(jié)點(diǎn)執(zhí)行命令

（2）計(jì)算hash slot

計(jì)算hash slot的算法，就是根據(jù)key計(jì)算CRC16值，然后對16384取模，拿到對應(yīng)的hash slot

用hash tag可以手動(dòng)指定key對應(yīng)的slot，同一個(gè)hash tag下的key，都會(huì)在一個(gè)hash slot中，比如set mykey1:{100}和set mykey2:{100}

（3）hash slot查找

節(jié)點(diǎn)間通過gossip協(xié)議進(jìn)行數(shù)據(jù)交換，就知道每個(gè)hash slot在哪個(gè)節(jié)點(diǎn)上

smart jedis

（1）什么是smart jedis

基于重定向的客戶端，很消耗網(wǎng)絡(luò)IO，因?yàn)榇蟛糠智闆r下，可能都會(huì)出現(xiàn)一次請求重定向，才能找到正確的節(jié)點(diǎn)

所以大部分的客戶端，比如java redis客戶端，就是jedis，都是smart的

本地維護(hù)一份hashslot -> node的映射表，緩存，大部分情況下，直接走本地緩存就可以找到hashslot -> node，不需要通過節(jié)點(diǎn)進(jìn)行moved重定向

（2）JedisCluster的工作原理

在JedisCluster初始化的時(shí)候，就會(huì)隨機(jī)選擇一個(gè)node，初始化hashslot -> node映射表，同時(shí)為每個(gè)節(jié)點(diǎn)創(chuàng)建一個(gè)JedisPool連接池

每次基于JedisCluster執(zhí)行操作，首先JedisCluster都會(huì)在本地計(jì)算key的hashslot，然后在本地映射表找到對應(yīng)的節(jié)點(diǎn)

如果那個(gè)node正好還是持有那個(gè)hashslot，那么就ok; 如果說進(jìn)行了reshard這樣的操作，可能hashslot已經(jīng)不在那個(gè)node上了，就會(huì)返回moved

如果JedisCluter API發(fā)現(xiàn)對應(yīng)的節(jié)點(diǎn)返回moved，那么利用該節(jié)點(diǎn)的元數(shù)據(jù)，更新本地的hashslot -> node映射表緩存

重復(fù)上面幾個(gè)步驟，直到找到對應(yīng)的節(jié)點(diǎn)，如果重試超過5次，那么就報(bào)錯(cuò)，JedisClusterMaxRedirectionException

jedis老版本，可能會(huì)出現(xiàn)在集群某個(gè)節(jié)點(diǎn)故障還沒完成自動(dòng)切換恢復(fù)時(shí)，頻繁更新hash slot，頻繁ping節(jié)點(diǎn)檢查活躍，導(dǎo)致大量網(wǎng)絡(luò)IO開銷

jedis最新版本，對于這些過度的hash slot更新和ping，都進(jìn)行了優(yōu)化，避免了類似問題

（3）hashslot遷移和ask重定向

如果hash slot正在遷移，那么會(huì)返回ask重定向給jedis

jedis接收到ask重定向之后，會(huì)重新定位到目標(biāo)節(jié)點(diǎn)去執(zhí)行，但是因?yàn)閍sk發(fā)生在hash slot遷移過程中，所以JedisCluster API收到ask是不會(huì)更新hashslot本地緩存

已經(jīng)可以確定說，hashslot已經(jīng)遷移完了，moved是會(huì)更新本地hashslot->node映射表緩存的

高可用性與主備切換原理

redis cluster的高可用的原理，幾乎跟哨兵是類似的

1、判斷節(jié)點(diǎn)宕機(jī)

如果一個(gè)節(jié)點(diǎn)認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)，那么就是pfail，主觀宕機(jī)

如果多個(gè)節(jié)點(diǎn)都認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)了，那么就是fail，客觀宕機(jī)，跟哨兵的原理幾乎一樣，sdown，odown

在cluster-node-timeout內(nèi)，某個(gè)節(jié)點(diǎn)一直沒有返回pong，那么就被認(rèn)為pfail

如果一個(gè)節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn)pfail了，那么會(huì)在gossip ping消息中，ping給其他節(jié)點(diǎn)，如果超過半數(shù)的節(jié)點(diǎn)都認(rèn)為pfail了，那么就會(huì)變成fail

2、從節(jié)點(diǎn)過濾

對宕機(jī)的master node，從其所有的slave node中，選擇一個(gè)切換成master node

檢查每個(gè)slave node與master node斷開連接的時(shí)間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那么就沒有資格切換成master

這個(gè)也是跟哨兵是一樣的，從節(jié)點(diǎn)超時(shí)過濾的步驟

3、從節(jié)點(diǎn)選舉

哨兵：對所有從節(jié)點(diǎn)進(jìn)行排序，slave priority，offset，run id

每個(gè)從節(jié)點(diǎn)，都根據(jù)自己對master復(fù)制數(shù)據(jù)的offset，來設(shè)置一個(gè)選舉時(shí)間，offset越大（復(fù)制數(shù)據(jù)越多）的從節(jié)點(diǎn)，選舉時(shí)間越靠前，優(yōu)先進(jìn)行選舉

所有的master node開始slave選舉投票，給要進(jìn)行選舉的slave進(jìn)行投票，如果大部分master node（N/2 + 1）都投票給了某個(gè)從節(jié)點(diǎn)，那么選舉通過，那個(gè)從節(jié)點(diǎn)可以切換成master

從節(jié)點(diǎn)執(zhí)行主備切換，從節(jié)點(diǎn)切換為主節(jié)點(diǎn)

4、與哨兵比較

整個(gè)流程跟哨兵相比，非常類似，所以說，redis cluster功能強(qiáng)大，直接集成了replication和sentinal的功能

補(bǔ)充：redis集群（cluster）模式詳解與實(shí)操

一概念

Redis集群是一個(gè)分布式（distributed）、容錯(cuò)（fault-tolerant）的 Redis內(nèi)存K/V服務(wù)，集群可以使用的功能是普通單機(jī) Redis 所能使用的功能的一個(gè)子集（subset），比如Redis集群并不支持處理多個(gè)keys的命令,因?yàn)檫@需要在不同的節(jié)點(diǎn)間移動(dòng)數(shù)據(jù),從而達(dá)不到像Redis那樣的性能,在高負(fù)載的情況下可能會(huì)導(dǎo)致不可預(yù)料的錯(cuò)誤。

二特性

Redis集群的幾個(gè)重要特征：

1.Redis 集群的分片特征在于將鍵空間分拆了16384個(gè)槽位，每一個(gè)節(jié)點(diǎn)負(fù)責(zé)其中一些槽位。

2.Redis提供一定程度的可用性,可以在某個(gè)節(jié)點(diǎn)宕機(jī)或者不可達(dá)的情況下繼續(xù)處理命令.（只要集群中大多數(shù)Master可達(dá)、且失效的Master至少有一個(gè)Slave可達(dá)，即集群非Fail狀態(tài)，集群都是可用）

3.Redis 集群中不存在中心（central）節(jié)點(diǎn)或者代理（proxy）節(jié)點(diǎn)，集群的其中一個(gè)主要設(shè)計(jì)目標(biāo)是達(dá)到線性可擴(kuò)展性（linear scalability）

三架構(gòu)

3.1 redis-cluster架構(gòu)圖

Redis cluster集群模式的原理解析

實(shí)現(xiàn)哈希映射

Redis cluster集群模式的原理解析

架構(gòu)細(xì)節(jié):

所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬.

節(jié)點(diǎn)的fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測失效時(shí)才生效.

客戶端與redis節(jié)點(diǎn)直連,不需要中間proxy層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可

redis-cluster把所有的物理節(jié)點(diǎn)映射到[0-16383]slot上,cluster 負(fù)責(zé)維護(hù)node<->slot<->value

3.2 redis-cluster選舉:容錯(cuò)

Redis cluster集群模式的原理解析

選舉過程是集群中所有master參與,如果半數(shù)以上master節(jié)點(diǎn)與某個(gè)master節(jié)點(diǎn)通信超時(shí)(cluster-node-timeout),認(rèn)為該master節(jié)點(diǎn)掛掉.

什么時(shí)候整個(gè)集群不可用(cluster_state:fail)：

a:如果集群任意master掛掉,且當(dāng)前master沒有slave，集群進(jìn)入fail狀態(tài),也可以理解成集群的slot映射[0-16383]不完全時(shí)進(jìn)入fail狀態(tài).

b:如果集群超過半數(shù)以上master掛掉，無論是否有slave，集群進(jìn)入fail狀態(tài).

當(dāng)集群不可用時(shí),所有對集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)錯(cuò)誤。

四環(huán)境要求

Redis3.0版本以上

要讓集群正常工作至少需要3個(gè)主節(jié)點(diǎn)，在這里我們要?jiǎng)?chuàng)建6個(gè)redis節(jié)點(diǎn)，其中三個(gè)為主節(jié)點(diǎn)，三個(gè)為從節(jié)點(diǎn)

五集群搭建

5.1 安裝ruby

apt-get install ruby
apt-get install rubygems

安裝ruby redis 擴(kuò)展包：

gem install redis

5.2. 安裝redis server：

apt-get install redis-server

5.3. 創(chuàng)建redis-cluster文件夾

mkdir /usr/local/redis-cluster

5.4. 將你的redis.conf配置文件分別復(fù)制到redis-cluster這個(gè)文件夾中

更改如下

port 6379 #端口6379
bind 本機(jī)ip #默認(rèn)ip為172.20.0.2/3/4/5/6/7需要改為其他節(jié)點(diǎn)機(jī)器可訪問的ip 否則創(chuàng)建集群時(shí)無法訪問對應(yīng)的端口，無法創(chuàng)建集群
daemonize yes #redis后臺運(yùn)行
pidfile /var/run/redis_6379.pid #pidfile #文件對應(yīng)6379
cluster-enabled yes #開啟集群把注釋#去掉
cluster-config-file nodes_7000.conf #集群的配置配置文件首次啟動(dòng)自動(dòng)生成
cluster-node-timeout 15000 #請求超時(shí) 默認(rèn)15秒，可自行設(shè)置
appendonly yes #aof日志開啟有需要就開啟，它會(huì)每次寫操作都記錄一條日志　
masterauth '86a1b907d54bf7010394bf316e183e67'
requirepass '86a1b907d54bf7010394bf316e183e67' #設(shè)置密碼

5.5. 啟動(dòng)redis服務(wù)

需要啟動(dòng)6個(gè)服務(wù)

redis-server /usr/local/redis_cluster/redis.conf

5.6 創(chuàng)建集群

其中redis-trib.rb在你的redis安裝目錄/src下：

/usr/local/redis-cluster/redis-trib.rb create --replicas 1 172.20.0.2:6379 172.20.0.3:6379 172.20.0.4:6379 172.20.0.5:6379 172.20.0.6:6379 172.20.0.7:6379

可以看到創(chuàng)建集群成功了：（如圖：2,3,4為主，5,6,7為從）

Redis cluster集群模式的原理解析