文章目錄

• • • 一、redis持久化
    • • 1.1.RDB持久化
      • • 1.1.1.執(zhí)行時(shí)機(jī)
        • 1.1.2.RDB原理
        • 1.1.3.小結(jié)
      • 1.2.AOF持久化
      • • 1.2.1.AOF原理
        • 1.2.2.AOF配置
        • 1.2.3.AOF文件重寫
        • 1.2.4.小結(jié)
      • 1.3.RDB與AOF對(duì)比
    • 二、Redis主從集群
    • • 2.1.集群結(jié)構(gòu)
      • 2.2.準(zhǔn)備實(shí)例和配置
      • 2.3.啟動(dòng)
      • 2.4.開(kāi)啟主從關(guān)系
      • 2.5.測(cè)試
      • 2.6.主從數(shù)據(jù)同步原理
      • • 2.6.1.全量同步
        • 2.6.2.增量同步
        • 2.2.3.repl_backlog原理
      • 2.7.主從同步優(yōu)化
      • 2.8.小結(jié)
    • 三、搭建哨兵集群
    • • 3.1.哨兵原理
      • • 3.1.1.集群結(jié)構(gòu)和作用
        • 3.1.2.集群監(jiān)控原理
        • 3.1.3.集群故障恢復(fù)原理
        • 3.1.4.小結(jié)
      • 3.2.準(zhǔn)備實(shí)例和配置
      • 3.3.啟動(dòng)
      • 3.4.測(cè)試
      • 3.5.RedisTemplate
      • • 3.5.1.引入依賴
        • 3.5.2.配置Redis地址
        • 3.5.3.配置讀寫分離
        • 3.5.4.測(cè)試
    • 四、Redis分片集群
    • • 4.1.搭建分片集群
      • • 4.1.1.準(zhǔn)備實(shí)例和配置
        • 4.1.2.啟動(dòng)
        • 4.1.3.創(chuàng)建集群
      • 4.2.散列插槽
      • • 4.2.1.插槽原理
        • 4.2.2.小結(jié)
      • 4.3.集群伸縮
      • • 4.3.1.需求分析
        • 4.3.2.創(chuàng)建新的redis實(shí)例
        • 4.3.3.添加新節(jié)點(diǎn)到redis
        • 4.3.4.轉(zhuǎn)移插槽
      • 4.4.故障轉(zhuǎn)移
      • • 4.4.1.自動(dòng)故障轉(zhuǎn)移
        • 4.4.2.手動(dòng)故障轉(zhuǎn)移
      • 4.5.RedisTemplate訪問(wèn)分片集群

一、redis持久化

Redis有兩種持久化方案：

• RDB持久化
• AOF持久化

1.1.RDB持久化

RDB全稱Redis Database Backup file（Redis數(shù)據(jù)備份文件），也被叫做Redis數(shù)據(jù)快照。簡(jiǎn)單來(lái)說(shuō)就是把內(nèi)存中的所有數(shù)據(jù)都記錄到磁盤中。當(dāng)Redis實(shí)例故障重啟后，從磁盤讀取快照文件，恢復(fù)數(shù)據(jù)。快照文件稱為RDB文件，默認(rèn)是保存在當(dāng)前運(yùn)行目錄。

1.1.1.執(zhí)行時(shí)機(jī)

RDB持久化在四種情況下會(huì)執(zhí)行：

• 執(zhí)行save命令
• 執(zhí)行bgsave命令
• redis停機(jī)時(shí)
• 觸發(fā)RDB條件時(shí)

1）save命令

執(zhí)行下面的命令，可以立即執(zhí)行一次RDB：

save命令會(huì)導(dǎo)致主進(jìn)程執(zhí)行RDB，這個(gè)過(guò)程中其它所有命令都會(huì)被阻塞。只有在數(shù)據(jù)遷移時(shí)可能用到，數(shù)據(jù)遷移時(shí)redis不再接收新的請(qǐng)求，使用save可以阻塞請(qǐng)求。

2）bgsave命令

下面的命令可以異步執(zhí)行RDB：

這個(gè)命令執(zhí)行后會(huì)開(kāi)啟獨(dú)立進(jìn)程完成RDB，主進(jìn)程可以持續(xù)處理用戶請(qǐng)求，不受影響。

3）停機(jī)時(shí)

redis停機(jī)時(shí)會(huì)執(zhí)行一次save命令，實(shí)現(xiàn)RDB持久化。

4）觸發(fā)RDB條件

Redis內(nèi)部有觸發(fā)RDB的機(jī)制，可以在redis.conf文件中找到，格式如下：

# 900秒內(nèi)，如果至少有1個(gè)key被修改，則執(zhí)行bgsave ， 如果是save "" 則表示禁用RDB save 900 1 save 300 10 save 60 10000

RDB的其它配置也可以在redis.conf文件中設(shè)置：

# 是否壓縮 ,建議不開(kāi)啟，壓縮也會(huì)消耗cpu，磁盤的話不值錢 rdbcompression yes# RDB文件名稱 dbfilename dump.rdb # 文件保存的路徑目錄 dir ./

1.1.2.RDB原理

bgsave開(kāi)始時(shí)會(huì)fork主進(jìn)程得到子進(jìn)程，子進(jìn)程共享主進(jìn)程的內(nèi)存數(shù)據(jù)。完成fork后讀取內(nèi)存數(shù)據(jù)并寫入 RDB 文件。

fork采用的是copy-on-write技術(shù)：

• 當(dāng)主進(jìn)程執(zhí)行讀操作時(shí)，訪問(wèn)共享內(nèi)存；
• 當(dāng)主進(jìn)程執(zhí)行寫操作時(shí)，則會(huì)拷貝一份數(shù)據(jù)，執(zhí)行寫操作。
  

