突击Redis数据库(五) Redis的持久化之RDB与AOF

一. 持久化

Redis 主要是工作在内存中。
内存本身就不是一个持久化设备，断电后数据会清空。所以 Redis 在工作过程中，如果发生了意外停电事故，如何尽可能减少数据丢失。

二. RDB (Redis DataBase)

1. RDB 简介：

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

工作机制：每隔一段时间，就把内存中的数据保存到硬盘上的指定文件中。
RDB 是默认开启的！

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

RDB 的缺点是最后一次持久化后的数据可能丢失。

2. RDB 保存策略：

3. RDB 常用属性配置：

4. RDB 数据丢失的情况：

两次保存的时间间隔内，服务器宕机，或者发生断电问题。

5. RDB 的触发：

6. RDB 的优缺点：

三. AOF (Appen Only File)

1. AOF 简介：

AOF 是以日志的形式来记录每个写操作，将每一次对数据进行修改，都把新建、修改数据的命令保存到指定文件中(appendonly.aof)。
Redis 重新启动时读取这个文件(appendonly.aof)，重新执行新建、修改数据的命令恢复数据。

默认不开启，需要手动开启。

AOF 文件的保存路径，同 RDB 的路径一致。

AOF在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！

当 RDB和 AOF存的不一致的情况下，按照 AOF来恢复。因为 AOF是对 RDB的补充。备份周期更短，也就更可靠。

2. AOF 保存策略：

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即 1 秒钟的数据）。

appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

3. AOF 常用属性：

4. AOF 文件的修复：

如果 AOF 文件中出现了残余命令，会导致服务器无法重启。此时需要借助 redis-check-aof 工具来修复！
命令： redis-check-aof  --fix 文件

5. AOF 的优缺点：

优点：

备份机制更稳健，丢失数据概率更低
可读的日志文本，通过操作 AOF 稳健，可以处理误操作

缺点：

比起 RDB 占用更多的磁盘空间
恢复备份速度要慢
每次读写都同步的话，有一定的性能压力
存在个别 Bug，造成恢复不能

四. 备份建议

1. 如何看待数据“绝对”安全

2. 官方建议：

总结：如果对数据不敏感，可以选单独用 RDB；不建议单独用 AOF，因为可能出现 Bug;如果只是做纯内存缓存，可以都不用。