1. 程式人生 > >Redis主從哨兵叢集模式概念以及搭建

Redis主從哨兵叢集模式概念以及搭建

目錄

 

前言

一、Redis使用準備工作

1.1、下載redis

1.2、安裝redis

二、Redis部署

2.1、單節點模式部署

2.2、主從模式部署

2.2.1 主從模式的感念:

2.2.2 主從模式的理解:

2.2.3 主從模式的缺點:

2.2.4 配置主從模式:

2.3、哨兵模式部署

2.3.1 對哨兵模式(Sentinel)的理解:

2.3.2 Sentinel模式的好處:

2.3.3 Sentinel叢集:

2.3.4 配置Sentinel模式

2.4、叢集模式

2.4.1 對叢集模式的理解

2.4.2 叢集模式配置

2.4.3 叢集過程

總結:


前言

本文是我借鑑網上很多大神的總結,並結合自己在專案中的使用歸納出的。如果發現有的地方與其他大神的文章有類似的地方,絕不是偶然。。。。

下面放上一些借鑑的文章連結:

https://new.qq.com/omn/20180126/20180126G00THE.html

http://www.cnblogs.com/yu421/p/8081544.html

 

一、Redis使用準備工作

1.1、下載redis

據瞭解,redis官方只有linux版,沒有windows版的。

下面是微軟的windows版的redis,linux版的請自行去官網下載:

https://github.com/MSOpenTech/redis/releases

關於redis版本,一般情況下不會有問題,但是以後專案的依賴更新,有可能不相容老版本的redis。

1.2、安裝redis

windows的版本直接解壓就可以了

Linux需要先通過解壓命令解壓:tar zxvf redis-4.0.11.tar.gz

之後會出現一個解壓後的資料夾,然後進入裡面的src目錄下:cd redis-4.0.11/src

然後進行安裝命令:make install PREFIX=../

PREFIX後面跟的是想要安裝到的路徑,可以自定義,這裡安裝到了src檔案的上一級目錄

然後看到以下字樣證明安裝成功了

到這裡安裝完成

二、Redis部署

2.1、單節點模式部署

單節點模式其實就是直接啟動一個redis,一般小專案或者資料量不大的專案才有可能會用到。

直接進入bin資料夾輸入命令啟動即可:./redis-server

出現下面這張圖證明啟動成功了

2.2、主從模式部署

2.2.1 主從模式的感念:

主從模式就是N個redis例項,可以是1主N從,也可以N主N從(N主N從則不是嚴格意義上的主從模式了,後續的叢集模式會說到,N主N從就是N+N個redis例項。)

  主從模式的一個作用是備份資料,這樣當一個節點損壞(指不可恢復的硬體損壞)時,資料因為有備份,可以方便恢復。

  另一個作用是負載均衡,所有客戶端都訪問一個節點肯定會影響Redis工作效率,有了主從以後,查詢操作就可以通過查詢從節點來完成。

2.2.2 主從模式的理解:

這裡引用網上大神總結的內容,大神總結的非常到位

1.一個Master可以有多個Slaves,可以是1主N從。

2.預設配置下,master節點可以進行讀和寫,slave節點只能進行讀操作,寫操作被禁止(readonly)。

3.不要修改配置讓slave節點支援寫操作,沒有意義,原因一,寫入的資料不會被同步到其他節點;原因二,當master節點修改同一條資料後,slave節點的資料會被覆蓋掉。

4.slave節點掛了不影響其他slave節點的讀和master節點的讀和寫,重新啟動後會將資料從master節點同步過來。

5.master節點掛了以後,不影響slave節點的讀,Redis將不再提供寫服務,master節點啟動後Redis將重新對外提供寫服務。

6.特別說明:該種模式下,master節點掛了以後,slave不會競選成為master。

對有密碼的情況說明一下,當master節點設定密碼時:

客戶端訪問master需要密碼,啟動slave需要密碼,在配置中進行配置即可。客戶端訪問slave不需要密碼