主進(jìn)程fork()子進(jìn)程之后，內(nèi)核把主進(jìn)程中所有的內(nèi)存頁(yè)的權(quán)限都設(shè)為read-only，然后子進(jìn)程的地址空間指向主進(jìn)程。這也就是共享了主進(jìn)程的內(nèi)存，當(dāng)其中某個(gè)進(jìn)程寫內(nèi)存時(shí)(這里肯定是主進(jìn)程寫，因?yàn)樽舆M(jìn)程只負(fù)責(zé)rdb文件持久化工作，不參與客戶端的請(qǐng)求)，CPU硬件檢測(cè)到內(nèi)存頁(yè)是read-only的，于是觸發(fā)頁(yè)異常中斷（page-fault），陷入內(nèi)核的一個(gè)中斷例程。中斷例程中，內(nèi)核就會(huì)把觸發(fā)的異常的頁(yè)復(fù)制一份（這里僅僅復(fù)制異常頁(yè)，也就是所修改的那個(gè)數(shù)據(jù)頁(yè)，而不是內(nèi)存中的全部數(shù)據(jù)），于是主子進(jìn)程各自持有獨(dú)立的一份。主進(jìn)程修改了哪個(gè)數(shù)據(jù)，指針就指向那個(gè)新的數(shù)據(jù)，其余指針依舊指向和子進(jìn)程共享的數(shù)據(jù)

1.1.3.小結(jié)

RDB方式bgsave的基本流程？

• fork主進(jìn)程得到一個(gè)子進(jìn)程，共享內(nèi)存空間
• 子進(jìn)程讀取內(nèi)存數(shù)據(jù)并寫入新的RDB文件
• 用新RDB文件替換舊的RDB文件

RDB會(huì)在什么時(shí)候執(zhí)行？save 60 1000代表什么含義？

• 默認(rèn)是服務(wù)停止時(shí)
• 代表60秒內(nèi)至少執(zhí)行1000次修改則觸發(fā)RDB

RDB的缺點(diǎn)？

• RDB是間隔一段時(shí)間進(jìn)行持久化,如果持久化之間 redis 發(fā)生故障,會(huì)發(fā)生數(shù)據(jù)丟失風(fēng)險(xiǎn)
• fork子進(jìn)程、壓縮、寫出RDB文件都比較耗時(shí)

1.2.AOF持久化

1.2.1.AOF原理

AOF全稱為Append Only File（追加文件）。Redis處理的每一個(gè)寫命令都會(huì)記錄在AOF文件，可以看做是命令日志文件。

1.2.2.AOF配置

AOF默認(rèn)是關(guān)閉的，需要修改redis.conf配置文件來(lái)開(kāi)啟AOF：

# 是否開(kāi)啟AOF功能，默認(rèn)是no appendonly yes # AOF文件的名稱 appendfilename "appendonly.aof"

AOF的命令記錄的頻率也可以通過(guò)redis.conf文件來(lái)配：

# 表示每執(zhí)行一次寫命令，立即記錄到AOF文件 appendfsync always # 寫命令執(zhí)行完先放入AOF緩沖區(qū)，然后表示每隔1秒將緩沖區(qū)數(shù)據(jù)寫到AOF文件，是默認(rèn)方案 appendfsync everysec # 寫命令執(zhí)行完先放入AOF緩沖區(qū)，由操作系統(tǒng)決定何時(shí)將緩沖區(qū)內(nèi)容寫回磁盤 appendfsync no

三種策略對(duì)比：

1.2.3.AOF文件重寫

因?yàn)槭怯涗浢?#xff0c;AOF文件會(huì)比RDB文件大的多。而且AOF會(huì)記錄對(duì)同一個(gè)key的多次寫操作，但只有最后一次寫操作才有意義。通過(guò)執(zhí)行bgrewriteaof命令，可以讓AOF文件執(zhí)行重寫功能，用最少的命令達(dá)到相同效果。

如圖，AOF原本有三個(gè)命令，但是set num 123 和 set num 666都是對(duì)num的操作，第二次會(huì)覆蓋第一次的值，因此第一個(gè)命令記錄下來(lái)沒(méi)有意義。

所以重寫命令后，理論上AOF文件內(nèi)容就是：mset name jack num 666，實(shí)際上是一堆亂碼

Redis也會(huì)在觸發(fā)閾值時(shí)自動(dòng)去重寫AOF文件。閾值也可以在redis.conf中配置：

# AOF文件比上次文件 增長(zhǎng)超過(guò)多少百分比則觸發(fā)重寫 auto-aof-rewrite-percentage 100 # AOF文件體積最小多大以上才觸發(fā)重寫 auto-aof-rewrite-min-size 64mb

1.2.4.小結(jié)

AOF的缺點(diǎn)？

• 比如在同樣數(shù)據(jù)規(guī)模的情況下，AOF文件要比RDB文件的體積大。而且，AOF 方式的恢復(fù)速度也要慢于RDB 方式。

1.3.RDB與AOF對(duì)比

RDB和AOF各有自己的優(yōu)缺點(diǎn)，如果對(duì)數(shù)據(jù)安全性要求較高，在實(shí)際開(kāi)發(fā)中往往會(huì)結(jié)合兩者來(lái)使用。

二、Redis主從集群

2.1.集群結(jié)構(gòu)

我們搭建的主從集群結(jié)構(gòu)如圖：

共包含三個(gè)節(jié)點(diǎn)，一個(gè)主節(jié)點(diǎn)，兩個(gè)從節(jié)點(diǎn)。

這里我們會(huì)在同一臺(tái)虛擬機(jī)中開(kāi)啟3個(gè)redis實(shí)例，模擬主從集群，信息如下：

IPPORT角色

192.168.150.101	7001	master
192.168.150.101	7002	slave
192.168.150.101	7003	slave

2.2.準(zhǔn)備實(shí)例和配置

要在同一臺(tái)虛擬機(jī)開(kāi)啟3個(gè)實(shí)例，必須準(zhǔn)備三份不同的配置文件和目錄，配置文件所在目錄也就是工作目錄。

1）創(chuàng)建目錄

我們創(chuàng)建三個(gè)文件夾，名字分別叫7001、7002、7003：

# 進(jìn)入/tmp目錄 cd /tmp # 創(chuàng)建目錄 mkdir 7001 7002 7003

