一 Redis單機(jī)缺陷

redis單機(jī)容量方面會(huì)有瓶頸颈墅，主從模式只能保證支撐更多讀并發(fā)，但是slave和master的數(shù)據(jù)是一模一樣的啼器，也就是說master能存儲(chǔ)多少數(shù)據(jù)披诗，slave就也只能存儲(chǔ)這么多數(shù)據(jù)甲献。比如我們用的是32G的機(jī)器,但是我們要存100G東西,那怎么存呢?用單master的主從集群只能存32G宰缤，想存更多，只能擴(kuò)展master晃洒，這就需要我們用到redis的集群策略了,我們可以以分布式的建立多個(gè)master來做這種集群結(jié)構(gòu),那么具體如何做redis的集群呢?請看下面.

二 集群方式

目前實(shí)現(xiàn)集群主要借助 redis cluster慨灭，redis集群模式，你可以做到在多臺(tái)機(jī)器上球及，部署多個(gè)redis實(shí)例氧骤，每個(gè)實(shí)例存儲(chǔ)一部分的數(shù)據(jù)，同時(shí)每個(gè)redis實(shí)例可以掛redis從實(shí)例吃引，自動(dòng)確保說筹陵，如果redis主實(shí)例掛了，會(huì)自動(dòng)切換到redis從實(shí)例頂上來镊尺。

現(xiàn)在redis的新版本朦佩，大家都是用redis cluster的，也就是redis原生支持的redis集群模式庐氮。

三 redis集群的一般架構(gòu)

redis cluster（多master + 讀寫分離 + 高可用）

• 支撐N個(gè)redis master node语稠，每個(gè)master node都可以掛載多個(gè)slave node
• 讀寫分離:對于每個(gè)master來說，寫就寫到master弄砍，然后讀就從mater對應(yīng)的slave去讀
• 高可用:因?yàn)槊總€(gè)master都有salve節(jié)點(diǎn)仙畦，那么如果mater掛掉，redis cluster這套機(jī)制音婶，就會(huì)自動(dòng)將某個(gè)slave切換成master

我們只要基于redis cluster去搭建redis集群即可慨畸，不需要手工去搭建replication復(fù)制+主從架構(gòu)+讀寫分離+哨兵集群+高可用

三 redis cluster

redis cluster功能

• 自動(dòng)將數(shù)據(jù)進(jìn)行分片，每個(gè)master上放一部分?jǐn)?shù)據(jù)
• 提供內(nèi)置的高可用支持衣式，可以自主進(jìn)行主備切換

在redis cluster架構(gòu)下先口，每個(gè)redis要放開兩個(gè)端口號型奥，比如一個(gè)是6379，另外一個(gè)就是加10000的端口號碉京，比如16379

16379端口號是用來進(jìn)行節(jié)點(diǎn)間通信的厢汹，也就是cluster bus的東西，集群總線谐宙。cluster bus的通信烫葬，用來進(jìn)行故障檢測，配置更新凡蜻，故障轉(zhuǎn)移授權(quán)

cluster bus用了另外一種二進(jìn)制的協(xié)議搭综，主要用于節(jié)點(diǎn)間進(jìn)行高效的數(shù)據(jù)交換，占用更少的網(wǎng)絡(luò)帶寬和處理時(shí)間

四 如何解決分布式系統(tǒng)中負(fù)載均衡的問題

4.1 有哪些算法划栓？

4.1.1普通hash

弊端比較大兑巾，會(huì)導(dǎo)致非常嚴(yán)重的數(shù)據(jù)錯(cuò)亂問題，簡單說下忠荞。
根據(jù)key進(jìn)行普通hash蒋歌，如果其中一個(gè)結(jié)點(diǎn)宕機(jī)了，會(huì)立馬損失掉整個(gè)結(jié)點(diǎn)的數(shù)據(jù)委煤，并且數(shù)據(jù)分布也錯(cuò)亂了堂油，每次請求拿不到，導(dǎo)致大量請求打到mysql上碧绞。

