Java 教程 Redis

Redis 分布式缓存

介绍了Redis持久化以及主从架构、哨兵机制、分片集群

引言

本文基于黑马2022的Redis课程高级篇编写，课程地址：黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目

课程资料：https://pan.baidu.com/s/1189u6u4icQYHg_9_7ovWmA&pwd=eh11

教程中将以6.2.6版本的Redis进行演示

单机Redis的问题

单机的Redis存在如下四大问题：

  • 数据丢失问题
  • 并发能力问题
  • 存储能力问题
  • 故障恢复问题

image-20260517155529831

接下来将会解决以上四个问题

Redis持久化

RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

执行时机

RDB持久化在四种情况下会执行：

  • 执行save命令
  • 执行bgsave命令
  • Redis停机时
  • 触发RDB条件时

1）save命令

执行下面的命令，可以立即执行一次RDB：

image-20260517162257616

save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。

2）bgsave命令

下面的命令可以异步执行RDB：

image-20260517162334878

这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响，一般RDB持久化是使用这个。

3）停机时

Redis停机时会执行一次bgsave命令，实现RDB持久化。

4）触发RDB条件

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

1
2
3
4

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000

RDB的其它配置也可以在redis.conf文件中设置：

1
2
3
4
5
6
7
8

# 是否压缩，建议不开启，压缩过程也会消耗cpu性能
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./

RDB原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

  • 在写RDB文件时，当主进程执行读操作时，访问的是共享内存；
  • 在写RDB文件时，当主进程执行写操作时，操作系统会触发写时复制（COW）机制，将对应的内存页拷贝一份数据，主进程在副本上执行写操作。在子进程写完RDB之前，主进程读的是拷贝出来的这一份数据。（所以最极端的情况下内存占用会翻倍，所以一般要给Redis预留一点内存空间）

image-20260517164639380

小结

RDB方式bgsave的基本流程？

  • fork主进程得到一个子进程，共享内存空间
  • 子进程读取内存数据并写入新的RDB文件
  • 用新RDB文件替换旧的RDB文件

RDB会在什么时候执行？save 60 1000代表什么含义？

  • 默认是服务停止时
  • 代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

  • RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
  • fork子进程、压缩、写出RDB文件都比较耗时

AOF持久化

AOF原理

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

image-20260517172823850

AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

1
2
3
4

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配，有下列三种方案：

1
2
3
4
5
6

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

三种策略对比：

image-20260517173255200

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

image-20260517175413610

如图，AOF原本有三个命令，但是set num 123 和 set num 666都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：mset name jack num 666

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

1
2
3
4

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

image-20260517175554474

Redis主从

搭建主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从架构，实现读写分离。

image-20260517202827647

我将基于我的单台Ubuntu 24.04进行搭建，Redis的安装我已在我的另一篇文章Redis初识与安装中写过了，此处不再赘述。

准备实例目录和配置文件

要在同一台机器上启动多个 Redis 实例，需要为每个实例准备独立的配置目录。

先创建实例目录：

1
2

cd /tmp
mkdir 7001 7002 7003

拷贝配置文件到每个实例目录

我的目录是基于我的Redis初识与安装教程中的安装位置写的，若不是安装我的教程安装的Redis，请修改下面命令中的配置文件位置为自己的位置

1
2
3
4
5
6
7
8
9

cd /tmp

# 方式一：逐个拷贝
cp /tmp/redis-build/redis-6.2.6/redis.conf 7001/
cp /tmp/redis-build/redis-6.2.6/redis.conf 7002/
cp /tmp/redis-build/redis-6.2.6/redis.conf 7003/

# 方式二：管道组合命令一键拷贝
echo 7001 7002 7003 | xargs -t -n 1 cp /tmp/redis-build/redis-6.2.6/redis.conf

修改每个实例的端口和工作目录

使用 sed 命令批量修改每个配置文件中的端口号和持久化文件存放目录：

1
2
3
4
5

cd /tmp

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