綜上,客戶端只需要配置一個密碼引數,而redis配置檔案中需要配置兩個引數。

分別是:

Redis服務端配置檔案:

masterauth "chrdw,hdhxt!"

requirepass "chrdw,hdhxt!"

客戶端配置檔案:

jedis-cluster.password=chrdw,hdhxt!

注意沒有引號。

2.2.3 主從模式的缺點:

主從模式的缺點其實從上面的描述中可以得出:

master節點掛了以後,redis就不能對外提供寫服務了,因為剩下的slave不能成為master

這個缺點影響是很大的,尤其是對生產環境來說,是一刻都不能停止服務的,所以一般的生產壞境是不會單單隻有主從模式的。所以有了下面的sentinel模式。

2.2.4 配置主從模式:

首先複製3份redis目錄下的redis.conf檔案,分別命名:

redis6379.conf

redis6380.conf

redis6381.conf

其中6379為master,剩下兩個為slave,並對3個檔案進行配置:

bind 127.0.0.1
port=6380
daemonize yes
slaveof 127.0.0.1 6379

master的話只需要新增前三條即可

daemonize yes表示後臺啟動,原值為no

然後啟動:

redis-server.exe redis6379.conf

redis-server.exe redis6380.conf

redis-server.exe redis6381.conf

開啟master客戶端介面檢視狀態

redis-cli.exe -h 127.0.0.1 -p 6379

info replication

可以看到master下有兩個slave,證明啟動成功

關閉redis

可以通過命令:ps -ef|grep redis 來檢視後臺執行的redis程序

可以通過:./redis-cli -h 127.0.0.1 -p 6380 shutdown 來指定要關閉的redis

2.3、哨兵模式部署

sentinel的中文含義是哨兵、守衛。也就是說既然主從模式中,當master節點掛了以後,slave節點不能主動選舉一個master節點出來,那麼我就安排一個或多個sentinel來做這件事,當sentinel發現master節點掛了以後,sentinel就會從slave中重新選舉一個master。

2.3.1 對哨兵模式(Sentinel)的理解:

1.sentinel模式是建立在主從模式的基礎上,如果只有一個Redis節點,sentinel就沒有任何意義。

2.當master節點掛了以後,sentinel會在slave中選擇一個做為master,並修改它們的配置檔案,其他slave的配置檔案也會被修改,比如slaveof屬性會指向新的master。

3.當master節點重新啟動後,它將不再是master,而是作為slave接收新的master節點的同步資料

4.sentinel因為也是一個程序有掛掉的可能,所以sentinel也會啟動多個形成一個sentinel叢集。

5.當主從模式配置密碼時,sentinel也會同步將配置資訊修改到配置檔案中,不需要擔心。

6.一個sentinel或sentinel叢集可以管理多個主從Redis。

7.sentinel最好不要和Redis部署在同一臺機器,不然Redis的伺服器掛了以後,sentinel也掛了。

8.sentinel監控的Redis叢集都會定義一個master名字,這個名字代表Redis叢集的master Redis。

當使用sentinel模式的時候,客戶端就不要直接連線Redis,而是連線sentinel的ip和port,由sentinel來提供具體的可提供服務的Redis實現,這樣當master節點掛掉以後,sentinel就會感知並將新的master節點提供給使用者。

2.3.2 Sentinel模式的好處:

1.如果只有一個sentinel程序,如果這個程序執行出錯,或者是網路堵塞,那麼將無法實現redis叢集的主備切換(單點問題)。

2.如果有多個sentinel,redis的客戶端可以隨意地連線任意一個sentinel來獲得關於redis叢集中的資訊。

3.sentinel叢集自身也需要多數機制,也就是2個sentinel程序時,掛掉一個另一個就不可用了。

2.3.3 Sentinel叢集:

和其他叢集不同,你無須設定其他Sentinel的地址,Sentinel程序可以通過釋出與訂閱來自動發現正在監視相同主例項的其他Sentinel。當一個 Sentinel 發現一個新的 Sentinel 時,它會將新的 Sentinel 新增到一個列表中,這個列表儲存了 Sentinel 已知的,監視同一個主伺服器的所有其他Sentinel。

