之前講解了redis主從讀寫(xiě)分離+sentinel架構(gòu)，保證了slave節(jié)點(diǎn)能橫向擴(kuò)展提高qps，也保證了
99.99%的高可用性。但是也存在如下一些問(wèn)題：

• 單master架構(gòu)的內(nèi)存瓶頸問(wèn)題
  • master的內(nèi)存大小的上限，就是整個(gè)集群數(shù)據(jù)量的上限
  • 用之前的方式配置讀寫(xiě)寫(xiě)分離，最大的問(wèn)題是master和slave存的內(nèi)容完全一樣， 比較浪費(fèi)內(nèi)存資源。

所以做好能夠突破單master的瓶頸，搭建多個(gè)master，承載海量數(shù)據(jù)，一個(gè)master對(duì)幾個(gè)slave，這樣就能橫向擴(kuò)展。

reids官網(wǎng)提供了另一種集群方式，就是redis cluster，能滿足上面的需求。

redis如何通過(guò)master橫向擴(kuò)容支撐1T+數(shù)據(jù)量.png

redis cluster介紹

• 自動(dòng)將數(shù)據(jù)進(jìn)行分片，每個(gè)master上放一部分?jǐn)?shù)據(jù)
• 提供內(nèi)置的高可用支持。部分master不可用時(shí)，還是可以繼續(xù)工作
• 在 redis cluster 架構(gòu)下，每個(gè)redis要開(kāi)放兩個(gè)端口號(hào)，一個(gè)是6379,另一個(gè)加10000，16379端口號(hào)是用來(lái)進(jìn)行節(jié)點(diǎn)通信的，也就是cluster bus的東西，集群總線。cluster bus的通信，用來(lái)進(jìn)行故障檢測(cè)，配置更新，故障轉(zhuǎn)移授權(quán)。
• cluster bus用了另外一種二進(jìn)制的協(xié)議，主要用于節(jié)點(diǎn)間進(jìn)行高效的數(shù)據(jù)交換，占用更少的網(wǎng)絡(luò)帶寬和處理時(shí)間
• redis cluster = sentinel+sharded （哨兵+多master數(shù)據(jù)共享）

redis cluster特性

• 支撐N個(gè)redis master node ，每個(gè)master node都可以掛在多個(gè)slave node
• 讀寫(xiě)分離架構(gòu)，對(duì)于每個(gè)master來(lái)說(shuō)，寫(xiě)就寫(xiě)到master ，然后讀就從master對(duì)應(yīng)的slave讀。
• 因?yàn)槊總€(gè)master都有slave節(jié)點(diǎn)，如果master掛掉，redis cluster這套機(jī)制，就會(huì)將某個(gè)slave切換成master
• redis cluster（多master + 高可用）

所以到這里已經(jīng)有單機(jī)redis，主從復(fù)制架構(gòu)，cluster架構(gòu)，面對(duì)這么多架構(gòu)，我們?nèi)绾巫鲞x擇?

• 如果數(shù)據(jù)量很少，主要是承載高并發(fā)高性能場(chǎng)景，比如緩存一般就幾個(gè)g，單機(jī)足夠了
• replication, 一個(gè)master，多個(gè)slave，要幾個(gè)slave跟你要求的吞吐量有關(guān)系，然后自己搭建一個(gè)sentinal集群，保證redis主從架構(gòu)的高可用性，就可以了。
• redis cluster，主要是針對(duì)海量數(shù)據(jù)，高并發(fā)，高可用的場(chǎng)景，海量數(shù)據(jù)，如果數(shù)量很大，那么建議使用。

下面就從一下幾個(gè)方面介紹redis-cluster

• 1、多master下，不同key分布在不同master的各種算法原理
• 2、實(shí)驗(yàn)：使用docker搭建一套6節(jié)點(diǎn)，3主3從的redis-cluster集群（帶redis配置和docker啟動(dòng)腳本）
• 3、cluster橫向擴(kuò)展以及冗余節(jié)點(diǎn)
• 4、redis-cluster的核心原理分析：gossip通信，jedis smart定位，主備切換
• 5、總結(jié)

多master下，不同key分布在不同master的各種算法原理

