微服务中间件-分布式缓存Redis

分布式缓存

    • a.Redis持久化
      • 1) RDB持久化
        • 1.a) RDB持久化-原理
      • 2) AOF持久化
      • 3) 两者对比
    • b.Redis主从
      • 1) 搭建主从架构
      • 2) 数据同步原理（全量同步）
      • 3) 数据同步原理（增量同步）
    • c.Redis哨兵
      • 1) 哨兵的作用
      • 2) 搭建Redis哨兵集群
      • 3) RedisTemplate的哨兵模式
    • d.Redis分片集群
      • 1) 搭建分片集群
      • 2) 散列插槽
      • 3) 集群伸缩
      • 4) 故障转移
      • 5) RedisTemplate访问分片集群

– 基于Redis集群解决单机Redis存在的问题

单机的Redis存在四大问题：

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

在这里插入图片描述

a.Redis持久化

1) RDB持久化

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

快照文件称为RDB文件，默认是保存在当前运行目录。

在这里插入图片描述

Redis停机时会执行一次RDB。

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

在这里插入图片描述

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

在这里插入图片描述

1.a) RDB持久化-原理

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

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9auWz7oi-1692354289144)(C:\Users\captaindeng\AppData\Roaming\Typora\typora-user-images\image-20230817140743459.png)]

RDB方式bgsave的基本流程？

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

RDB会在什么时候执行？

  • 默认是服务停止时。
  • 也可以设置在60秒内至少执行1000次修改则触发RDB (自修改)

RDB的缺点？

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

2) AOF持久化

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

在这里插入图片描述

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

在这里插入图片描述

AOF的命令记录的频率也可以通过redis.conf文件来配：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pkPcdXYV-1692354289145)(C:\Users\captaindeng\AppData\Roaming\Typora\typora-user-images\image-20230817144856449.png)]

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

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

在这里插入图片描述

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

在这里插入图片描述

3) 两者对比

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

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

b.Redis主从

1) 搭建主从架构

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

在这里插入图片描述

共包含三个节点，一个主节点，两个从节点。

这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IPPORT角色
192.168.150.1017001master
192.168.150.1017002slave
192.168.150.1017003slave

准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

1）创建目录

我们创建三个文件夹，名字分别叫7001、7002、7003：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir 7001 7002 7003

如图：

image-20210630113929868

2）恢复原始配置

修改redis-6.2.4/redis.conf文件，将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态。

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000# 关闭AOF
appendonly no

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

然后将redis-6.2.4/redis.conf文件拷贝到三个目录中（在/tmp目录执行下列命令）：

# 方式一：逐个拷贝
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

4）修改每个实例的端口、工作目录

修改每个文件夹内的配置文件，将端口分别修改为7001、7002、7003，将rdb文件保存位置都修改为自己所在目录（在/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

5）修改每个实例的声明IP

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

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

每个目录都要改，我们一键完成修改（在/tmp目录执行下列命令）：

# 逐一执行
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

启动

为了方便查看日志，我们打开3个ssh窗口，分别启动3个redis实例，启动命令：

# 第1个
redis-server 7001/redis.conf
# 第2个
redis-server 7002/redis.conf
# 第3个
redis-server 7003/redis.conf

启动后：

image-20210630183914491

如果要一键停止，可以运行下面命令：

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

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

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

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

  • 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

    slaveof <masterip> <masterport>

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

这里我们为了演示方便，使用方式二。

通过redis-cli命令连接7002，执行下面命令：

# 连接 7002
redis-cli -p 7002
# 执行slaveof
slaveof 192.168.150.101 7001

通过redis-cli命令连接7003，执行下面命令：

# 连接 7003
redis-cli -p 7003
# 执行slaveof
slaveof 192.168.150.101 7001

然后连接 7001节点，查看集群状态：

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

结果：

image-20210630201258802

测试

执行下列操作以测试：

  • 利用redis-cli连接7001，执行set num 123

  • 利用redis-cli连接7002，执行get num，再执行set num 666

  • 利用redis-cli连接7003，执行get num，再执行set num 888