说明：

  • -e 's/6379/7001/g' 将默认端口 6379 替换为 7001；
  • -e 's/dir .\//dir \/tmp\/7001\//g' 将数据保存目录指向 /tmp/7001/。

修改每个实例的绑定 IP 和声明 IP

由于虚拟机可能存在多个 IP 地址，需要在配置文件中明确声明实例的 IP，避免后续主从通信混乱。

批量添加 replica-announce-ip 配置：（ip替换为自己Redis所在机子的ip，不要照搬我的，后面不再赘述）

1
2
3
4
5
6
7
8
9

cd /tmp

# 在每个配置文件的头部插入 replica-announce-ip 配置，声明当前实例的 IP 地址（用于主从通信）
sed -i '1a replica-announce-ip 172.24.51.42' 7001/redis.conf
sed -i '1a replica-announce-ip 172.24.51.42' 7002/redis.conf
sed -i '1a replica-announce-ip 172.24.51.42' 7003/redis.conf

# 或者使用一条命令
printf '%s\n' 7001 7002 7003 | xargs -I{} -t sed -i '1a replica-announce-ip 172.24.51.42' {}/redis.conf

如果是部署在云服务器上或者保险起见可以再打开每个目录下的 redis.conf，添加或确认以下配置：

1
2
3
4
5

# 绑定所有网卡地址，允许外部访问
bind 0.0.0.0

# 关闭保护模式
protected-mode no

可选：设置 Redis 以守护进程方式运行

如需让 Redis 在后台运行，可在配置文件中添加：

1
2
3
4
5

cd /tmp

echo "daemonize yes" >> 7001/redis.conf
echo "daemonize yes" >> 7002/redis.conf
echo "daemonize yes" >> 7003/redis.conf

注意：如果以后台方式运行，将不会看到控制台日志输出，调试时可先不加此项。

启动 Redis 实例

分别启动三个实例

打开三个终端窗口，分别执行：

1
2
3
4
5
6
7
8

# 终端 1 - 启动 7001
redis-server /tmp/7001/redis.conf

# 终端 2 - 启动 7002
redis-server /tmp/7002/redis.conf

# 终端 3 - 启动 7003
redis-server /tmp/7003/redis.conf

如果已配置 daemonize yes，可直接在同一个终端顺序运行：

1
2
3

redis-server /tmp/7001/redis.conf
redis-server /tmp/7002/redis.conf
redis-server /tmp/7003/redis.conf

检查启动状态：

1

ps -ef | grep redis

一键停止所有实例：

1

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

配置主从关系

此时三个实例相互独立。需要通过 REPLICAOF（Redis 5.0 之后）或 SLAVEOF（Redis 5.0 之前）命令建立主从关系。

4.2 永久配置

直接在配置文件中添加主节点信息，Redis重启后依然生效。

在 7002/redis.conf 和 7003/redis.conf 中添加配置信息：

1
2

echo "replicaof 172.24.51.42 7001" >> /tmp/7002/redis.conf
echo "replicaof 172.24.51.42 7001" >> /tmp/7003/redis.conf

然后重启 7002 和 7003 实例即可自动建立主从关系。

还可以临时配置，但此处不做说明

验证主从状态

重新启动三个节点后，连接主节点 7001 查看集群状态：

1
2

redis-cli -p 7001
INFO replication

输出示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

root@iZuf65rn445tqski3inolpZ:~# redis-cli -p 7001
127.0.0.1:7001> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.24.51.42,port=7002,state=online,offset=28,lag=1
slave1:ip=172.24.51.42,port=7003,state=online,offset=28,lag=1
master_failover_state:no-failover
master_replid:1ed5d0889313b1f0f22b7011b5543a1478c244bf
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:28
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28

connected_slaves:2 表示两个从节点已成功连接，state=online 表示状态正常。

功能测试

测试主节点写操作 

1
2
3

redis-cli -p 7001
set num 123
# 返回 OK

测试从节点读操作 

1
2
3

redis-cli -p 7002
get num
# 返回 "123"

1
2
3

redis-cli -p 7003
get num
# 返回 "123"