由于有多個(gè)master，能寫(xiě)的地方不止一個(gè)，所以，每有一個(gè)寫(xiě)操作過(guò)來(lái)，都需要選擇一個(gè)master去寫(xiě)，
所以需要有一個(gè)，算法，把每個(gè)key較為均勻的分配到各個(gè)master節(jié)點(diǎn)上，這樣才能保證發(fā)揮每臺(tái)機(jī)器的性能。
算法從以前到現(xiàn)在經(jīng)歷的以下幾個(gè)版本。

• 最原始的hash算法
  • 算法流程
    • 來(lái)了一個(gè)key，計(jì)算hash值，對(duì)master，對(duì)master節(jié)點(diǎn)數(shù)取模，取模就分配到對(duì)應(yīng)的master節(jié)點(diǎn)
    • 例如3個(gè)master節(jié)點(diǎn)，就對(duì)3取模，然后值在0-2之間，0就分配給1號(hào)節(jié)點(diǎn)，1就分配給2號(hào)節(jié)點(diǎn)，2就分配給3號(hào)節(jié)點(diǎn)
  • 缺點(diǎn)
    • 3個(gè)節(jié)點(diǎn)，對(duì)3取模，樣本數(shù)過(guò)少，很容易出現(xiàn)那種，大多數(shù)key都計(jì)算出一個(gè)結(jié)果，每個(gè)機(jī)器壓力差別大。
    • 容錯(cuò)率太低，當(dāng)一個(gè)master掛了，那么會(huì)導(dǎo)致之前的所有key不可用
      • 假設(shè)之前有三個(gè)節(jié)點(diǎn)，一個(gè)key之前計(jì)算出來(lái)為123對(duì)3取模是0，存0號(hào)機(jī)器
      • 但是掛了一個(gè)，當(dāng)這個(gè)key又過(guò)來(lái)123對(duì)2取模（掛了一個(gè)3變2）為1，存2號(hào)機(jī)器。
      • 所以之前存的key，當(dāng)掛了一個(gè)機(jī)器以后就都不可用了。

最老土的hash算法以及弊端.png

• 一致性hash算法 + 虛擬節(jié)點(diǎn)（自動(dòng)負(fù)載均衡）
  • 搞一個(gè)hash環(huán)，然后把多個(gè)master節(jié)點(diǎn)分配在hash環(huán)上 , 當(dāng)對(duì)key進(jìn)行hash，落在hash環(huán)上，然后順時(shí)針移動(dòng)，碰到的第一個(gè)master節(jié)點(diǎn)就存。
  • 當(dāng)一個(gè)master節(jié)點(diǎn)掛了，只是在之前的master節(jié)點(diǎn)上找不到了，會(huì)順時(shí)針去下一個(gè)節(jié)點(diǎn)，也找不到。但是對(duì)另外兩臺(tái)機(jī)器上有的數(shù)據(jù)沒(méi)影響，就是導(dǎo)致1/3的數(shù)據(jù)涌入數(shù)據(jù)庫(kù)。重新查詢一次。
  • 緩存熱點(diǎn)問(wèn)題
    • 可能集中在某個(gè)hash區(qū)間內(nèi)的值特別多，然后導(dǎo)致大量的數(shù)據(jù)全部涌入同一個(gè)masterneural，造成master的熱點(diǎn)問(wèn)題，性能出現(xiàn)瓶頸。
  • 解決緩存熱點(diǎn)
    • 會(huì)搞一堆虛擬節(jié)點(diǎn)，例如1號(hào)機(jī)器有3個(gè)點(diǎn)虛擬節(jié)點(diǎn)，3個(gè)機(jī)器就有9個(gè)節(jié)點(diǎn)，交叉均勻分布在環(huán)上，那么，在某個(gè)區(qū)間內(nèi)的數(shù)據(jù)，又會(huì)分不到不同的節(jié)點(diǎn)內(nèi)。

一致性hash算法的講解和優(yōu)點(diǎn).png

一致性hash算法的虛擬節(jié)點(diǎn)實(shí)現(xiàn)負(fù)載均衡.png

