疑問1：主節(jié)點(diǎn)掛掉后，從節(jié)點(diǎn)頂上，那么掛掉的主節(jié)點(diǎn)會(huì)怎樣？

解答：當(dāng)S1成為了新的Master之后，S2和節(jié)點(diǎn)3該如何處理？顯然并不是篡位之后就殺掉hh。實(shí)際上我們是讓S2和節(jié)點(diǎn)3成為新的主節(jié)點(diǎn)S1的Slave節(jié)點(diǎn)，去備份S1節(jié)點(diǎn)的數(shù)據(jù)。
在https://zhuanlan.zhihu.com/p/106110578?utm_source=wechat_session這篇文章找到了答案。

疑問2：槽位是什么

Redis 集群并沒有使用一致性hash，而是引入了哈希槽的概念。Redis 集群有16384個(gè)哈希槽，每個(gè)key通過CRC16校驗(yàn)后對(duì)16384取模來決定放置哪個(gè)槽，集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽。哈希槽的數(shù)量是16384（2^14）個(gè)。

為什么是16384（2^14）個(gè)？
在redis節(jié)點(diǎn)發(fā)送心跳包時(shí)需要把所有的槽放到這個(gè)心跳包里，以便讓節(jié)點(diǎn)知道當(dāng)前集群信息，16384=16k，在發(fā)送心跳包時(shí)使用char進(jìn)行bitmap壓縮后是2k（2 * 8 (8 bit) * 1024(1k) = 16K），也就是說使用2k的空間創(chuàng)建了16k的槽數(shù)。

雖然使用CRC16算法最多可以分配65535（2^16-1）個(gè)槽位，65535=65k，壓縮后就是8k（8 * 8 (8 bit) * 1024(1k) =65K），也就是說需要需要8k的心跳包，作者認(rèn)為這樣做不太值得；并且一般情況下一個(gè)redis集群不會(huì)有超過1000個(gè)master節(jié)點(diǎn)，所以16k的槽位是個(gè)比較合適的選擇

目標(biāo)3：了解哨兵機(jī)制

哨兵模式

該模式是從Redis的2.6版本開始提供的，但是當(dāng)時(shí)這個(gè)版本的模式是不穩(wěn)定的，直到Redis的2.8版本以后，這個(gè)哨兵模式才穩(wěn)定下來，無論是主從模式，還是哨兵模式，這兩個(gè)模式都有一個(gè)問題，不能水平擴(kuò)容，并且這兩個(gè)模式的高可用特性都會(huì)受到Master主節(jié)點(diǎn)內(nèi)存的限制。

Sentinel(哨兵)進(jìn)程是用于監(jiān)控redis集群中Master主服務(wù)器工作的狀態(tài)，在Master主服務(wù)器發(fā)生故障的時(shí)候，可以實(shí)現(xiàn)Master和Slave服務(wù)器的切換，保證系統(tǒng)的高可用。

Sentinel（哨兵）進(jìn)程的作用

監(jiān)控(Monitoring): 哨兵(sentinel) 會(huì)不斷地檢查你的Master和Slave是否運(yùn)作正常。

提醒(Notification)：當(dāng)被監(jiān)控的某個(gè)Redis節(jié)點(diǎn)出現(xiàn)問題時(shí), 哨兵(sentinel) 可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知。

自動(dòng)故障遷移(Automatic failover)：當(dāng)一個(gè)Master不能正常工作時(shí)，哨兵(sentinel) 會(huì)開始一次自動(dòng)故障遷移操作，它會(huì)將失效Master的其中一個(gè)Slave升級(jí)為新的Master, 并讓失效Master的其他Slave改為復(fù)制新的Master；當(dāng)客戶端試圖連接失效的Master時(shí)，集群也會(huì)向客戶端返回新Master的地址，使得集群可以使用現(xiàn)在的Master替換失效Master。Master和Slave服務(wù)器切換后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的內(nèi)容都會(huì)發(fā)生相應(yīng)的改變，即，Master主服務(wù)器的redis.conf配置文件中會(huì)多一行slaveof的配置，sentinel.conf的監(jiān)控目標(biāo)會(huì)隨之調(diào)換。

