Redis 持久化

一、RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件，使持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失

保存的文件名字是dump.rdb

RDB 的优缺点（引用自）

优点：

1. 适合大规模的数据恢复。
2. 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

配置文件：

1. save 60 5 60秒内如果修改5次及以上就会触发一次持久化操作
2. 执行flushall命令也会触发
3. 退出redis也会触发

当用docker创建的redis，dump文件会保存在

docker run --name myredis -p 6379:6379
-v /usr/local/redis/redis.conf:/etc/redis/redis.conf
-v /root/usr/local/redis/data:/data -d redis:6.0.9redis-server /etc/redis/redis.conf
红色字体部分处

如何恢复？

1.只需要将rdb文件放在redis启动目录即可
2.查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/data"

缺点：

1. 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2. 备份时占用内存，因为Redis
   在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以要考虑到大概两倍的数据膨胀性。

二、AOF（Append Only File）

如何开启？

appendonly yes

以日志形式 来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取改文件重新构造数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次完成数据的恢复工作

Aof保存文件名字叫做appendonly.aof文件

配置文件：

appendfsync :

• everysec 每一秒写入临时aof文件，并完成磁盘同步
• always 总是写入临时aof文件，并完成磁盘同步
• no 写入临时aof文件，不等待磁盘同步，让操作系统自己同步。

从持久化角度讲，always是最安全的。从效率上讲，no是最快的

no-appendfsync-on-rewrite no (默认是no)

引用一段理解:

bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。

现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。

因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。(引用)
重写后的AOF文件为什么可以变小？有如下原因：

1. 进程内已经超时的数据不再写入文件。
2. 旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set
   a222等。重写使用进程内数据直接生成，这样新的AOF文件只保
   留最终数据的写入命令。
3. 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush
   list a b c。为了防止单条命令过大造成客户端缓冲区溢
   出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF 文件可以更快地被Redis加载

auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。

auto-aof-rewrite-percentage：代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。