【README】

轉(zhuǎn)自： https://segmentfault.com/a/1190000022808576??? （好文章）

Redis 支持三種集群方案

• 主從復(fù)制模式
• Sentinel（哨兵）模式
• Cluster 模式

?

【1】主從復(fù)制模式?

主從復(fù)制的作用

通過(guò)持久化功能，Redis保證了即使在服務(wù)器重啟的情況下也不會(huì)丟失（或少量丟失）數(shù)據(jù)，因?yàn)槌志没瘯?huì)把內(nèi)存中數(shù)據(jù)保存到硬盤上，重啟會(huì)從硬盤上加載數(shù)據(jù)。 但是由于數(shù)據(jù)是存儲(chǔ)在一臺(tái)服務(wù)器上的，如果這臺(tái)服務(wù)器出現(xiàn)硬盤故障等問(wèn)題，也會(huì)導(dǎo)致數(shù)據(jù)丟失。

為了避免單點(diǎn)故障，通常的做法是將數(shù)據(jù)庫(kù)復(fù)制多個(gè)副本以部署在不同的服務(wù)器上，這樣即使有一臺(tái)服務(wù)器出現(xiàn)故障，其他服務(wù)器依然可以繼續(xù)提供服務(wù)。

為此，?Redis 提供了復(fù)制（replication）功能，可以實(shí)現(xiàn)當(dāng)一臺(tái)數(shù)據(jù)庫(kù)中的數(shù)據(jù)更新后，自動(dòng)將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫(kù)上。

在復(fù)制的概念中，數(shù)據(jù)庫(kù)分為兩類，一類是主數(shù)據(jù)庫(kù)（master），另一類是從數(shù)據(jù)庫(kù)(slave）。主數(shù)據(jù)庫(kù)可以進(jìn)行讀寫操作，當(dāng)寫操作導(dǎo)致數(shù)據(jù)變化時(shí)會(huì)自動(dòng)將數(shù)據(jù)同步給從數(shù)據(jù)庫(kù)。而從數(shù)據(jù)庫(kù)一般是只讀的，并接受主數(shù)據(jù)庫(kù)同步過(guò)來(lái)的數(shù)據(jù)。一個(gè)主數(shù)據(jù)庫(kù)可以擁有多個(gè)從數(shù)據(jù)庫(kù)，而一個(gè)從數(shù)據(jù)庫(kù)只能擁有一個(gè)主數(shù)據(jù)庫(kù)。

總結(jié)：引入主從復(fù)制機(jī)制的目的有兩個(gè)

• 一個(gè)是讀寫分離，分擔(dān) "master" 的讀寫壓力
• 一個(gè)是方便做容災(zāi)恢復(fù)

?

主從復(fù)制原理

• 從數(shù)據(jù)庫(kù)啟動(dòng)成功后，連接主數(shù)據(jù)庫(kù)，發(fā)送 SYNC 命令；
• 主數(shù)據(jù)庫(kù)接收到 SYNC 命令后，開始執(zhí)行 BGSAVE 命令生成 RDB 文件并使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令；
• 主數(shù)據(jù)庫(kù) BGSAVE 執(zhí)行完后，向所有從數(shù)據(jù)庫(kù)發(fā)送快照文件，并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令；
• 從數(shù)據(jù)庫(kù)收到快照文件后丟棄所有舊數(shù)據(jù)，載入收到的快照；
• 主數(shù)據(jù)庫(kù)快照發(fā)送完畢后開始向從數(shù)據(jù)庫(kù)發(fā)送緩沖區(qū)中的寫命令；
• 從數(shù)據(jù)庫(kù)完成對(duì)快照的載入，開始接收命令請(qǐng)求，并執(zhí)行來(lái)自主數(shù)據(jù)庫(kù)緩沖區(qū)的寫命令；（從數(shù)據(jù)庫(kù)初始化完成）
• 主數(shù)據(jù)庫(kù)每執(zhí)行一個(gè)寫命令就會(huì)向從數(shù)據(jù)庫(kù)發(fā)送相同的寫命令，從數(shù)據(jù)庫(kù)接收并執(zhí)行收到的寫命令（從數(shù)據(jù)庫(kù)初始化完成后的操作）
• 出現(xiàn)斷開重連后，2.8之后的版本會(huì)將斷線期間的命令傳給重?cái)?shù)據(jù)庫(kù)，增量復(fù)制。
• 主從剛剛連接的時(shí)候，進(jìn)行全量同步；全同步結(jié)束后，進(jìn)行增量同步。當(dāng)然，如果有需要，slave 在任何時(shí)候都可以發(fā)起全量同步。Redis 的策略是，無(wú)論如何，首先會(huì)嘗試進(jìn)行增量同步，如不成功，要求從機(jī)進(jìn)行全量同步。
• ?

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