验证从节点只读特性

尝试在从节点执行写操作：

1
2
3

redis-cli -p 7002
set num 666
# 返回 (error) READONLY You can't write against a read only replica.

从节点默认只读，无法写入数据，符合主从架构的设计。

image-20260517215913052

配置主从节点密码

要给 Redis 主从架构加上密码认证，需要修改两个关键配置项：

配置项 作用 配置位置
requirepass 客户端连接后需执行 AUTH <密码> 才能操作 所有节点（master + slave）
masterauth 从节点自动用此密码向主节点认证 所有节点（主从都配，防止主从切换后失效）

需要修改配置文件，在所有三个节点的 redis.conf 末尾追加密码与从节点认证：

1
2
3
4
5
6
7
8
9

# 统一设置密码，三个节点使用相同的密码
echo "requirepass redis123" >> /tmp/7001/redis.conf
echo "masterauth redis123" >> /tmp/7001/redis.conf

echo "requirepass redis123" >> /tmp/7002/redis.conf
echo "masterauth redis123" >> /tmp/7002/redis.conf

echo "requirepass redis123" >> /tmp/7003/redis.conf
echo "masterauth redis123" >> /tmp/7003/redis.conf

redis重启后会自动建立主从，无需手动执行。

现在连接redis客户端就需要密码了

1
2
3
4
5
6

# 方式一：命令行指定密码
redis-cli -p 7001 -a redis123

# 方式二：连接后再认证
redis-cli -p 7001
AUTH redis123

主从数据同步原理

全量同步

主从第一次建立连接时，会执行全量同步（Full Sync），将master节点的所有数据都拷贝给slave节点，流程如图：

image-20260517221329995

master如何得知salve是第一次来连接呢？

有几个概念，可以作为判断依据：

  • Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
  • offset：偏移量，随着 Master 处理写命令、产生新的数据流而不断增大。Slave 也会实时记录自己当前已经处理到的 offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id和offset，master才可以判断到底需要同步哪些数据。

因为 Slave 在本地会保存之前同步过的 Master 的 replid 和 offset，当第一次变成slave，与master建立连接时，发送的replid和offset是它本地保存的这些历史信息（如果是首次启动则为空）。

上面这句话有点抽象（对我来说），下面是通俗易懂的解释：

这句话的核心是在解释：Slave（从节点）在跟 Master（主节点）“握手”时，手里到底拿着什么信息去汇报。

我们可以把 Slave 想象成一个新入职的员工，把 Master 想象成老板。

  1. “Slave 在本地会保存之前同步过的 Master 的 replid 和 offset”
    • 大白话：员工（Slave）有个小本本（本地内存/配置文件），上面专门记录他上一份工作的老板是谁（replid），以及他上次工作干到了第几页（offset）。
    • 技术含义：只要 Slave 之前跟某个 Master 同步过数据，它就会在内存里记下那个 Master 的专属 ID 和最后同步到的数据进度。
  2. “当第一次变成slave，与master建立连接时”
    • 大白话：现在，这个员工去了一家新公司，第一次见到新老板（Master），准备开始汇报工作并建立上下级关系。
  3. “发送的replid和offset是它本地保存的这些历史信息（如果是首次启动则为空）”
    • 大白话：员工见到新老板，第一件事就是掏出小本本汇报：“老板，我上一个老板叫张三（replid），我走的时候工作干到了第100页（offset）。”
    • 括号里的“如果是首次启动则为空”：如果这个员工是刚毕业的应届生，从来没有打过工（Slave 是第一次启动，从来没跟任何 Master 同步过），那他的小本本就是空白的。他会跟新老板说：“老板，我没跟过别人，小本本是空的（replid 为空或无效）。”

这句话想表达的重点是：

无论 Slave 的小本本是“空白的”（首次启动），还是写着“别人的名字”（之前跟过别的 Master），只要他汇报的 replid 和新老板（当前 Master）自己的 replid 对不上号，新老板就会判定：“这人没跟过我，我不认识他，得把公司所有资料重新给他发一份（触发全量同步）。”

