【51CTO.com原創稿件】 上一篇我們講解了 Redis 哨兵的工作原理，哨兵主要針對單節點故障無法自動恢復的解決方案，集群主要針對單節點容量、并發問題、線性可擴展性的解決方案。

圖片來自 Pexels

本篇我將講解 Redis 集群的工作原理，文末有你們想要的設置 SSH 背景哦!

本文主要圍繞如下幾個方面介紹集群：

• 集群簡介
• 集群作用
• 配置集群
• 手動、自動故障轉移
• 故障轉移原理

本文實現環境：

• CentOS 7.3
• Redis 4.0
• Redis 工作目錄 /usr/local/redis
• 所有操作均在虛擬機模擬進行

集群簡介

集群是為了解決主從復制中單機內存上限和并發問題，假如你現在的云服務內存為 256GB，當達到這個內存時 Redis 就沒辦法再提供服務。

同時數據量能達到這個地步寫數據量也會很大，容易造成緩沖區溢出，造成從節點無限的進行全量復制導致主從無法正常工作。

那么我們就需要把單機的主從改為多對多的方式，并且所有的主節點都會連接在一起互相通信。

這樣的方式既可以分擔單機內存，也可以分發請求，提高系統的可用性。

如下圖：當有大量請求寫入時，不再會單一的向一個主節點發送指令，而會把指令進行分流到各個主節點，達到分擔內存、避免大量請求的作用。

那么指令是如何進行分流存儲的呢?我們就需要到集群存儲結構中一探究竟。

集群作用

集群的作用有如下幾個：

• 分散單機的存儲能力，同時也可以很方便的實現擴展。
• 分流單機的訪問請求。
• 提高系統的可用性。

如何理解提高系統的可用性這句話，我們看下圖，當 master1 宕機后對系統的影響不會那么大，仍然可以提供正常的服務。

這個時候就會有人問了，當 master1 宕機后，集群這個時候怎么工作呀?這個問題會在下文的故障轉移來給你解答，并且在原理篇會對這個問題進行詳解。

集群存儲結構

存儲結構

單機的存儲是當用戶發起請求后直接把 key 存儲到自己的內存即可。

集群的存儲結構就沒有那么簡單了，首先當用戶發起一個 key 指令后需要做的事情如下：

• 通過 CRC16(key) 會計算出來一個值。
• 用這個值取模 16384，會得到一個值，我們就先認為是 28。
• 這個值 28 就是 key 保存的空間位置。

那么現在問題來了，這個 key 到底應該存儲在哪個 Redis 存儲空間里邊呢?

其實 Redis 在集群啟動后就已經把存儲空間劃分了 16384 份，每臺主機保存一部分。

這里需要注意的是我給每個 Redis 存儲空間里邊的編號就相當于一個小的存儲空間(專業術語“哈希槽”)。

你可以理解為一棟樓里邊的編號，一棟樓就是 Redis 的整個存儲空間，每個房子的編號就相當于一個存儲空間，這個存儲空間會有一定的區域來保存對應的 key，并非上圖取模后的位置。

箭頭指向的 28 是指的 28 會存儲在這個區域里，這個房子有可能會存儲 29、30、31 等。

此時問題來了，如果新增、減少一臺機器后怎么辦呢?看圖說話，能用圖說明盡量不去用文字。

在新增一臺機器后，會從其他三個存儲空間中拿出一定的槽分配給新的機器。這里可以自己設置想給新的機器放多少個槽。

同樣減少一臺機器后會把去掉的槽在重新分配給其它現有的機器跟新增節點一樣，可以指定節點接收槽。

所謂的增節點或去節點就是改變槽所存儲的位置不同。

了解了集群的存儲結構后，我們就需要在對另一個問題進行說明了，集群是如何設計內部通訊呢?

來了一個值，獲取一個 key，去哪拿數據?跟著這個問題我們看下文。

通訊設計

集群中的每個節點會在一定的時期給其它節點發送 ping 消息，其他節點返回 pong 作為響應。

經過一段時間后所有節點都會知道集群全部節點的槽信息。如下圖有三個節點，那么就會把 16384 個哈希槽分成三份。

分別為：

• 0-5500
• 5501-11000
• 11001-16384

當用戶發起了一個 key 的請求，集群是如何處理請求的呢?上圖的黑框代表這集群所有節點的槽信息，里邊還有很多其它信息。

如圖所示，用戶發起請求 key，Redis 接收后計算 key 的槽位置，在根據槽位置找出對應的節點。

如果訪問的槽就在節點本身，那么就會直接返回 key 對應數據。否則會回復 moved 重定向錯誤，并且給客戶端返回正確的節點。

然后重發 key 指令，如下圖：

配置集群

①修改配置文件

如下圖：

只需要注意圈中的配置信息即可：

• cluster-enabled yes：開啟集群模式。
• cluster-config-file nodes-6379.conf：集群配置文件。
• clustre-node-timeout 10000：節點超時時間，這里為了方便測試設置為 10s。

②構建 6 個節點的配置文件并全啟動

給大家提供一個命令可以很方便的替換文件：