2）拷貝配置文件到每個(gè)實(shí)例目錄

然后將redis-6.2.4/redis.conf文件拷貝到三個(gè)目錄中（在/tmp目錄執(zhí)行下列命令）：

# 方式一：逐個(gè)拷貝 cp redis-6.2.4/redis.conf 7001 cp redis-6.2.4/redis.conf 7002 cp redis-6.2.4/redis.conf 7003# 方式二：管道組合命令，一鍵拷貝 echo 7001 7002 7003 | xargs -t -n 1 cp redis-6.2.4/redis.conf

3）修改每個(gè)實(shí)例的端口、工作目錄

修改每個(gè)文件夾內(nèi)的配置文件，將端口分別修改為7001、7002、7003，將rdb文件保存位置都修改為自己所在目錄（在/tmp目錄執(zhí)行下列命令）：

sed -i -e 's/6379/7001/g' -e 's/dir .\//dir \/tmp\/7001\//g' 7001/redis.conf sed -i -e 's/6379/7002/g' -e 's/dir .\//dir \/tmp\/7002\//g' 7002/redis.conf sed -i -e 's/6379/7003/g' -e 's/dir .\//dir \/tmp\/7003\//g' 7003/redis.conf

4）修改每個(gè)實(shí)例的聲明IP

虛擬機(jī)本身有多個(gè)IP，為了避免將來(lái)混亂，我們需要在redis.conf文件中指定每一個(gè)實(shí)例的綁定ip信息，格式如下：

# redis實(shí)例的聲明 IP replica-announce-ip 192.168.150.101

每個(gè)目錄都要改，我們一鍵完成修改（在/tmp目錄執(zhí)行下列命令）：

# 逐一執(zhí)行 sed -i '1a replica-announce-ip 192.168.150.101' 7001/redis.conf sed -i '1a replica-announce-ip 192.168.150.101' 7002/redis.conf sed -i '1a replica-announce-ip 192.168.150.101' 7003/redis.conf# 或者一鍵修改 printf '%s\n' 7001 7002 7003 | xargs -I{} -t sed -i '1a replica-announce-ip 192.168.150.101' {}/redis.conf

2.3.啟動(dòng)

為了方便查看日志，我們打開(kāi)3個(gè)ssh窗口，分別啟動(dòng)3個(gè)redis實(shí)例，啟動(dòng)命令：

# 第1個(gè) redis-server 7001/redis.conf # 第2個(gè) redis-server 7002/redis.conf # 第3個(gè) redis-server 7003/redis.conf

啟動(dòng)后：

如果要一鍵停止，可以運(yùn)行下面命令：

printf '%s\n' 7001 7002 7003 | xargs -I{} -t redis-cli -p {} shutdown

2.4.開(kāi)啟主從關(guān)系

現(xiàn)在三個(gè)實(shí)例還沒(méi)有任何關(guān)系，要配置主從可以使用replicaof 或者slaveof（5.0以前）命令。

有臨時(shí)和永久兩種模式：

• 修改配置文件（永久生效）

  • 在redis.conf中添加一行配置：slaveof <masterip> <masterport>

• 使用redis-cli客戶端連接到redis服務(wù)，執(zhí)行slaveof命令（重啟后失效）：

  slaveof <masterip> <masterport>

注意：在5.0以后新增命令replicaof，與salveof效果一致。

通過(guò)redis-cli命令連接7002，執(zhí)行下面命令：

# 連接 7002 redis-cli -p 7002 # 執(zhí)行slaveof slaveof 192.168.150.101 7001

通過(guò)redis-cli命令連接7003，執(zhí)行下面命令：

# 連接 7003 redis-cli -p 7003 # 執(zhí)行slaveof slaveof 192.168.150.101 7001

然后連接 7001節(jié)點(diǎn)，查看集群狀態(tài)：

# 連接 7001 redis-cli -p 7001 # 查看狀態(tài) info replication

結(jié)果：

注意：在linxu服務(wù)器搭建主從復(fù)制報(bào)錯(cuò)

解決方案：

• 去云服務(wù)器安全組打開(kāi)7001,7002，7003端口即可

2.5.測(cè)試

執(zhí)行下列操作以測(cè)試：

• 利用redis-cli連接7001，執(zhí)行set num 123

• 利用redis-cli連接7002，執(zhí)行g(shù)et num，再執(zhí)行set num 666

• 利用redis-cli連接7003，執(zhí)行g(shù)et num，再執(zhí)行set num 888

可以發(fā)現(xiàn)，只有在7001這個(gè)master節(jié)點(diǎn)上可以執(zhí)行寫操作，7002和7003這兩個(gè)slave節(jié)點(diǎn)只能執(zhí)行讀操作。

2.6.主從數(shù)據(jù)同步原理

2.6.1.全量同步

主從第一次建立連接時(shí)，會(huì)執(zhí)行全量同步，將master節(jié)點(diǎn)的所有數(shù)據(jù)都拷貝給slave節(jié)點(diǎn)，流程：

這里有一個(gè)問(wèn)題，master如何得知salve是第一次來(lái)連接呢？？

有幾個(gè)概念，可以作為判斷依據(jù)：

• Replication Id：簡(jiǎn)稱replid，是數(shù)據(jù)集的標(biāo)記，id一致則說(shuō)明是同一數(shù)據(jù)集。每一個(gè)master都有唯一的replid，slave則會(huì)繼承master節(jié)點(diǎn)的replid
• offset：偏移量，隨著記錄在repl_baklog中的數(shù)據(jù)增多而逐漸增大。slave完成同步時(shí)也會(huì)記錄當(dāng)前同步的offset。如果slave的offset小于master的offset，說(shuō)明slave數(shù)據(jù)落后于master，需要更新。

因此slave做數(shù)據(jù)同步，必須向master聲明自己的replication id 和offset，master才可以判斷到底需要同步哪些數(shù)據(jù)。

因?yàn)閟lave原本也是一個(gè)master，有自己的replid和offset，當(dāng)?shù)谝淮巫兂蓅lave，與master建立連接時(shí)，發(fā)送的replid和offset是自己的replid和offset。