master判断发现slave发送来的replid与自己的不一致，说明 Slave 缺少当前 Master 的数据上下文，就知道要做全量同步了。master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

image-20260518150919001

完整流程描述：

  • slave节点请求增量同步
  • master节点判断replid，发现不一致，拒绝增量同步
  • master在后台生成RDB快照数据，发送给slave
  • slave清空本地数据，加载master的RDB
  • master将RDB生成期间的命令记录在repl_backlog，并持续将log中的命令发送给slave
  • slave执行接收到的命令，保持与master之间的同步

增量同步(部分同步)

全量同步需要先做RDB，然后将RDB文件通过网络传输个slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步（PSYNC，又称部分同步）。

*什么是增量同步？*就是只更新slave与master存在差异的部分数据。如图：

image-20260518223710794

master怎么知道slave与自己的数据差异在哪里呢?

这就要说到增量同步时的repl_backlog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_backlog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

image-20260518224033793

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

image-20260518224834559

直到数组被填满：

image-20260518224347644

此时，如果有新的数据写入，master就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

image-20260518224437568

如果此时master继续写入新数据，其offset就会继续覆盖旧的数据，直到将slave现在的offset也覆盖：

image-20260518224537155

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

所以需要注意：repl_backlog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。

主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从架构：

  • 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时在master本地磁盘生成RDB文件的IO开销
  • Redis单节点上的内存占用不要太大，减少RDB生成与传输的时间及开销
  • 适当提高repl_backlog的大小，发现slave宕机时尽快实现故障恢复，增加slave断线重连后能进行增量同步的机会，尽可能避免全量同步
  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

主从从架构图：

image-20260518230053131

Redis哨兵

Redis提供了**哨兵（Sentinel）**机制来实现主从架构的自动故障恢复。

哨兵的作用与原理

集群结构和作用

哨兵的结构如图：

image-20260518232709329

哨兵的作用如下：

  • 监控：Sentinel 会不断检查你的master和slave是否按预期工作
  • 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
  • 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

  • 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

  • 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则认为该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

image-20260518233228738

集群故障恢复原理

一旦发现master故障，sentinel需要在slave中选择一个作为新的master，选择依据是这样的：

  • 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
  • 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
  • 如果slave-priority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
  • 最后是判断slave节点的运行id大小，越小优先级越高。

当选出一个新的master后，该如何实现切换呢？

流程如下：

  • sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
  • sentinel给所有其它slave发送slaveof 172.24.51.42 7002命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
  • 最后，sentinel会修改故障节点的配置，当故障节点恢复后，会作为新的master的slave节点加入集群

image-20260518233810094

搭建哨兵集群

集群结构

接下来搭建一个三节点形成的Sentinel集群，来监管之前的Redis主从架构。如图：

image-20260519164015661

三个 sentinel 实例信息如下：

节点 IP PORT
s1 172.24.51.42 27001
s2 172.24.51.42 27002
s3 172.24.51.42 27003

准备实例和配置

在同一台虚拟机上开启三个 sentinel 实例，需要准备三份不同的配置文件及目录。

  • 创建目录
1
2

cd /tmp
mkdir s1 s2 s3
  • 创建 Sentinel 配置文件

在 s1 目录下创建 sentinel.conf 文件，内容如下：

1
2
3
4
5
6

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

配置说明：

  • port 27001：当前 sentinel 实例的端口
  • sentinel announce-ip 172.24.51.42：sentinel 实例对外声明的 IP 地址
  • sentinel monitor mymaster 172.24.51.42 7001 2：
    • mymaster：主节点名称，可自定义
    • 172.24.51.42 7001：主节点的 IP 和端口
    • 2：选举 master 时的 quorum 值（即至少 2 个 sentinel 同意才进行故障转移）
  • sentinel down-after-milliseconds mymaster 5000：主观下线判定时间（5 秒）
  • sentinel failover-timeout mymaster 60000：故障转移超时时间（60 秒）
  • 将s1/sentinel.conf文件拷贝到s2、s3两个目录中（在/tmp目录执行下列命令）：
