久久久久久久视色,久久电影免费精品,中文亚洲欧美乱码在线观看,在线免费播放AV片

<center id="vfaef"><input id="vfaef"><table id="vfaef"></table></input></center>

    <p id="vfaef"><kbd id="vfaef"></kbd></p>

    
    
    <pre id="vfaef"><u id="vfaef"></u></pre>

      <thead id="vfaef"><input id="vfaef"></input></thead>

    1. 站長(zhǎng)資訊網(wǎng)
      最全最豐富的資訊網(wǎng)站

      面試問(wèn)Redis集群,被虐的不行了……

      ?

      哨兵主要針對(duì)單節(jié)點(diǎn)故障無(wú)法自動(dòng)恢復(fù)的解決方案,集群主要針對(duì)單節(jié)點(diǎn)容量、并發(fā)問(wèn)題、線性可擴(kuò)展性的解決方案。本文使用官方提供的redis cluster。文末有你們想要的設(shè)置ssh背景哦!

      ?

      前言

      ?

      咔咔整理了一個(gè)路線圖,打造一份面試寶典,準(zhǔn)備按照這樣的路線圖進(jìn)行編寫(xiě)文章,后期發(fā)現(xiàn)沒(méi)有補(bǔ)充到的知識(shí)點(diǎn)在進(jìn)行添加。也期待各位伙伴一起來(lái)幫助補(bǔ)充一下。評(píng)論區(qū)見(jiàn)哦!

      ?

      面試問(wèn)Redis集群,被虐的不行了......
      在這里插入圖片描述

      本文主要圍繞如下幾個(gè)方面介紹集群

      • 集群簡(jiǎn)介
      • 集群作用
      • 配置集群
      • 手動(dòng)、自動(dòng)故障轉(zhuǎn)移
      • 故障轉(zhuǎn)移原理

      本文實(shí)現(xiàn)環(huán)境

      • centos 7.3
      • redis 4.0
      • redis工作目錄 /usr/local/redis
      • 所有操作均在虛擬機(jī)模擬進(jìn)行

      一、集群簡(jiǎn)介

      集群是為了解決主從復(fù)制中單機(jī)內(nèi)存上限和并發(fā)問(wèn)題,假如你現(xiàn)在的云服務(wù)內(nèi)存為256GB,當(dāng)達(dá)到這個(gè)內(nèi)存時(shí)redis就沒(méi)辦法再提供服務(wù),同時(shí)數(shù)據(jù)量能達(dá)到這個(gè)地步寫(xiě)數(shù)據(jù)量也會(huì)很大,容易造成緩沖區(qū)溢出,造成從節(jié)點(diǎn)無(wú)限的進(jìn)行全量復(fù)制導(dǎo)致主從無(wú)法正常工作。

      面試問(wèn)Redis集群,被虐的不行了......
      在這里插入圖片描述

      那么我們就需要把單機(jī)的主從改為多對(duì)多的方式并且所有的主節(jié)點(diǎn)都會(huì)連接在一起互相通信。這樣的方式既可以分擔(dān)單機(jī)內(nèi)存,也可以分發(fā)請(qǐng)求,提高系統(tǒng)的可用性。

      如圖:當(dāng)有大量請(qǐng)求寫(xiě)入時(shí),不再會(huì)單一的向一個(gè)主節(jié)點(diǎn)發(fā)送指令,而會(huì)把指令進(jìn)行分流到各個(gè)主節(jié)點(diǎn),達(dá)到分擔(dān)內(nèi)存、避免大量請(qǐng)求的作用。

      那么指令是如何進(jìn)行分流存儲(chǔ)的呢!我們就需要到集群存儲(chǔ)結(jié)構(gòu)中一探究竟。面試問(wèn)Redis集群,被虐的不行了......

      二、集群作用

      • 分散單機(jī)的存儲(chǔ)能力,同時(shí)也可以很方便的實(shí)現(xiàn)擴(kuò)展。
      • 分流單機(jī)的訪問(wèn)請(qǐng)求
      • 提高系統(tǒng)的可用性

      如何理解提高系統(tǒng)的可用性這句話,我們看下圖,當(dāng)master1宕機(jī)后對(duì)系統(tǒng)的影響不會(huì)那么大,仍然可以提供正常的服務(wù)。

      這個(gè)時(shí)候就會(huì)有人問(wèn)了,當(dāng)master1宕機(jī)后集群這個(gè)時(shí)候怎么工作呀!這個(gè)問(wèn)題會(huì)在下文的故障轉(zhuǎn)移來(lái)給你解答。并且在原理篇會(huì)對(duì)這個(gè)問(wèn)題進(jìn)行詳解面試問(wèn)Redis集群,被虐的不行了......

      三、集群存儲(chǔ)結(jié)構(gòu)

      1. 存儲(chǔ)結(jié)構(gòu)

      單機(jī)的存儲(chǔ)是當(dāng)用戶發(fā)起請(qǐng)求后直接把key存儲(chǔ)到自己的內(nèi)存即可。面試問(wèn)Redis集群,被虐的不行了......集群的存儲(chǔ)結(jié)構(gòu)就沒(méi)有那么簡(jiǎn)單了,首先當(dāng)用戶發(fā)起一個(gè)key指令后需要做的事情。

      • 通過(guò)CRC16(key)會(huì)計(jì)算出來(lái)一個(gè)值
      • 用這個(gè)值取模16384,會(huì)得到一個(gè)值,我們就先認(rèn)為是28
      • 這個(gè)值28就是key保存的空間位置

      那么現(xiàn)在問(wèn)題來(lái)了,這個(gè)key到底應(yīng)該存儲(chǔ)在那個(gè)redis存儲(chǔ)空間里邊呢!面試問(wèn)Redis集群,被虐的不行了......

      其實(shí)redis在集群?jiǎn)?dòng)后就已經(jīng)把存儲(chǔ)空間劃分了16384份,每臺(tái)主機(jī)保存一部分。

      這里需要注意的是我給每個(gè)redis存儲(chǔ)空間里邊的編號(hào)就相當(dāng)于一個(gè)小的存儲(chǔ)空間(專(zhuān)業(yè)術(shù)語(yǔ)“哈希槽”),你可以理解為一棟樓里邊的編號(hào),一棟樓就是redis的整個(gè)存儲(chǔ)空間,每個(gè)房子的編號(hào)就相當(dāng)于一個(gè)存儲(chǔ)空間,這個(gè)存儲(chǔ)空間會(huì)有一定的區(qū)域來(lái)保存對(duì)應(yīng)的key,并非上圖取模后的位置。

      箭頭指向的28是指的28會(huì)存儲(chǔ)在這個(gè)區(qū)域里,這個(gè)房子有可能會(huì)存儲(chǔ)29、30、31等。

      面試問(wèn)Redis集群,被虐的不行了......此時(shí)問(wèn)題來(lái)了,如果新增、減少一臺(tái)機(jī)器后怎么辦呢!看圖說(shuō)話,能用圖說(shuō)明盡量不去用文字。

      在新增一臺(tái)機(jī)器后,會(huì)從其他三個(gè)存儲(chǔ)空間中拿出一定的槽分配給新的機(jī)器。這里可以自己設(shè)置想給新的機(jī)器放多少個(gè)槽。

      同樣減少一臺(tái)機(jī)器后會(huì)把去掉的槽在重新分配給其它現(xiàn)有的機(jī)器跟新增節(jié)點(diǎn)一樣,可以指定節(jié)點(diǎn)接收槽。

      所謂的增節(jié)點(diǎn)或去節(jié)點(diǎn)就是改變槽所存儲(chǔ)的位置不同。面試問(wèn)Redis集群,被虐的不行了......了解了集群的存儲(chǔ)結(jié)構(gòu)后,我們就需要在對(duì)另一個(gè)問(wèn)題進(jìn)行說(shuō)明了,集群是如何設(shè)計(jì)內(nèi)部通訊呢!來(lái)了一個(gè)值,獲取一個(gè)key,去哪拿數(shù)據(jù),跟著這個(gè)問(wèn)題我們看下文。

      2. 通訊設(shè)計(jì)

      集群中的每個(gè)節(jié)點(diǎn)會(huì)在一定的時(shí)期給其它節(jié)點(diǎn)發(fā)送ping消息,其它節(jié)點(diǎn)返回pong作為響應(yīng)。經(jīng)過(guò)一段時(shí)間后所有節(jié)點(diǎn)都會(huì)知道集群全部節(jié)點(diǎn)的槽信息。

      如下圖有三個(gè)節(jié)點(diǎn),那么就會(huì)把16384個(gè)哈希槽分成三份。

      分別為0-5500、5501-11000、11001-16384

      當(dāng)用戶發(fā)起了一個(gè)key的請(qǐng)求,集群是如何處理請(qǐng)求的呢!

      下圖的黑框代表這集群所有節(jié)點(diǎn)的槽信息,里邊還有很多其它信息。面試問(wèn)Redis集群,被虐的不行了......

      如圖所示,用戶發(fā)起請(qǐng)求key,redis接收后計(jì)算key的槽位置,在根據(jù)槽位置找出對(duì)應(yīng)的節(jié)點(diǎn)

      如果訪問(wèn)的槽就在節(jié)點(diǎn)本身,那么就會(huì)直接返回key對(duì)應(yīng)數(shù)據(jù)。

      否則會(huì)回復(fù)moved重定向錯(cuò)誤, 并且給客戶端返回正確的節(jié)點(diǎn)。

      然后重發(fā)key指令

      面試問(wèn)Redis集群,被虐的不行了......
      在這里插入圖片描述

      四、配置集群

      1. 修改配置文件

      面試問(wèn)Redis集群,被虐的不行了......只需要注意咔咔圈中的配置信息即可

      • cluster-enabled yes:開(kāi)啟集群模式
      • cluster-config-file nodes-6379.conf:集群配置文件
      • clustre-node-timeout 10000:節(jié)點(diǎn)超時(shí)時(shí)間,這里為了方便測(cè)試設(shè)置為10s
      面試問(wèn)Redis集群,被虐的不行了......
      在這里插入圖片描述

      2. 構(gòu)建6個(gè)節(jié)點(diǎn)的配置文件并全啟動(dòng)

      咔咔給大家提供一個(gè)命令可以很方便的替換文件sed 's/6379/6380/g' 6379-redis.conf > 6380-redis.conf

      按照這樣的方式創(chuàng)建出來(lái)6個(gè)不同端口的配置文件

      面試問(wèn)Redis集群,被虐的不行了......隨便打開(kāi)一個(gè)配置文件查看,檢測(cè)是否替換成功面試問(wèn)Redis集群,被虐的不行了......為了查看日志信息方便,全部使用前臺(tái)啟動(dòng)。并且查看服務(wù)是否都正常啟動(dòng),執(zhí)行命令ps -ef | grep redis

      可以看到啟動(dòng)后多了個(gè)cluster標(biāo)識(shí),代表著都是集群的一個(gè)節(jié)點(diǎn)。面試問(wèn)Redis集群,被虐的不行了......所有節(jié)點(diǎn)啟動(dòng)完成,集群?jiǎn)?dòng)的指令需要基于ruby(咔咔使用redis版本為4.0)。接下來(lái)一起安裝

      3. 安裝ruby

      執(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ù)自己下載的版本來(lái)解壓

      安裝:./configure | make | make install這三個(gè)指令一氣呵成。

      查看ruby和gem版本:ruby -v

      面試問(wèn)Redis集群,被虐的不行了......
      在這里插入圖片描述

      4. 啟動(dòng)集群

      集群的執(zhí)行命令在/usr/local/redis/src/redis-trib.rb

      注意如果需要直接使用redis-trib.rb命令,需要ln到bin目錄下,否則就必須使用./redis-trib.rb的方式。

      如果按照步驟走,這里會(huì)出現(xiàn)一個(gè)錯(cuò)誤面試問(wèn)Redis集群,被虐的不行了......執(zhí)行gem install redis很不幸的是在這里也會(huì)出現(xiàn)錯(cuò)誤。面試問(wèn)Redis集群,被虐的不行了......隨后需要安裝yum install zlib-develyum 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面試問(wèn)Redis集群,被虐的不行了......這時(shí)在回頭來(lái)執(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面試問(wèn)Redis集群,被虐的不行了......「信息解讀」

      創(chuàng)建集群,并且給6個(gè)節(jié)點(diǎn)分配哈希槽,后三個(gè)節(jié)點(diǎn)配置為前三個(gè)節(jié)點(diǎn)的從節(jié)點(diǎn)面試問(wèn)Redis集群,被虐的不行了......顯示每個(gè)節(jié)點(diǎn)的哈希槽信息和節(jié)點(diǎn)ID,最后一步需要輸入yes面試問(wèn)Redis集群,被虐的不行了......來(lái)到data目錄下查看配置文件的變化。配置文件主要信息是每個(gè)主節(jié)點(diǎn)分的槽面試問(wèn)Redis集群,被虐的不行了......面試問(wèn)Redis集群,被虐的不行了......「查看主機(jī)點(diǎn)的運(yùn)行日志」

      這里給的主要信息cluster status changed:ok 集群狀態(tài)正常面試問(wèn)Redis集群,被虐的不行了......

      5. 集群設(shè)置與獲取數(shù)據(jù)

      當(dāng)直接設(shè)置數(shù)據(jù)會(huì)報(bào)錯(cuò),并且把name這個(gè)key進(jìn)行轉(zhuǎn)化后的槽位置為5798 并且給出了ip地址和端口號(hào)。面試問(wèn)Redis集群,被虐的不行了......需要使用命令redis-cli -c

      在進(jìn)行設(shè)置值的時(shí)候提示說(shuō)重定向到5798的這個(gè)槽面試問(wèn)Redis集群,被虐的不行了......接下來(lái)進(jìn)行獲取數(shù)據(jù),會(huì)自動(dòng)的切換節(jié)點(diǎn)。面試問(wèn)Redis集群,被虐的不行了......

      五、故障轉(zhuǎn)移

      1. 集群從節(jié)點(diǎn)下線

      根據(jù)上文集群?jiǎn)?dòng)信息知道端口6383是6379的從節(jié)點(diǎn)。

      接下來(lái)就是讓6383下線查看6379的日志信息。

      6379會(huì)報(bào)出連接6383丟失,并且給上標(biāo)記fail,表示不可用。這個(gè)時(shí)候集群還是正常工作的。

      「總結(jié):從節(jié)點(diǎn)下線對(duì)集群沒(méi)有影響」面試問(wèn)Redis集群,被虐的不行了......當(dāng)端口6383上線后,所有的節(jié)點(diǎn)會(huì)把fail的標(biāo)記清除面試問(wèn)Redis集群,被虐的不行了......

      2. 集群主節(jié)點(diǎn)下線

      手動(dòng)下線主節(jié)點(diǎn)6379,查看從節(jié)點(diǎn)6383日志信息

      此時(shí)的6383節(jié)點(diǎn)會(huì)持續(xù)連接6379共計(jì)10次。那為什么是10次呢! 是根據(jù)我們配置的參數(shù)cluster-node-timeout 10來(lái)決定的,這里給我們一個(gè)信息就是一秒連接一次

      直到時(shí)間到期后,開(kāi)始故障轉(zhuǎn)移。

      這時(shí)6383在故障轉(zhuǎn)移選舉中勝任,翻身奴隸把歌唱,成為了主節(jié)點(diǎn)。面試問(wèn)Redis集群,被虐的不行了......此時(shí)在查看一下集群的節(jié)點(diǎn)信息,命令cluster nodes。

      會(huì)發(fā)現(xiàn)這里竟然存在四個(gè)主節(jié)點(diǎn),但是其中一個(gè)主節(jié)點(diǎn)時(shí)下線狀態(tài)面試問(wèn)Redis集群,被虐的不行了......「6379原主節(jié)點(diǎn)上線」

      6379上線后,同樣所有的節(jié)點(diǎn)也會(huì)清除fail信息。

      并且節(jié)點(diǎn)信息也會(huì)改變,此時(shí)的6379改變?yōu)?383的從節(jié)點(diǎn)。面試問(wèn)Redis集群,被虐的不行了......

      3. 新增主節(jié)點(diǎn)

      在新增倆個(gè)端口6385和6386面試問(wèn)Redis集群,被虐的不行了......執(zhí)行新增命令./redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379,這里發(fā)送的就是meet消息

      執(zhí)行add-node命令,第一個(gè)參數(shù)為新節(jié)點(diǎn)的ip+端口 第二個(gè)參數(shù)為已存在集群中的節(jié)點(diǎn)。根據(jù)下圖我們就可以看到新增的節(jié)點(diǎn)已經(jīng)存在集群中了。

      「注意:雖說(shuō)6385已經(jīng)成為集群中的節(jié)點(diǎn)了,但是跟其它節(jié)點(diǎn)有區(qū)別。它沒(méi)有數(shù)據(jù),也就是沒(méi)有哈希槽」面試問(wèn)Redis集群,被虐的不行了......接下來(lái)我們就需要把集群中的某些哈希槽分配到這個(gè)新節(jié)點(diǎn)上,分配結(jié)束后這個(gè)節(jié)點(diǎn)才會(huì)成為真正意義上的主節(jié)點(diǎn)

      執(zhí)行命令./redis-trib.rb reshard 127.0.0.1:6385

      會(huì)提示轉(zhuǎn)移多少個(gè)哈希槽并填寫(xiě)接收節(jié)點(diǎn)的id

      最后一步詢問(wèn)是否從所有節(jié)點(diǎn)中轉(zhuǎn)移:咔咔使用的是all

      使用指令:cluster nodes查看,6385的這個(gè)節(jié)點(diǎn)就已經(jīng)擁有三個(gè)范圍的哈希槽了面試問(wèn)Redis集群,被虐的不行了......

      「主節(jié)點(diǎn)已經(jīng)新增好了,接下來(lái)就需要給6385這個(gè)主節(jié)點(diǎn)配置一個(gè)從節(jié)點(diǎn)6386」

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

      master-id是6385的id,第一個(gè)參數(shù)為新節(jié)點(diǎn)的ip+端口 第二個(gè)為指定的主節(jié)點(diǎn)ip+端口面試問(wèn)Redis集群,被虐的不行了......

      4. 手動(dòng)故障遷移

      當(dāng)想對(duì)集群中的主節(jié)點(diǎn)進(jìn)行升級(jí)的話可以手動(dòng)執(zhí)行故障轉(zhuǎn)移到從節(jié)點(diǎn),避免集群可用性受影響。

      在從節(jié)點(diǎn)執(zhí)行命令:cluster failover

      「執(zhí)行過(guò)程」

      查看節(jié)點(diǎn)信息就可以看到6386這個(gè)節(jié)點(diǎn)已經(jīng)成為了主機(jī)點(diǎn)。

      當(dāng)給從節(jié)點(diǎn)發(fā)送cluster failover 指令后,從節(jié)點(diǎn)會(huì)給主節(jié)點(diǎn)發(fā)送CLUSTERMSG_TYPE_MFSTART包。從節(jié)點(diǎn)請(qǐng)求主節(jié)點(diǎn)停止訪問(wèn),從而對(duì)比兩者的數(shù)據(jù)偏移量達(dá)到一致。

      這時(shí)客戶端不會(huì)連接我們淘汰的主節(jié)點(diǎn),同時(shí)主節(jié)點(diǎn)向從節(jié)點(diǎn)發(fā)送復(fù)制偏移量,從節(jié)點(diǎn)得到復(fù)制偏移量后故障轉(zhuǎn)移開(kāi)始,接著通知主節(jié)點(diǎn)進(jìn)行配置切換,當(dāng)客戶端在舊的master上解鎖后重新連接到新的主節(jié)點(diǎn)上。面試問(wèn)Redis集群,被虐的不行了......

      六、故障轉(zhuǎn)移原理篇

      上文中我們測(cè)試了故障轉(zhuǎn)移,主節(jié)點(diǎn)下線后從節(jié)點(diǎn)變?yōu)橹鞴?jié)點(diǎn),接下來(lái)剖析這個(gè)過(guò)程。

      1. 故障發(fā)現(xiàn)到確認(rèn)

      集群中的每個(gè)節(jié)點(diǎn)會(huì)定期的給其它節(jié)點(diǎn)發(fā)送ping消息,接收方用pong作為回復(fù)。

      如果在cluster-node-timeout的時(shí)間內(nèi)ping消息一直失敗,則會(huì)把接收方的節(jié)點(diǎn)標(biāo)記為pfail狀態(tài)也就是主觀下線。

      這個(gè)下線狀態(tài)是不是很熟悉。沒(méi)錯(cuò),這個(gè)跟哨兵判斷主節(jié)點(diǎn)是否異常有點(diǎn)相似。當(dāng)一個(gè)哨兵發(fā)現(xiàn)主節(jié)點(diǎn)有問(wèn)題時(shí)也會(huì)標(biāo)記主節(jié)點(diǎn)客觀下線(s_down)。 突然發(fā)現(xiàn)跑題了,尷尬…….

      面試問(wèn)Redis集群,被虐的不行了......在提一下哨兵,當(dāng)一個(gè)哨兵認(rèn)為主節(jié)點(diǎn)異常后標(biāo)記主觀下線,但是其它哨兵怎么能會(huì)同意,不能你說(shuō)什么就是什么。都會(huì)去嘗試連接異常的主節(jié)點(diǎn),當(dāng)半數(shù)以上的哨兵都認(rèn)為主節(jié)點(diǎn)異常后會(huì)直接讓其主節(jié)點(diǎn)客觀下線。

      同樣集群也不會(huì)因?yàn)橐粋€(gè)節(jié)點(diǎn)判斷其狀態(tài)為下線就行的,節(jié)點(diǎn)直接通過(guò)Gossip消息傳播,集群中節(jié)點(diǎn)會(huì)不斷收集故障節(jié)點(diǎn)的下線反饋并且存儲(chǔ)到本地的故障節(jié)點(diǎn)下線報(bào)告中。當(dāng)有半數(shù)以上的集群主節(jié)點(diǎn)都標(biāo)記為主觀下線后改變狀態(tài)為客觀下線。

      最后向集群廣播一條fail消息,通知所有節(jié)點(diǎn)將故障節(jié)點(diǎn)標(biāo)記為客觀下線。

      例如:節(jié)點(diǎn)A發(fā)送ping到節(jié)點(diǎn)B通信異常后標(biāo)記節(jié)點(diǎn)B為pfail,之后節(jié)點(diǎn)A會(huì)繼續(xù)給節(jié)點(diǎn)C發(fā)送ping并且攜帶節(jié)點(diǎn)B的pfail信息然后節(jié)點(diǎn)C將節(jié)點(diǎn)B的故障保存到下線報(bào)告中。當(dāng)下線報(bào)告數(shù)量大于有哈希槽主節(jié)點(diǎn)的一半數(shù)量以上后就會(huì)嘗試客觀下線。

      2. 故障恢復(fù)(從節(jié)點(diǎn)從此翻身奴隸把歌唱)

      當(dāng)故障節(jié)點(diǎn)被定義為客觀下線后,故障節(jié)點(diǎn)的所有從節(jié)點(diǎn)承擔(dān)故障恢復(fù)的責(zé)任。

      故障恢復(fù)是從節(jié)點(diǎn)通過(guò)定時(shí)任務(wù)發(fā)現(xiàn)自己的主機(jī)點(diǎn)客觀下線后就會(huì)執(zhí)行故障恢復(fù)流程。

      「1. 資格檢查」

      所有的從節(jié)點(diǎn)都會(huì)進(jìn)行檢查與主節(jié)點(diǎn)最后的連接時(shí)間,斷線時(shí)間大于cluster-node-time*cluster-slave-validity-factor時(shí)不具備故障轉(zhuǎn)移的資格。

      「2. 準(zhǔn)備選舉時(shí)間」

      先說(shuō)說(shuō)為什么這里會(huì)有一個(gè)準(zhǔn)備選舉時(shí)間。

      資格檢查過(guò)后存在多個(gè)從節(jié)點(diǎn),那么就需要使用不同的延遲選舉時(shí)間來(lái)支持優(yōu)先級(jí)。這里的優(yōu)先級(jí)就是 以復(fù)制偏移量為基準(zhǔn),偏移量越大與故障主節(jié)點(diǎn)的延遲越小,那么就更有機(jī)會(huì)擁有替換主節(jié)點(diǎn)的機(jī)會(huì)。

      主要的作用就是確保數(shù)據(jù)一致性最好的節(jié)點(diǎn)優(yōu)先發(fā)起選舉

      「3.選舉投票」

      redis集群的投票機(jī)制沒(méi)有采用從節(jié)點(diǎn)進(jìn)行領(lǐng)導(dǎo)選舉,這點(diǎn)切記不要跟哨兵搞混了。集群的投票機(jī)制都是持有槽的主機(jī)點(diǎn)進(jìn)行投票的。

      故障節(jié)點(diǎn)的從節(jié)點(diǎn)會(huì)廣播一個(gè)FAILOVER_AUTH_REQUEST 數(shù)據(jù)包給所有的持有槽的主節(jié)點(diǎn)請(qǐng)求投票。

      當(dāng)主節(jié)點(diǎn)回復(fù)FAILOVER_AUTH_ACK投票后在NODE_TIMEOUT * 2的這段時(shí)間不能給其它的從節(jié)點(diǎn)投票

      從節(jié)點(diǎn)獲取到半數(shù)以上的投票后就會(huì)進(jìn)行故障恢復(fù)階段

      「4. 故障轉(zhuǎn)移」

      選舉成功的從節(jié)點(diǎn)取消復(fù)制變?yōu)橹鞴?jié)點(diǎn)

      刪除故障節(jié)點(diǎn)的槽,并且將故障節(jié)點(diǎn)的槽委托到自己身上

      向集群廣播自己的pong消息,通知主機(jī)點(diǎn)的改變和接管了故障節(jié)點(diǎn)的槽信息。

      你們想要的ssh的背景!?。?/span>

      一篇利用倆個(gè)夜晚才弄完的redis哨兵文章,結(jié)果你們的關(guān)注點(diǎn)卻不在文章本身,??!小編心很痛

      為了滿足大家的要求,咔咔忍痛說(shuō)一下如何設(shè)置亮瞎的背景。面試問(wèn)Redis集群,被虐的不行了......咔咔使用的工具是xsheel面試問(wèn)Redis集群,被虐的不行了......打開(kāi)工具選擇選項(xiàng)面試問(wèn)Redis集群,被虐的不行了......接著到查看有個(gè)窗口透明就可以設(shè)置xsheel透明了。面試問(wèn)Redis集群,被虐的不行了......對(duì)嘍!你想的沒(méi)錯(cuò)這就是桌面背景,是不是準(zhǔn)備開(kāi)始設(shè)置去了。那設(shè)置完了回來(lái)再把文章看完好嗎?咔咔也需要各路大神給予技術(shù)點(diǎn)補(bǔ)充和辨錯(cuò)。

      ?

      堅(jiān)持學(xué)習(xí)、堅(jiān)持寫(xiě)博、堅(jiān)持分享是咔咔從業(yè)以來(lái)一直所秉持的信念。希望在偌大互聯(lián)網(wǎng)中咔咔的文章能帶給你一絲絲幫助。我們下期再見(jiàn)。

      ?

      推薦:《redis教程》

      贊(0)
      分享到: 更多 (0)
      網(wǎng)站地圖   滬ICP備18035694號(hào)-2    滬公網(wǎng)安備31011702889846號(hào)