Linux系统下分布式缓存Redis持久化、搭建Redis主从集群和原理讲解，配置Redis哨兵；搭建Redis分片集群，对散列插槽、集群伸缩、故障转移详解配置RedisTemplate访问分片集群

丘丘fighting

于 2024-10-10 19:36:38 发布

阅读量559

点赞数 4

文章标签：缓存分布式 redis java

本文链接：https://blog.csdn.net/weixin_64339548/article/details/142819256

版权

一、实现redis数据持久化

1.1通过RDB实现Redis数据持久化

1.1.1通过save指令实现数据持久化

1.1.2通过bgsave指令实现数据持久化

1.2通过AOF实现Redis数据持久化

1.3RDB和AOF模式详细对比

二、搭建Redis主从集群，实现读写分离，搭建哨兵集群，监听Redis主从集群实现自动故障恢复（故障转移）

2.1启动所有redis服务，开启主从关系

2.5整合Maven项目和哨兵集群，搭建RedisTemplate的哨兵模式

2.5.1在pom文件中引入redis的starter依赖

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

3.2.1准备分片集群的redis.conf文件，内容如下：

四、搭建配置RedisTemplate访问分片集群

前言：

重要：redis服务集群和哨兵集群都是部署在Linux中，如果需要通过windows等外部设备进行访问需要关闭Linux系统的防火墙，或者开放指定端口

搭建分布式Redis之前我们先了解以下单节点的Redis存在的问题，了解为什么需要Redis集群及其作用

单节点redis的不足：

数据丢失问题：Redis是内存存储，服务重启可能会丢失数据
并发能力问题：单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景
故障恢复问题：如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段
存储能力问题：Redis基于内存，单节点能存储的数据量难以满足海量数据需求

以上就是单节点redis存在的缺陷，那么搭建redis集群又是怎么解决这些问题呢？

数据丢失问题：这个问题其实在单节点上也能解决，就是通过redsi数据持久化
并发能力问题：可以通过搭建主从集群，实现读写分离
故障恢复问题：利用redis哨兵机制，实现健康检测和自定恢复
存储能力问题：搭建分片集群，利用插槽机制实现动态扩容

一、实现redis数据持久化

前言：

Redis持久化有两种模式：

RDB持久化：RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。（快照文件称为RDB文件，默认是保存在当前运行目录。）
AOF持久化：AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

1.1通过RDB实现Redis数据持久化

前言：

通过RDB实现数据持久化有两种指令一个是"save"另一个是"bgsave"

两者的不同：

"save"指令是通过主进程实现数据持久化，此时在进行数据持久化的过程中一切其他的指令将会被拦截，知道数据持久化过程结束
"bgsave"指令是fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件，此时不会阻塞主进程，主进程依旧能够接收其他指令

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

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

注意：

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

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

如果需要开启自动bgsave，则将前面的注释去掉，并按照上面例子的格式进行修改如下图表示，表示每五秒内有一个key被修改就进行bgsave指令

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

# 是否压缩 ,建议不开启，压缩也会消耗cpu

rdbcompression yes

# RDB文件名称

dbfilename dump.rdb

# 文件保存的路径目录

dir ./

1.1.1通过save指令实现数据持久化

启动redis服务后，通过redis-cli进行连接，输入save，手动进行数据保存
save
可以通过重启redis服务进行查看数据是否存在

关闭服务命令
shutdown
通过get命令重新获取到数据，说明我们已经实现了数据的持久化

1.1.2通过bgsave指令实现数据持久化

bgsave

1.2通过AOF实现Redis数据持久化

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

# 是否开启AOF功能，默认是no

appendonly yes

# AOF文件的名称

appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配（注意：选择其中一个就好）：

# 表示每执行一次写命令，立即记录到AOF文件

appendfsync always

# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案

appendfsync everysec

# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

appendfsync no

三种机制的详细对比：

配置项

刷盘时机

优点

缺点

Always

同步刷盘

可靠性高，几乎不丢数据

性能影响大

everysec

每秒刷盘

性能适中

最多丢失1秒数据

no

操作系统控制

性能最好

可靠性较差，可能丢失大量数据

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

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

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

1.3RDB和AOF模式详细对比

RDB

AOF

持久化方式

定时对整个内存做快照

记录每一次执行的命令

数据完整性

不完整，两次备份之间会丢失

相对完整，取决于刷盘策略

文件大小

会有压缩，文件体积小

记录命令，文件体积很大

宕机恢复速度

很快

慢

数据恢复优先级

低，因为数据完整性不如AOF

高，因为数据完整性更高

系统资源占用