1
2
3
4
5

# 方式一：逐个拷贝
cp s1/sentinel.conf s2
cp s1/sentinel.conf s3
# 方式二：管道组合命令，一键拷贝
echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf
  • 修改s2、s3两个文件夹内的配置文件，将端口分别修改为27002、27003：
1
2

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

启动哨兵集群

打开三个终端窗口（或使用 tmux），分别启动三个 sentinel 实例：

1
2
3
4
5
6
7
8

# 终端 1：启动 s1
redis-sentinel /tmp/s1/sentinel.conf

# 终端 2：启动 s2
redis-sentinel /tmp/s2/sentinel.conf

# 终端 3：启动 s3
redis-sentinel /tmp/s3/sentinel.conf

提示：若希望后台运行，可在配置文件中添加 daemonize yes，或用 nohup / systemd 管理。

启动后可以看到类似如下的日志输出：

1
2
3

* Running mode=sentinel, port=27001.
* Sentinel new configuration saved on disk
* +monitor master mymaster 172.24.51.42 7001 quorum 2

image-20260519204652388

验证哨兵状态

连接任意一个 sentinel 实例查看状态：

1

redis-cli -p 27001

在 redis-cli 中执行：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 查看哨兵信息
SENTINEL masters

# 查看指定主节点信息
SENTINEL master mymaster

# 查看从节点信息
SENTINEL slaves mymaster

# 查看哨兵节点信息
SENTINEL sentinels mymaster

正常输出应显示主节点在线，从节点已识别，以及所有 sentinel 实例的信息。

故障转移测试

  • 模拟主节点宕机

使用 redis-cli 连接到主节点 7001 并手动关闭：

1

redis-cli -p 7001 DEBUG SLEEP 30

或者直接使用 shutdown 命令：

1

redis-cli -p 7001 shutdown
  • 观察哨兵日志

查看 sentinel 日志，可以看到类似以下流程：

  1. +sdown master mymaster 172.24.51.42 7001 — 主观下线
  2. +odown master mymaster 172.24.51.42 7001 #quorum 2/2 — 客观下线
  3. +new-epoch 1 — 开始新的选举纪元
  4. +try-failover master mymaster 172.24.51.42 7001 — 尝试故障转移
  5. +vote-for-leader — 选举哨兵领导者
  6. +switch-master mymaster 172.24.51.42 7001 172.24.51.42 7002 — 切换主节点

RedisTemplate集成哨兵机制

在Sentinel集群监管下的Redis主从架构，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。

下面介绍如何在Spring项目中实现RedisTemplate集成哨兵机制。

引入依赖

在项目的pom文件中引入依赖：

1
2
3
4

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

配置Redis地址

然后在配置文件application.yml中指定redis的sentinel相关信息：

1
2
3
4
5
6
7
8

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

配置读写分离

在项目的启动类中或配置类，添加一个新的bean：

1
2
3
4

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

这个bean中配置的就是读写策略，包括四种：

  • MASTER：从主节点读取
  • MASTER_PREFERRED：优先从master节点读取，master不可用才读取replica
  • REPLICA：从slave（replica）节点读取
  • REPLICA_PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master

Redis分片集群

分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

  • 海量数据存储问题

  • 高并发写的问题

使用分片集群可以解决上述问题，如图：

image-20260519203419508

分片集群特征：

  • 集群中有多个master，每个master保存不同数据

  • 每个master都可以有多个slave节点

  • master之间通过ping监测彼此健康状态

  • 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

搭建分片集群

集群结构

分片集群需要的节点数量较多，下面就搭建一个最小的分片集群，包含3个master节点，每个master包含一个slave节点，结构如下：

image-20260519204325277

接下来将会在同一台虚拟机中开启6个redis实例，模拟分片集群，信息如下：

IP PORT 角色
172.24.51.42 7001 master
172.24.51.42 7002 master
172.24.51.42 7003 master
172.24.51.42 8001 slave
172.24.51.42 8002 slave
172.24.51.42 8003 slave