【主從復(fù)制優(yōu)點(diǎn)】支持主從復(fù)制，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離； 為了分載 Master 的讀操作壓力，Slave 服務(wù)器可以為客戶端提供只讀操作的服務(wù)，寫服務(wù)仍然必須由Master來(lái)完成； Slave 同樣可以接受其它 Slaves 的連接和同步請(qǐng)求，這樣可以有效的分載 Master 的同步壓力； Master Server 是以非阻塞的方式為 Slaves 提供服務(wù)。所以在 Master-Slave 同步期間，客戶端仍然可以提交查詢或修改請(qǐng)求； Slave Server 同樣是以非阻塞的方式完成數(shù)據(jù)同步。在同步期間，如果有客戶端提交查詢請(qǐng)求，Redis則返回同步之前的數(shù)據(jù)；【主從復(fù)制缺點(diǎn)】Redis不具備自動(dòng)容錯(cuò)和恢復(fù)功能，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗，需要等待機(jī)器重啟或者手動(dòng)切換前端的IP才能恢復(fù)（也就是要人工介入）； 主機(jī)宕機(jī)，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)，切換IP后還會(huì)引入數(shù)據(jù)不一致的問(wèn)題，降低了系統(tǒng)的可用性； 如果多個(gè) Slave 斷線了，需要重啟的時(shí)候，盡量不要在同一時(shí)間段進(jìn)行重啟。因?yàn)橹灰?Slave 啟動(dòng)，就會(huì)發(fā)送sync 請(qǐng)求和主機(jī)全量同步，當(dāng)多個(gè) Slave 重啟的時(shí)候，可能會(huì)導(dǎo)致 Master IO 劇增從而宕機(jī)。 Redis 較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜；

【2】哨兵模式?

1）哨兵模式是什么？ 啟動(dòng)一個(gè)線程作為哨兵監(jiān)控 redis節(jié)點(diǎn)是否宕機(jī)，若有宕機(jī)，則做進(jìn)一步處理；

2）哨兵模式為什么要引入？ 由于主從復(fù)制模式下的redis集群，當(dāng) master宕機(jī)時(shí)，無(wú)法自動(dòng)把 slave節(jié)點(diǎn)切換為 master節(jié)點(diǎn)； 哨兵模式就是解決自動(dòng)切換slave節(jié)點(diǎn)為master，而引入的；

3）怎么啟動(dòng)哨兵模式集群？ 簡(jiǎn)單，這里不再累述；

4）哨兵模式原理

5）哨兵模式優(yōu)缺點(diǎn)

哨兵模式的優(yōu)缺點(diǎn) 【優(yōu)點(diǎn)】 哨兵模式是基于主從模式的，所有主從的優(yōu)點(diǎn)，哨兵模式都具有。 主從可以自動(dòng)切換，系統(tǒng)更健壯，可用性更高(可以看作自動(dòng)版的主從復(fù)制)。【缺點(diǎn)】 Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。

【3】cluster模式（分片存儲(chǔ)）

1）cluster模式的redis集群是什么？

Redis 的哨兵模式基本已經(jīng)可以實(shí)現(xiàn)高可用，讀寫分離 ，但是在這種模式下每臺(tái) Redis 服務(wù)器都存儲(chǔ)相同的數(shù)據(jù)，很浪費(fèi)內(nèi)存，所以在 redis3.0上加入了 Cluster 集群模式，實(shí)現(xiàn)了 Redis 的分布式存儲(chǔ)，也就是說(shuō)每臺(tái) Redis 節(jié)點(diǎn)上存儲(chǔ)不同的內(nèi)容。

補(bǔ)充： cluster模式的redis集群讀寫原理；

在這個(gè)圖中，每一個(gè)藍(lán)色的圈都代表著一個(gè) redis 的服務(wù)器節(jié)點(diǎn)。它們?nèi)魏蝺蓚€(gè)節(jié)點(diǎn)之間都是相互連通的。客戶端可以與任何一個(gè)節(jié)點(diǎn)相連接，然后就可以訪問(wèn)集群中的任何一個(gè)節(jié)點(diǎn)。對(duì)其進(jìn)行存取和其他操作。

【荔枝】分布式存儲(chǔ)

k1 存儲(chǔ)在 203:6379 master節(jié)點(diǎn)，如下；