• hash slot算法（redis-cluster使用）
  • hash算法是對(duì)機(jī)器數(shù)量取模，當(dāng)機(jī)器掛了一個(gè)后，數(shù)量就變少了，那么所有的取模都變了，導(dǎo)致所有的key命中不準(zhǔn)
  • 而hash slot就是不對(duì)機(jī)器數(shù)取模，不管多少個(gè)機(jī)器，都對(duì)slot數(shù)量16384取模。
  • 機(jī)器在或者不在都對(duì)16384取模，那么當(dāng)一個(gè)機(jī)器掛了，只會(huì)影響該機(jī)器上的slot，也就是1/3的數(shù)據(jù)命中不到，去數(shù)據(jù)庫(kù)取數(shù)據(jù)。
  • hash slot有16384的節(jié)點(diǎn)，那么能盡量保證，數(shù)據(jù)命中的數(shù)據(jù)均勻。

redis cluster hash slot算法.png

2、實(shí)驗(yàn)：使用docker搭建一套6節(jié)點(diǎn)，3主3從的redis-cluster集群（帶redis配置和docker啟動(dòng)腳本）

redis.conf

port 7001
requirepass "123456"
dir "/data"
logfile "redis.log"
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 192.168.5.10
cluster-announce-port 7001
cluster-announce-bus-port 17001
masterauth "123456"
appendonly yes

docker啟動(dòng)一個(gè)redis腳本

docker run -d --name redis7001 -p 7001:7001 -p 17001:17001 -v /data/redis-cluster/7001:/data redis redis-server /data/redis.conf

創(chuàng)建集群腳本

redis-cli -c -h  192.168.5.10 -p 7001 -a 123456 --cluster create 192.168.5.10:7001 192.168.5.10:7002 192.168.5.11:7003 192.168.5.11:7004 192.168.5.12:7005 192.168.5.12:7006 --cluster-replicas 1

步驟：

• 1、準(zhǔn)備三臺(tái)虛擬機(jī)，然后創(chuàng)建6個(gè) /data/cluster-redis/7001文件夾，每臺(tái)機(jī)器兩個(gè)，使用7001-7006六個(gè)數(shù)字標(biāo)識(shí)
• 2、在每個(gè) /data/cluster-redis/700*下面新建一個(gè) redis.conf, 把上面的redis.conf配置復(fù)制進(jìn)去
  • 注意修改 redis.conf 中的 cluster-announce-ip 為本機(jī)ip
  • 注意修改 port 7001 ，cluster-announce-port 7001，cluster-announce-bus-port 17001，這三個(gè)配置，例如是7001目錄下就都是7001，7002目錄下就都是7002
• 3、每天機(jī)器啟動(dòng)兩個(gè)redis實(shí)例，使用上面的docker腳本
  • 注意映射端口和掛載盤(pán)的時(shí)候，所有的700*都要對(duì)應(yīng)修改。
• 4、6個(gè)實(shí)例啟動(dòng)完畢，進(jìn)入redis7001這個(gè)容器去創(chuàng)建集群
  • 1.docker exec -it redis7001 /bin/bash
  • 2.然后使用上面創(chuàng)建集群腳本，注意修改ip為三臺(tái)機(jī)器的ip
• 5、這樣，就創(chuàng)建好了三主三從的cluster集群。
• 6、驗(yàn)證集群創(chuàng)建好了沒(méi)，就進(jìn)入redis7001節(jié)點(diǎn), 然后進(jìn)入redis，然后執(zhí)行 info replication
  • docker exec -it redis7001 /bin/bash
  • redis-cli -h 192.168.5.10 -p 7001 -a 123456
  • info replication
  • 如下：就是一個(gè)master節(jié)點(diǎn)，然后掛了一個(gè)slave

redis cluster hash slot算法.png

3、cluster橫向擴(kuò)展以及冗余節(jié)點(diǎn)

redis_cluster通過(guò)master水平擴(kuò)容來(lái)支撐更高的吞吐量+海量數(shù)據(jù)

• redis cluster模式下，不建議做物理的讀寫(xiě)分離了
• 我們建議通過(guò)master的水平擴(kuò)容，來(lái)橫向擴(kuò)展讀寫(xiě)吞吐量，還有支撐更多的海量數(shù)據(jù)
• redis單機(jī)，讀吞吐是5w/s，寫(xiě)吞吐2w/s
• 擴(kuò)展redis更多master，那么如果有5臺(tái)master，不就讀吞吐可以達(dá)到總量25/s QPS，寫(xiě)可以達(dá)到10w/s QPS
• redis單機(jī)不宜存過(guò)多的數(shù)據(jù)，內(nèi)存，6G，8G，fork類操作的時(shí)候很耗時(shí)，會(huì)導(dǎo)致請(qǐng)求延時(shí)的問(wèn)題
• 擴(kuò)容到5臺(tái)master，能支撐的總的緩存數(shù)據(jù)量就是30G，40G -> 100臺(tái)，600G，800G，甚至1T+，海量數(shù)據(jù)