Sentinel（哨兵）進(jìn)程的工作方式

每個(gè)Sentinel（哨兵）進(jìn)程以每秒鐘一次的頻率向整個(gè)集群中的Master主服務(wù)器，Slave從服務(wù)器以及其他Sentinel（哨兵）進(jìn)程發(fā)送一個(gè) PING 命令。

如果一個(gè)實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時(shí)間超過 down-after-milliseconds 選項(xiàng)所指定的值， 則這個(gè)實(shí)例會(huì)被 Sentinel（哨兵）進(jìn)程標(biāo)記為主觀下線（SDOWN）

如果一個(gè)Master主服務(wù)器被標(biāo)記為主觀下線（SDOWN），則正在監(jiān)視這個(gè)Master主服務(wù)器的所有 Sentinel（哨兵）進(jìn)程要以每秒一次的頻率確認(rèn)Master主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)

當(dāng)有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程（大于等于配置文件指定的值）在指定的時(shí)間范圍內(nèi)確認(rèn)Master主服務(wù)器進(jìn)入了主觀下線狀態(tài)（SDOWN）， 則Master主服務(wù)器會(huì)被標(biāo)記為客觀下線（ODOWN）

在一般情況下， 每個(gè) Sentinel（哨兵）進(jìn)程會(huì)以每 10 秒一次的頻率向集群中的所有Master主服務(wù)器、Slave從服務(wù)器發(fā)送 INFO 命令。

當(dāng)Master主服務(wù)器被 Sentinel（哨兵）進(jìn)程標(biāo)記為客觀下線（ODOWN）時(shí)，Sentinel（哨兵）進(jìn)程向下線的 Master主服務(wù)器的所有 Slave從服務(wù)器發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次。

若沒有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程同意 Master主服務(wù)器下線， Master主服務(wù)器的客觀下線狀態(tài)就會(huì)被移除。若 Master主服務(wù)器重新向 Sentinel（哨兵）進(jìn)程發(fā)送 PING 命令返回有效回復(fù)，Master主服務(wù)器的主觀下線狀態(tài)就會(huì)被移除。

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

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

哨兵集群模式是基于主從模式的，所有主從的優(yōu)點(diǎn)，哨兵模式同樣具有。

主從可以切換，故障可以轉(zhuǎn)移，系統(tǒng)可用性更好。

哨兵模式是主從模式的升級(jí)，系統(tǒng)更健壯，可用性更高。

缺點(diǎn):

Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜。為避免這一問題，運(yùn)維人員在系統(tǒng)上線時(shí)必須確保有足夠的空間，這對(duì)資源造成了很大的浪費(fèi)。

配置復(fù)雜

目標(biāo)4：三種集群模式

主從模式、哨兵模式、Cluster集群模式。詳見上一篇文章

目標(biāo)5：集群搭建

環(huán)境：
一臺(tái)虛擬機(jī)Centos7
redis 5.0.5

Cluster集群模式，參考《redis 5.0.5 5分鐘搭建redis集群》文章完成cluster集群搭建。

主從+哨兵模式，參考《在一臺(tái)centos7服務(wù)器上搭建redis集群以及哨兵》文章

Redis Cluster 是在Redis 3.0開始支持的，3.0主要是更新了多機(jī)方面的功能，在5.0之前Redis Cluster 主要是采用 Redis提供的 redis-trib.rb（Ruby實(shí)現(xiàn)的腳本,需要安裝相應(yīng)的依賴環(huán)境）這個(gè)管理工具。5.0版本開始支持 --cluster 參數(shù)來進(jìn)行管理。

總結(jié)

以上是生活随笔為你收集整理的redis集群学习一些记录的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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