高，大量CPU和内存消耗

低，主要是磁盘IO资源

但AOF重写时会占用大量CPU和内存资源

使用场景

可以容忍数分钟的数据丢失，追求更快的启动速度

对数据安全性要求较高常见

二、搭建Redis主从集群，实现读写分离，搭建哨兵集群，监听Redis主从集群实现自动故障恢复（故障转移）

前言：

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。主节点进行数据写，从节点进行数据读，因为在实际应用中，读的操作会大于写，所以写节点只有一个且为主节点进行数据同步到从节点，而读节点为多个，应对高并发

这了小编因为设备受限则是在一台虚拟机开启3个实例，准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

每个目录下包含一份redis.conf文件，配置文件的母版就是初始的配置文件，将其中的port改为7001、7002、7003分别放在不同目录下，同时修改了rdb的保存目录

修改redis.conf文件更改端口号

修改rdb文件名称

修改rdb存放路径

7001子目录，新创建不会产生test.rdb

注意：在进行配置redis集群的配置文件时，需要将集群内的持久化模式改为默认的RDB模式，AOF保持关闭状态（因为）

修改每个实例的声明IP

虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息（绑定自己虚拟机的本地IP地址），格式如下：

# redis实例的声明 IP
replica-announce-ip 192.168.8.128

2.1启动所有redis服务，开启主从关系

这里小编共有三个redis服务全部启动，IP相同，端口不同，现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：
修改配置文件（永久生效）

在redis.conf中添加一行配置：slaveof <masterip> <masterport>
使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：
slaveof <masterip> <masterport>
注意：在5.0以后新增命令replicaof，与salveof效果一致。

通过redis-cli命令连接7001是其作为7003的从节点，执行下面命令：
# 连接 7001
redis-cli -p 7001
# 执行slaveof
slaveof 192.168.8.128 7003
注意：这里我的主节点的ip和端口分别是192.168.8.128和7003大家在配置集群时，应注意自己的主节点的IP地址和端口号

通过redis-cli命令连接7002使其作为7003的从节点，执行下面命令：
# 连接 7002
redis-cli -p 7002
# 执行slaveof
slaveof 192.168.8.128 7003
观测7003redis的服务端窗口数据，表示配置成功

或者通过7003查看集群状态

# 连接 7003
redis-cli -p 7003
# 查看状态
info replication

此时，只能通过主节点也就是我的7003的redis服务进行写操作，而从节点只能进行读操作

这样我们接完成了redis集群的读写分离操作

2.2redis主从集群数据同步原理

当从节点与主节点建立连接后，会向主节点发送请求数据同步的请求并且会带上自己的Replication Id和offset，主节点会根据从节点携带来的是数据进行判断从节点是否需要进行全量同步还是增量同步

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

全量同步的流程：

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

增量同步的流程：

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

2.3哨兵集群的工作原理

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

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

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

主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

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

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

当选中了其中一个slave为新的master后（例如 7002），故障的转移的步骤如下：

sentinel给备选的7002节点发送slaveof no one命令，让该节点成为master

sentinel给所有其它slave发送slaveof 192.168.8.128 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。

最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

2.4搭建哨兵集群

前言：

这里小编和前面搭建redis服务集群相似，同一台虚拟机开放三个端口作为哨兵集群，并创建三个文件夹分别放入各自的配置文件

2.4.1配置集群文件，并启动哨兵集群

首先创建sentinel.conf文件，添加下面内容
port 27001
sentinel announce-ip 192.168.8.128
sentinel monitor mymaster 192.168.8.128 7003 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/res/sentinel-cluster/s1"
解读：

port 27001：是当前sentinel实例的端口

sentinel monitor mymaster 192.168.8.128 7001 2：指定主节点信息

mymaster：主节点名称，自定义，任意写

192.168.8.128 7003：主节点的ip和端口

2：选举master时的quorum值

dir "/res/sentinel-cluster/s1" ：指定工作目录

然后小编这里将这份作为模板，并修改其中的端口号再进行粘贴到我创建的三个文件中，然后通过redis-sentinel指令加载不同文件夹下的配置文件，启动三个不同实例，如

启动后，随便观测一个sentinel服务的后台窗口，结果显示如下，就代表配置成功

这里可以将自己主节点进行宕机查看sentinel集群的窗口数据进行观测到，哨兵集群将会选举新的master节点作为主节点

2.5整合Maven项目和哨兵集群，搭建RedisTemplate的哨兵模式

2.5.1在pom文件中引入redis的starter依赖

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

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

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