master判斷發(fā)現(xiàn)slave發(fā)送來(lái)的replid與自己的不一致，說(shuō)明這是一個(gè)全新的slave，就知道要做全量同步了。

master會(huì)將自己的replid和offset都發(fā)送給這個(gè)slave，slave保存這些信息。以后slave的replid就與master一致了。

因此，master判斷一個(gè)節(jié)點(diǎn)是否是第一次同步的依據(jù)，就是看replid是否一致。

如圖：

完整流程描述：

• slave節(jié)點(diǎn)請(qǐng)求增量同步
• master節(jié)點(diǎn)判斷replid，發(fā)現(xiàn)不一致，拒絕增量同步
• master將完整內(nèi)存數(shù)據(jù)生成RDB，發(fā)送RDB到slave
• slave清空本地?cái)?shù)據(jù)，加載master的RDB
• master將RDB期間的命令記錄在repl_baklog，并持續(xù)將log中的命令發(fā)送給slave
• slave執(zhí)行接收到的命令，保持與master之間的同步

2.6.2.增量同步

全量同步需要先做RDB，然后將RDB文件通過(guò)網(wǎng)絡(luò)傳輸個(gè)slave，成本太高了。因此除了第一次做全量同步，其它大多數(shù)時(shí)候slave與master都是做增量同步。

什么是增量同步？就是只更新slave與master存在差異的部分?jǐn)?shù)據(jù)。如圖：

那么master怎么知道slave與自己的數(shù)據(jù)差異在哪里呢?

2.2.3.repl_backlog原理

master怎么知道slave與自己的數(shù)據(jù)差異在哪里呢?

這就要說(shuō)到全量同步時(shí)的repl_baklog文件了。

這個(gè)文件是一個(gè)固定大小的數(shù)組，只不過(guò)數(shù)組是環(huán)形，也就是說(shuō)角標(biāo)到達(dá)數(shù)組末尾后，會(huì)再次從0開(kāi)始讀寫，這樣數(shù)組頭部的數(shù)據(jù)就會(huì)被覆蓋。

repl_baklog中會(huì)記錄Redis處理過(guò)的命令日志及offset，包括master當(dāng)前的offset，和slave已經(jīng)拷貝到的offset：

slave與master的offset之間的差異，就是salve需要增量拷貝的數(shù)據(jù)了。

隨著不斷有數(shù)據(jù)寫入，master的offset逐漸變大，slave也不斷的拷貝，追趕master的offset：

直到數(shù)組被填滿：

此時(shí)，如果有新的數(shù)據(jù)寫入，就會(huì)覆蓋數(shù)組中的舊數(shù)據(jù)。不過(guò)，舊的數(shù)據(jù)只要是綠色的，說(shuō)明是已經(jīng)被同步到slave的數(shù)據(jù)，即便被覆蓋了也沒(méi)什么影響。因?yàn)槲赐降膬H僅是紅色部分。

但是，如果slave出現(xiàn)網(wǎng)絡(luò)阻塞，導(dǎo)致master的offset遠(yuǎn)遠(yuǎn)超過(guò)了slave的offset：

如果master繼續(xù)寫入新數(shù)據(jù)，其offset就會(huì)覆蓋舊的數(shù)據(jù)，直到將slave現(xiàn)在的offset也覆蓋：

棕色框中的紅色部分，就是尚未同步，但是卻已經(jīng)被覆蓋的數(shù)據(jù)。此時(shí)如果slave恢復(fù)，需要同步，卻發(fā)現(xiàn)自己的offset都沒(méi)有了，無(wú)法完成增量同步了。只能做全量同步。

2.7.主從同步優(yōu)化

主從同步可以保證主從數(shù)據(jù)的一致性，非常重要。

可以從以下幾個(gè)方面來(lái)優(yōu)化Redis主從就集群：

• 在master中配置repl-diskless-sync yes啟用無(wú)磁盤復(fù)制，避免全量同步時(shí)的磁盤IO。
• Redis單節(jié)點(diǎn)上的內(nèi)存占用不要太大，減少RDB導(dǎo)致的過(guò)多磁盤IO
• 適當(dāng)提高repl_baklog的大小，發(fā)現(xiàn)slave宕機(jī)時(shí)盡快實(shí)現(xiàn)故障恢復(fù)，盡可能避免全量同步
• 限制一個(gè)master上的slave節(jié)點(diǎn)數(shù)量，如果實(shí)在是太多slave，則可以采用主-從-從鏈?zhǔn)浇Y(jié)構(gòu)，減少master壓力

主從從架構(gòu)圖：

2.8.小結(jié)

簡(jiǎn)述全量同步和增量同步區(qū)別？

• 全量同步：master將完整內(nèi)存數(shù)據(jù)生成RDB，發(fā)送RDB到slave。后續(xù)命令則記錄在repl_baklog，逐個(gè)發(fā)送給slave。
• 增量同步：slave提交自己的offset到master，master獲取repl_baklog中從offset之后的命令給slave

什么時(shí)候執(zhí)行全量同步？

• slave節(jié)點(diǎn)第一次連接master節(jié)點(diǎn)時(shí)
• slave節(jié)點(diǎn)斷開(kāi)時(shí)間太久，repl_baklog中的offset已經(jīng)被覆蓋時(shí)

什么時(shí)候執(zhí)行增量同步？

• slave節(jié)點(diǎn)斷開(kāi)又恢復(fù)，并且在repl_baklog中能找到offset時(shí)

三、搭建哨兵集群

3.1.哨兵原理

3.1.1.集群結(jié)構(gòu)和作用

這里我們搭建一個(gè)三節(jié)點(diǎn)形成的Sentinel集群，來(lái)監(jiān)管之前的Redis主從集群。如圖：

哨兵的作用如下：