冗余slave

• 假設(shè)現(xiàn)在有3個(gè)master，有5個(gè)slave，就會(huì)出現(xiàn)有的master不止一個(gè)的情況
• 這種情況是冗余slave，保證cluster的高可用性
• 為了避免的場(chǎng)景，就是說(shuō)，如果你每個(gè)master只有一個(gè)slave，萬(wàn)一說(shuō)一個(gè)slave死了，然后很快，master也死了，那可用性還是降低了
• 如果有的master掛了，那么slave能快速補(bǔ)成slave，那這個(gè)新master就沒(méi)有slave了，那么多的冗余slave就會(huì)補(bǔ)上

4、redis-cluster的核心原理分析：gossip通信，jedis smart定位，主備切換

redis自身是有一些元數(shù)據(jù)的，比如 hashslot 對(duì)應(yīng)每個(gè)master節(jié)點(diǎn)的信息，master和slave的對(duì)應(yīng)關(guān)系，故障信息等。
(1):基本通信原理

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

• 集中元數(shù)據(jù)管理

  • 集中式元數(shù)據(jù)管理，底層基于zookeeper（分布式協(xié)調(diào)的中間件）的集群所有元數(shù)據(jù)維護(hù)
  • 所有節(jié)點(diǎn)信息由zookeeper集中維護(hù)，同步

• goosip

  • 跟git一樣，每個(gè)節(jié)點(diǎn)都持有一份元數(shù)據(jù)
  • 不同節(jié)點(diǎn)如果出現(xiàn)了元數(shù)據(jù)的變更以后，就不斷將元數(shù)據(jù)發(fā)送給其他節(jié)點(diǎn)，讓其他節(jié)點(diǎn)進(jìn)行更新

• 集中式優(yōu)缺點(diǎn)

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

• goosip優(yōu)缺點(diǎn)

  • 好處：元數(shù)據(jù)的更新比較分散，不是集中在一個(gè)地方，更新請(qǐng)求會(huì)陸陸續(xù)續(xù)，打到所有節(jié)點(diǎn)上更新，有一點(diǎn)延時(shí)，降低壓力
  • 缺點(diǎn)：元數(shù)據(jù)更新有延時(shí)，可能導(dǎo)致集群的一些操作會(huì)有些滯后

• 10000端口

  • 每個(gè)節(jié)點(diǎn)需要相互交換信息，需要一個(gè)特定的端口，就是自己的服務(wù)端口號(hào) + 10000 , 比如7001，節(jié)點(diǎn)間通信端口就是17001端口
  • 每個(gè)節(jié)點(diǎn)每隔一段時(shí)間都會(huì)往另外幾個(gè)節(jié)點(diǎn)發(fā)送ping消息，同時(shí)其他節(jié)點(diǎn)接受到ping之后，返回pong。就是網(wǎng)絡(luò)正常的

• 交換信息

  • 故障信息，節(jié)點(diǎn)的增加和移除，hash slot 信息，等等。

• gossip協(xié)議

  • gossip協(xié)議包含多種消息，包括ping，pong，meet，fail，等等
  • meet: 某個(gè)節(jié)點(diǎn)發(fā)送meet給新加入的節(jié)點(diǎn)，讓新節(jié)點(diǎn)加入集群中，然后新節(jié)點(diǎn)就會(huì)開(kāi)始與其他節(jié)點(diǎn)進(jìn)行通信
  • ping: 每個(gè)節(jié)點(diǎn)都會(huì)頻繁給其他節(jié)點(diǎn)發(fā)送ping，其中包含自己的狀態(tài)還有自己維護(hù)的集群元數(shù)據(jù)，互相通過(guò)ping交換元數(shù)據(jù),每個(gè)節(jié)點(diǎn)每秒都會(huì)頻繁發(fā)送ping給其他的集群，ping，頻繁的互相之間交換數(shù)據(jù)，互相進(jìn)行元數(shù)據(jù)的更新
  • 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ī)了