可以发现，只有在7001这个master节点上可以执行写操作，7002和7003这两个slave节点只能执行读操作。

2) 数据同步原理（全量同步）

主从第一次同步是全量同步：

在这里插入图片描述

master如何判断slave是不是第一次来同步数据？

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

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

image-20230817161009021

简述全量同步的流程？

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

3) 数据同步原理（增量同步）

主从第一次同步是全量同步，但如果slave重启后同步，则执行增量同步

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qv8gWjxp-1692354289145)(C:\Users\captaindeng\AppData\Roaming\Typora\typora-user-images\image-20230817161911269.png)]

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

可以从以下几个方面来优化Redis主从集群：

  • 在master中配置repl-diskless-sync yes启用无磁盘复制(写入网络的IO中)，避免全量同步时的磁盘IO
  • Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
  • 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

在这里插入图片描述

c.Redis哨兵

1) 哨兵的作用

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

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

在这里插入图片描述

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

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

选举新的master

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

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

如何实现故障转移

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

  • sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
  • sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据
  • 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

2) 搭建Redis哨兵集群

三个sentinel实例信息如下：

节点IPPORT
s1192.168.150.10127001
s2192.168.150.10127002
s3192.168.150.10127003

准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我们创建三个文件夹，名字分别叫s1、s2、s3：

# 进入/tmp目录
cd /tmp
# 创建目录
mkdir s1 s2 s3

如图：

image-20210701215534714

然后我们在s1目录创建一个sentinel.conf文件，添加下面的内容：

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：是当前sentinel实例的端口
  • sentinel monitor mymaster 192.168.150.101 7001 2：指定主节点信息
    • mymaster：主节点名称，自定义，任意写
    • 192.168.150.101 7001：主节点的ip和端口
    • 2：选举master时的quorum值

然后将s1/sentinel.conf文件拷贝到s2、s3两个目录中（在/tmp目录执行下列命令）：

# 方式一：逐个拷贝
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：

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个ssh窗口，分别启动3个redis实例，启动命令：

# 第1个
redis-sentinel s1/sentinel.conf
# 第2个
redis-sentinel s2/sentinel.conf
# 第3个
redis-sentinel s3/sentinel.conf

启动后：

image-20210701220714104

测试

尝试让master节点7001宕机，查看sentinel日志：

image-20210701222857997

查看7003的日志：

image-20210701223025709

查看7002的日志：

image-20210701223131264

3) RedisTemplate的哨兵模式

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

1.在pom文件中引入redis的starter依赖：

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

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

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

3.配置主从读写分离

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

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

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

d.Redis分片集群

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

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

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

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

在这里插入图片描述

1) 搭建分片集群

分片集群需要的节点数量较多，这里我们搭建一个最小的分片集群，包含3个master节点，每个master包含一个slave节点

这里我们会在同一台虚拟机中开启6个redis实例，模拟分片集群，信息如下：

IPPORT角色
192.168.150.1017001master
192.168.150.1017002master
192.168.150.1017003master
192.168.150.1018001slave
192.168.150.1018002slave
192.168.150.1018003slave

准备实例和配置

删除之前的7001、7002、7003这几个目录，重新创建出7001、7002、7003、8001、8002、8003目录：

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

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

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 192.168.150.101
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log

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

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

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

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

启动

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

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

通过ps查看状态：

ps -ef | grep redis

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

image-20210702174255799

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

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

创建集群

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

我们需要执行命令来创建集群，在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.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以后

集群管理以及集成到了redis-cli中，格式如下：

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

命令说明：

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

运行后的样子：

image-20210702181101969

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

image-20210702181215705

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

redis-cli -p 7001 cluster nodes

image-20210702181922809

测试

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

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

结果悲剧了：

image-20210702182343979

集群操作时，需要给redis-cli加上-c参数才可以：

redis-cli -c -p 7001

这次可以了：

image-20210702182602145

2) 散列插槽

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

在这里插入图片描述

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

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

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

在这里插入图片描述

Redis如何判断某个key应该在哪个实例？

  • 将16384个插槽分配到不同的实例
  • 根据key的有效部分计算哈希值，对16384取余
  • 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

  • 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