• 監(jiān)控：Sentinel 會(huì)不斷檢查您的master和slave是否按預(yù)期工作
• 自動(dòng)故障恢復(fù)：如果master故障，Sentinel會(huì)將一個(gè)slave提升為master。當(dāng)故障實(shí)例恢復(fù)后也以新的master為主
• 通知：Sentinel充當(dāng)Redis客戶端的服務(wù)發(fā)現(xiàn)來(lái)源，當(dāng)集群發(fā)生故障轉(zhuǎn)移時(shí)，會(huì)將最新信息推送給Redis的客戶端

3.1.2.集群監(jiān)控原理

Sentinel基于心跳機(jī)制監(jiān)測(cè)服務(wù)狀態(tài)，每隔1秒向集群的每個(gè)實(shí)例發(fā)送ping命令：

?主觀下線：如果某sentinel節(jié)點(diǎn)發(fā)現(xiàn)某實(shí)例未在規(guī)定時(shí)間響應(yīng)，則認(rèn)為該實(shí)例主觀下線。

?客觀下線：若超過(guò)指定數(shù)量（quorum）的sentinel都認(rèn)為該實(shí)例主觀下線，則該實(shí)例客觀下線。quorum值最好超過(guò)Sentinel實(shí)例數(shù)量的一半。

3.1.3.集群故障恢復(fù)原理

一旦發(fā)現(xiàn)master故障，sentinel需要在salve中選擇一個(gè)作為新的master，選擇依據(jù)是這樣的：

• 首先會(huì)判斷slave節(jié)點(diǎn)與master節(jié)點(diǎn)斷開(kāi)時(shí)間長(zhǎng)短，如果超過(guò)指定值（down-after-milliseconds * 10）則會(huì)排除該slave節(jié)點(diǎn)
• 然后判斷slave節(jié)點(diǎn)的slave-priority值，越小優(yōu)先級(jí)越高，如果是0則永不參與選舉
• 如果slave-prority一樣，則判斷slave節(jié)點(diǎn)的offset值，越大說(shuō)明數(shù)據(jù)越新，優(yōu)先級(jí)越高
• 最后是判斷slave節(jié)點(diǎn)的運(yùn)行id大小，越小優(yōu)先級(jí)越高。

當(dāng)選出一個(gè)新的master后，該如何實(shí)現(xiàn)切換呢？

流程如下：

• sentinel給備選的slave1節(jié)點(diǎn)發(fā)送slaveof no one命令，讓該節(jié)點(diǎn)成為master
• sentinel給所有其它slave發(fā)送slaveof 192.168.150.101 7002 命令，讓這些slave成為新master的從節(jié)點(diǎn)，開(kāi)始從新的master上同步數(shù)據(jù)。
• 最后，sentinel將故障節(jié)點(diǎn)標(biāo)記為slave，當(dāng)故障節(jié)點(diǎn)恢復(fù)后會(huì)自動(dòng)成為新的master的slave節(jié)點(diǎn)

3.1.4.小結(jié)

Sentinel的三個(gè)作用是什么？

• 監(jiān)控
• 故障轉(zhuǎn)移
• 通知

Sentinel如何判斷一個(gè)redis實(shí)例是否健康？

• 每隔1秒發(fā)送一次ping命令，如果超過(guò)一定時(shí)間沒(méi)有相向則認(rèn)為是主觀下線
• 如果大多數(shù)sentinel都認(rèn)為實(shí)例主觀下線，則判定服務(wù)下線

故障轉(zhuǎn)移步驟有哪些？

• 首先選定一個(gè)slave作為新的master，執(zhí)行slaveof no one
• 然后讓所有節(jié)點(diǎn)都執(zhí)行slaveof 新master
• 修改故障節(jié)點(diǎn)配置，添加slaveof 新master

3.2.準(zhǔn)備實(shí)例和配置

要在同一臺(tái)虛擬機(jī)開(kāi)啟3個(gè)實(shí)例，必須準(zhǔn)備三份不同的配置文件和目錄，配置文件所在目錄也就是工作目錄。

三個(gè)sentinel實(shí)例信息如下：

節(jié)點(diǎn)IPPORT

s1	192.168.150.101	27001
s2	192.168.150.101	27002
s3	192.168.150.101	27003

我們創(chuàng)建三個(gè)文件夾，名字分別叫s1、s2、s3：

# 進(jìn)入/tmp目錄 cd /tmp # 創(chuàng)建目錄 mkdir s1 s2 s3

然后我們?cè)趕1目錄創(chuàng)建一個(gè)sentinel.conf文件，添加下面的內(nèi)容：

port 27001 sentinel announce-ip 192.168.150.101 sentinel monitor mymaster 192.168.150.101 7001 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 dir "/tmp/s1"

解讀：

• port 27001：是當(dāng)前sentinel實(shí)例的端口
• sentinel monitor mymaster 192.168.150.101 7001 2：指定主節(jié)點(diǎn)信息
  • mymaster：主節(jié)點(diǎn)名稱，自定義，任意寫
  • 192.168.150.101 7001：主節(jié)點(diǎn)的ip和端口
  • 2：選舉master時(shí)的quorum值
• down-after-milliseconds mymaster：在指定的毫秒數(shù)內(nèi)，若主節(jié)點(diǎn)沒(méi)有應(yīng)答哨兵的 PING 命令，此時(shí)哨兵認(rèn)為服務(wù)器主觀下線，默認(rèn)時(shí)間為 30 秒。
• failover-timeout mymaster：在該時(shí)間內(nèi)未完成failover（故障轉(zhuǎn)移），則failover（故障轉(zhuǎn)移）失敗

然后將s1/sentinel.conf文件拷貝到s2、s3兩個(gè)目錄中（在/tmp目錄執(zhí)行下列命令）：

# 方式一：逐個(gè)拷貝 cp s1/sentinel.conf s2 cp s1/sentinel.conf s3 # 方式二：管道組合命令，一鍵拷貝 echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf

修改s2、s3兩個(gè)文件夾內(nèi)的配置文件，將端口分別修改為27002、27003：

sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf

3.3.啟動(dòng)

為了方便查看日志，我們打開(kāi)3個(gè)ssh窗口，分別啟動(dòng)3個(gè)redis實(shí)例，啟動(dòng)命令：