比如ABC三個(gè)master分別接受對3取模后hash值為0府框，1，2的key值數(shù)據(jù)讥邻，如果B宕機(jī)了迫靖，首先B數(shù)據(jù)丟失了，其次兴使，當(dāng)請求再次取模是對2（現(xiàn)有機(jī)器數(shù)）取模系宜，那么原來請求落到的redis結(jié)點(diǎn)可能也就變了，新的接受請求的結(jié)點(diǎn)并沒有存儲(chǔ)原來的數(shù)據(jù)鲫惶，就會(huì)重新查mysql拿數(shù)據(jù)蜈首，如果此時(shí)有高并發(fā)，極可能發(fā)送雪崩問題欠母。

4.1.2一致性hash

百度百科
在使用n臺(tái)緩存服務(wù)器時(shí)欢策，一種常用的負(fù)載均衡方式是，對資源o的請求使用hash(o)=o mod n來映射到某一臺(tái)緩存服務(wù)器赏淌。當(dāng)增加或減少一臺(tái)緩存服務(wù)器時(shí)這種方式可能會(huì)改變所有資源對應(yīng)的hash值踩寇，也就是所有的緩存都失效了，這會(huì)使得緩存服務(wù)器大量集中地向原始內(nèi)容服務(wù)器更新緩存六水。因此需要一致哈希算法來避免這樣的問題俺孙。 一致哈希盡可能使同一個(gè)資源映射到同一臺(tái)緩存服務(wù)器辣卒。這種方式要求增加一臺(tái)緩存服務(wù)器時(shí)，新的服務(wù)器盡量分擔(dān)存儲(chǔ)其他所有服務(wù)器的緩存資源睛榄。減少一臺(tái)緩存服務(wù)器時(shí)荣茫，其他所有服務(wù)器也可以盡量分擔(dān)存儲(chǔ)它的緩存資源。 一致哈希算法的主要思想是將每個(gè)緩存服務(wù)器與一個(gè)或多個(gè)哈希值域區(qū)間關(guān)聯(lián)起來场靴，其中區(qū)間邊界通過計(jì)算緩存服務(wù)器對應(yīng)的哈希值來決定啡莉。（定義區(qū)間的哈希函數(shù)不一定和計(jì)算緩存服務(wù)器哈希值的函數(shù)相同，但是兩個(gè)函數(shù)的返回值的范圍需要匹配旨剥。）如果一個(gè)緩存服務(wù)器被移除咧欣，則它所對應(yīng)的區(qū)間會(huì)被并入到鄰近的區(qū)間，其他的緩存服務(wù)器不需要任何改變 ^[1] 轨帜。

上述問題和需求的解決方法→使用數(shù)據(jù)分片：按照某種規(guī)則去劃分海量數(shù)據(jù)魄咕，分散存儲(chǔ)在多個(gè)Redis服務(wù)器節(jié)點(diǎn)上

4.1 原理:

redis一致性哈希算法

• 對2^32取模，將哈希值空間組織成虛擬的圓環(huán)
• 用同樣的Hash算法計(jì)算服務(wù)器的Hash值(可以用服務(wù)器IP或者主機(jī)名計(jì)算)確定在環(huán)上的位置
• 用同樣的Hash算法計(jì)算數(shù)據(jù)的Hash值,確定在環(huán)上的位置
• 數(shù)據(jù)映射保存到在環(huán)上順時(shí)針遇到最近的服務(wù)器
• 這樣即可將數(shù)據(jù)分散到不同服務(wù)器上面進(jìn)行處理
  • 這樣當(dāng)一個(gè)服務(wù)器宕機(jī)了只會(huì)影響這臺(tái)服務(wù)器于逆時(shí)針碰到的第一臺(tái)服務(wù)器之間的數(shù)據(jù),不會(huì)影響其他數(shù)據(jù)
  • 當(dāng)新添加了一個(gè)結(jié)點(diǎn)服務(wù)器時(shí)也只會(huì)影響新服務(wù)器在Hash環(huán)上的位置到逆時(shí)針碰到的第一臺(tái)服務(wù)器之間的數(shù)據(jù) ,其他數(shù)據(jù)不會(huì)收到影響