sed?'s/6379/6380/g'?6379-redis.conf?>?6380-redis.conf?

按照這樣的方式創建出來 6 個不同端口的配置文件：

隨便打開一個配置文件查看，檢測是否替換成功：

為了查看日志信息方便，全部使用前臺啟動。并且查看服務是否都正常啟動，執行命令：

ps?-ef?|?grep?redis?

可以看到啟動后多了個 cluster 標識，代表著都是集群的一個節點。

所有節點啟動完成，集群啟動的指令需要基于 Ruby(本人使用 Redis 版本為 4.0)，接下來一起安裝。

③安裝 Ruby

執行命令：

wget?https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.1.tar.gz?

解壓(根據自己下載的版本來解壓)：

tar?-xvzf?ruby-2.7.1.tar.gz?

安裝：

./configure?|?make?|?make?install?

這三個指令一氣呵成，查看 ruby 和 gem 版本：ruby -v。

④啟動集群

集群的執行命令在 /usr/local/redis/src/redis-trib.rb，注意如果需要直接使用 redis-trib.rb 命令，需要 ln 到 bin 目錄下，否則就必須使用 ./redis-trib.rb 的方式。

如果按照步驟走，這里會出現一個錯誤，如下圖：

執行 gem install redis，很不幸的是在這里也會出現錯誤：

隨后需要安裝 yum install zlib-devel 和 yum install openssl-devel。

安裝完成后，在 /ruby-2.7.1/ext/openssl 和 /ruby-2.7.1/ext/zlib 分別執行 ruby extconf.rb，并且執行 make | make install。

然后再執行 gem install redis 就 OK：

這時再回頭來執行：

./redis-trib.rb?create?--replicas?1?127.0.0.1:6379?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?

信息解讀：創建集群，并且給 6 個節點分配哈希槽，后三個節點配置為前三個節點的從節點。

顯示每個節點的哈希槽信息和節點 ID，最后一步需要輸入 yes：

來到 data 目錄下查看配置文件的變化。配置文件主要信息是每個主節點分的槽：

查看主機點的運行日志：這里給的主要信息 cluster status changed:ok 集群狀態正常。

⑤集群設置與獲取數據

當直接設置數據會報錯，并且把 name 這個 key 進行轉化后的槽位置為 5798 并且給出了 ip 地址和端口號。

需要使用命令 redis-cli -c，在進行設置值的時候提示說重定向到 5798 的這個槽。

接下來進行獲取數據，會自動的切換節點：

故障轉移

①集群從節點下線

根據上文集群啟動信息知道端口 6383 是 6379 的從節點。接下來就是讓 6383 下線查看 6379 的日志信息。

6379 會報出連接 6383 丟失，并且給上標記 fail，表示不可用。這個時候集群還是正常工作的。

總結：從節點下線對集群沒有影響。

當端口 6383 上線后，所有的節點會把 fail 的標記清除，如下圖：

②集群主節點下線

手動下線主節點 6379，查看從節點 6383 日志信息，此時的 6383 節點會持續連接 6379 共計 10 次，那為什么是 10 次呢?

是根據我們配置的參數 cluster-node-timeout 10 來決定的，這里給我們一個信息就是一秒連接一次。

直到時間到期后，開始故障轉移。這時 6383 在故障轉移選舉中勝任，翻身奴隸把歌唱，成為了主節點。

此時在查看一下集群的節點信息，命令 cluster nodes。會發現這里竟然存在四個主節點，但是其中一個主節點時下線狀態：

6379 原主節點上線：6379 上線后，同樣所有的節點也會清除 fail 信息。并且節點信息也會改變，此時的 6379 改變為 6383 的從節點。

③新增主節點

再新增倆個端口 6385 和 6386：

執行新增命令 ./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379，這里發送的就是 meet 消息。

執行 add-node 命令，第一個參數為新節點的 ip+端口，第二個參數為已存在集群中的節點。根據下圖我們就可以看到新增的節點已經存在集群中了。

注意：雖說 6385 已經成為集群中的節點了，但是跟其它節點有區別。它沒有數據，也就是沒有哈希槽。

接下來我們就需要把集群中的某些哈希槽分配到這個新節點上，分配結束后這個節點才會成為真正意義上的主節點。

執行命令 ./redis-trib.rb reshard 127.0.0.1:6385，會提示轉移多少個哈希槽并填寫接收節點的 id。

最后一步詢問是否從所有節點中轉移：我使用的是 all。使用指令：cluster nodes 查看，6385 的這個節點就已經擁有三個范圍的哈希槽了。

主節點已經新增好了，接下來就需要給 6385 這個主節點配置一個從節點 6386，命令如下：

./redis-trib.rb add-node --slave --master-id dcc0ec4d0c932ac5c35ae76af4f9c5d27a422d9f 127.0.0.1:6386 127.0.0.1:6385

master-id 是 6385 的 id，第一個參數為新節點的 ip+端口，第二個為指定的主節點 ip+端口。

④手動故障遷移

當想對集群中的主節點進行升級的話可以手動執行故障轉移到從節點，避免集群可用性受影響。

在從節點執行命令：cluster failover。