# 第1個(gè) redis-sentinel s1/sentinel.conf # 第2個(gè) redis-sentinel s2/sentinel.conf # 第3個(gè) redis-sentinel s3/sentinel.conf

啟動(dòng)后：

3.4.測(cè)試

嘗試讓master節(jié)點(diǎn)7001宕機(jī)，查看sentinel日志：

查看7003，可以看到已經(jīng)變?yōu)橹鞴?jié)點(diǎn)了

再啟動(dòng)7001，哨兵會(huì)讓7001成為7003的從節(jié)點(diǎn)

問(wèn)題：讓7001宕機(jī)后，哨兵沒(méi)有進(jìn)行故障轉(zhuǎn)移

解決方案

• 兩個(gè)從機(jī)的redis.conf 文件沒(méi)有配置這個(gè)

3.5.RedisTemplate

在Sentinel集群監(jiān)管下的Redis主從集群，其節(jié)點(diǎn)會(huì)因?yàn)樽詣?dòng)故障轉(zhuǎn)移而發(fā)生變化，Redis的客戶端必須感知這種變化，及時(shí)更新連接信息。Spring的RedisTemplate底層利用lettuce實(shí)現(xiàn)了節(jié)點(diǎn)的感知和自動(dòng)切換。

3.5.1.引入依賴

在項(xiàng)目的pom文件中引入依賴：

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

3.5.2.配置Redis地址

然后在配置文件application.yml中指定redis的sentinel相關(guān)信息：

spring:redis:sentinel:master: mymasternodes:- 192.168.150.101:27001- 192.168.150.101:27002- 192.168.150.101:27003

3.5.3.配置讀寫分離

在項(xiàng)目的啟動(dòng)類中，添加一個(gè)新的bean：

@Bean public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED); }

這個(gè)bean中配置的就是讀寫策略，包括四種：

• MASTER：從主節(jié)點(diǎn)讀取
• MASTER_PREFERRED：優(yōu)先從master節(jié)點(diǎn)讀取，master不可用才讀取replica
• REPLICA：從slave（replica）節(jié)點(diǎn)讀取
• REPLICA _PREFERRED：優(yōu)先從slave（replica）節(jié)點(diǎn)讀取，所有的slave都不可用才讀取master

3.5.4.測(cè)試

啟動(dòng)項(xiàng)目，瀏覽器訪問(wèn)：http://localhost:8080/get/num

查看日志

把日志清掉，刷新界面，查看結(jié)果

可以看到請(qǐng)讀求走的7003

瀏覽器發(fā)送：http://localhost:8080/set/num/111


看到寫走的7001，符合讀寫分離

四、Redis分片集群

4.1.搭建分片集群

主從和哨兵可以解決高可用、高并發(fā)讀的問(wèn)題。但是依然有兩個(gè)問(wèn)題沒(méi)有解決：

• 海量數(shù)據(jù)存儲(chǔ)問(wèn)題

• 高并發(fā)寫的問(wèn)題

使用分片集群可以解決上述問(wèn)題，如圖:

分片集群特征：

• 集群中有多個(gè)master，每個(gè)master保存不同數(shù)據(jù)

• 每個(gè)master都可以有多個(gè)slave節(jié)點(diǎn)

• master之間通過(guò)ping監(jiān)測(cè)彼此健康狀態(tài)

• 客戶端請(qǐng)求可以訪問(wèn)集群任意節(jié)點(diǎn)，最終都會(huì)被轉(zhuǎn)發(fā)到正確節(jié)點(diǎn)

4.1.1.準(zhǔn)備實(shí)例和配置

這里我們會(huì)在同一臺(tái)虛擬機(jī)中開(kāi)啟6個(gè)redis實(shí)例，模擬分片集群，信息如下：

IPPORT角色

192.168.150.101	7001	master
192.168.150.101	7002	master
192.168.150.101	7003	master
192.168.150.101	8001	slave
192.168.150.101	8002	slave
192.168.150.101	8003	slave

刪除之前的7001、7002、7003這幾個(gè)目錄，重新創(chuàng)建出7001、7002、7003、8001、8002、8003目錄：

# 進(jìn)入/tmp目錄 cd /tmp # 刪除舊的，避免配置干擾 rm -rf 7001 7002 7003 # 創(chuàng)建目錄 mkdir 7001 7002 7003 8001 8002 8003

在/tmp下準(zhǔn)備一個(gè)新的redis.conf文件，內(nèi)容如下：

port 6379 # 開(kāi)啟集群功能 cluster-enabled yes # 集群的配置文件名稱，不需要我們創(chuàng)建，由redis自己維護(hù) cluster-config-file /tmp/6379/nodes.conf # 節(jié)點(diǎn)心跳失敗的超時(shí)時(shí)間 cluster-node-timeout 5000 # 持久化文件存放目錄 dir /tmp/6379 # 綁定地址 bind 0.0.0.0 # 讓redis后臺(tái)運(yùn)行 daemonize yes # 注冊(cè)的實(shí)例ip replica-announce-ip 192.168.150.101 # 保護(hù)模式 protected-mode no # 數(shù)據(jù)庫(kù)數(shù)量 databases 1 # 日志 logfile /tmp/6379/run.log

將這個(gè)文件拷貝到每個(gè)目錄下：

# 進(jìn)入/tmp目錄 cd /tmp # 執(zhí)行拷貝 echo 7001 7002 7003 8001 8002 8003 | xargs -t -n 1 cp redis.conf

修改每個(gè)目錄下的redis.conf，將其中的6379修改為與所在目錄一致：

# 進(jìn)入/tmp目錄 cd /tmp # 修改配置文件 printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t sed -i 's/6379/{}/g' {}/redis.conf

4.1.2.啟動(dòng)

因?yàn)橐呀?jīng)配置了后臺(tái)啟動(dòng)模式，所以可以直接啟動(dòng)服務(wù)：

# 進(jìn)入/tmp目錄 cd /tmp # 一鍵啟動(dòng)所有服務(wù) printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-server {}/redis.conf