3) 集群伸缩

添加一个节点到集群

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

在这里插入图片描述

比如，添加节点的命令：

在这里插入图片描述

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

需求：

  • 启动一个新的redis实例，端口为7004
  • 添加7004到之前的集群，并作为一个master节点
  • 给7004节点分配插槽，使得num这个key可以存储到7004实例
# 在tmp目录下，创建新的7004目录
mkdir 7004
# 拷贝redis.conf到7004目录下
cp redis.conf 7004
# 将redis.conf的端口号全部替换成7004
sed -i s/6379/7004/g 7004/redis.conf
# 启动7004的redis
redis-server 7004/redis.conf
# 添加7004到之前的集群中
redis-cli --cluster add-node 192.168.200.128:7004 192.168.200.128:7001
# 将7001的部分插槽移至7004
redis-cli --cluster reshard 192.168.200.128:7001# 提示输入要移动多少个插槽：3000# 提示输入接收插槽的id：输入7004 redis的id# 提示输入从那个插槽移动：输入7001 redis的id# 输入 done# 输入 yes
# 查看插槽，是否移动成功
redis-cli -p 7001 cluster nodes
# 将num存入redis中
redis-cli -c -p 7004# set num 10

案例：删除集群中的一个节点

需求：删除7004这个实例

# 将7004的全部插槽移至7001
redis-cli --cluster reshard 192.168.200.128:7001# 提示输入要移动多少个插槽：3000# 提示输入接收插槽的id：输入7001 redis的id# 提示输入从那个插槽移动：输入7004 redis的id# 输入 done# 输入 yes
# 查看插槽，是否移动成功。并获取7004的id
redis-cli -p 7001 cluster nodes
# 删除7004节点：redis-cli --cluster del-node nodeId
redis-cli --cluster del-node 192.168.200.128:7004 08af8f1fedc0d211bbb94225d3cef59efd75aa6a

4) 故障转移

Redis集群拥有自动主从切换的功能，无需使用哨兵

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

1.首先是该实例与其它实例失去连接

2.然后是疑似宕机：

在这里插入图片描述

3.最后是确定下线，自动提升一个slave为新的master：

在这里插入图片描述

数据迁移

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

在这里插入图片描述

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

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

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

步骤如下：

  • 1.利用redis-cli连接7002这个节点
  • 2.执行cluster failover命令
# 进入redis 7002的控制台
redis-cli -p 7002# 在控制台输入 cluster failover# 7002将成为master

5) RedisTemplate访问分片集群

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

  • 1.引入redis的starter依赖
  • 2.配置分片集群地址
  • 3.配置读写分离

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

spring:redis:cluster:nodes:- 192.168.200.128:7001- 192.168.200.128:7002- 192.168.200.128:7003- 192.168.200.128:8001- 192.168.200.128:8002- 192.168.200.128:8003

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/43095.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

金融语言模型：FinGPT

金融语言模型：FinGPT

项目简介 FinGPT是一个开源的金融语言模型&#xff08;LLMs&#xff09;&#xff0c;由FinNLP项目提供。这个项目让对金融领域的自然语言处理&#xff08;NLP&#xff09;感兴趣的人们有了一个可以自由尝试的平台&#xff0c;并提供了一个与专有模型相比更容易获取的金融数据。…
阅读更多...
VS2015项目中，MFC内存中调用DLL函数（VC6生成的示例DLL）

VS2015项目中，MFC内存中调用DLL函数（VC6生成的示例DLL）

本例主要讲一下&#xff0c;用VC6如何生成DLL&#xff0c;用工具WinHex取得DLL全部内容&#xff0c;VC2015项目加载内存中的DLL函数&#xff0c;并调用函数的示例。 本例中的示例代码下载&#xff0c;点击可以下载 一、VC6.0生成示例DLL项目 1.新建项目&#xff0c;…
阅读更多...
SQL Server Express 自动备份方案

SQL Server Express 自动备份方案