准备实例和配置

删除之前的7001、7002、7003这几个目录（先关闭redis集群），重新创建出7001、7002、7003、8001、8002、8003目录：

1
2
3
4
5
6

# 进入/tmp目录
cd /tmp
# 删除旧的，避免配置干扰
rm -rf 7001 7002 7003
# 创建目录
mkdir 7001 7002 7003 8001 8002 8003

在/tmp下准备一个新的redis.conf文件，内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

port 6379
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称，不需要我们创建，由redis自己维护
cluster-config-file /tmp/6379/nodes.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir /tmp/6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
replica-announce-ip 172.24.51.42
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log

将这个文件拷贝到每个目录下：

1
2
3
4

# 进入/tmp目录
cd /tmp
# 执行拷贝
echo 7001 7002 7003 8001 8002 8003 | xargs -t -n 1 cp redis.conf

修改每个目录下的redis.conf，将其中的6379修改为与所在目录一致：

1
2
3
4

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

启动

因为已经配置了后台启动模式，所以可以直接启动服务：

1
2
3
4

# 进入/tmp目录
cd /tmp
# 一键启动所有服务
printf '%s\n' 7001 7002 7003 8001 8002 8003 | xargs -I{} -t redis-server {}/redis.conf

通过ps查看状态：

1

ps -ef | grep redis

发现服务都已经正常启动：

image-20260519205218053

如果要关闭所有进程，可以执行命令：

1

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

或者（推荐这种方式）：

1

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

创建集群

虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。

我们需要执行命令来创建集群，在Redis5.0之前创建集群比较麻烦，5.0之后集群管理命令都集成到了redis-cli中就简单了。

1）Redis5.0之前

Redis5.0之前集群命令都是用redis安装包下的src/redis-trib.rb来实现的。因为redis-trib.rb是有ruby语言编写的所以需要安装ruby环境。

1
2
3
4
5
6
7

# 更新软件源（推荐先执行，确保获取最新的软件包信息）
sudo apt update

# 使用 apt 安装 zlib、ruby 和 rubygems
sudo apt install -y zlib1g ruby rubygems

gem install redis

然后通过命令来管理集群：

1
2
3
4

# 进入redis的src目录
cd /tmp/redis-build/redis-6.2.6/src
# 创建集群
./redis-trib.rb create --replicas 1 172.24.51.42:7001 172.24.51.42:7002 172.24.51.42:7003 172.24.51.42:8001 172.24.51.42:8002 172.24.51.42:8003

2）Redis5.0以后

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

1

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

命令说明：

  • redis-cli --cluster或者./redis-trib.rb：代表集群操作命令
  • create：代表是创建集群
  • --replicas 1或者--cluster-replicas 1：指定集群中每个master的副本个数为1，此时节点总数 ÷ (replicas + 1) 得到的就是master的数量。这里replicas传的是1，因此节点列表中的前6 ÷ (1 + 1) = 3个就是master，其它节点都是slave节点，自动分配到不同master

运行后的样子：

image-20260519210942422

通过下面的命令可以查看集群状态：

1

redis-cli -p 7001 cluster nodes

image-20260519211105184

散列插槽

插槽原理

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：

image-20260519212004764

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

  • key中包含"{}"，且“{}”中至少包含1个字符时，“{}”中的部分是有效部分
  • key中不包含“{}”，整个key都是有效部分

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

测试

尝试连接7001节点，存储一个数据：

1
2
3
4
5
6
7
8

# 连接
redis-cli -p 7001
# 存储数据
set num 123
# 读取数据
get num
# 再次存储
set a 1

运行结果如下：

image-20260519212501475

发现“a”这个key存不了，因为计算后得到的slot值是15495，而7001这个节点存的是0-5460

所以在分片集群模式下不能直接用redis-cli -p 7001连接，而是要用redis-cli -c -p 7001连接

image-20260519212806407

此时就能正常存取了，-c 代表开启集群模式（Cluster mode），此时存取key时会自动重定向到对应插槽所在的节点