通過(guò)ps查看狀態(tài)：

ps -ef | grep redis

如果要關(guān)閉所有進(jìn)程，可以執(zhí)行命令：

ps -ef | grep redis | awk '{print $2}' | xargs kill

或者（推薦這種方式）：

printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-cli -p {} shutdown

4.1.3.創(chuàng)建集群

雖然服務(wù)啟動(dòng)了，但是目前每個(gè)服務(wù)之間都是獨(dú)立的，沒(méi)有任何關(guān)聯(lián)。

我們需要執(zhí)行命令來(lái)創(chuàng)建集群，在Redis5.0之前創(chuàng)建集群比較麻煩，5.0之后集群管理命令都集成到了redis-cli中。

1）Redis5.0之前

Redis5.0之前集群命令都是用redis安裝包下的src/redis-trib.rb來(lái)實(shí)現(xiàn)的。因?yàn)閞edis-trib.rb是有ruby語(yǔ)言編寫的所以需要安裝ruby環(huán)境。

# 安裝依賴 yum -y install zlib ruby rubygems gem install redis

然后通過(guò)命令來(lái)管理集群：

# 進(jìn)入redis的src目錄 cd /tmp/redis-6.2.4/src # 創(chuàng)建集群 ./redis-trib.rb create --replicas 1 192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 192.168.150.101:8001 192.168.150.101:8002 192.168.150.101:8003

2）Redis5.0以后

我們使用的是Redis6.2.4版本，集群管理以及集成到了redis-cli中，格式如下：

redis-cli --cluster create --cluster-replicas 1 192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 192.168.150.101:8001 192.168.150.101:8002 192.168.150.101:8003

命令說(shuō)明：

• redis-cli --cluster或者./redis-trib.rb：代表集群操作命令
• create：代表是創(chuàng)建集群
• --replicas 1或者--cluster-replicas 1 ：指定集群中每個(gè)master的副本個(gè)數(shù)為1，此時(shí)節(jié)點(diǎn)總數(shù) ÷ (replicas + 1) 得到的就是master的數(shù)量。因此節(jié)點(diǎn)列表中的前n個(gè)就是master，其它節(jié)點(diǎn)都是slave節(jié)點(diǎn)，隨機(jī)分配到不同master

運(yùn)行后的樣子：

這里輸入yes，則集群開(kāi)始創(chuàng)建：

通過(guò)命令可以查看集群狀態(tài)：

redis-cli -p 7001 cluster nodes

創(chuàng)建集群時(shí)如果出現(xiàn)以下問(wèn)題：

去安全組開(kāi)放端口，我這里用的是7001，7002，7003，8001，8002，8003，安全組不僅要開(kāi)放這6個(gè)端口，還要開(kāi)放17001,17002,17003,18001,18002,18003

原因：
每個(gè)Redis集群中的節(jié)點(diǎn)都需要打開(kāi)兩個(gè)TCP連接。一個(gè)連接用于正常的給Client提供服務(wù)，比如6379，還有一個(gè)額外的端口（通過(guò)在這個(gè)端口號(hào)上加10000）作為數(shù)據(jù)端口，比如16379。第二個(gè)端口（本例中就是16379）用于集群總線，這是一個(gè)用二進(jìn)制協(xié)議的點(diǎn)對(duì)點(diǎn)通信信道。這個(gè)集群總線（Cluster bus）用于節(jié)點(diǎn)的失敗偵測(cè)、配置更新、故障轉(zhuǎn)移授權(quán)，等等?？蛻舳藦膩?lái)都不應(yīng)該嘗試和這些集群總線端口通信，它們只應(yīng)該和正常的Redis命令端口進(jìn)行通信。注意，確保在你的防火墻中開(kāi)放著兩個(gè)端口，否則，Redis集群節(jié)點(diǎn)之間將無(wú)法通信。
命令端口和集群總線端口的偏移量總是10000

集群操作時(shí)，需要給redis-cli加上-c參數(shù)才可以：

redis-cli -c -p 7001

4.2.散列插槽

4.2.1.插槽原理

Redis會(huì)把每一個(gè)master節(jié)點(diǎn)映射到0~16383共16384個(gè)插槽（hash slot）上，查看集群信息時(shí)就能看到：

數(shù)據(jù)key不是與節(jié)點(diǎn)綁定，而是與插槽綁定。redis會(huì)根據(jù)key的有效部分計(jì)算插槽值，分兩種情況：

• key中包含"{}"，且“{}”中至少包含1個(gè)字符，“{}”中的部分是有效部分
• key中不包含“{}”，整個(gè)key都是有效部分

例如：key是num，那么就根據(jù)num計(jì)算，如果是{itcast}num，則根據(jù)itcast計(jì)算。計(jì)算方式是利用CRC16算法得到一個(gè)hash值，然后對(duì)16384取余，得到的結(jié)果就是slot值。

如圖，在7001這個(gè)節(jié)點(diǎn)執(zhí)行set a 1時(shí)，對(duì)a做hash運(yùn)算，對(duì)16384取余，得到的結(jié)果是15495，因此要存儲(chǔ)到103節(jié)點(diǎn)。

到了7003后，執(zhí)行g(shù)et num時(shí)，對(duì)num做hash運(yùn)算，對(duì)16384取余，得到的結(jié)果是2765，因此需要切換到7001節(jié)點(diǎn)

4.2.2.小結(jié)

Redis如何判斷某個(gè)key應(yīng)該在哪個(gè)實(shí)例？

• 將16384個(gè)插槽分配到不同的實(shí)例
• 根據(jù)key的有效部分計(jì)算哈希值，對(duì)16384取余
• 余數(shù)作為插槽，尋找插槽所在實(shí)例即可

如何將同一類數(shù)據(jù)固定的保存在同一個(gè)Redis實(shí)例？

• 這一類數(shù)據(jù)使用相同的有效部分，例如key都以{typeId}為前綴

4.3.集群伸縮

redis-cli --cluster提供了很多操作集群的命令，可以通過(guò)下面方式查看：

