- 一、RDB
- 1. 什么是RDB?
- 2. 工作过程
- 3. 开启RDB快照(docker方式)
- 4.优缺点
- 二、AOF
- 1. 什么是AOF?
- 2. 工作过程
- 3. 开启AOF(docker方式)
- 4. AOF和RDB同时开启时,Redis会按照什么执行持久化
- 5. AOF同步频率设置
- 6. Rewrite压缩
- 6.1 什么是Rewrite压缩
- 6.2 重写过程
- 6.3 触发机制,何时重写
- 7. 优缺点
- 三、总结
- 1. 用哪个比较好
- 2. 官网建议
一、RDB 1. 什么是RDB?
在指定的时间内将内存中的数据集快照写入到磁盘中,在恢复时是将快照文件直接读取到内存中去。
2. 工作过程Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中去,待持久化过程都结束了,再使用这个临时文件来替换上次持久化好的文件。整个过程中,主进程是不进行任何的IO操作的,只进行数据的读写,这就确保了Redis的高性能。该持久化方式适用于大规模的数据恢复,并且对于数据的完整性不是很看重的场景。因为RDB的缺点是最后面执行持久化的数据可能会丢失。
3. 开启RDB快照(docker方式)- 官网下载redis.conf文件
Redis6.0版本redis.conf配置文件地址 - 下载后的文件修改几处位置
bind 127.0.0.1表示只能本地可以连接redis服务,可以直接注释掉或者修改为0.0.0.0,让任意Ip可以访问redis服务。
将保护模式关闭 - Linux中新建存储redis持久化文件存储文件夹以及配置文件夹
mkdir /opt/dockerMapping/redis/conf mkdir /opt/dockerMapping/redis/data
- 拉取redis镜像
docker pull redis
- 启动redis容器
docker run -d --privileged=true -p 6379:6379 -v /opt/dockerMapping/redis/conf/redis.conf:/etc/redis/redis.conf -v /opt/dockerMapping/redis/data:/data --name redis redis redis-server /etc/redis/redis.conf
4.优缺点run:启动容器
d:在后台运行容器,并打印id
p:端口映射
v:挂载数据卷
优点
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高的适用
- 节省磁盘空间
- 恢复速度快
缺点 - Fork的时候(即执行save操作时),内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
- 备份是间隔一段时间做一次的,如果在间隔的时间内发生了导致服务挂了,会丢失掉最后一次快照之后所有的修改操作
以日志的形式记录下来所有的写操作(增量保存),将执行过的所有操作都记录下来(不包括读操作),只许追加不能改写文件,redis在重启的时候就是根据日志文件的内容将指令从前往后执行一次来完成恢复工作
2. 工作过程- 客户端的请求命令会被append追加到AOF缓冲区内
- AOF缓冲区根据AOF持久化策略[always,everysec,no],将操作同步到AOF文件中
- 当AOF的文件大小超过了重写策略规定的大小的时候时,或者执行手动重写时,会对AOF文件进行rewrite重写,压缩AOF文件容量
- redis服务重启时,会重新加载AOF文件中的所有写操作达到文件恢复的目的
- 下载Redis配置文件
- 修改配置,开启aof持久化方式
- Linux中新建存储redis持久化文件存储文件夹以及配置文件夹
mkdir /opt/dockerMapping/redis/conf mkdir /opt/dockerMapping/redis/data
- 拉取redis镜像
docker pull redis
- 启动redis容器
docker run -d --privileged=true -p 6379:6379 -v /opt/dockerMapping/redis/conf/redis.conf:/etc/redis/redis.conf -v /opt/dockerMapping/redis/data:/data --name redis redis redis-server /etc/redis/redis.conf4. AOF和RDB同时开启时,Redis会按照什么执行持久化
AOF和RDB同时开启时,系统重启的时候读取AOF文件进行持久化
5. AOF同步频率设置- always:始终同步,每次redis的写入都会记录到aof文件中;性能较差,但是数据完整性较好
- everysec:每秒同步,每秒写入日志一次,如果宕机可能会丢失本秒的数据
- no:redis不主动进行同步,把同步时机交由操作系统
因为AOF采用的是文件追加方式,所以文件会越来越大,为了避免这种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
6.2 重写过程AOF文件持续增长过大时,会fork出来一条新进程来将文件重写(也是先写临时文件,然后再替换),reids4.0以后的重写,就是把rdb的快照,以二进制的形式附在新的aof头部,作为已有的历史数据,替换掉原来的流水账操作。
6.3 触发机制,何时重写Redis会记录上一次重写时的AOF文件大小,默认的配置是当AOF文件的大小是上次重写后大小的一倍并且文件大于64M时触发重写。
例如:当文件第一次达到64M时,开始重写,重写之后压缩到了50M。下一次重写需要等到文件大小达到100M时才自动触发。
优点
- 备份机制更加的完善,丢失数据的概率更低
- 可读的日志文件,通过操作AOF文件,可以处理误操作
缺点 - 比起RDB需要占用更多的磁盘空间
- 恢复备份的数据更慢
- 每次读写都同步的话有一定的性能压力
官方推荐的是两个都是开启。如果是对数据不敏感,可以单独使用RDB。不建议单独使用AOF,因为可能会出现bug。如果单纯的做内存操作,可以都不用
2. 官网建议- RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾
- Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式
- 同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那么要不要只使用AOF呢?
- 建议不要,因为RDB更合适用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段



