redis的持久化机制

redis主要提供了两种持久化机制：RDB和AOF。

RDB

简介

RDB是一种在指定的间隔时间内将内存中的数据集写入磁盘的一种持久化机制，也就是我们通常所说的快照Snapshot，在恢复文件时，将快照文件直接读取到内存中。

redis默认使用的就是RDB持久化机制。

RDB是如何进行备份的？

• redis持久化的数据默认都是保存在一个dump.rdb文件中的，也就是我们所说的快照文件
  
• redis在运行的时候，会从当前父进程中fork出一个子进程，这个子进程所有的数据（变量、环境变量、程序计数器等）都和我们父进程相同。
• 这个子进程会将当前内存中的数据保存到一个临时的rbd文件中，注意，这里并不是直接的同步到我们磁盘中的dump.rdb文件，而是先同步到一个临时的rdb文件，直到本次数据同步完成时，在将这个临时的rdb文件替换掉我们磁盘中的dump.rdb文件，这样做的好处就是在我们进行一次新的数据同步的时候，不会影响到原来的那份数据。
• 这种持久化的操作全部由子进程来完成，父进程不做任何的IO操作。

RDB持久化配置

我们可以在redis.conf文件中配置RDB持久化的规则。

除了save方式，还可以使用bgsave，区别：

• save ：save 时只管保存，其它不管，全部阻塞。手动保存。不建议。
• bgsave：Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

其它配置：

• stop-writes-on-bgsave-error，开启之后，当我们持久化不能用了或者最后一次持久化的时候失败了，也就是无法写入磁盘的时候，会直接关闭掉redis的写操作，默认yes开启。
  - rdbcompression，开启之后，会将快照文件中的一些可压缩的key或value使用LZF算法进行压缩，减少文件的大小，但是压缩会消耗一定的内存，默认yes开启，如果你想最大化的利用cpu，可以设置为no关闭。
  
• rdbchecksum：检查数据完整性，在存储快照后，还可以让 redis 使用 CRC64 算法来进行数据校验， 但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以设置为no关闭。
  
• dbfilename，设置存储数据的快照文件
  

优缺点

优点：

• 最大化redis性能，在上述提到了，它的持久化操作都是由子进程来操作的，父进程不进行任何的IO操作。
• 恢复数据比较快，因为它是直接将数据保存到快照文件中的。
• 适合大规模数据的恢复。

缺点：

• fork的时候，会复制出一份临时的rdb文件，两倍的膨胀性需要考虑。
• 因为它是在一定的间隔时间去进行一次持久化机制，会造成数据丢失的情况，比如我们指定在5分钟至少一个key被修改，则进行一次持久化，那么最少间隔5分钟才进行一次持久化，如果在这几分钟之内，系统发生故障宕机了，就会丢失好几分钟的数据。

在redis.conf文件中，人家也这么说了。

• 虽然 Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

AOF

简介

将redis中每一个写操作已日志的形式记录到一个.aof文件中（只记录写，不记录读），只许追加文件，而不许改写文件，redis在启动时，会读取该文件恢复数据，换句话说，也就是将日志文件记录的操作在执行一遍。

AOF的持久化流程

• redis客户端的写命令会被append到AOF缓冲区内。
• AOF缓存区再根据我们配置的持久化策略（always，everysec，no）将操作同步到AOF文件中。
• 当AOF文件大小超过重写策略或者我们进行手动重写时，会对AOF文件进行rewrite重写，压缩AOF文件容量。
• redis重启时，会读取aof文件，重写加载aof文件中的写操作，达到数据恢复的目的。
  

使用流程

AOF持久化默认不开启。如需开启aop持久化策略，在redis.conf文件中将appendonly属性改为yes。

这个时候，你会发现redis目录中多了一个appendonly.aof文件。

配置AOF持久化策略

• everysec（默认）：每秒同步，每秒记录日志一次；
• always：每次redis的写操作都会立刻记录到日志，性能较差，但更好的保证数据完整性；
• no：redis不主动进行同步，把同步时机交给操作系统。

这也体现AOF的一个优点：最多只会丢失1秒的数据或者一次写操作的数据。

RDB和AOF同时开启，会使用哪个？

在配置文件的注释中，明确说了，如果RDB和AOF同时开启，会优先使用AOF，因为它能更好的保证持久化数据的完整性。

AOF异常备份修复

如果遇到aof文件损坏，比如我们随便在appendonly.aof文件添加几行，启动会直接报错，这种情况也可以直接使用AOF的自动修复。

这个时候，可以直接通过redis-check-aof--fix appendonly.aof命令进行修复。

AOF的优缺点

优点：

• 数据完整性高，最多只会丢失1秒的数据或者一次写操作的数据。
  缺点：
• 比起 RDB 占用更多的磁盘空间（要将每个写操作都记录，所以需要的空间更大）。
• 恢复备份速度要慢。（每次恢复都相当于重新执行日志中记录的操作）。

ReWrite 压缩

AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩， 只保留 可以恢复数据的最小指令集.可以使用命令 bgrewriteaof，例如set k1 v1,set k2 v2,set k3 v3，会被压缩成一行set k1 v1 k2 v2 k3 v3。

用哪个好？

官方推荐两个都启用。

如果对数据不敏感，可以选单独用 RDB。

不建议单独用 AOF，因为可能会出现 Bug。

如果只是做纯内存缓存，可以都不用。