執行過程：查看節點信息就可以看到 6386 這個節點已經成為了主機點。

當給從節點發送 cluster failover 指令后，從節點會給主節點發送 CLUSTERMSG_TYPE_MFSTART 包。從節點請求主節點停止訪問，從而對比兩者的數據偏移量達到一致。

這時客戶端不會連接我們淘汰的主節點，同時主節點向從節點發送復制偏移量，從節點得到復制偏移量后故障轉移開始，接著通知主節點進行配置切換。

當客戶端在舊的 master 上解鎖后，重新連接到新的主節點上。

故障轉移原理篇

上文中我們測試了故障轉移，主節點下線后從節點變為主節點，接下來剖析這個過程。

①故障發現到確認

集群中的每個節點會定期的給其它節點發送 ping 消息，接收方用 pong 作為回復。

如果在 cluster-node-timeout 的時間內 ping 消息一直失敗，則會把接收方的節點標記為 pfail 狀態也就是主觀下線。

這個下線狀態是不是很熟悉?沒錯，這個跟哨兵判斷主節點是否異常有點相似。

當一個哨兵發現主節點有問題時也會標記主節點客觀下線(s_down)。突然發現跑題了，尷尬......

再提一下哨兵，當一個哨兵認為主節點異常后標記主觀下線，但是其他哨兵怎么能會同意，不能你說什么就是什么。

都會去嘗試連接異常的主節點，當半數以上的哨兵都認為主節點異常后會直接讓其主節點客觀下線。

同樣集群也不會因為一個節點判斷其狀態為下線就行的，節點直接通過 Gossip 消息傳播，集群中節點會不斷收集故障節點的下線反饋并且存儲到本地的故障節點下線報告中。

當有半數以上的集群主節點都標記為主觀下線后改變狀態為客觀下線。最后向集群廣播一條 fail 消息，通知所有節點將故障節點標記為客觀下線。

例如：節點 A 發送 ping 到節點 B 通信異常后標記節點 B 為 pfail，之后節點 A 會繼續給節點 C 發送 ping，并且攜帶節點 B 的 pfail 信息，然后節點 C 將節點 B 的故障保存到下線報告中。

當下線報告數量大于有哈希槽主節點的一半數量以上后就會嘗試客觀下線。

②故障恢復(從節點從此翻身奴隸把歌唱)

當故障節點被定義為客觀下線后，故障節點的所有從節點承擔故障恢復的責任。

故障恢復是從節點通過定時任務發現自己的主機點客觀下線后就會執行故障恢復流程。

資格檢查：所有的從節點都會進行檢查與主節點最后的連接時間，斷線時間大于 cluster-node-time*cluster-slave-validity-factor 時不具備故障轉移的資格。

準備選舉時間：先說說為什么這里會有一個準備選舉時間。資格檢查過后存在多個從節點，那么就需要使用不同的延遲選舉時間來支持優先級。

這里的優先級就是以復制偏移量為基準，偏移量越大與故障主節點的延遲越小，那么就更有機會擁有替換主節點的機會。主要的作用就是確保數據一致性最好的節點優先發起選舉。

選舉投票：Redis 集群的投票機制沒有采用從節點進行領導選舉，這點切記不要跟哨兵搞混了。集群的投票機制都是持有槽的主機點進行投票的。

故障節點的從節點會廣播一個 FAILOVER_AUTH_REQUEST 數據包給所有的持有槽的主節點請求投票。

當主節點回復 FAILOVER_AUTH_ACK 投票后在 NODE_TIMEOUT * 2 的這段時間不能給其他的從節點投票。從節點獲取到半數以上的投票后就會進行故障恢復階段。

故障轉移：選舉成功的從節點取消復制變為主節點，刪除故障節點的槽，并且將故障節點的槽委托到自己身上，向集群廣播自己的 pong 消息，通知主機點的改變和接管了故障節點的槽信息。

福利：你們想要的 SSH 的背景

上一篇利用兩個夜晚才弄完的 Redis 哨兵文章，結果你們的關注點卻不在文章本身，啊!小編心很痛......

為了滿足大家的要求，我忍痛說一下如何設置亮瞎的背景，我使用的工具是xsheel。

打開工具選擇選項 ：

接著到查看有個窗口透明就可以設置 xsheel 透明了。

對嘍!你想的沒錯，這就是桌面背景，是不是準備開始設置去了?最后，歡迎各路大神給予技術點補充和辨錯。

作者：咔咔

簡介：從業三年，從搬磚一樣的生活方式換成了現在有“單”而居的日子。當然這個單不是單身的單!雖然極盡苛刻的技術學習但也遠不及客戶千奇百怪的要求。進入了朝九晚六，雖然躲過了風吹日曬，但是仍然很享受那些熬得只剩下黑眼圈的日子。堅持學習、堅持寫博、堅持分享是咔咔從業以來一直所秉持的信念。希望在諾大互聯網中咔咔的文章能帶給你一絲絲幫助。

編輯：陶家龍

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】

總結

以上是生活随笔為你收集整理的12c集群日志位置_面试问Redis集群，被虐的不行了......的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。