文章目录 SQL Server Express 自动备份方案前言方案原理SQL Server Express 自动备份1.创建存储过程2.设定计划任务3.结果检查sqlcmd 参数说明SQL Server Express 自动备份方案 前言 对于许多小型企业和个人开发者来说，SQL Server Express是一个经济实惠且强大的数据库解决方…
阅读更多...
Spring Framework中的Bean生命周期

Spring Framework中的Bean生命周期

目录 一.Bean生命周期的简介 1.基本概念 2.Spring生命周期的几大阶段 3.注意点及小结 4.生活案例 5.Spring容器管理JavaBean的初始化过程 二. Bean的单例选择与多例选择 1.单例选择与多例选择的优缺点 1.1单例模式的优点&#xff1a; 1.2单例模式的缺点&#xff1a; 1…
阅读更多...
JDK 8 升级 JDK 17 全流程教学指南

JDK 8 升级 JDK 17 全流程教学指南

JDK 8 升级 JDK 17 首先已有项目升级是会经历一个较长的调试和自测过程来保证允许和兼容没有问题。先说几个重要的点 遇到问题别放弃仔细阅读报错&#xff0c;精确到每个单词每一行&#xff0c;不是自己项目的代码也要点进去看看源码到底是为啥报错明确你项目引入的包&#x…
阅读更多...
第三届“赣政杯”网络安全大赛 | 赛宁筑牢安全应急防线

第三届“赣政杯”网络安全大赛 | 赛宁筑牢安全应急防线

​​为持续强化江西省党政机关网络安全风险防范意识&#xff0c;提高信息化岗位从业人员基础技能&#xff0c;提升应对网络安全风险处置能力。由江西省委网信办、江西省发展改革委主办&#xff0c;江西省大数据中心、国家计算机网络与信息安全管理中心江西分中心承办&#xff0…
阅读更多...
Qt扫盲-QTableView理论总结

Qt扫盲-QTableView理论总结

QTableView理论总结 一、概述二、导航三、视觉外观四、坐标系统五、示例代码1. 性别代理2. 学生信息模型3. 对应视图 一、概述 QTableView实现了一个tableview 来显示model 中的元素。这个类用于提供之前由QTable类提供的标准表&#xff0c;但这个是使用Qt的model/view架构提供…
阅读更多...
MySQL 存储过程

MySQL 存储过程

create procedure 存储过程名 &#xff08;in | out | INPUT 参数名 参数类型&#xff0c;。。。&#xff09; 【characteristics 。。。】begin存储过程体end存储过程的参数类型 IN 、OUT、INPUT 都可以在一个存储过程带多个 没有参数&#xff08;无参数无返回&#xff09;仅…
阅读更多...
边缘网络的作用及管理工具

边缘网络的作用及管理工具

自从引入软件即服务 &#xff08;SaaS&#xff09; 以来&#xff0c;它一直引领着全球按需软件部署创新的竞赛&#xff0c;它提供的灵活性以及其云计算架构带来的易于集成使其成为交付业务应用程序的标准。 在 SaaS 模型中&#xff0c;最佳用户体验的三重奏涉及无缝设置、低延…
阅读更多...
JMeter 特殊组件-逻辑控制器与BeanShell PreProcessor 使用示例

JMeter 特殊组件-逻辑控制器与BeanShell PreProcessor 使用示例

文章目录 前言JMeter 特殊组件-逻辑控制器与BeanShell PreProcessor 使用示例1. 逻辑控制器使用1.1. While Controller 使用示例1.2. 如果&#xff08;If&#xff09;控制器 使用示例 2. BeanShell PreProcessor 使用示例 前言 如果您觉得有用的话&#xff0c;记得给博主点个赞…
阅读更多...
Java课题笔记~ SpringBoot简介

Java课题笔记~ SpringBoot简介

1. 入门案例 问题导入 SpringMVC的HelloWord程序大家还记得吗&#xff1f; SpringBoot是由Pivotal团队提供的全新框架&#xff0c;其设计目的是用来简化Spring应用的初始搭建以及开发过程 原生开发SpringMVC程序过程 1.1 入门案例开发步骤 ①&#xff1a;创建新模块&#…
阅读更多...
设计模式-过滤器模式(使用案例)