集群伸缩

redis-cli –cluster提供了很多操作集群的命令，可以通过redis-cli --cluster help查看，其中就有添加节点的命令：

image-20260519213924055

下面就用案例演示节点扩容功能

需求分析

需求：向集群中添加一个新的master节点，并向其中存储 num = 10

  • 启动一个新的redis实例，端口为7004
  • 添加7004到之前的集群，并作为一个master节点
  • 给7004节点分配插槽，使得num这个key可以存储到7004实例

这里需要两个新的功能：

  • 添加一个节点到集群中
  • 将部分插槽分配到新插槽

创建新的redis实例

步骤如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

cd /tmp

# 创建一个文件夹
mkdir 7004

# 拷贝配置文件
cp redis.conf ./7004

# 修改配置文件
sed -i s/6379/7004/g 7004/redis.conf

# 启动
redis-server 7004/redis.conf

# 查看redis启动情况
ps -ef | grep redis

添加新节点到redis

添加节点的语法如下：

image-20260519214801775

将7004节点添加到集群中：

1

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

通过命令查看集群状态：

1

redis-cli -p 7001 cluster nodes

如图，7004加入了集群，并且默认是一个master节点，但7004节点的插槽数量为0，因此没有任何数据可以存储到7004上：

image-20260519215107958

转移插槽

要将num存储到7004节点，因此需要先看看num的插槽是多少：

image-20260519215717875

如上图所示，num的插槽为2765

所以可以将0~3000的插槽从7001转移到7004，命令格式如下：

image-20260519215748511

具体操作：

指定集群中任意一个端口进行重新分片：

1

redis-cli --cluster reshard 172.24.51.42:7001

然后会询问你希望移动多少插槽：

image-20260519220157344

这里输入3000个，然后回车，又会询问要用哪个节点接收这些插槽，此处选择7004节点接收，填入7004节点的id：

image-20260519220353142

然后会询问你的插槽要从哪里移动过来

image-20260519220635552

  • all：代表全部，也就是三个节点各转移一部分
  • 具体的id：目标节点的id
  • done：没有了

此处选择转移7001的插槽，所以填入7001的id，回车后再输入done，然后再回车

image-20260519220809122

输入yes确认转移插槽即可

检查是否转移成功：

1

redis-cli -p 7001 cluster nodes

image-20260519221107968

确认转移成功

image-20260519221203264

需求完成

故障转移

自动故障转移

当集群中有一个master宕机会发生什么呢？

当前集群情况：

image-20260519221949627

手动停止7002节点：redis-cli -p 7002 shutdown

再次查看集群情况：

image-20260519221955927

一开始是疑似宕机，过一会就是确认宕机，自动提升一个slave为新的master：

image-20260519222038929

当7002再次启动，就会变为一个slave节点了：

image-20260519222051417

手动故障转移

利用 cluster failover 命令可以在从节点上手动触发故障转移，将执行该命令的 slave 节点提升为新的 master 节点，实现平滑的主从切换，可以以此实现服务升级。其流程如下：

image-20260519222150978

这种failover命令可以指定三种模式：

  • 不传参：默认的流程，如图1~6歩
  • force：省略了对offset的一致性校验
  • takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见

案例需求：在7002这个slave节点执行手动故障转移，重新夺回master地位

步骤如下：

1）利用redis-cli连接7002这个节点

2）执行cluster failover命令

如图：

image-20260519222745728

结果：

image-20260519222754283

RedisTemplate访问分片集群

RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：

1）引入redis的starter依赖

2）配置分片集群地址

3）配置读写分离

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

spring:
  redis:
    cluster:
      nodes:
        - 172.24.51.42:7001
        - 172.24.51.42:7002
        - 172.24.51.42:7003
        - 172.24.51.42:8001
        - 172.24.51.42:8002
        - 172.24.51.42:8003
© 2025 - 2026 缘鱼
本站于2025年3月26日建立
使用 Hugo 构建
主题 Stack 由 Jimmy 设计