redis-cli --cluster help

4.3.1.需求分析

需求：向集群中添加一個(gè)新的master節(jié)點(diǎn)，并向其中存儲(chǔ) num = 10

• 啟動(dòng)一個(gè)新的redis實(shí)例，端口為7004
• 添加7004到之前的集群，并作為一個(gè)master節(jié)點(diǎn)
• 給7004節(jié)點(diǎn)分配插槽，使得num這個(gè)key可以存儲(chǔ)到7004實(shí)例

這里需要兩個(gè)新的功能：

• 添加一個(gè)節(jié)點(diǎn)到集群中
• 將部分插槽分配到新插槽

4.3.2.創(chuàng)建新的redis實(shí)例

創(chuàng)建一個(gè)文件夾：

mkdir 7004

拷貝配置文件：

cp redis.conf 7004

修改配置文件：

printf '%s\n' 7004 | xargs -I{} -t sed -i 's/6379/{}/g' {}/redis.conf

安全組開(kāi)啟7004和17004端口后啟動(dòng)

redis-server 7004/redis.conf

4.3.3.添加新節(jié)點(diǎn)到redis

添加節(jié)點(diǎn)的語(yǔ)法如下：

執(zhí)行命令：

redis-cli --cluster add-node 192.168.150.101:7004 192.168.150.101:7001

通過(guò)命令查看集群狀態(tài)：

redis-cli -p 7001 cluster nodes

如圖，7004加入了集群，并且默認(rèn)是一個(gè)master節(jié)點(diǎn)：

但是，可以看到7004節(jié)點(diǎn)的插槽數(shù)量為0，因此沒(méi)有任何數(shù)據(jù)可以存儲(chǔ)到7004上

4.3.4.轉(zhuǎn)移插槽

我們要將num存儲(chǔ)到7004節(jié)點(diǎn)，因此需要先看看num的插槽是多少：num的插槽為2765.

我們可以將0~3000的插槽從7001轉(zhuǎn)移到7004，命令格式如下：

具體命令如下：

建立連接：

redis-cli --cluster reshard 192.168.150.101:7001

得到下面的反饋：

2765<3000，轉(zhuǎn)移3000個(gè)就行

source1：填7001的id
這里詢問(wèn)，你的插槽是從哪里移動(dòng)過(guò)來(lái)的？

• all：代表全部，也就是三個(gè)節(jié)點(diǎn)各轉(zhuǎn)移一部分
• 具體的id：目標(biāo)節(jié)點(diǎn)的id
• done：沒(méi)有了

通過(guò)命令查看結(jié)果：

redis-cli -p 7001 cluster nodes

4.4.故障轉(zhuǎn)移

集群現(xiàn)在狀態(tài)是這樣的：

其中7001、7002、7003、7004都是master，我們計(jì)劃讓7002宕機(jī)。

4.4.1.自動(dòng)故障轉(zhuǎn)移

當(dāng)集群中有一個(gè)master宕機(jī)會(huì)發(fā)生什么呢？

直接停止一個(gè)redis實(shí)例，例如7002：
1）首先是該實(shí)例與其它實(shí)例失去連接
2）然后是疑似宕機(jī)
3）最后是確定下線，自動(dòng)提升一個(gè)slave為新的master：

4）當(dāng)7002再次啟動(dòng)，就會(huì)變?yōu)橐粋€(gè)slave節(jié)點(diǎn)了：

redis-server 7002/redis.conf

4.4.2.手動(dòng)故障轉(zhuǎn)移

利用cluster failover命令可以手動(dòng)讓集群中的某個(gè)master宕機(jī)，切換到執(zhí)行cluster failover命令的這個(gè)slave節(jié)點(diǎn)，實(shí)現(xiàn)無(wú)感知的數(shù)據(jù)遷移。其流程如下：

這種failover命令可以指定三種模式：

• 缺省：默認(rèn)的流程，如圖1~6歩
• force：省略了對(duì)offset的一致性校驗(yàn)
• takeover：直接執(zhí)行第5歩，忽略數(shù)據(jù)一致性、忽略master狀態(tài)和其它master的意見(jiàn)

案例需求：在7002這個(gè)slave節(jié)點(diǎn)執(zhí)行手動(dòng)故障轉(zhuǎn)移，重新奪回master地位

步驟如下：

1）利用redis-cli連接7002這個(gè)節(jié)點(diǎn)

2）執(zhí)行cluster failover命令

如圖：

效果：

4.5.RedisTemplate訪問(wèn)分片集群

RedisTemplate底層同樣基于lettuce實(shí)現(xiàn)了分片集群的支持，而使用的步驟與哨兵模式基本一致：

1）引入redis的starter依賴

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId> </dependency>

2）配置分片集群地址

3）配置讀寫分離

與哨兵模式相比，其中只有分片集群的配置方式略有差異，如下：

spring:redis:cluster:nodes:- 150.158.164.135:7001- 150.158.164.135:7002- 150.158.164.135:7003- 150.158.164.135:7004- 150.158.164.135:8001- 150.158.164.135:8002- 150.158.164.135:8003lettuce:pool:max-active: 20 # 連接池最大連接數(shù)（使用負(fù)值表示沒(méi)有限制）max-idle: 10 # 連接池中的最大空閑連接min-idle: 5 # 連接池中的最小空閑連接max-wait: 5000ms # 連接池最大阻塞等待時(shí)間（使用負(fù)值表示沒(méi)有限制）

在瀏覽器訪問(wèn)：http://localhost:8080/get/num

因?yàn)樯厦孀霾宀坜D(zhuǎn)移num應(yīng)該打到7004上，7004是主節(jié)點(diǎn)，沒(méi)有從節(jié)點(diǎn)，所以打到了7004上

訪問(wèn)個(gè)get/b,8001是從節(jié)點(diǎn)，讀訪問(wèn)從節(jié)點(diǎn)

set/b/qqq,應(yīng)該寫7001

總結(jié)

以上是生活随笔為你收集整理的七、redis分布式集群的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。