在分布式缓存中常常使用redis的技术实现方案。
RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。
快照文件称为RDB文件,默认是保存在当前运行目录
sava #由Redis主进程来执行RDB,会阻塞所有命令
bgsava #由子进程来执行RDB
bgsava开始时会fork主进程的到子进程,子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件
fork采用copy-on-write技术:
注意:关闭Redis时会自动执行一次RDB
那么是否只有关闭Redis时才会执行RDB呢?当然不是!
Redis内部有触发RDB机制,可以在redis.conf文件中找到格式如下:
# sava 时间(单位秒) key修改次数
sava 900 1 #900秒内如果有一个key被修改则执行bgsava
注意:如果是 sava ""则关闭RDB
RDB的其他配置也可以在redis.conf文件中设置
#是否压缩,建议不开启,压缩也会消耗cpu,磁盘资源相对便宜
rdbcompression yes
#RDB文件名称
dbfilename dump.rdb
#文件保存的目录
dir ./
建议:生产环境下的redis不要修改避免造成数据丢失
AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件。
AOF默认是关闭的,需要修改redis.conf配置文件来开启AOF:
#是否开启AOF功能,默认是no
appendsync yes
#AOF文件名称
appendfilename "appendonly.aof"
AOF的命令记录的频率也可以通过redis.conf文件来配
#表示每执行一次写命令,立即记录到AOF文件
appendsync always
#写命令执行完先放入缓冲区,然后每隔1秒将缓冲区数据写入到AOF文件,是默认方案
appendsync everysec
#写命令执行完先放入缓冲区,由系统决定何时将缓冲区内容写回磁盘
appendsync no
配置项 | 刷盘时机 | 优点 | 缺点 |
---|---|---|---|
Always | 同步刷盘 | 可靠性高,几乎不丢数据 | 性能影响大 |
everysec | 没秒刷盘 | 性能适中 | 最多丢失1秒数据 |
no | 操作系统控制 | 性能最好 | 可靠性差,可能丢失大量数据 |
因为AOF是记录命令,所以AOF文件会比RDB文件大很多。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果。
Redis也会在出发阈值时自动去重写AOF文件,阈值也可以在Redis.conf中配置
#AOF文件比上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
#AOF文件体积超过多少就触发重写
auto-aof-rewrite-min-size 64mb
RDB和AOF各有自己的优缺点,如果对数据的安全要求比较高就使用AOF反之则使用RDB,在实际的开发中往往会二者结合使用。
RDB | AOF | |
---|---|---|
持久化方式 | 定时对整个内存做快照 | 记录每一次写命令 |
数据完整性 | 不完整,两次备份之间会丢失 | 相对完整,取决于刷盘策略 |
文件大小 | 会有压缩,文件体积较小 | 记录命令,文件体积很大 |
宕机恢复速度 | 很快 | 慢 |
数据恢复优先级 | 低,因为数据完整性不如AOF | 高,因为数据完整性更高 |
系统资源占用 | 高,大量cpu和内存消耗 | 低,主要是磁盘IO资源,但AOF重写时会占用大量CPU和内存资源 |
使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求高 |
单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离
master如何判断slave是不是第一次来同步数据?这里会用到两个概念:
全量同步步骤
增量同步步骤
注意:repl_baklog大小有上限,写满后会覆盖最早的数据。如果slave断开时间过久,导致尚未备份的数据被覆盖,则无法基于log做增量同步,只能再次全量同步
在主从结构中slave宕机之后可以从master节点恢复数据,那么master节点宕机之后呢?
这里就需要使用redis的哨兵来进行故障恢复,节点选举,服务监控
Sentinel基于心跳机制检测服务状态,每隔1秒向集群的每个实例发送ping命令:
quorun的值最好超过sentinel实例数量的一半
一单发现master故障,sentinel需要在salve中选择一个新的master:
当选中了其中一个slave为新的master后(例如slave1),故障迁移的步骤如下:
依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
配置
spring:
redis:
sentinel:
master: mymaster
nodes:
- 127.0.0.1:27001
- 127.0.0.1:27002
- 127.0.0.1:27003
配置主从读写分离
@Bean
public LettuceClientConfigurationBuilderCustomizer configurationBuilderCustomizer(){
return configBuilder -> configBuilder.readFrom (ReadFrom.REPLICA_PREFERRED);
}
ReadFrom读取策略
•MASTER:从主节点读取
•MASTER_PREFERRED:优先从master节点读取,master不可用才读取replica
•REPLICA:从slave(replica)节点读取
•REPLICA _PREFERRED:优先从slave(replica)节点读取,所有的slave都不可用才读取master
主从和哨兵可以解决高可用,高并发读的问题,但是依然有两个问题没有解决:
使用分片集群可以解决上述问题
Redis会把每一个master节点映射到0~16383共16384个插槽(hash slot)上
数据key与插槽绑定。redis会根据kety有效部分计算插槽值,分两种情况:
key中包含“{}”,且"{}“中至少包含一个字符,”{}"中的部分是有效部分
key中不包含“{}”,整个key都是有效部分
例如:{typeId}typeName typeId是计算插槽值有效部分,key为typeIdtypeNema