溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下Redis集群指的是什么，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
本文主要圍繞如下幾個方面介紹集群
集群是為了解決主從復制中單機內(nèi)存上限和并發(fā)問題，假如你現(xiàn)在的云服務內(nèi)存為256GB，當達到這個內(nèi)存時redis就沒辦法再提供服務，同時數(shù)據(jù)量能達到這個地步寫數(shù)據(jù)量也會很大，容易造成緩沖區(qū)溢出，造成從節(jié)點無限的進行全量復制導致主從無法正常工作。
那么我們就需要把單機的主從改為多對多的方式并且所有的主節(jié)點都會連接在一起互相通信。這樣的方式既可以分擔單機內(nèi)存，也可以分發(fā)請求，提高系統(tǒng)的可用性。
如圖：當有大量請求寫入時，不再會單一的向一個主節(jié)點發(fā)送指令，而會把指令進行分流到各個主節(jié)點，達到分擔內(nèi)存、避免大量請求的作用。
那么指令是如何進行分流存儲的呢！我們就需要到集群存儲結構中一探究竟。
如何理解提高系統(tǒng)的可用性這句話，我們看下圖，當master1宕機后對系統(tǒng)的影響不會那么大，仍然可以提供正常的服務。
這個時候就會有人問了，當master1宕機后集群這個時候怎么工作呀！這個問題會在下文的故障轉移來給你解答。并且在原理篇會對這個問題進行詳解
單機的存儲是當用戶發(fā)起請求后直接把key存儲到自己的內(nèi)存即可。
集群的存儲結構就沒有那么簡單了，首先當用戶發(fā)起一個key指令后需要做的事情。
那么現(xiàn)在問題來了，這個key到底應該存儲在那個redis存儲空間里邊呢！
其實redis在集群啟動后就已經(jīng)把存儲空間劃分了16384份，每臺主機保存一部分。
這里需要注意的是我給每個redis存儲空間里邊的編號就相當于一個小的存儲空間（專業(yè)術語“哈希槽”），你可以理解為一棟樓里邊的編號，一棟樓就是redis的整個存儲空間，每個房子的編號就相當于一個存儲空間，這個存儲空間會有一定的區(qū)域來保存對應的key，并非上圖取模后的位置。
箭頭指向的28是指的28會存儲在這個區(qū)域里，這個房子有可能會存儲29、30、31等。
此時問題來了，如果新增、減少一臺機器后怎么辦呢！看圖說話，能用圖說明盡量不去用文字。
在新增一臺機器后，會從其他三個存儲空間中拿出一定的槽分配給新的機器。這里可以自己設置想給新的機器放多少個槽。
同樣減少一臺機器后會把去掉的槽在重新分配給其它現(xiàn)有的機器跟新增節(jié)點一樣，可以指定節(jié)點接收槽。
所謂的增節(jié)點或去節(jié)點就是改變槽所存儲的位置不同。
了解了集群的存儲結構后，我們就需要在對另一個問題進行說明了，集群是如何設計內(nèi)部通訊呢！來了一個值，獲取一個key，去哪拿數(shù)據(jù)，跟著這個問題我們看下文。
集群中的每個節(jié)點會在一定的時期給其它節(jié)點發(fā)送ping消息，其它節(jié)點返回pong作為響應。經(jīng)過一段時間后所有節(jié)點都會知道集群全部節(jié)點的槽信息。
如下圖有三個節(jié)點，那么就會把16384個哈希槽分成三份。
分別為0-5500、5501-11000、11001-16384
當用戶發(fā)起了一個key的請求，集群是如何處理請求的呢！
下圖的黑框代表這集群所有節(jié)點的槽信息，里邊還有很多其它信息。
如圖所示，用戶發(fā)起請求key，redis接收后計算key的槽位置，在根據(jù)槽位置找出對應的節(jié)點
如果訪問的槽就在節(jié)點本身，那么就會直接返回key對應數(shù)據(jù)。
否則會回復moved重定向錯誤， 并且給客戶端返回正確的節(jié)點。
然后重發(fā)key指令
只需要注意咔咔圈中的配置信息即可
咔咔給大家提供一個命令可以很方便的替換文件sed 's/6379/6380/g' 6379-redis.conf > 6380-redis.conf
按照這樣的方式創(chuàng)建出來6個不同端口的配置文件
隨便打開一個配置文件查看，檢測是否替換成功
為了查看日志信息方便，全部使用前臺啟動。并且查看服務是否都正常啟動，執(zhí)行命令ps -ef | grep redis
可以看到啟動后多了個cluster標識，代表著都是集群的一個節(jié)點。
所有節(jié)點啟動完成，集群啟動的指令需要基于ruby（咔咔使用redis版本為4.0）。接下來一起安裝
執(zhí)行命令wget https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.1.tar.gz
解壓：tar -xvzf ruby-2.7.1.tar.gz 根據(jù)自己下載的版本來解壓
安裝：./configure | make | make install這三個指令一氣呵成。
查看ruby和gem版本：ruby -v
集群的執(zhí)行命令在/usr/local/redis/src/redis-trib.rb
注意如果需要直接使用redis-trib.rb命令，需要ln到bin目錄下，否則就必須使用./redis-trib.rb的方式。
如果按照步驟走，這里會出現(xiàn)一個錯誤
執(zhí)行gem install redis很不幸的是在這里也會出現(xiàn)錯誤。
隨后需要安裝yum install zlib-devel和yum install openssl-devel
安裝完成后，在/ruby-2.7.1/ext/openssl 和 /ruby-2.7.1/ext/zlib 分別執(zhí)行ruby extconf.rb并且執(zhí)行make | make install
然后在執(zhí)行gem install redis就OK
這時在回頭來執(zhí)行./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
「信息解讀」
創(chuàng)建集群，并且給6個節(jié)點分配哈希槽，后三個節(jié)點配置為前三個節(jié)點的從節(jié)點
顯示每個節(jié)點的哈希槽信息和節(jié)點ID，最后一步需要輸入yes
來到data目錄下查看配置文件的變化。配置文件主要信息是每個主節(jié)點分的槽
「查看主機點的運行日志」
這里給的主要信息cluster status changed:ok 集群狀態(tài)正常
當直接設置數(shù)據(jù)會報錯，并且把name這個key進行轉化后的槽位置為5798 并且給出了ip地址和端口號。
需要使用命令redis-cli -c
在進行設置值的時候提示說重定向到5798的這個槽
接下來進行獲取數(shù)據(jù)，會自動的切換節(jié)點。
根據(jù)上文集群啟動信息知道端口6383是6379的從節(jié)點。
接下來就是讓6383下線查看6379的日志信息。
6379會報出連接6383丟失，并且給上標記fail，表示不可用。這個時候集群還是正常工作的。
「總結：從節(jié)點下線對集群沒有影響」
當端口6383上線后，所有的節(jié)點會把fail的標記清除
手動下線主節(jié)點6379，查看從節(jié)點6383日志信息
此時的6383節(jié)點會持續(xù)連接6379共計10次。那為什么是10次呢！
是根據(jù)我們配置的參數(shù)cluster-node-timeout 10來決定的，這里給我們一個信息就是一秒連接一次
直到時間到期后，開始故障轉移。
這時6383在故障轉移選舉中勝任，翻身奴隸把歌唱，成為了主節(jié)點。
此時在查看一下集群的節(jié)點信息，命令cluster nodes。
會發(fā)現(xiàn)這里竟然存在四個主節(jié)點，但是其中一個主節(jié)點時下線狀態(tài)
「6379原主節(jié)點上線」
6379上線后，同樣所有的節(jié)點也會清除fail信息。
并且節(jié)點信息也會改變，此時的6379改變?yōu)?383的從節(jié)點。
在新增倆個端口6385和6386
執(zhí)行新增命令./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379，這里發(fā)送的就是meet消息
執(zhí)行add-node命令，第一個參數(shù)為新節(jié)點的ip+端口 第二個參數(shù)為已存在集群中的節(jié)點。根據(jù)下圖我們就可以看到新增的節(jié)點已經(jīng)存在集群中了。
「注意：雖說6385已經(jīng)成為集群中的節(jié)點了，但是跟其它節(jié)點有區(qū)別。它沒有數(shù)據(jù)，也就是沒有哈希槽」
接下來我們就需要把集群中的某些哈希槽分配到這個新節(jié)點上，分配結束后這個節(jié)點才會成為真正意義上的主節(jié)點
執(zhí)行命令./redis-trib.rb reshard 127.0.0.1:6385
會提示轉移多少個哈希槽并填寫接收節(jié)點的id
最后一步詢問是否從所有節(jié)點中轉移：咔咔使用的是all
使用指令：cluster nodes查看，6385的這個節(jié)點就已經(jīng)擁有三個范圍的哈希槽了
「主節(jié)點已經(jīng)新增好了，接下來就需要給6385這個主節(jié)點配置一個從節(jié)點6386」
命令：./redis-trib.rb add-node --slave --master-id dcc0ec4d0c932ac5c35ae76af4f9c5d27a422d9f 127.0.0.1:6386 127.0.0.1:6385
master-id是6385的id，第一個參數(shù)為新節(jié)點的ip+端口 第二個為指定的主節(jié)點ip+端口
當想對集群中的主節(jié)點進行升級的話可以手動執(zhí)行故障轉移到從節(jié)點，避免集群可用性受影響。
在從節(jié)點執(zhí)行命令：cluster failover
「執(zhí)行過程」
查看節(jié)點信息就可以看到6386這個節(jié)點已經(jīng)成為了主機點。
當給從節(jié)點發(fā)送cluster failover 指令后，從節(jié)點會給主節(jié)點發(fā)送CLUSTERMSG_TYPE_MFSTART包。從節(jié)點請求主節(jié)點停止訪問，從而對比兩者的數(shù)據(jù)偏移量達到一致。
這時客戶端不會連接我們淘汰的主節(jié)點，同時主節(jié)點向從節(jié)點發(fā)送復制偏移量,從節(jié)點得到復制偏移量后故障轉移開始,接著通知主節(jié)點進行配置切換,當客戶端在舊的master上解鎖后重新連接到新的主節(jié)點上。
上文中我們測試了故障轉移，主節(jié)點下線后從節(jié)點變?yōu)橹鞴?jié)點，接下來剖析這個過程。
集群中的每個節(jié)點會定期的給其它節(jié)點發(fā)送ping消息，接收方用pong作為回復。
如果在cluster-node-timeout的時間內(nèi)ping消息一直失敗，則會把接收方的節(jié)點標記為pfail狀態(tài)也就是主觀下線。
這個下線狀態(tài)是不是很熟悉。沒錯，這個跟哨兵判斷主節(jié)點是否異常有點相似。當一個哨兵發(fā)現(xiàn)主節(jié)點有問題時也會標記主節(jié)點客觀下線(s_down)。 突然發(fā)現(xiàn)跑題了，尷尬.......
在提一下哨兵，當一個哨兵認為主節(jié)點異常后標記主觀下線，但是其它哨兵怎么能會同意，不能你說什么就是什么。都會去嘗試連接異常的主節(jié)點，當半數(shù)以上的哨兵都認為主節(jié)點異常后會直接讓其主節(jié)點客觀下線。
同樣集群也不會因為一個節(jié)點判斷其狀態(tài)為下線就行的，節(jié)點直接通過Gossip消息傳播，集群中節(jié)點會不斷收集故障節(jié)點的下線反饋并且存儲到本地的故障節(jié)點下線報告中。當有半數(shù)以上的集群主節(jié)點都標記為主觀下線后改變狀態(tài)為客觀下線。
最后向集群廣播一條fail消息，通知所有節(jié)點將故障節(jié)點標記為客觀下線。
例如：節(jié)點A發(fā)送ping到節(jié)點B通信異常后標記節(jié)點B為pfail，之后節(jié)點A會繼續(xù)給節(jié)點C發(fā)送ping并且攜帶節(jié)點B的pfail信息然后節(jié)點C將節(jié)點B的故障保存到下線報告中。當下線報告數(shù)量大于有哈希槽主節(jié)點的一半數(shù)量以上后就會嘗試客觀下線。
當故障節(jié)點被定義為客觀下線后，故障節(jié)點的所有從節(jié)點承擔故障恢復的責任。
故障恢復是從節(jié)點通過定時任務發(fā)現(xiàn)自己的主機點客觀下線后就會執(zhí)行故障恢復流程。
「1. 資格檢查」
所有的從節(jié)點都會進行檢查與主節(jié)點最后的連接時間，斷線時間大于cluster-node-time*cluster-slave-validity-factor時不具備故障轉移的資格。
「2. 準備選舉時間」
先說說為什么這里會有一個準備選舉時間。
資格檢查過后存在多個從節(jié)點，那么就需要使用不同的延遲選舉時間來支持優(yōu)先級。這里的優(yōu)先級就是 以復制偏移量為基準，偏移量越大與故障主節(jié)點的延遲越小，那么就更有機會擁有替換主節(jié)點的機會。
主要的作用就是確保數(shù)據(jù)一致性最好的節(jié)點優(yōu)先發(fā)起選舉
「3.選舉投票」
redis集群的投票機制沒有采用從節(jié)點進行領導選舉，這點切記不要跟哨兵搞混了。集群的投票機制都是持有槽的主機點進行投票的。
故障節(jié)點的從節(jié)點會廣播一個FAILOVER_AUTH_REQUEST 數(shù)據(jù)包給所有的持有槽的主節(jié)點請求投票。
當主節(jié)點回復FAILOVER_AUTH_ACK投票后在NODE_TIMEOUT * 2的這段時間不能給其它的從節(jié)點投票
從節(jié)點獲取到半數(shù)以上的投票后就會進行故障恢復階段
「4. 故障轉移」
選舉成功的從節(jié)點取消復制變?yōu)橹鞴?jié)點
刪除故障節(jié)點的槽，并且將故障節(jié)點的槽委托到自己身上
向集群廣播自己的pong消息，通知主機點的改變和接管了故障節(jié)點的槽信息。
一篇利用倆個夜晚才弄完的redis哨兵文章，結果你們的關注點卻不在文章本身，??！小編心很痛
為了滿足大家的要求，咔咔忍痛說一下如何設置亮瞎的背景。
咔咔使用的工具是xsheel
打開工具選擇選項
接著到查看有個窗口透明就可以設置xsheel透明了。
對嘍！你想的沒錯這就是桌面背景，是不是準備開始設置去了。那設置完了回來再把文章看完好嗎？咔咔也需要各路大神給予技術點補充和辨錯。
以上是Redis集群指的是什么的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內(nèi)容。
