Redis三種集群模式是什么

本文小編為大家詳細(xì)介紹“Redis三種集群模式是什么”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“Redis三種集群模式是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識(shí)吧。

三種集群模式

• redis有三種集群模式，其中主從是最常見的模式。

• Sentinel 哨兵模式是為了彌補(bǔ)主從復(fù)制集群中主機(jī)宕機(jī)后，主備切換的復(fù)雜性而演變出來的。哨兵顧名思義，就是用來監(jiān)控的，主要作用就是監(jiān)控主從集群，自動(dòng)切換主備，完成集群故障轉(zhuǎn)移。

• cluster 模式是redis官方提供的集群模式，使用了Sharding 技術(shù)，不僅實(shí)現(xiàn)了高可用、讀寫分離、也實(shí)現(xiàn)了真正的分布式存儲(chǔ)。

一、主從復(fù)制

redis主從復(fù)制

1、reids主從模式

2、redis復(fù)制原理

redis 的復(fù)制分為兩部分操作 同步（SYNC）和 命令傳播（command propagate）

• 同步（SYNC）用來將從服務(wù)器的狀態(tài) 更新到 和主服務(wù)器 一致。白話文解釋就是從服務(wù)器主動(dòng)獲取 主服務(wù)器的數(shù)據(jù)。保持?jǐn)?shù)據(jù)一致。具體實(shí)現(xiàn)是，主服務(wù)器收到SYNC命令后，生成RDB快照文件，然后發(fā)送給從服務(wù)器。

• 命令傳播 （command propagate）用于在主服務(wù)器數(shù)據(jù)被修改后，主從不一致，為了讓從服務(wù)器保持和主服務(wù)器狀態(tài)一致，而做的命令傳播。白話文解釋就是主服務(wù)器收到客戶端修改數(shù)據(jù)命令后，數(shù)據(jù)庫(kù)數(shù)據(jù)發(fā)生變化，同時(shí)將命令緩存起來，然后將緩存命令發(fā)送到從服務(wù)器，從服務(wù)器通過載入緩存命令來達(dá)到主從數(shù)據(jù)一致。這就是所謂的命令傳播。

• 為什么需要有同步和命令傳播的兩種復(fù)制操作： 當(dāng)只有同步操作時(shí)候，那么在從服務(wù)器向主服務(wù)器發(fā)送SYNC命令時(shí)候，主服務(wù)器在生成RDB快照文件時(shí)候，仍然會(huì)收到客戶端的命令修改數(shù)據(jù)狀態(tài)，這部分?jǐn)?shù)據(jù)如果不能傳達(dá)給從服務(wù)器，那么就會(huì)出現(xiàn)主從數(shù)據(jù)不一致的現(xiàn)象。這時(shí)候就出現(xiàn)了命令傳播，主服務(wù)器收到從服務(wù)器的SYNC命令后，生成RDB快照文件同時(shí)，將此段時(shí)間內(nèi)收到的命令緩存起來，然后使用命令傳播的操作發(fā)送從服務(wù)器。來達(dá)到主從數(shù)據(jù)一致。

3、redis主從復(fù)制原理

上面介紹了redis復(fù)制的兩種操作，而redis得主從復(fù)制正式基于 同步 和 命令傳播 來實(shí)現(xiàn)得。下面兩張圖展示了redis復(fù)制的流程：

4、redis主從復(fù)制優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

1、實(shí)現(xiàn)讀寫分離，提高了可用性，解決了單機(jī)故障2、主從復(fù)制期間master和slave都是非阻塞方式，仍然可用。

缺點(diǎn)：

1、master宕機(jī)期間，需要手動(dòng)切換主機(jī)，同時(shí)會(huì)有部分?jǐn)?shù)據(jù)不能及時(shí)同步從服務(wù)器，造成數(shù)據(jù)不一致（需要人工手動(dòng)介入）

2、slave宕機(jī)后，多個(gè)slave恢復(fù)后，大量的SYNC同步會(huì)造成master IO壓力倍增（可以手動(dòng)規(guī)避啟動(dòng)時(shí)間）

3、在線擴(kuò)容較復(fù)雜。

總結(jié)：

redis主從復(fù)制的優(yōu)點(diǎn)主要是提高了可用性缺點(diǎn)

二、Sentinel 哨兵模式

Sentinel 哨兵Sentinel 哨兵介紹

Sentinel 哨兵本質(zhì)上是一個(gè)運(yùn)行在特殊模式下的Redis實(shí)例，只是初始化的過程和工作與普通的Redis不同，本質(zhì)上也是一個(gè)單獨(dú)的進(jìn)程。

Sentinel 哨兵 是Redis的高可用解決方案：一個(gè)或多個(gè)Sentinel實(shí)例（instance）組成的Sentinel系統(tǒng)（system）可以監(jiān)視任意多個(gè)主服務(wù)器，以及這些主服務(wù)器屬下的所有從服務(wù)器，并在主服務(wù)器下線時(shí)可以自動(dòng)切換從服務(wù)器升級(jí)為主服務(wù)器。

1、Sentinel系統(tǒng)

下圖是一個(gè)簡(jiǎn)單的Sentinel系統(tǒng)架構(gòu)圖，一個(gè)Sentinel系統(tǒng)監(jiān)視一個(gè)主從集群，其中server1是Redis主服務(wù)器，server2/3/4是Redis 從服務(wù)器。主從之間利用上面的主從復(fù)制來達(dá)到主從一致。而Sentinel系統(tǒng)監(jiān)視整個(gè)主從集群。