• 一致性Hash算法具有很高的容錯(cuò)性和可擴(kuò)展性

圖解一致性Hash算法

4.2一致性hash數(shù)據(jù)傾斜問題（也叫數(shù)據(jù)熱點(diǎn)問題）

數(shù)據(jù)傾斜問題及解決

虛擬結(jié)點(diǎn)是隨機(jī)分布的,這樣會(huì)使原來少量服務(wù)器時(shí)候造成的數(shù)據(jù)分布不均勻變的均勻,原理如圖

具體的生產(chǎn)環(huán)境實(shí)體落地情景是怎樣的呢?

• 首先取各個(gè)機(jī)器的特定值的hash值,比如mac地址hash值
• 將hash值進(jìn)行排序組成一個(gè)數(shù)組,如[15,20,55,106],分別對應(yīng)m2,m3,m1,m4
• 那么對要存的數(shù)據(jù)進(jìn)行一個(gè)hash找到第一個(gè)數(shù)據(jù)的hash值大于機(jī)器值的機(jī)器,該數(shù)據(jù)就存到這個(gè)機(jī)器上

4.1.3 slot實(shí)現(xiàn)數(shù)據(jù)分布

一旦某個(gè)master宕機(jī)了蚌父，redis會(huì)快速將原來的hash slot分配到其他master上哮兰，當(dāng)然這里避免不了的，會(huì)有一定的請求需要重新拿mysql數(shù)據(jù)

redis cluster有固定的16384個(gè)hash slot(2的14次方)梢什，我們會(huì)對每個(gè)key計(jì)算CRC16值奠蹬，然后對16384取模朝聋，可以獲取key對應(yīng)的hash slot

redis cluster中每個(gè)master都會(huì)持有部分slot嗡午，比如有3個(gè)master，那么可能每個(gè)master持有5000多個(gè)hash slot

hash slot讓node的增加和移除很簡單冀痕，增加一個(gè)master荔睹，就將其他master的hash slot移動(dòng)部分過去，減少一個(gè)master言蛇，就將它的hash slot移動(dòng)到其他master上去

移動(dòng)hash slot的成本是非常低的

客戶端的api僻他，可以對指定的數(shù)據(jù)，讓他們走同一個(gè)hash slot腊尚，通過hash tag來實(shí)現(xiàn)吨拗；

為什么hash slot用的是16384而不是其他？老毛病了婿斥，總感覺這些特殊的數(shù)字有點(diǎn)意思（鏡像問題：redis為什么每次容量都設(shè)置2的冪次方劝篷，為什么轉(zhuǎn)紅黑樹的條件是鏈表長度為8即同一節(jié)點(diǎn)hash沖突次數(shù)為8？）民宿，果不其然娇妓，可以看看作者給的回答

• 空間上 ：正常的心跳數(shù)據(jù)包帶有節(jié)點(diǎn)的完整配置，可以用冪等方式用舊的節(jié)點(diǎn)替換舊節(jié)點(diǎn)活鹰，以便更新舊的配置哈恰。
  這意味著它們包含原始節(jié)點(diǎn)的插槽配置只估，這樣節(jié)點(diǎn)16k的插槽會(huì)使用2k的空間，使用65k的插槽使用8k的空間着绷。
• 需求上：Redis集群不太可能擴(kuò)展到1000個(gè)以上的主節(jié)點(diǎn)蛔钙，因此16k處于正確的范圍內(nèi)，足以使每個(gè)主機(jī)具有足夠的插槽荠医。
• 保存?zhèn)鬟f：另外Redis主節(jié)點(diǎn)的配置信息中夸楣，它所負(fù)責(zé)的哈希槽是通過一張bitmap的形式來保存的，在傳輸過程中子漩，會(huì)對bitmap進(jìn)行壓縮豫喧，