• ping消息深入

  • ping很頻繁，而且要攜帶一些元數(shù)據(jù)，所以可能會(huì)加重網(wǎng)絡(luò)負(fù)擔(dān)
  • 每個(gè)節(jié)點(diǎn)每秒會(huì)執(zhí)行10次ping，每次會(huì)選擇5個(gè)最久沒(méi)有通信的其他節(jié)點(diǎn)
  • 當(dāng)然如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)通信延時(shí)達(dá)到了cluster_node_timeout / 2，那么立即發(fā)送ping，避免數(shù)據(jù)交換延時(shí)過(guò)長(zhǎng)，落后的時(shí)間太長(zhǎng)了
  • 比如說(shuō)，兩個(gè)節(jié)點(diǎn)之間都10分鐘沒(méi)有交換數(shù)據(jù)了，那么整個(gè)集群處于嚴(yán)重的元數(shù)據(jù)不一致的情況，就會(huì)有問(wèn)題
  • 所以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)的信息

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

• 開(kāi)發(fā)，jedis，redis的java client客戶端，redis cluster，jedis cluster api
• jedis cluster api與redis cluster集群交互的一些基本原理
• 當(dāng)在cluster集群中g(shù)et值的時(shí)候，經(jīng)常會(huì)出現(xiàn)move 到其他機(jī)器，因?yàn)檫@個(gè)key不在這個(gè)機(jī)器
• 1、基于重定向的客戶端
  • redis-cli -c，自動(dòng)重定向
    -（1）請(qǐng)求重定向
    • 客戶端可能會(huì)挑選任意一個(gè)redis實(shí)例去發(fā)送命令，每個(gè)redis實(shí)例接收到命令，都會(huì)計(jì)算key對(duì)應(yīng)的hash slot
    • 如果在本地就在本地處理，否則返回moved給客戶端，讓客戶端進(jìn)行重定向
    • cluster keyslot mykey，可以查看一個(gè)key對(duì)應(yīng)的hash slot是什么
      -（2）計(jì)算hash slot
    • 計(jì)算hash slot的算法，就是根據(jù)key計(jì)算CRC16值，然后對(duì)16384取模，拿到對(duì)應(yīng)的hash slot
    • 用hash tag可以手動(dòng)指定key對(duì)應(yīng)的slot，同一個(gè)hash tag下的key，都會(huì)在一個(gè)hash slot中，比如set mykey1:{100}和set mykey2:{100}
      -（3）hash slot查找
    • 節(jié)點(diǎn)間通過(guò)gossip協(xié)議進(jìn)行數(shù)據(jù)交換，就知道每個(gè)hash slot在哪個(gè)節(jié)點(diǎn)上
• 2、smart jedis
  • 基于重定向的客戶端，很消耗網(wǎng)絡(luò)IO，因?yàn)榇蟛糠智闆r下，可能都會(huì)出現(xiàn)一次請(qǐng)求重定向，才能找到正確的節(jié)點(diǎn)（經(jīng)常需多move一次）
  • 所以大部分的客戶端，比如java redis客戶端，就是jedis，都是smart的
  • 本地維護(hù)一份hashslot -> node的映射表，緩存，大部分情況下，直接走本地緩存就可以找到hashslot -> node，不需要通過(guò)節(jié)點(diǎn)進(jìn)行moved重定向