设计模式-过滤器模式(使用案例)

过滤器模式&#xff08;Filter Pattern&#xff09;或标准模式&#xff08;Criteria Pattern&#xff09;是一种设计模式&#xff0c;这种模式允许开发人员使用不同的标准来过滤一组对象&#xff0c;通过逻辑运算以解耦的方式把它们连接起来。这种类型的设计模式属于结构型模式…
阅读更多...
服务器安装centos7踩坑

服务器安装centos7踩坑

1、制作启动工具 下载iso https://developer.aliyun.com/mirror/?spma2c6h.25603864.0.0.20387abbo2RFbn http://mirrors.aliyun.com/centos/7.9.2009/isos/x86_64/?spma2c6h.25603864.0.0.1995f5ad4AhJaW下载 UltraISO https://cn.ultraiso.net/插入u盘启动 到了如图所示页面…
阅读更多...
nginx php-fpm安装配置

nginx php-fpm安装配置

nginx php-fpm安装配置 nginx本身不能处理PHP&#xff0c;它只是个web服务器&#xff0c;当接收到请求后&#xff0c;如果是php请求&#xff0c;则发给php解释器处理&#xff0c;并把结果返回给客户端。 nginx一般是把请求发fastcgi管理进程处理&#xff0c;fascgi管理进程选…
阅读更多...
架构演进及常用架构

架构演进及常用架构

1架构演进及常用架构 1.1单体分层架构 1.2 多应用微服务架构 1.3 分布式集群部署 部署 CDN 节点&#xff1a; 用户访问量的增加意味着用户地域的分散请求&#xff0c;如果所有请求都直接发送中心服务器的话&#xff0c;距离越远&#xff0c;响应速度越差&#xff0c;这时就需…
阅读更多...
【编织时空四：探究顺序表与链表的数据之旅】

【编织时空四：探究顺序表与链表的数据之旅】

本章重点 链表的分类 带头双向循环链表接口实现 顺序表和链表的区别 缓存利用率参考存储体系结构 以及 局部原理性。 一、链表的分类 实际中链表的结构非常多样&#xff0c;以下情况组合起来就有8种链表结构&#xff1a; 1. 单向或者双向 2. 带头或者不带头 3. 循环或者非…
阅读更多...
yolov5封装进ros系统

yolov5封装进ros系统

一&#xff0c;要具备ROS环境 ROS环境搭建可以参考我之前的文章 ROS参考文章1 ROS参考文章2   建立ROS工作空间 ROS系统由自己的编译空间规则。 cd 你自己想要的文件夹&#xff08;我一般是home目录&#xff09; mkdir -p (你自己的文件夹名字&#xff0c;比如我是yolov5…
阅读更多...
C++的stack和queue+优先队列

C++的stack和queue+优先队列

文章目录 什么是容器适配器底层逻辑为什么选择deque作为stack和queue的底层默认容器优先队列优先队列的模拟实现stack和queue的模拟实现 什么是容器适配器 适配器是一种设计模式(设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总 结)&#xff0c;…
阅读更多...
PyTorch训练深度卷积生成对抗网络DCGAN

PyTorch训练深度卷积生成对抗网络DCGAN

文章目录 DCGAN介绍代码结果参考 DCGAN介绍 将CNN和GAN结合起来&#xff0c;把监督学习和无监督学习结合起来。具体解释可以参见 深度卷积对抗生成网络(DCGAN) DCGAN的生成器结构&#xff1a; 图片来源&#xff1a;https://arxiv.org/abs/1511.06434 代码 model.py impor…
阅读更多...
Electron入门，项目启动。

Electron入门，项目启动。

electron 简单介绍&#xff1a; 实现&#xff1a;HTML/CSS/JS桌面程序&#xff0c;搭建跨平台桌面应用。 electron 官方文档&#xff1a; [https://electronjs.org/docs] 本文是基于以下2篇文章且自行实践过的&#xff0c;可行性真实有效。 文章1&#xff1a; https://www.cnbl…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023