Redis数据库RDB和AOF（redis rds aof）

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

Redis会单独创建( fork ) -个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文

件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢

复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。 RDB的缺点是最后-次持久化后的数据可能丟

失。我们默认的就是RDB,一般情况下不需要慘改这个配置!

rdb保存的文件是dump.rdb都是在我们的配置文件中快照中进行配置的!

# The filerame where to duip the DB

dbf i Lename dump. rdb

# save 900 1

# save 300 10

# save 60 10000

save 60 5 #只要60s内修改了5次key，就会触发rdb操作

# By default Redis will stop accepting writes if RDB snapshots ar

触发机制

1，save的规则满足的情况下,会自动触发rdb规则

2.执行flushall命令。也会触发我们的rdb规则!

3.退出redis,也会产生rdb文件!

备份就自动生成一个dump.rdbl

如果恢复rdb文件!

1.只需要将rdb文件放在我们redis启动目录就可以, redis启动的时候会自动检查dump.rdb恢复其中的数据!

2.查看需要存在的位置

127.0.0.1:6379> config get dir

1) "dir"

2) "/usr/1oca1/bin" #如果在这个目录下存在dump.rdb 文件，自动就会 自动恢复其中的数州

优点:

1.适合大规模的数据恢复!

2.对数据的完整性要不高!

缺点:

1.需要一定的时间间隔进程操作!如果redls意外宕机了,这个最后-次修改数据就没有的了!

2. fork进程的时候,会占用一一定的内容空间! !

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件, redis

启动之初会读取该文件重新构建数据。换言之。redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复

工作

Aof保存的是appendonly.aof文件

默认是不开启的。我们需要手动进行配置!我们只需要将appendonly改为yes就开启了aof!

重启，redis就可以生效了!

如果这个aof文件有错位,这时候redis 是启动不起来的蚂,我们需要惨复这个aof文件

优点和缺点!

appendonly no #默认是不开启aof模式的。默认是使用rdb方式持久化的。在大部分所有的情况下。rdb完 全够用:

appendfilename "appendonly.aof" # 持久化的文件的名字

# appendfsync always #每次修改都会sync.消耗性能

appendfsync everysec #每秒执行一次sync. 可能会丢失这1s的数据!

# appendfsync no #不执行sync. 这个时候操作系統自己同步数据。速度最快!

优点:

1.每一次修改都同步,文件的完整会更加好!

2.每秒同步-次,可能会丢失-秒的数据

3.从不同步,效率最高的!

缺点:

1.相对于数据文件来说。aof远远大于rdb，修复的速度也比rdb慢!

2. Aof 运行效率也要比rdb慢,所以我们redis默认的配置就是rdb持久化!

1. RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以Redis协

议追加保存每次写的操作到文件未尾, Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。