Redis持久化

使用Redis作为数据缓存，缓存的目标主要是那些需要经常访问的数据，或计算复杂而耗时的数据。缓存的效果就是减少了数据库读的次数，减少了复杂数据的计算次数，从而提高了服务器的性能。

Redis的持久化有两种方式：RDB和AOF，redis默认采用的是RDB的方式。

RDB (Redis DataBase)

RDB是一种快照式的持久化方法。

在默认配置中，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。

可以配置持久化策略：save N M，让redis在“N秒内至少有M个改动”才会触发一次rdb持久化操作。
例如redis的默认策略有：

还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，
每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

RDB的写入流程：

1.redis执行bgsave命令，Redis判断当前存在正在进行执行的子进程，如RDB/AOF子进程，存在bgsave命令直接返回
2.fork出子进程，fork操作中Redis父进程会阻塞
3.fork完成返回　　59117:M 13 Apr 13:44:40.312 * Background saving started by pid 59180
4.子进程进程对内存数据生成快照文件
5.子进程告诉父进程处理完成

bgsave写时复制的（COW）机制

Redis借助了linux系统的写时复制（Copy-On-Write）技术，在生成快照的同时，仍然可以接收命令处理数据。简单来说，bgsave进程是由主进程fork生成的子进程，可以共享进程程所有的内存数据。bgsave进程中的线程运行后，开始读取主进程的内存数据，也就是redis的内存数据，将内存数据写入到dump.rdb文件中。此时，如果主进程处理的命令都是读操作，则bgsave线程不受影响。如果主进程处理了写操作，则会对该命令操作的数据复制一份，生成副本，bgsave进程中的线程会把这个副本写入到dump.rdb文件中，而在这个过程中，主进程仍可执行命令。

save与bgsave对比：

配置自动生成rdb文件后台默认使用的是bgsave方式。

RDB特点：

1、RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

2、redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。

3、对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。

4、如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB优缺点

优点：

• 因为dump.rdb文件是二进制文件，所以当redis服务崩溃恢复的时候，能很快的将文件数据恢复到内存之中。

缺点：

• RDB每次持久化需要将所有内存数据写入文件，然后替换原有文件，当内存数据量很大的时候，频繁的生成快照会很耗性能。
• 如果将生成快照的策略设置的时间间隔很大，会导致redis宕机的时候丢失过的的数据。

AOF(Append Only File)

为解决RDB方式丢失数据的问题，从1.1版本开始，redis增加了一种更加可靠的方式：AOF持久化方式。
在使用AOF方式时，redis每执行一次修改数据命令，都会将该命令追加到appendonly.aof文件中（先写入os cache，然后通过fsync刷盘）。

在默认配置中，默认是不开启AOF，默认写入文件是appendonly.aof，AOF写入的是执行的命令

redis重启的时候，会重放appendonly.aof中的命令恢复数据。

AOF三种刷盘策略

默认开启everysec

# appendfsync always:每次执行写命令都会刷盘，非常慢，也非常安全。
appendfsync everysec:每秒刷盘一次，兼顾性能和安全。
# appendfsync no:将刷盘操作交给系统，很快，不安全。

推荐使用everysec，该策略下，最多会丢1秒的数据。

AOF重写

因为appendonly.aof文件中存储的是执行命令，所以会产生很多没用的命令，因此，redis会定期根据最新的内存数据生成新的aof文件。
如下两个配置可以控制aop文件重写的频率：

auto-aof-rewrite-percentage 100 # 距离上次重写增长了100%才会再次触发重写
auto-aof-rewrite-min-size 64mb # aof文件至少达到了64m才会触发重写

AOF也可以手动触发重写：bgrewriteof
注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多
影响

RDB与AOF对比

生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof
一般来说数据更全一点。

AOF写入的流程如下：

1）所有的写入命令会追加到aof_buf（缓冲区）中
2）AOF缓冲区根据对应的策略向磁盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）当redis服务器重启时，可以加载AOF文件进行数据恢复。

Redis 4.0混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重
放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很
长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
aof-use-rdb-preamble yes