Sentinel叢集中的Sentinel不會再同一時刻併發去failover(故障切換or故障轉移)同一個master,第一個進行failover的Sentinel如果失敗了(上文配置的failover-timeout),另外一個才會重新進行failover,以此類推。

當Sentinel將一個slave選舉為master併發送SLAVE OF NO ONE後,即使其它的slave還沒針對新master重新配置自己,failover也被認為是成功了。

上述過度過程中,若此時重啟old master,則redis叢集將處於無master狀態,此時只能手動修改配置檔案,然後重新啟動叢集.(生產情況下千萬不要做如此愚蠢的操作,否則你會導致整個應用叢集都啟動失敗。)

Master-Slave切換後,Sentinel會改寫master,slave和sentinel的conf配置檔案。

一旦一個Sentinel成功地對一個master進行了failover,它將會把關於master的最新配置通過廣播形式通知其它sentinel,其它的Sentinel則更新對應master的配置。

Sentinel模式基本可以滿足一般生產的需求,具備高可用性。但是當資料量過大到一臺伺服器存放不下的情況(這個一般是記憶體瓶頸,本人進行過Redis的壓力測試,Redis在高併發、大資料量的情況下CPU等資源的消耗不高,主要壓力是記憶體。)時,主從模式或sentinel模式就不能滿足需求了,這個時候需要對儲存的資料進行分片,將資料儲存到多個Redis例項中,就是下面要講的。

2.3.4 配置Sentinel模式

首先依然是先複製3個哨兵的配置檔案

sentinel26379.conf

sentinel26380.conf

sentinel26381.conf

修改其中的配置

port 26379 // 當前Sentinel服務執行的埠  

sentinel monitor mymaster 127.0.0.1 6379 2   // 去監視一個名為mymaster的主redis例項,這個主例項的IP地址為本機地址127.0.0.1,埠號為6379,而將這個主例項判斷為失效至少需要2個 Sentinel程序的同意,只要同意Sentinel的數量不達標,自動failover就不會執行

sentinel down-after-milliseconds mymaster 5000  // 指定了Sentinel認為Redis例項已經失效所需的毫秒數。當 例項超過該時間沒有返回PING,或者直接返回錯誤,那麼Sentinel將這個例項標記為主觀下線。只有一個 Sentinel程序將例項標記為主觀下線並不一定會引起例項的自動故障遷移:只有在足夠數量的Sentinel都將一個例項標記為主觀下線之後,例項才會被標記為客觀下線,這時自動故障遷移才會執行

sentinel parallel-syncs mymaster 1  // 指定了在執行故障轉移時,最多可以有多少個從Redis例項在同步新的主例項,在從Redis例項較多的情況下這個數字越小,同步的時間越長,完成故障轉移所需的時間就越長

sentinel failover-timeout mymaster 15000 // 如果在該時間(ms)內未能完成failover操作,則認為該failover失敗

daemonize yes //新增此條可以後臺啟動

 

然後啟動即可:

./redis-server ./config/sentinel26379.conf --sentinel

./redis-server ./config/sentinel26380.conf --sentinel

./redis-server ./config/sentinel26381.conf --sentinel

可以利用redis客戶端檢視

如圖,證明啟動成功

2.4、叢集模式

2.4.1 對叢集模式的理解

cluster的出現是為了解決單機Redis容量有限的問題,將Redis的資料根據一定的規則分配到多臺機器。對cluster的一些理解:

一個 Redis 叢集包含 16384 個雜湊槽(hash slot),資料庫中的每個鍵都屬於這 16384 個雜湊槽的其中一個,叢集中的每個節點負責處理一部分雜湊槽。

例如一個叢集有三個主節點,其中:

節點 A 負責處理 0 號至 5500 號雜湊槽。

節點 B 負責處理 5501 號至 11000 號雜湊槽。

節點 C 負責處理 11001 號至 16384 號雜湊槽。

