分布式緩存

– 基于Redis集群解決單機(jī)Redis存在的問題

1.Redis持久化

Redis有兩種持久化方案：

• RDB持久化
• AOF持久化

1.1.RDB持久化

RDB全稱Redis Database Backup file（Redis數(shù)據(jù)備份文件），也被叫做Redis數(shù)據(jù)快照。簡單來說就是把內(nèi)存中的所有數(shù)據(jù)都記錄到磁盤中。當(dāng)Redis實(shí)例故障重啟后，從磁盤讀取快照文件，恢復(fù)數(shù)據(jù)?？煺瘴募Q為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è)過程中其它所有命令都會(huì)被阻塞。只有在數(shù)據(jù)遷移時(shí)可能用到。

2）bgsave命令

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

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

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è)置：

```properties
# 是否壓縮 ,建議不開啟，壓縮也會(huì)消耗cpu，磁盤的話不值錢
rdbcompression yes

# RDB文件名稱
dbfilename dump.rdb  

# 文件保存的路徑目錄
dir ./ 

1.1.2.RDB原理

bgsave開始時(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í)，訪問共享內(nèi)存；
• 當(dāng)主進(jìn)程執(zhí)行寫操作時(shí)，則會(huì)拷貝一份數(shù)據(jù)，執(zhí)行寫操作。

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執(zhí)行間隔時(shí)間長，兩次RDB之間寫入數(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配置文件來開啟AOF：

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

AOF的命令記錄的頻率也可以通過redis.conf文件來配：

# 表示每執(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

1.2.3.AOF文件重寫

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-yl5nc05w-1681919435409)(assets/image-20210725151729118.png)]

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

所以重寫命令后，AOF文件內(nèi)容就是：mset name jack num 666

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

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

1.3.RDB與AOF對比

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

2.Redis主從

2.1.搭建主從架構(gòu)

單節(jié)點(diǎn)Redis的并發(fā)能力是有上限的，要進(jìn)一步提高Redis的并發(fā)能力，就需要搭建主從集群，實(shí)現(xiàn)讀寫分離。

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

2.2.1.全量同步

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

• Replication Id：簡稱replid，是數(shù)據(jù)集的標(biāo)記，id一致則說明是同一數(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，說明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ā)送來的replid與自己的不一致，說明這是一個(gè)全新的slave，就知道要做全量同步了。

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

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

完整流程描述：

• slave節(jié)點(diǎn)請求增量同步
• 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.2.2.增量同步

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

2.2.3.repl_backlog原理

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

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

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

repl_baklog中會(huì)記錄Redis處理過的命令日志及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ù)。不過，舊的數(shù)據(jù)只要是綠色的，說明是已經(jīng)被同步到slave的數(shù)據(jù)，即便被覆蓋了也沒什么影響。因?yàn)槲赐降膬H僅是紅色部分。

但是，如果slave出現(xiàn)網(wǎng)絡(luò)阻塞，導(dǎo)致master的offset遠(yuǎn)遠(yuǎn)超過了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都沒有了，無法完成增量同步了。只能做全量同步。

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

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

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

• 在master中配置repl-diskless-sync yes啟用無磁盤復(fù)制，避免全量同步時(shí)的磁盤IO。
• Redis單節(jié)點(diǎn)上的內(nèi)存占用不要太大，減少RDB導(dǎo)致的過多磁盤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壓力

2.4.小結(jié)

全量同步和增量同步區(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)斷開時(shí)間太久，repl_baklog中的offset已經(jīng)被覆蓋時(shí)

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

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

3.Redis哨兵

Redis提供了哨兵（Sentinel）機(jī)制來實(shí)現(xiàn)主從集群的自動(dòng)故障恢復(fù)。

3.1.哨兵原理

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

哨兵的結(jié)構(gòu)如圖：

哨兵的作用如下：

• 監(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)來源，當(dāng)集群發(fā)生故障轉(zhuǎn)移時(shí)，會(huì)將最新信息推送給Redis的客戶端

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

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

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

?客觀下線：若超過指定數(shù)量（quorum）的sentinel都認(rèn)為該實(shí)例主觀下線，則該實(shí)例客觀下線。quorum值最好超過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)斷開時(shí)間長短，如果超過指定值（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值，越大說明數(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)，開始從新的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命令，如果超過一定時(shí)間沒有相向則認(rèn)為是主觀下線

• 如果大多數(shù)sentinel都認(rèn)為實(shí)例主觀下線，則判定服務(wù)下線

• 首先選定一個(gè)slave作為新的master，執(zhí)行slaveof no one

• 然后讓所有節(jié)點(diǎn)都執(zhí)行slaveof 新master

• 修改故障節(jié)點(diǎn)配置，添加slaveof 新master

3.2.搭建哨兵集群

百度…

3.3.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.3.2.引入依賴

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

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

3.3.3.配置Redis地址

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

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

3.3.4.配置讀寫分離

在項(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

4.Redis分片集群

4.1.搭建分片集群

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

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

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

分片集群特征：

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

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

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

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

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ì)算，如果是{test}num，則根據(jù)test計(jì)算。計(jì)算方式是利用CRC16算法得到一個(gè)hash值，然后對16384取余，得到的結(jié)果就是slot值。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-HnNzikh6-1681919435434)(assets/image-20210725155850200.png)]

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

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

4.2.1.小結(jié)

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

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

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

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

4.3.集群伸縮

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

比如，添加節(jié)點(diǎn)的命令

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

修改配置文件：

sed /s/6379/7004/g 7004/redis.conf

啟動(dòng)

redis-server 7004/redis.conf

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

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

執(zhí)行命令：

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

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

redis-cli -p 7001 cluster nodes

4.3.4.轉(zhuǎn)移插槽

百度

4.4.故障轉(zhuǎn)移

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

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

直接停止一個(gè)redis實(shí)例，例如7002：

redis-cli -p 7002 shutdown

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)了：

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)無感知的數(shù)據(jù)遷移。

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

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

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

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

4.5.RedisTemplate訪問分片集群

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

1）引入redis的starter依賴

2）配置分片集群地址

3）配置讀寫分離

與哨兵模式相比，其中只有分片集群的配置方式略有差異，如下：文章來源地址http://www.zghlxwxcb.cn/news/detail-424230.html

spring:
  redis:
    cluster:
      nodes:
        - 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

，切換到執(zhí)行cluster failover命令的這個(gè)slave節(jié)點(diǎn)，實(shí)現(xiàn)無感知的數(shù)據(jù)遷移。其流程如下：

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

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

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

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

4.5.RedisTemplate訪問分片集群

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

1）引入redis的starter依賴

2）配置分片集群地址

3）配置讀寫分離

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

spring:
  redis:
    cluster:
      nodes:
        - 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

到了這里，關(guān)于分布式緩存的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！