Redis持久化

redis持久化主要分为RDB 和AOF 两种

1. RDB（快照模式）

        在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中，对应配置文件中的save, 这三个配置只要满足任意的一种就会触发dump.rdb文件的保存，可以理解为 “N 秒内数据集至少有 M 个改动”, 例如默认配置中 900秒有一次修改内容的操作就会自动保存一次。

 也可以使用手动保存，首先连接到客户端，输入save 或者 bgsave, 这里保存是将内存中的数据新的dump.rdb文件中，并且覆盖原有的文件，即每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

bgsave的写时复制(COW)机制

Redis 借助操作系统提供的写时复制技术（Copy-On-Write, COW），在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

2. AOF

 RDB 模式不是实时的将内存中的数据进行持久化，因此服务器出现故障、停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。AOF 就是为了弥补这种缺陷而产生的。AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘) 

AOF 打开的配置文件为：   appendonly yes， 重启redis 之后就会产生一个appendonly.aof的文件，打开文件内容如下

这是一种resp协议格式数据，星号后面的数字代表命令有多少个参数，$号后面的数字代表这个参数有几个字符

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

有三个选项：

1. appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。

2. appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。

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

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

AOF重写

AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件

例如， 将一个key 设置了多次，那么重写的时候就只记录最后一次即可。

如下两个配置可以控制AOF自动重写频率

1. auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大

2. auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写

 

当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF

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