詳細(xì)大家可以看
https://www.cnblogs.com/rjzheng/p/11430592.html

https://blog.csdn.net/zalu9810/article/details/102797240
https://blog.csdn.net/hollis_chuang/article/details/103692187

五 Redis 結(jié)點(diǎn)之間內(nèi)部通信

5.1 Redis 結(jié)點(diǎn)之間內(nèi)部通信機(jī)制

redis cluster節(jié)點(diǎn)間采取gossip協(xié)議進(jìn)行通信

分布式系統(tǒng)中結(jié)點(diǎn)之間主要有兩種通訊機(jī)制

• 集中式：好處在于，元數(shù)據(jù)的更新和讀取幢泼，時(shí)效性非常好紧显，一旦元數(shù)據(jù)出現(xiàn)了變更，立即就更新到集中式的存儲(chǔ)中缕棵，其他節(jié)點(diǎn)讀取的時(shí)候立即就可以感知到; 不好在于孵班，所有的元數(shù)據(jù)的跟新壓力全部集中在一個(gè)地方，可能會(huì)導(dǎo)致元數(shù)據(jù)的存儲(chǔ)有壓力

• gossip：跟集中式不同招驴，不是將集群元數(shù)據(jù)（節(jié)點(diǎn)信息篙程，故障，等等）集中存儲(chǔ)在某個(gè)節(jié)點(diǎn)上别厘，而是互相之間不斷通信虱饿，保持整個(gè)集群所有節(jié)點(diǎn)的數(shù)據(jù)是完整的。好處在于触趴，元數(shù)據(jù)的更新比較分散氮发，不是集中在一個(gè)地方，更新請求會(huì)陸陸續(xù)續(xù)冗懦，打到所有節(jié)點(diǎn)上去更新爽冕，有一定的延時(shí)，降低了壓力; 缺點(diǎn)披蕉，元數(shù)據(jù)更新有延時(shí)颈畸，可能導(dǎo)致集群的一些操作會(huì)有一些滯后

流言協(xié)議Gossip

進(jìn)程間使用流言協(xié)議即Gossip來同步信息，接收主服務(wù)器是否下線的信息,并使用投票協(xié)議來決定是否進(jìn)行自動(dòng)故障遷移以及選擇哪個(gè)從服務(wù)器作為新的主服務(wù)器

5.1.1流言協(xié)議Gossip --在雜亂無章中尋求一致

• 每個(gè)節(jié)點(diǎn)都隨機(jī)地與對方通信没讲，最終所有節(jié)點(diǎn)的狀態(tài)達(dá)成一致
• 種子節(jié)點(diǎn)定期隨機(jī)向其他節(jié)點(diǎn)發(fā)送節(jié)點(diǎn)列表以及需要傳播的消息
• 不保證信息一定會(huì)傳遞給所有節(jié)點(diǎn)眯娱，但是最終會(huì)趨于一致

gossip協(xié)議包含多種消息，包括ping食零，pong困乒，meet，fail贰谣，等等

• meet: 某個(gè)節(jié)點(diǎn)發(fā)送meet給新加入的節(jié)點(diǎn)娜搂，讓新節(jié)點(diǎn)加入集群中迁霎，然后新節(jié)點(diǎn)就會(huì)開始與其他節(jié)點(diǎn)進(jìn)行通信
  redis-trib.rb add-node 其實(shí)內(nèi)部就是發(fā)送了一個(gè)gossip meet消息，給新加入的節(jié)點(diǎn)百宇，通知那個(gè)節(jié)點(diǎn)去加入我們的集群

