您好,登錄后才能下訂單哦!
再認識redis集群前,若想先知道redis單機版的可查看,springboot整合redis。好了,下面開始了。
每個redis實例可稱為一個節點,安裝redis并以默認端口啟動是節點,不關閉,以另一個端口啟動,是一個新節點。在另一臺機器安裝redis并啟動,也是一個新節點。
節點分為主節點 (master) ,從節點 (slave) ,數據從主節點向多個從節點上同步 。
redis3.0開始支持集群,redis集群是沒有統一的入口的,客戶端(client)連接集群的時候連接集群中的任意節點(node)即可,集群內部的節點是相互通信的(PING-PONG機制)。
@[toc]
一個master可以擁有多個slave,但是一個slave只能對應一個master。這樣,當某個slave掛了不影響其他slave的讀和master的讀和寫,重新啟動后會,數據會從master上同步過來。
在主從模式下,因為只有一個主節點可以寫,而主,從節點都可以讀,所以通常主節點負責寫,從節點負責讀。
但是,當唯一的master掛了以后,雖然這樣并不影響slave的讀,但redis也不再提供寫服務,需要將master重啟后,redis才重新對外提供寫服務。
sentinel模式是建立在主從模式的基礎上,避免單個master掛了以后,redis不能提供寫服務。因為從節點上備份了主節點的所有數據,那么當master掛了以后,sentinel會在slave中選擇一個做為master,并修改它們的配置文件,其他slave的配置文件也會被修改,比如slaveof屬性會指向新的master,比如之前配置的密碼。此時,客戶端就不是直接連接Redis,而是連接sentinel的ip和port,由sentinel來提供具體Redis服務。
把之前掛了的master重新啟動后,它將不再是master而是做為slave接收新的master的同步數據。
Cluster模式是建立在Sentinel模式的基礎上的,當數據多到需要動態擴容的時候,前面兩種就不行了,需要對數據進行分片,根據一定的規則把redis數據分配到多臺機器。
該模式就支持動態擴容,可以在線增加或刪除節點,而且客戶端可以連接任何一個主節點進行讀寫,不過此時的從節點僅僅只是備份的作用。至于為何能做到動態擴容,主要是因為Redis 集群沒有使用一致性hash, 而是使用的哈希槽。Redis 集群會有16384個哈希槽,每個key通過CRC16校驗后對16384取模來決定放置哪個槽,而集群的每個節點負責一部分hash槽。
那么這樣就很容易添加或者刪除節點, 比如如果我想新添加個新節點, 我只需要從已有的節點中得部分槽到過來;如果我想移除某個節點,就只需要將該節點的槽移到其它節點上,然后將沒有任何槽的A節點從集群中移除即可。由于從一個節點將哈希槽移動到另一個節點并不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態。
需要注意的是,該模式下不支持同時處理多個key(如MSET/MGET),因為redis需要把key均勻分布在各個節點上,并發量很高的情況下同時創建key-value會降低性能并導致不可預測的行為。
這里就直接搭建較為復雜的Cluster模式集群,也是企業級開發過程中使用最多的。
Linux可以連接外網,有wget(用于在線下載redis),系統安裝好gcc環境,(不然編譯redis會報錯)。
wget http://download.redis.io/releases/redis-5.0.4.tar.gz
tar xzf redis-5.0.4.tar.gz
mv redis-5.0.4 /usr/local/redis
cd /usr/local/redis/redis-5.0.4
make
make install
安裝完成,在/usr/local/bin/
目錄下就會看見
mkdir /usr/local/redis-cluster
cd /usr/local/redis-cluster
mkdir -p 9001/data 9002/data 9003/data 9004/data 9005/data 9006/data
mkdir bin
最終目錄結構如下
把之前安裝好的redis的src目錄下運行腳本拷貝過來,每個redis版本的運行腳本有細微差異,請以你自己的版本為準,就是下圖綠色部分。
cd /usr/local/redis/redis-5.0.4/src
cp mkreleasehdr.sh redis-benchmark redis-check-aof redis-check-rdb redis-cli redis-sentinel redis-server redis-trib.rb /usr/local/redis-cluster/bin
最終效果如下圖所示
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9001
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9002
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9003
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9004
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9005
cp /usr/local/redis/redis-5.0.4/* /usr/local/redis-cluster/9006
最終效果圖如下所示
以 9001 的為例子,其余五個類似。
cd /usr/local/redis-cluster/9001
vi redis.conf
打開配置文件,按 i
進入編輯模式,按照出現的順序,主要需要修改的地方是
:wq
保存并退出。 類似同樣的操作操作再來五次。若是對redis的配置文件有興趣,我在學習的過程中找到個詳細的翻譯版,可點擊鏈接進去學習。
redis配置中文翻譯
cd /usr/local/redis-cluster
/usr/local/bin/redis-server /usr/local/redis-cluster/9001/redis.conf
/usr/local/bin/redis-server /usr/local/redis-cluster/9002/redis.conf
/usr/local/bin/redis-server /usr/local/redis-cluster/9003/redis.conf
/usr/local/bin/redis-server /usr/local/redis-cluster/9004/redis.conf
/usr/local/bin/redis-server /usr/local/redis-cluster/9005/redis.conf
/usr/local/bin/redis-server /usr/local/redis-cluster/9006/redis.conf
運行效果如圖所示
現在檢查一下是否成功開啟,如下圖所示,都開啟成功。
ps -el | grep redis
此時的節點雖然都啟動成功了,但他們還不在一個集群里面,不能互相發現,測試會報錯:(error) CLUSTERDOWN Hash slot not served
。
/usr/local/redis-cluster/bin/redis-cli -h 192.168.119.128 -p 9001
keys *
set name mafly
如下圖所示
解決報錯,如果你是redis5.0以前的,你需要安裝集群所需的ruby相關依賴
yum install ruby
yum install rubygems
cd /usr/local/redis-cluster/
gem install redis
這步若安裝報錯,請查看Could not find a valid gem 'redis'
如果你是redis5.0及之后的,無需安裝ruby依賴,redis安裝目錄里內置了集群命令行工具 redis-trib ,它是一個 Ruby 程序, 這個程序通過向實例發送特殊命令來完成創建新集群, 檢查集群, 或者對集群進行重新分片工作。
redis-cli --cluster create 192.168.119.128:9001 192.168.119.128:9002 192.168.119.128:9003 192.168.119.128:9004 192.168.119.128:9005 192.168.119.128:9006 --cluster-replicas 1
--cluster-replicas 1 這個指的是從機的數量,表示我們希望為集群中的每個主節點創建一個從節點。
紅色選框是給三個主節點分配的共16384個槽點。
黃色選框是主從節點的分配情況。
藍色選框是各個節點的詳情。
現在通過客戶端命令連接上,通過集群命令看一下狀態和節點信息等
/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9001
cluster info
cluster nodes
效果圖如下,集群搭建成功。
現在往9001這個主節點寫入一條信息,我們可以在9002這個主節點取到信息,集群間各個節點可以通信。
現在往9001這個主節點寫入一條信息,我們可以在9002這個主節點取到信息,集群間各個節點可以通信。
set name lgx
get name
集群中的節點會向其它節點發送PING消息(該PING消息會帶著當前集群和節點的信息),如果在規定時間內,沒有收到對應的PONG消息,就把此節點標記為疑似下線。
當被分配了slot槽位的主節點中有超過一半的節點都認為此節點疑似下線(就是其它節點以更高的頻次,更頻繁的與該節點PING-PONG),那么該節點就真的下線。
其它節點收到某節點已經下線的廣播后,把自己內部的集群維護信息也修改為該節點已事實下線。
節點資格審查:然后對從節點進行資格審查,每個從節點檢查最后與主節點的斷線時間,如果該值超過配置文件的設置,那么取消該從節點的資格。
準備選舉時間:這里使用了延遲觸發機制,主要是給那些延遲低的更高的優先級,延遲低的讓它提前參與被選舉,延遲高的讓它靠后參與被選舉。(延遲的高低是依據之前與主節點的最后斷線時間確定的)
選舉投票:當從節點獲取選舉資格后,會向其他帶有slot槽位的主節點發起選舉請求,由它們進行投票,優先級越高的從節點就越有可能成為主節點,當從節點獲取的票數到達一定數值時(如集群內有N個主節點,那么只要有一個從節點獲得了N/2+1的選票即認為勝出),就會替換成為主節點。
替換主節點:被選舉出來的從節點會執行slaveof no one把自己的狀態從slave變成master,然后執行clusterDelSlot操作撤銷故障主節點負責的槽,并執行 clusterAddSlot把這些槽分配給自己,之后向集群廣播自己的pong消息,通知集群內所有的節點,當前從節點已變為主節點。
這是之前集群中具體節點的情況,我簡化成如下,可以向上回看圖片中的集群信息。
這里關閉該9001端口的進程,即模擬該主節點掛掉。
netstat -tunlp | grep 9001
kill 15705
登錄掛掉的redis節點,會被拒絕服務,通過還在正常運行的某個主節點進入,然后再次查看集群中的信息
/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9001
/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9002
cluster nodes
簡而言之,就是之前的集群信息變成了如下所示
現在,我重啟剛才掛掉的主節點,重新查看集群內部的節點情況,具體情況如下圖所示。
cd /usr/local/redis-cluster/
/usr/local/bin/redis-server /usr/local/redis-cluster/9001/redis.conf
/usr/local/redis-cluster/bin/redis-cli -c -h 192.168.119.128 -p 9002
cluster nodes
簡而言之,現在集群內的節點情況如下
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。