RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB文件,默认是保存在当前运行目录
RDB持久化在四种情况下会执行:
Redis停机时:Redis停机时会执行一次save命令,实现RDB持久化
触发RDB条件时:
Redis内部有触发RDB的机制,可以在redis.conf文件中找到,格式如下:
# 900秒内,如果至少有1个key被修改,则执行bgsave , 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000
RDB的其它配置也可以在redis.conf文件中设置:
# 是否压缩 ,建议不开启,压缩也会消耗cpu,磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
RDB原理
bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件
fork采用的是copy-on-write技术:
AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件
AOF配置
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
AOF文件重写
因为是记录命令,AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果
如图,AOF原本有三个命令,但是
set num 123 和 set num 666
都是对num的操作,第二次会覆盖第一次的值,因此第一个命令记录下来没有意义。 所以重写命令后,AOF文件内容就是:mset name jack num 666
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
RDB和AOF各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会 结合 两者来使用
单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离
这里我们会在同3台虚拟机中开启3个redis实例,模拟主从集群,信息如下:
IP | PORT | 角色 |
---|---|---|
192.168.1.10 | 6379 | master |
192.168.1.11 | 6379 | slave |
192.168.1.12 | 6379 | slave |
在三台虚拟机分别安装Redis
修改每个实例的声明IP
虚拟机本身有多个IP,为了避免将来混乱,我们需要在redis.conf文件中指定每一个实例的绑定ip信息,格式如下:
# redis实例的声明 IP
replica-announce-ip 192.168.1.10
分别启动Redis服务
现在三个实例还没有任何关系,要配置主从可以使用replicaof 或者slaveof(5.0以前)命令
有临时和永久两种模式:
修改配置文件(永久生效)
slaveof 主Redis地址 端口号
使用redis-cli客户端连接到redis服务,执行slaveof命令(重启后失效):
slaveof 主Redis地址 顿口号
主从第一次建立连接时,会执行 全量同步 ,将master节点的所有数据都拷贝给slave节点,流程:
有几个概念,可以作为判断依据:
因此slave做数据同步,必须向master声明自己的replication id 和offset,master才可以判断到底需要同步哪些数据
因为slave原本也是一个master,有自己的replid和offset,当第一次变成slave,与master建立连接时,发送的replid和offset是自己的replid和offset
master判断发现slave发送来的replid与自己的不一致,说明这是一个全新的slave,就知道要做全量同步了
master会将自己的replid和offset都发送给这个slave,slave保存这些信息。以后slave的replid就与master一致了
因此,master判断一个节点是否是第一次同步的依据,就是看replid是否一致
全量同步需要先做RDB,然后将RDB文件通过网络传输个slave,成本太高了。因此除了第一次做全量同步,其它大多数时候slave与master都是做增量同步
什么是增量同步?就是只更新slave与master存在差异的部分数据。如图:
master怎么知道slave与自己的数据差异在哪里呢?
这就要说到全量同步时的repl_baklog文件了。
这个文件是一个固定大小的数组,只不过数组是环形,也就是说角标到达数组末尾后,会再次从0开始读写,这样数组头部的数据就会被覆盖。
repl_baklog中会记录Redis处理过的命令日志及offset,包括master当前的offset,和slave已经拷贝到的offset:
slave与master的offset之间的差异,就是salve需要增量拷贝的数据了
repl_baklog大小有上限,写满后会覆盖最早的数据。如果slave断开时间过久,导致尚未备份的数据被覆盖,则无法基于log做增量同步,只能再次全量同步
可以从以下几个方面来优化Redis主从就集群:
repl-diskless-sync yes
启用无磁盘复制,避免全量同步时的磁盘IORedis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复
哨兵的作用如下:
集群监控原理
Sentinel基于心跳机制监测服务状态,每隔1秒向集群的每个实例发送ping命令:
集群故障恢复原理
一旦发现master故障,sentinel需要在salve中选择一个作为新的master,选择依据是这样的:
当选出一个新的master后,该如何实现切换呢?
流程如下:
这里我们搭建一个三节点形成的Sentinel集群,来监管之前的Redis主从集群
三个sentinel实例信息如下:
节点 | IP | PORT |
---|---|---|
s1 | 192.168.1.10 | 27000 |
s2 | 192.168.1.11 | 27000 |
s3 | 192.168.1.12 | 27000 |
分别创建s1、s2、s3目录
在创建的目录下创建sentinel.conf文件,添加下面内容:
解读:
port 27000
:是当前sentinel实例的端口
sentinel announce-ip
: 声明访问本机的ip
sentinel monitor mymaster 192.168.1.10 6379 2
:指定主节点信息
mymaster
:主节点名称,自定义,任意写
192.168.1.10 6379
:主节点的ip和端口
2
:选举master时的quorum值
port 27000
sentinel announce-ip 192.168.1.10
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/tmp/s1"
分别启动:redis-sentinel s1/sentinel.conf
在Sentinel集群监管下的Redis主从集群,其节点会因为自动故障转移而发生变化,Redis的客户端必须感知这种变化,及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换
导入工程
在项目的pom文件中引入依赖:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
然后在配置文件application.yml中指定redis的sentinel相关信息:
spring:
redis:
sentinel:
master: mymaster # 指定Master名称
nodes: # 指定redis-sentinel集群信息
- 192.168.1.10:27000
- 192.168.1.11:27000
- 192.168.1.12:27000
在项目的配置类中,添加一个新的bean
这个bean中配置的就是读写策略,包括四种:
@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决:
分片集群特征:
分片集群需要的节点数量较多,这里我们搭建一个最小的分片集群,包含3个master节点,每个master包含一个slave节点,结构如下:
这里我们会在三台虚拟机中开启6个redis实例,模拟分片集群,信息如下:
192.168.1.10 | 6379 | master |
---|---|---|
192.168.1.11 | 6379 | master |
192.168.1.12 | 6379 | master |
192.168.1.10 | 8000 | slave |
192.168.1.11 | 8000 | slave |
192.168.1.12 | 8000 | slave |
在/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.1.10
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log
启动redis
创建集群
虽然服务启动了,但是目前每个服务之间都是独立的,没有任何关联。
我们需要执行命令来创建集群,在Redis5.0之前创建集群比较麻烦,5.0之后集群管理命令都集成到了redis-cli中
redis-cli --cluster create --cluster-replicas 1 192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 192.168.1.10:8000 192.168.1.11:8000 192.168.1.12:8000
命令说明:
进入集群客户端需要加额外的参数 -c
:redis-cli -c -p 6379
Redis会把每一个master节点映射到0~16383共16384个插槽(hash slot)上,查看集群信息时就能看到:
数据key不是与节点绑定,而是与插槽绑定。redis会根据key的有效部分计算插槽值,分两种情况:
例如:key是num,那么就根据num计算,如果是{itcast}num,则根据itcast计算。计算方式是利用CRC16算法得到一个hash值,然后对16384取余,得到的结果就是slot值
如图,在192.168.1.10:6379这个节点执行set a 1时,对a做hash运算,对16384取余,得到的结果是15495,因此要存储到103节点。
到了192.168.1.12:6379后,执行get num
时,对num做hash运算,对16384取余,得到的结果是2765,因此需要切换到192.168.1.10:6379节点
RedisTemplate底层同样基于lettuce实现了分片集群的支持,而使用的步骤与哨兵模式基本一致:
spring:
redis:
cluster:
nodes: # 指定分片集群的每一个节点信息
- 192.168.1.10:6379
- 192.168.1.11:6379
- 192.168.1.12:6379
- 192.168.1.10:8000
- 192.168.1.11:8000
- 192.168.1.12:8000