• ping: 每個(gè)節(jié)點(diǎn)都會(huì)頻繁給其他節(jié)點(diǎn)發(fā)送ping考廉，其中包含自己的狀態(tài)還有自己維護(hù)的集群元數(shù)據(jù)，互相通過ping交換元數(shù)據(jù)
  每個(gè)節(jié)點(diǎn)每秒都會(huì)頻繁發(fā)送ping給其他的集群携御，ping昌粤，頻繁的互相之間交換數(shù)據(jù)，互相進(jìn)行元數(shù)據(jù)的更新

  • ping消息深入
    ping很頻繁啄刹，而且要攜帶一些元數(shù)據(jù)涮坐，所以可能會(huì)加重網(wǎng)絡(luò)負(fù)擔(dān)
    每個(gè)節(jié)點(diǎn)每秒會(huì)執(zhí)行10次ping，每次會(huì)選擇5個(gè)最久沒有通信的其他節(jié)點(diǎn)
    當(dāng)然如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)通信延時(shí)達(dá)到了cluster_node_timeout / 2誓军，那么立即發(fā)送ping袱讹，避免數(shù)據(jù)交換延時(shí)過長，落后的時(shí)間太長了
    比如說昵时，兩個(gè)節(jié)點(diǎn)之間都10分鐘沒有交換數(shù)據(jù)了捷雕，那么整個(gè)集群處于嚴(yán)重的元數(shù)據(jù)不一致的情況，就會(huì)有問題
    所以cluster_node_timeout可以調(diào)節(jié)壹甥，如果調(diào)節(jié)比較大救巷，那么會(huì)降低發(fā)送的頻率
    每次ping，一個(gè)是帶上自己節(jié)點(diǎn)的信息句柠，還有就是帶上1/10其他節(jié)點(diǎn)的信息浦译，發(fā)送出去，進(jìn)行數(shù)據(jù)交換
    至少包含3個(gè)其他節(jié)點(diǎn)的信息俄占，最多包含總節(jié)點(diǎn)-2個(gè)其他節(jié)點(diǎn)的信息

• pong: 返回ping和meet管怠，包含自己的狀態(tài)和其他信息淆衷，也可以用于信息廣播和更新

• fail: 某個(gè)節(jié)點(diǎn)判斷另一個(gè)節(jié)點(diǎn)fail之后缸榄，就發(fā)送fail給其他節(jié)點(diǎn)，通知其他節(jié)點(diǎn)祝拯，指定的節(jié)點(diǎn)宕機(jī)了

5.2 開放端口 +10000端口

每個(gè)節(jié)點(diǎn)都有一個(gè)專門用于節(jié)點(diǎn)間通信的端口甚带，就是自己提供服務(wù)的端口號+10000，比如7001佳头，那么用于節(jié)點(diǎn)間通信的就是17001端口

每隔節(jié)點(diǎn)每隔一段時(shí)間都會(huì)往另外幾個(gè)節(jié)點(diǎn)發(fā)送ping消息鹰贵，同時(shí)其他幾點(diǎn)接收到ping之后返回pong

5.3結(jié)點(diǎn)間通訊交換的信息

故障信息，節(jié)點(diǎn)的增加和移除康嘉，hash slot信息碉输，等等

六 面向集群的jedis內(nèi)部實(shí)現(xiàn)原理

jedis是redis cluster的java client客戶端，jedis cluster api

1）請求重定向

客戶端可能會(huì)挑選任意一個(gè)redis實(shí)例去發(fā)送命令亭珍，每個(gè)redis實(shí)例接收到命令敷钾，都會(huì)計(jì)算key對應(yīng)的hash slot

如果在本地就在本地處理枝哄，否則返回moved給客戶端，讓客戶端進(jìn)行重定向

cluster keyslot mykey阻荒，可以查看一個(gè)key對應(yīng)的hash slot是什么

用redis-cli的時(shí)候挠锥，可以加入-c參數(shù)，支持自動(dòng)的請求重定向侨赡，redis-cli接收到moved之后蓖租，會(huì)自動(dòng)重定向到對應(yīng)的節(jié)點(diǎn)執(zhí)行命令