• 3、JedisCluster的工作原理
  • 在JedisCluster初始化的時(shí)候，就會(huì)隨機(jī)選擇一個(gè)node，初始化hashslot -> node映射表，同時(shí)為每個(gè)節(jié)點(diǎn)創(chuàng)建一個(gè)JedisPool連接池
  • 每次基于JedisCluster執(zhí)行操作，首先JedisCluster都會(huì)在本地計(jì)算key的hashslot，然后在本地映射表找到對(duì)應(yīng)的節(jié)點(diǎn)
  • 如果那個(gè)node正好還是持有那個(gè)hashslot，那么就ok; 如果說(shuō)進(jìn)行了reshard這樣的操作，可能hashslot已經(jīng)不在那個(gè)node上了，就會(huì)返回moved
  • 如果JedisCluter API發(fā)現(xiàn)對(duì)應(yīng)的節(jié)點(diǎn)返回moved，那么利用該節(jié)點(diǎn)的元數(shù)據(jù)，更新本地的hashslot -> node映射表緩存
  • 重復(fù)上面幾個(gè)步驟，直到找到對(duì)應(yīng)的節(jié)點(diǎn)，如果重試超過(guò)5次，那么就報(bào)錯(cuò)，JedisClusterMaxRedirectionException
  • jedis老版本，可能會(huì)出現(xiàn)在集群某個(gè)節(jié)點(diǎn)故障還沒(méi)完成自動(dòng)切換恢復(fù)時(shí)，頻繁更新hash slot，頻繁ping節(jié)點(diǎn)檢查活躍，導(dǎo)致大量網(wǎng)絡(luò)IO開(kāi)銷
  • jedis最新版本，對(duì)于這些過(guò)度的hash slot更新和ping，都進(jìn)行了優(yōu)化，避免了類似問(wèn)題
• 4、hashslot遷移和ask重定向
  • 如果hash slot正在遷移，那么會(huì)返回ask重定向給jedis
  • jedis接收到ask重定向之后，會(huì)重新定位到目標(biāo)節(jié)點(diǎn)去執(zhí)行，但是因?yàn)閍sk發(fā)生在hash slot遷移過(guò)程中，所以，JedisCluster API收到ask是不會(huì)更新hashslot本地緩存
  • 已經(jīng)可以確定說(shuō)，hashslot已經(jīng)遷移完了，moved是會(huì)更新本地hashslot->node映射表緩存的

(3)高可用性和主備切換原理

• 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)一直沒(méi)有返回pong，那么就被認(rèn)為pfail
    • 如果一個(gè)節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn)pfail了，那么會(huì)在gossip ping消息中，ping給其他節(jié)點(diǎn)，如果超過(guò)半數(shù)的節(jié)點(diǎn)都認(rèn)為pfail了，那么就會(huì)變成fail
  • 2、從節(jié)點(diǎn)過(guò)濾
    • 對(duì)宕機(jī)的master node，從其所有的slave node中，選擇一個(gè)切換成master node
    • 檢查每個(gè)slave node與master node斷開(kāi)連接的時(shí)間，如果超過(guò)了cluster-node-timeout * cluster-slave-validity-factor，那么就沒(méi)有資格切換成master
    • 這個(gè)也是跟哨兵是一樣的，從節(jié)點(diǎn)超時(shí)過(guò)濾的步驟
  • 3、從節(jié)點(diǎn)選舉
    • 哨兵：對(duì)所有從節(jié)點(diǎn)進(jìn)行排序，slave priority，offset，run id
    • 每個(gè)從節(jié)點(diǎn)，都根據(jù)自己對(duì)master復(fù)制數(shù)據(jù)的offset，來(lái)設(shè)置一個(gè)選舉時(shí)間，offset越大（復(fù)制數(shù)據(jù)越多）的從節(jié)點(diǎn)，選舉時(shí)間越靠前，優(yōu)先進(jìn)行選舉
    • 所有的master node開(kāi)始slave選舉投票，給要進(jìn)行選舉的slave進(jìn)行投票，如果大部分master node（N/2 + 1）都投票給了某個(gè)從節(jié)點(diǎn)，那么選舉通過(guò)，那個(gè)從節(jié)點(diǎn)可以切換成master
    • 從節(jié)點(diǎn)執(zhí)行主備切換，從節(jié)點(diǎn)切換為主節(jié)點(diǎn)
  • 4、與哨兵比較
    • 整個(gè)流程跟哨兵相比，非常類似，所以說(shuō)，redis cluster功能強(qiáng)大，直接集成了replication和sentinal的功能

5、總結(jié)
redis寫(xiě)了好幾篇，主要是單機(jī)redis，主從redis，哨兵,然后加上cluster，大家可以根據(jù)自己的
項(xiàng)目靈活選擇哪種架構(gòu)方式，但是注意線上redis一定要做好數(shù)據(jù)安全，做好數(shù)據(jù)備份。然后可以使用
redis-benchmark 工具對(duì)redis進(jìn)行壓測(cè)，分析當(dāng)前性能是否夠用。