2、Sentinel故障轉(zhuǎn)移

當(dāng)Sentinel系統(tǒng)察覺到Server1主服務(wù)器下線時(shí)，就會(huì)終止server2/3/4的復(fù)制。

同時(shí)Sentinel將server2升級(jí)為主服務(wù)器，server3/4從新的主服務(wù)器進(jìn)行復(fù)制。同時(shí)等待server1的再次上線。

Sentinel系統(tǒng)也可以主動(dòng)降級(jí)主服務(wù)為從服務(wù)器，將從服務(wù)器升級(jí)為主服務(wù)器。

2.1、Sentinel 哨兵監(jiān)控過程

Sentinel 哨兵監(jiān)控集群過程：

• 命令 Sentinel哨兵通過發(fā)送命令，讓redis服務(wù)器返回運(yùn)行狀態(tài)。發(fā)布訂閱 當(dāng)主服務(wù)器狀態(tài)發(fā)生變化時(shí)，Sentinel哨兵通過

• 發(fā)布訂閱模式通知其他從服務(wù)器。

2.2、Sentinel 哨兵故障轉(zhuǎn)移

Sentinel 故障轉(zhuǎn)移：

• 1、Sentinel系統(tǒng)中的Sentinel實(shí)例每隔1s就像集群發(fā)送PING命令

• 2、如果集群中有實(shí)例的回復(fù)Sentinel實(shí)例時(shí)間超過了 down-after-milliseconds，那么這個(gè)實(shí)例就會(huì)發(fā)送PING命令的Sentinel實(shí)例被主觀下線

• 3、那么什么時(shí)候會(huì)客觀下線呢？需要Sentinel系統(tǒng)中其他實(shí)例也確認(rèn)集群中該實(shí)例主管下線。

• 如果master主服務(wù)器被標(biāo)記為主觀下線，則Sentinel系統(tǒng)中監(jiān)視master的Sentinel進(jìn)程需要以每秒一次的頻率確認(rèn)Master是否進(jìn)入主管下線狀態(tài)

• 4、當(dāng)有足夠的Sentinel實(shí)例（取決于配置）確認(rèn)Master進(jìn)入了主管下線，則Master會(huì)被標(biāo)記為客觀下線。
  

3、Sentinel 哨兵優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

1、哨兵模式基于主從復(fù)制，因此主從復(fù)制的優(yōu)點(diǎn)哨兵都具備2、哨兵具備了主從切換和故障轉(zhuǎn)移，因此集群有了更高的可用性

缺點(diǎn)：

1、Redis較難支持在線擴(kuò)容，在線擴(kuò)容比較復(fù)雜。

總結(jié)：
sentinel 哨兵主要用來監(jiān)控redis主從集群，提高了redis 主從集群的可用性。

三、cluster 模式

redis cluster

1、reids cluster

Redis Cluster是一種服務(wù)器 Sharding 技術(shù)，redis 3.0版本開始正式提供。
Sentinel基本已經(jīng)實(shí)現(xiàn)了高可用，但是每臺(tái)機(jī)器都存儲(chǔ)相同內(nèi)容，很浪費(fèi)內(nèi)存，所以Redis Cluster實(shí)現(xiàn)了分布式存儲(chǔ)。每臺(tái)機(jī)器節(jié)點(diǎn)上存儲(chǔ)不同的內(nèi)容。

2、Redis Cluster 數(shù)據(jù)分片原理

redis 數(shù)據(jù)分片使用的是hash slot， redis集群有16384個(gè)哈希槽，每個(gè)Key通過CRC16校驗(yàn)后對(duì)16384取模來決定放置哪一個(gè)槽。
當(dāng)存取redis key時(shí)候，redis會(huì)根據(jù)CRC16算法得到一個(gè)結(jié)果，然后把結(jié)果和16384求余，通過這個(gè)值去對(duì)應(yīng)得節(jié)點(diǎn)獲取數(shù)據(jù)。
這個(gè)時(shí)候，應(yīng)用客戶端實(shí)際上只需要連接其中任意一個(gè)節(jié)點(diǎn)即可，然后Redis Cluster 中每個(gè)節(jié)點(diǎn)都保存了其他節(jié)點(diǎn)得槽信息。這樣當(dāng)存取key計(jì)算完槽之后，通過保存槽信息從配置中獲取節(jié)點(diǎn)信息，然后再去對(duì)應(yīng)得節(jié)點(diǎn)獲取數(shù)據(jù)。

3、Redis Cluster 復(fù)制原理

redis-cluster集群引入了主從復(fù)制模型，一個(gè)主節(jié)點(diǎn)對(duì)應(yīng)一個(gè)或者多個(gè)從節(jié)點(diǎn)，當(dāng)主節(jié)點(diǎn)宕機(jī)的時(shí)候，就會(huì)啟用從節(jié)點(diǎn)。當(dāng)其它主節(jié)點(diǎn) ping 一個(gè)主節(jié)點(diǎn) A 時(shí)，如果半數(shù)以上的主節(jié)點(diǎn)與 A 通信超時(shí)，那么認(rèn)為主節(jié)點(diǎn) A 宕機(jī)了。如果主節(jié)點(diǎn) A 和它的從節(jié)點(diǎn) A1 都宕機(jī)了，那么該集群就無法再提供服務(wù)了

讀到這里，這篇“Redis三種集群模式是什么”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。