2）計(jì)算hash slot

計(jì)算hash slot的算法，就是根據(jù)key計(jì)算CRC16值羊壹，然后對16384取模蓖宦，拿到對應(yīng)的hash slot

也可以手動(dòng)指定solt：用hash tag可以手動(dòng)指定key對應(yīng)的slot，同一個(gè)hash tag下的key油猫，都會(huì)在一個(gè)hash slot中球昨，比如set mykey1:{100} v1和set mykey2:{100} v2，他們屬于同一個(gè)tag眨攘，那么他們會(huì)路由到同一服務(wù)器上

3）hash slot查找

節(jié)點(diǎn)間通過gossip協(xié)議進(jìn)行數(shù)據(jù)交換主慰，就知道每個(gè)hash slot在哪個(gè)節(jié)點(diǎn)上

4）smart jedis

1.什么是smart jedis

上面我們也說了jedis一開始是基于客戶端進(jìn)行重定向，很消耗網(wǎng)絡(luò)IO鲫售，因?yàn)榇蟛糠智闆r下共螺，可能都會(huì)出現(xiàn)一次請求重定向，才能找到正確的節(jié)點(diǎn)

所以大部分的客戶端情竹，比如java redis客戶端藐不，就是jedis，都是smart的
本地維護(hù)一份hashslot -> node的映射表秦效，緩存雏蛮，大部分情況下，直接走本地緩存就可以找到hashslot -> node阱州，不需要通過節(jié)點(diǎn)進(jìn)行moved重定向

2. JedisCluster的工作原理(含如果數(shù)據(jù)遷移了的數(shù)據(jù)尋找過程)

• 在JedisCluster初始化的時(shí)候挑秉，就會(huì)隨機(jī)選擇一個(gè)node，初始化hashslot -> node映射表苔货，同時(shí)為每個(gè)節(jié)點(diǎn)創(chuàng)建一個(gè)JedisPool連接池

• 每次基于JedisCluster執(zhí)行操作犀概，首先JedisCluster都會(huì)在本地計(jì)算key的hashslot，然后在本地映射表找到對應(yīng)的節(jié)點(diǎn)

  • 如果那個(gè)node正好還是持有那個(gè)hashslot夜惭，那么就ok; 如果說進(jìn)行了reshard這樣的操作姻灶，可能hashslot已經(jīng)不在那個(gè)node上了，就會(huì)返回moved(表示該hashslot已不在這個(gè)node了)
  • 如果JedisCluter API發(fā)現(xiàn)對應(yīng)的節(jié)點(diǎn)返回moved诈茧，那么利用該節(jié)點(diǎn)的元數(shù)據(jù)产喉，更新本地的hashslot -> node映射表緩存

重復(fù)上面幾個(gè)步驟，直到找到對應(yīng)的節(jié)點(diǎn)，如果重試超過5次曾沈，那么就報(bào)錯(cuò)尘颓，JedisClusterMaxRedirectionException

jedis老版本，可能會(huì)出現(xiàn)在集群某個(gè)節(jié)點(diǎn)故障還沒完成自動(dòng)切換恢復(fù)時(shí)晦譬，頻繁更新hash slot疤苹，頻繁ping節(jié)點(diǎn)檢查活躍，導(dǎo)致大量網(wǎng)絡(luò)IO開銷
jedis最新版本敛腌，對于這些過度的hash slot更新和ping卧土，都進(jìn)行了優(yōu)化，避免了類似問題

3. hashslot遷移和ask重定向

• 1. 如果hash slot正在遷移像樊，那么會(huì)返回ask重定向給jedis
• 2. jedis接收到ask重定向之后尤莺，會(huì)重新定位到目標(biāo)節(jié)點(diǎn)去執(zhí)行，但是因?yàn)?strong>ask發(fā)生在hash slot遷移過程中生棍，所以JedisCluster API收到ask是不會(huì)更新hashslot本地緩存

