Redis持久化机制

最新推荐文章于 2023-09-12 09:35:41 发布

晨风灿

最新推荐文章于 2023-09-12 09:35:41 发布

阅读量147

点赞数

分类专栏： redis 文章标签： redis java docker 数据持久化

本文链接：https://blog.csdn.net/weixin_46254542/article/details/108424379

版权

redis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本文深入探讨了Redis的两种持久化机制：RDB和AOF。RDB通过生成二进制快照实现快速持久化，适合全量数据恢复。AOF则记录每次写操作，虽速度稍慢，但能提供更高的数据安全性，支持多种持久化时机设置。

摘要由CSDN通过智能技术生成

RDB存储

RDB是Redis默认的持久化机制

RDB持久化文件，速度比较快，而且存储的是一个二进制的文件，传输起来很方便。
save #主动触发RDB，由主进程亲自完成
bgsave #主动触发RDB，由子进程完成
当redis进程被stop时 #触发一次RDB

一、创建文件夹 rdbtest，所有文件和操作均在此文件夹下进行

1、创建docker-compose.yml文件

version: '3.1'
services:
  redis1:
    image: 10.0.134.175:5000/redis:5.0.9
    restart: always
    container_name: redis1
    environment:
      - TZ=Asia/Shanghai
    ports:
      - 6379:6379
    volumes:
    #数据卷映射，当前目录下的redis.conf映射到容器的redis.conf
      - ./redis.conf:/usr/local/redis/redis.conf
      - ./data:/data  #当前目录下的data目录，映射容器中的data目录
    #command是指redis容器启动后，执行我们定义的redis.conf文件
    command: ["redis-server","/usr/local/redis/redis.conf"]

2、创建redis.conf文件

dir "/data"
save 10 1   #在10秒内，有1个key改变了，就执行RDB持久化
save 5 2    #在5秒内，有2个key改变了，就执行RDB持久化
dbfilename "dump1.rdb"

3、开启容器，进行操作

#开启容器
docker-compose up -d
#进入容器内部
docker exec -it redis1 bash
#连接redis
redis-cli

在这里插入图片描述操作后，去data目录下查看dump1.rdb

在这里插入图片描述

SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：
SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。

Save是阻塞方式的；bgsave是非阻塞方式的

AOF存储

AOF持久化机制默认是关闭的，Redis官方推荐同时开启RDB和AOF持久化，更安全，避免数据丢失。

AOF持久化的速度，相对RDB较慢的，存储的是一个文本文件，到了后期文件会比较大，传输困难。

AOF持久化时机：

appendfsync always：每执行一个写操作，立即持久化到AOF文件中，性能比较低。
appendfsync everysec：每秒执行一次持久化。
appendfsync no：会根据你的操作系统不同，环境的不同，在一定时间内执行一次持久化。

AOF相对RDB更安全，推荐同时开启AOF和RDB。

AOF操作步骤

1、docker-compose.yml文件，内容不变，修改redis.conf

dir "/data"
#开启aof机制
appendonly yes
#每秒进行一次持久化
appendfsync everysec
#追加到文件appendonly1.conf
appendfilename "appendonly1.aof"

2、开启容器，进行操作

#开启容器
docker-compose up -d
#进入容器内部
docker exec -it redis1 bash
#连接redis
redis-cli

3、查看记录
在这里插入图片描述所有的set操作均已记录

AOF重写

命令：bgrewriteaof
触发aof重写，重新做了一份文件，同名的文件
在这里插入图片描述 1、主进程先创建了一个子进程，同时在子进程，把数据做了备份，就是图中的灰色方块。
2、子进程把所有的数据转为写指令，存入到新的aof文件中。
比如：文件里有age 18，那么它会转成set age 18
子进程在运行过程中，主进程还是有写操作，所以不能用子的aof文件，直接替换到旧的aof文件
3、在子进程运行时，主进程也在运行，它会把新的指令都追加到旧的aof文件中。这也是保底策略，如果新的aof失败，那么依然可以使用旧aof
4、在创建子进程时，主进程会把新的所有命令，都缓存起来，这里缓存的都是子进程备份没有的指令
5、之后主进程会把缓存的指令叠加到新的aof文件中，这样才是完整的新的aof文件
6、替换掉旧的aof文件
这里只有2是子在做，其他都是主进程做。
1 3 4步由主来做，是没有疑问的。
5由主来做也是合理的，主先暂停对外服务，然后把缓存加入到aof文件，然后替换掉旧的，这样才不会有数据差，如果不是主来做，那么主依然会接收新的指令，那么会有数据差。

AOF重写操作步骤

1、docker-compose.yml文件，内容不变，redis.conf内容：

dir "/data"
#开启aof机制
appendonly yes
#每秒进行一次持久化
appendfsync everysec
#追加到文件appendonly1.conf
appendfilename "appendonly1.aof"

2、开启容器，进行操作

#开启容器
docker-compose up -d
#进入容器内部
docker exec -it redis1 bash
#连接redis
redis-cli
set name zs
set age 19
set gender true

3、查看记录
同上图
4、重写，看生成的文件是否是rdb型

bgrewriteaof

在这里插入图片描述格式已经改变
5、继续写入，看新写入的格式是aof还是rdb

set city beijing

在这里插入图片描述新写入的部分是aof形式，所以aof重写后，生成的是rdb格式，继续写入命令，是aof格式，最后生成的文件是混合型。

AOF和RDB同时存储

修改redis.conf文件内容

dir "/data"
#aof
appendonly yes
appendfsync everysec
appendfilename "appendonly1.aof"
#rdb
save 10 1
save 5 2
dbfilename "dump1.rdb"

会生成对应的rdb文件和aof文件