注意：这里只需要指定sentinel节点的位置不需要指定redis集群的地址，哨兵集群会自动帮我们将对redis的操作请求发送到他们所监视的redis集群服务中，同时，master后面的名称必须与前面你自定义的主节点名称相同

2.5.3配置主从读写分离

定义一个配置类并配置一个bean交给springboot容器作为管理(这里代码通过Lambda表达式进行了简写)

package cn.itcast.redisdemo.config;

import io.lettuce.core.ReadFrom;
import org.springframework.boot.autoconfigure.data.redis.LettuceClientConfigurationBuilderCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedisConfiguration {

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

这里的ReadFrom是配置Redis的读取策略，是一个枚举，包括下面选择：

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

这样就完成了RedisTemplate的哨兵模式的搭建

三、搭建分片集群

3.1分片集群解决的问题

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

海量数据存储问题
高并发写的问题

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

集群中有多个master，每个master保存不同数据
每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确节点

3.2 搭建分片集群

前言：

小编这里将准备六个redis实例，IP地址相同，端口相同，其中三个作为主节点（7001、7002、7003），三个各对应一个主节点作为从节点（8001、8002、8003 ），并创建各自对应的工作目录

3.2.1准备分片集群的redis.conf文件，内容如下：

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

将准备文件的端口地址修改为对应的端口号并复制当准备的工作目录中

3.2.2启动所有redis服务

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

3.2.3创建分片集群

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

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

1）Redis5.0之前

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

# 安装依赖 
yum -y install zlib ruby rubygems gem install redis

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

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

2）Redis5.0以后

小编使用的是Redis7.4.0版本，集群管理以及集成到了redis-cli中，格式如下：

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

命令说明：

redis-cli --cluster或者./redis-trib.rb：代表集群操作命令

create：代表是创建集群

--replicas 1或者--cluster-replicas 1 ：指定集群中每个master的副本个数为1，此时节点总数 ÷ (replicas + 1) 得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master

样例：

这里输入yes，则集群开始创建：

创建完成后可通过命令查看集群状态

redis-cli -p 7001 cluster nodes

3.2.4测试分片集群

集群操作时，需要给redis-cli加上-c参数才可以（一定要加否则会报错）：

redis-cli -c -p 7001

3.3散列插槽

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

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

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

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

3.4Redis分页集群伸缩

3.4.1添加一个新的节点到集群中

这里我准备的时一个新的redis服务且基础配置文件为之前配置分片集群的配置文件相同，只修改了端口号

通过指令向集群中添加redis服务

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

解析：

add-node：添加新节点的指令
192.168.8.128:7004：添加节点的ip地址和端口号
192.168.8.128:7001：集群中任意主节点ip地址和端口号

更多指令可通过help指令查看

3.4.2为新节点分配插槽

通过指令进行重新分片：

redis-cli --cluster reshard 192.168.8.128:7001

解析：

reshard：重新分片指令
192.168.8.128:7001：集群任意主节点ip和端口

这里我输入3000

接下来指定接收插槽的节点

选择7004的节点id

选择拷贝的数据

这里我选择7001里面的数据，选择完成后，输入done回车结束输入，紧接着输入yes表示将插槽进行转移

查看节点状态

同时将7001的数据在转移到了7004中

3.4.3Redis分页集群删除节点

这里我删除7004节点做实例，首先按照重新分片的方式将7004上的所有插槽进行转移到其他主节点上

然后用过以下指令进行删除

redis-cli --cluster del-node 192.168.8.128:7001 e6469b0abea593003e295654df79f973c57c97aa

3.5故障转移

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

首先是该实例与其它实例失去连接
然后是疑似宕机：
最后是确定下线，自动提升一个slave为新的master（这里我手动的将7002服务进行关闭，分片集群将8001提升为master）
再将7002服务进行启动它变成了slave节点

所以，分片集群不需要哨兵机制，他能自动的实现实现故障转移

利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

手动的Failover支持三种不同模式：

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

这里我将已经变成slave节点的7002服务实现无感知的数据迁移变成主节点

四、搭建配置RedisTemplate访问分片集群

在搭建RedisTemplate的哨兵模式的基础上，重新编辑application.yml文件，并将之前的RedisTemplate的哨兵模式配置的集群ip地址进行删除

spring:
redis:
    cluster:
      nodes: # 指定分片集群的每一个节点信息
        - 192.168.8.128:7001
        - 192.168.8.128:7002
        - 192.168.8.128:7003
        - 192.168.8.128:8001
        - 192.168.8.128:8002
        - 192.168.8.128:8003

即可完成搭建RedisTemplate访问分片集群

丘丘fighting

关注

4
点赞
踩
18

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见