192.168.163.201:6379> set k1 v021801 -> Redirected to slot [12706] located at 192.168.163.203:6379 OK 192.168.163.203:6379> get k1 "v021801" 192.168.163.203:6379> keys * 1) "k1" 192.168.163.203:6379> get k1 "v021801"

又 203:6379? 201:6379?? 202:6379 這3個(gè)節(jié)點(diǎn)屬于同一個(gè)集群中的master節(jié)點(diǎn)，只不過(guò)存儲(chǔ)不同的分片或槽；

但當(dāng)客戶端連接 201:6379? 202:6379 節(jié)點(diǎn)時(shí)，同樣可以獲取到 k1的值，即便其沒有存儲(chǔ)在 201:6379? 202:6379節(jié)點(diǎn)上； 這就是集群的魅力所在；

[root@centos201 bin]# redis-cli -h 192.168.163.201 -p 6379 -c 192.168.163.201:6379> keys * (empty list or set) 192.168.163.201:6379> get k1 -> Redirected to slot [12706] located at 192.168.163.203:6379 "v021801" 192.168.163.203:6379> exit [root@centos201 bin]# [root@centos201 bin]# redis-cli -h 192.168.163.202 -p 6379 -c 192.168.163.202:6379> keys * (empty list or set) 192.168.163.202:6379> get k1 -> Redirected to slot [12706] located at 192.168.163.203:6379 "v021801"

2）為什么要引入？分片存儲(chǔ)，擴(kuò)容； 且支持在線擴(kuò)容；且擴(kuò)容非常簡(jiǎn)單；

【集群的數(shù)據(jù)分片】
Redis 集群沒有使用一致性 hash，而是引入了哈希槽【hash slot】的概念。

Redis 集群有16384 個(gè)哈希槽，每個(gè) key 通過(guò) CRC16 校驗(yàn)后對(duì) 16384 取模來(lái)決定放置哪個(gè)槽。集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽，舉個(gè)例子，比如當(dāng)前集群有3個(gè)節(jié)點(diǎn)，那么：

節(jié)點(diǎn) A 包含 0 到 5460 號(hào)哈希槽
節(jié)點(diǎn) B 包含 5461 到 10922 號(hào)哈希槽
節(jié)點(diǎn) C 包含 10923 到 16383 號(hào)哈希槽
這種結(jié)構(gòu)很容易添加或者刪除節(jié)點(diǎn)。比如如果我想新添加個(gè)節(jié)點(diǎn) D ， 我需要從節(jié)點(diǎn) A， B， C 中得部分槽到 D 上。如果我想移除節(jié)點(diǎn) A ，需要將 A 中的槽移到 B 和 C 節(jié)點(diǎn)上，然后將沒有任何槽的 A 節(jié)點(diǎn)從集群中移除即可。由于從一個(gè)節(jié)點(diǎn)將哈希槽移動(dòng)到另一個(gè)節(jié)點(diǎn)并不會(huì)停止服務(wù)，所以無(wú)論添加刪除或者改變某個(gè)節(jié)點(diǎn)的哈希槽的數(shù)量都不會(huì)造成集群不可用的狀態(tài)。

在 Redis 的每一個(gè)節(jié)點(diǎn)上，都有這么兩個(gè)東西（插槽+節(jié)點(diǎn)），一個(gè)是插槽（slot），它的的取值范圍是：0-16383。還有一個(gè)就是 cluster，可以理解為是一個(gè)集群管理的插件。當(dāng)我們的存取的 Key到達(dá)的時(shí)候，Redis 會(huì)根據(jù) CRC16 的算法得出一個(gè)結(jié)果，然后把結(jié)果對(duì) 16384 求余數(shù)，這樣每個(gè) key 都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在 0-16383 之間的哈希槽，通過(guò)這個(gè)值，去找到對(duì)應(yīng)的插槽所對(duì)應(yīng)的節(jié)點(diǎn)，然后直接自動(dòng)跳轉(zhuǎn)到這個(gè)對(duì)應(yīng)的節(jié)點(diǎn)上進(jìn)行存取操作。

?

3）Redis 集群的主從復(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ú)法再提供服務(wù)了。

4）redis集群特點(diǎn)

所有的 redis 節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制)，內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。 節(jié)點(diǎn)的 fail 是通過(guò)集群中超過(guò)半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效。 客戶端與 Redis 節(jié)點(diǎn)直連，不需要中間代理層.客戶端不需要連接集群所有節(jié)點(diǎn)，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

?

?

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的redis集群3种模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。