Redis 的持久化分析

Redis 的持久化有两种方式，分别是 RDB（默认），AOF两种方式。

RDB 持久化方式

当符合一定条件时，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，等到持久化过程都结束了，再用这个临时文件替换上次持久化好的文件（dump.rdb)。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

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

• 配置触发的时机

  • save 900 1 :save seconds changes (900秒内执行1次改变会触发) 
    

  • save / bgsave

  • shutdown / flushall

AOF 持久化

当对文件进行写入时，写入的内容首先会被存储到缓冲区，然后操作系统会在某个时候将缓冲区存储的内容写入硬盘。aof 文件的写入，只是针对数据变更的操作。从缓冲区写入硬盘的方式

• appendfsync : 记录日志的方式
  • appendfsync always：总是写入aof文件，并完成磁盘同步
  • appendfsync everysec：每一秒写入aof文件，并完成磁盘同步
  • appendfsync no：写入aof文件，不等待磁盘同步，由操作系统进行调度刷磁盘。

开启AOF持久化后每执行一条会更改Redis中的数据的命令后，Redis就会将该命令写入硬盘中的AOF文件。

AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是apendonly.aof。

可以在redis.conf 中的属性 appendfilename appendonlyh.aof修改

AOF 的重写原理

由于配置了AOF，当我们执行了对某个key 进行多次修改后，会看到AOF中存在了之前修改时的命令， 这样的话会导致aof 文件中的数据越来越大。另外还有一个问题是，Redis 重启后需要通过重新执行 AOF 的文件记录的所有写命令来还原数据，如果非常大那么还原数据的时间就可能非常长。 此时我们需要的是只保存最后一次的修改即可。Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合

而实际上Redis也考虑到了，可以配置一个条件，每当达到一定条件时Redis就会自动重写AOF文件，这个条件的配置是：

## 表示的是当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时AOF文件大小为依据
auto-aof-rewrite-percentage 100
## 表示限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多冗余的命令我们也并不太关心。
auto-aof-rewrite-min-size 64mb

还可以通过BGREWRITEAOF 命令手动执行AOF，执行完以后冗余的命令已经被删除了