save
:指定了保存RDB的策略,默认的配置是每900秒(15分钟)至少有一个键发生变化时保存一次RDB文件。save 900 1
:表示在900秒内至少发生1个变化时进行保存。save 300 10
:表示在300秒内至少发生10个变化时进行保存。save 60 10000
:表示在60秒内至少发生10000个变化时进行保存。dbfilename
:指定保存RDB文件的文件名,默认是dump.rdb
。dir
:指定RDB文件保存的目录,默认是Redis服务器所在的目录。appendonly
:指定是否启用AOF,默认值为no
。如果要启用AOF持久化,需要将该选项设置为yes
。appendfilename
:指定保存AOF文件的文件名,默认是appendonly.aof
。appendfsync
:指定AOF文件的同步策略,有以下三个选项:
always
:每个写操作都立即同步到磁盘。这样能确保数据的完整性,但写入性能较低。everysec
:每秒同步一次,Redis默认的配置。在发生故障时可能会丢失1秒的数据。no
:完全依赖操作系统来同步,写入性能较高,但可能会丢失多秒的数据。auto-aof-rewrite-percentage
:设置AOF文件重写的触发百分比,默认为100。当AOF文件的大小超过了上一次重写时的大小的指定百分比时,Redis会自动触发AOF文件的重写。auto-aof-rewrite-min-size
:设置AOF文件重写的最小大小,默认为64MB。当AOF文件的大小超过了这个值时,Redis会自动触发AOF文件的重写。区别:
RDB:Redis Databases
在指定时间间隔后,将内存中的数据集快照写入数据库 ;在恢复时候,直接读取快照文件,进行数据的恢复 ;
在进行 RDB 的时候,redis 的主线程是不会做 io 操作的,主线程会 fork 一个子线程来完成该操作;
? 1.Redis 调用forks。同时拥有父进程和子进程。
? 2.子进程将数据集写入到一个临时 RDB 文件中。
? 3.当子进程完成对新 RDB 文件的写入时,Redis 用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制(copy-on-write)机制中获益(因为是使用子进程进行写操作,而父进程依然可以接收来自客户端的请求。)
①修改配置文件中,有关生成写入rdb文件的说明
②测试1:先删除rdb文件,再出发rdb文件的创建机制
保存一下配置文件的修改
save可以使内存中的数据,立刻持久化,并阻塞其他进程
重新生成rdb文件
③测试2:重启redis,内存中的数据,还在rdb中
④测试3:删除rdb文件,flushall后,自动生成rdb文件
使用 save
命令,会立刻对当前内存中的数据进行持久化 ,但是会阻塞,也就是不接受其他操作了;
由于
save
命令是同步命令,会占用Redis的主进程。若Redis数据非常多时,save
命令执行速度会非常慢,阻塞所有客户端的请求。
flushall
命令也会触发持久化 ;
满足配置条件中的触发条件 ;
可以通过配置文件对 Redis 进行设置, 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动进行数据集保存操作。
bgsave
是异步进行,进行持久化的时候,redis
还可以将继续响应客户端请求 ;
bgsave和save对比
命令 | save | bgsave |
---|---|---|
IO类型 | 同步 | 异步 |
阻塞? | 是 | 是(阻塞发生在fock(),通常非常快) |
复杂度 | O(n) | O(n) |
优点 | 不会消耗额外的内存 | 不阻塞客户端命令 |
缺点 | 阻塞客户端命令 | 需要fock子进程,消耗内存 |
AOF几乎不使用,但是得理解原理
redis-check-aof:恢复原来的aof文件,但是会删除错误数据
破坏aof文件后,连接报错
修复aof文件:redis-check-aof --fix appendonly.aof
正常进入redis