這種將雜湊槽分佈到不同節點的做法使得使用者可以很容易地向叢集中新增或者刪除節點。例如:如果使用者將新節點 D 新增到叢集中, 那麼叢集只需要將節點 A 、B 、 C 中的某些槽移動到節點 D 就可以了。

如果使用者要從叢集中移除節點 A , 那麼叢集只需要將節點 A 中的所有雜湊槽移動到節點 B 和節點 C , 然後再移除空白(不包含任何雜湊槽)的節點 A 就可以了。

這裡需要注意的是,叢集如果是5主5從,主節點也是16384個hash slot,而不會因為主節點的增多slot也增多。我們在分槽的時候,儘量把槽平均分給主節點。因為一個key落在哪個槽裡面,是根據key的CRC16值模上16384得出的值來計算的。

2.Redis 叢集對節點使用了主從複製功能: 叢集中的每個節點都有 1 個至 N 個複製品(replica), 其中一個複製品為主節點(master), 而其餘的 N-1 個複製品為從節點(slave)。

我們知道叢集模式下,1主N從時,當主節點掛掉時,從節點通過心跳監聽機制,會競選成為主節點(這時設定的readonly會失效),所以在部署的時候,主從節點應該部署在不同的機器上,這個時候如果主節點的伺服器宕機,從節點競選成功後會繼續承擔讀寫的任務。

3.Redis 叢集的節點間通過Gossip協議通訊。

4.當前Redis叢集不支援NAT環境或者IP,埠重新對映的環境。

cluster這種模式適合資料量巨大的快取要求,當資料量不是很大使用sentinel即可。

5.以上四條全是網上大神總結的,所以我自己再加一條哈哈哈

2.4.2 叢集模式配置

安裝ruby環境:

普通Linux下:

     yum install ruby 
                yum install rubygems  
                gem install redis

Ubuntu下:

    Ubuntu的話安裝東西都需要獲得管理員許可權,所以跟Linux下不太一樣

    sudo apt-get install ruby

    sudo apt-get install rubygems

    sudo gem install redis

建立6個叢集檔案:

    redis6379.conf

    redis6380.conf

    redis6381.conf

    redis6382.conf

    redis6383.conf

    redis6384.conf

修改配置:

    cluster-enabled yes  --開啟叢集

    cluster-config-file nodes-6382.conf --叢集配置檔名,每個例項配置的要不同,redis會根據檔名自動新建

    這裡要注意:

        如果你沿用了上面的6379,6380和6391的話,需要註釋掉之前的slaveof 127.0.0.1 6379。因為兩個模式無法相容。

啟動叢集:

    進入redis資料夾下的src目錄,執行命令:

        ./redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6379

    這裡的節點,前三個表示master,後三個表示對應的slave。

    如圖:

    出現以上內容,輸入yes,叢集就搭建完畢了。

    登入任一臺redis,執行 info cluster,提示cluster_enabled:1

2.4.3 叢集過程

首先redis-trib.rb會以客戶端的形式嘗試連線所有的節點,併發送PING命令以確定節點能夠正常服務。如果有任何節點無法連線,則建立失敗。同時傳送 INFO 命令獲取每個節點的執行ID以及是否開啟了叢集功能(即cluster_enabled為1)。 準備就緒後集群會向每個節點發送 CLUSTER MEET命令,格式為 CLUSTER MEET ip port,這個命令用來告訴當前節點指定ip和port上在執行的節點也是叢集的一部分,從而使得6個節點最終可以歸入一個叢集。

然後redis-trib.rb會分配主從資料庫節點,分配的原則是儘量保證每個主資料庫執行在不同的IP地址上,同時每個從資料庫和主資料庫均不執行在同一IP地址上,以保證系統的容災能力

3主3從,當1個主故障,大家會給對應的從投票,把從立為主,若沒有從資料庫可以恢復則redis叢集就down了。

總結:

以上就是本文的全部內容,再次感謝網上大神們的總結。歡迎各位留言評論指出本文的不足。謝謝!