Redis 之 RDB 和AOF两种机制

redis提供两种持久化策略 rdb 和 aof

rdb：redis database

• rdb持久化方式能够在指定的时间间隔中对你的数据进行快照存储。
• 在默认情况下，redis将数据库快照保存在名字为dump.rdb的二进制文件中。
• 在redis运行时，rdb程序将当前内存中的数据库快照保存到磁盘文件中，在redis重新启动时，rob程序可以通过载入rdb文件来还原数据库的状态。

---

工作方式
当redis需要保存dump.rdb文件时。服务器执行以下操作：

1. redis调用forks。同时拥有父进程和子进程。
2. 子进程将数据集写入到一个临时rdb文件中。
3. 当子进程完成对新rdb文件的写入时，redis用新rdb文件替换原来的rdb文件，并删除旧的rdb文件。
   这种工作方式使得redis可以从写时复制(copy-on-write)机制中获益。

即 redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程时不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那rdb方式要比aof方式更加高效。rdb缺点时最后依次持久化的数据可能丢失。

redis的配置文件中已经配置的有文件备份的设置。

满足上面三个条件之一，那么会触发后台操作，在硬盘中生成一个dump.rdb文件，临时存储文件。
关机后，redis中的所有数据消失。redis重启后，会自动读取dump.rdb文件，把rdb中的所有数据读入到内存。

执行命令时，可直接save，立即生成到dump.rdb文件中做备份。

rdb缺点：宕机时候有可能会损失一个时间片的数据。
例如：每隔2分钟做一个备份，有可能刚要备份 宕机了，则损失2分钟的数据。即后2分钟数据没有备份到rdb中。

---

aof ：append only file

• aof：redis默认不开启。它的出现是为了弥补rdb的不足(数据的不一致性)，所以它采用日志的形式来记录每个写操作，并追加到文件中。redis重启的时候会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

需要去开启
进入到redis.conf文件中，找到 APPEND ONLY MODE
将no改为yes，然后重启会发现appendonly.aof文件


那么，为了验证aof文件起作用，可以删除rdb文件。
也可不删，aof和rdb可同时存在，但是启动时候先找的是aof文件。

执行操作：
执行操作 set 然后 查看aof文件，会记录命令

但是此时 客户端中没有数据，因为flushall命令，要把此命令删除掉，进入aof删除flushall命令即可

重启redis，查看到有数据，因为flushall是清空缓存

那么，还有一个就是修复aof文件，例如手动修改aof 随意添加内容

执行 src/redis-check-aof --fix appendonly.aof 命令

aof文件采用文件追加的形式，文件会越来越大，为了避免出现这种情况，新增了重写机制，当aof文件超过设定的阈值的时候，redis就会启用aof文件的内容压缩，只保留可以恢复数据的最小指令，可以使用bgrewriteaof
redis会记录上次重写的时候的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64MB的时候触发。

---

总结：

• redis默认开启rdb持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。因为查操作 不影响数据库中数据。

• rdb持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

• redis需要手动开启aof持久化方式，默认是每秒将写操作日志追加到aof文件中。

• aof的数据完整性比rdb高，但记录内容多了，会影响数据恢复的效率。

• redis针对aof文件大的问题，提供重写的瘦身机制。

• 若只打算用redis做缓存，可以关闭持久化。

• 若打算使用redis的持久化，建议rdb和aof都开启。其实rdb更适合做数据的备份，留一后手，aof出问题时，还有rdb。