只有確定說颤霎，hashslot已經(jīng)遷移完了，返回moved是會(huì)更新本地hashslot->node映射表緩存的

七 高可用性與主備切換原理

redis cluster的高可用的原理涂滴，幾乎跟哨兵是類似的

1）判斷節(jié)點(diǎn)宕機(jī)

如果一個(gè)節(jié)點(diǎn)認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)友酱，那么就是pfail，主觀宕機(jī)
如果多個(gè)節(jié)點(diǎn)都認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)了柔纵，那么就是fail缔杉，客觀宕機(jī)，跟哨兵的原理幾乎一樣搁料，sdown或详，odown

在cluster-node-timeout內(nèi)，某個(gè)節(jié)點(diǎn)一直沒有返回pong郭计，那么就被認(rèn)為pfail

如果一個(gè)節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn)pfail了霸琴，那么會(huì)在gossip ping消息中，ping給其他節(jié)點(diǎn)昭伸，如果超過半數(shù)的節(jié)點(diǎn)都認(rèn)為pfail了梧乘，那么就會(huì)變成fail

2）從節(jié)點(diǎn)過濾

對宕機(jī)的master node，從其所有的slave node中勋乾，選擇一個(gè)切換成master node

檢查每個(gè)slave node與master node斷開連接的時(shí)間宋下，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那么就沒有資格切換成master

這個(gè)也是跟哨兵是一樣的辑莫，從節(jié)點(diǎn)超時(shí)過濾的步驟

3）從節(jié)點(diǎn)選舉

哨兵：對所有從節(jié)點(diǎn)進(jìn)行排序，slave priority罩引，offset各吨，run id

redis cluster :每個(gè)從節(jié)點(diǎn)，都根據(jù)自己對master復(fù)制數(shù)據(jù)的offset，來設(shè)置一個(gè)選舉時(shí)間揭蜒，offset越大（復(fù)制數(shù)據(jù)越多）的從節(jié)點(diǎn)横浑，選舉時(shí)間越靠前，優(yōu)先進(jìn)行選舉
所有的master node開始slave選舉投票屉更，給要進(jìn)行選舉的slave進(jìn)行投票徙融，如果大部分master node（N/2 + 1）都投票給了某個(gè)從節(jié)點(diǎn)，那么選舉通過瑰谜，那個(gè)從節(jié)點(diǎn)可以切換成master

從節(jié)點(diǎn)執(zhí)行主備切換欺冀，從節(jié)點(diǎn)切換為主節(jié)點(diǎn)

4）三種集群模式的對比

• 主從模式 可以實(shí)現(xiàn)讀寫分離，數(shù)據(jù)備份萨脑。但是并不是「高可用」的
• 哨兵模式 可以看做是主從模式的「高可用」版本隐轩，其引入了 Sentinel 對整個(gè) Redis 服務(wù)集群進(jìn)行監(jiān)控。但是由于只有一個(gè)主節(jié)點(diǎn)渤早，因此仍然有寫入瓶頸职车。
• Cluster 模式 去中心化，無主節(jié)點(diǎn)不僅提供了高可用的手段鹊杖，同時(shí)數(shù)據(jù)是分片保存在各個(gè)節(jié)點(diǎn)中的悴灵，可以支持高并發(fā)的寫入與讀取。當(dāng)然實(shí)現(xiàn)也是其中最復(fù)雜的骂蓖。

八 redis架構(gòu)演進(jìn)

基于不同階段redis的演進(jìn)之路,到底為什么?

• 單機(jī)版 Redis：最簡版
• 數(shù)據(jù)持久化：有備無患
• 主從復(fù)制：多副本
• 哨兵：故障自動(dòng)轉(zhuǎn)移
• 分片集群：橫向擴(kuò)展

詳細(xì)的可以看,如果了解每個(gè)階段的發(fā)展可以起到融會(huì)貫通,huo'ran'kai https://mp.weixin.qq.com/s/WzbeCyOORPq2E3T43jfEjw