Redis持久化方式

1 RDB

RDB(Snapshot 内存快照) 。RDB是默认的持久化方式，按照一定的策略周期性的将内存中的数据生成快照保存到磁盘。

每次快照持久化都是将内存数据完整写入到磁盘一次。并不是增量，如果数据量过大，会引起大量的磁盘IO，影响性能

1.1 触发机制

1.save 命令

当客户端向Redis
server发送save命令请求进行持久化时，由于Redis是用一个主线程来处理所有,save命令会阻塞Redis
server处理其他客户端的请求，直到数据同步完成。

2. bgsave命令
   与save命令不同，bgsave是异步执行的，当执行bgsave命令之后，Redis主进程会fork 一个子进程将数据保存到rdb文件中，同步完数据之后，对原有文件进行替换，然后通知主进程表示同步完成。

3.自动触发
除了手动触发RDB持久化，Redis内部还存在自动触发机制，
在配置中集中配置 save m n 的方式，表示 m秒内数据集存在n次修改时，系统自动触发bgsave 操作。

#save 900 1
#save 300 10
#save 60 10000
1
2
3

1.2 关闭RDB持久化

关闭RDB只需要将所有的save保存策略注释掉，然后重启redis服务即可。

1. 注释掉原来的持久化规则

#save 900 1
#save 300 10
#save 60 10000
1
2
3

1. 设置为空
   save ""
   重点：此时你会发现按上述说明配置了，但持久化依然存在。
   如果是中途关闭RDB持久化，还需要删除已经生成的文件dump.rdb。在redis.conf中还有个dir配置，就是持久化的磁盘文件存放的目录，打开相应的目录，删除目录中的*.rdb文件。

1.3 相关参数

# 持久化 rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes
# 在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。
rdbcompression yes
# 配置 redis 是否使用 CRC64 校验算法校验 RDB 文件是否发生损坏,默认开启状态,如果你需要提升性能,可以选择性关闭
rdbchecksum yes
# 生成的快照的文件名
dbfilename dump.rdb
# 存放快照的目录
dir ./
1
2
3
4
5
6
7
8
9
10

1.4 优缺点

优点：
1. RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份。文件恢复速度快。
缺点：
1. 可能会有部分数据丢失
2. 持久化要全量刷内存到磁盘，成本太高
3. redis不通版本间的RDB文件不兼容

2 AOF

AOF(Append-only file)针对RDB的缺点做了优化，在使用AOF持久化方式时，Redis会将每一个收到的写操作命令都通过Write函数追加到文件最后。当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

2.1 持久化过程

1. 客户端发出 bgrewriteaof重写命令。
2. redis主进程fork子进程。
3. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的命令缓存到 AOF重写缓冲区。这样就能保证如果子进程重写失败的话并不会出问题。
4. 子进程按照命令合并规则写入到新AOF文件中。
5. 当子进程完成 AOF 重写之后，它会向父进程发送一个完成信号。将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
6. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

2.2 相关命令

# 是否开启AOF，默认关闭
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种刷写模式：
#客户端对redis服务器的每次写操作都写入AOF日志文件。但该模式下速度也是最慢的，一般不推荐使用.
# appendfsync always。
#每秒刷新一次缓冲区中的数据到AOF文件，在性能和持久化方面做平衡，推荐该方式。每隔一秒钟启动一个后台任务，用于异步地将文件通过fsync写入磁盘
appendfsync everysec 
#完全依赖操作系统写入，时机不确定，性能最好但是持久化最没有保证，不推荐。
# appendfsync no    
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
# 同时满足下面两个指标的时候才会发生重写。
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

三种写回命令：

1. Redis 执行完写操作命令后，会将命令追加到 server.aof_buf 缓冲区；
2. 然后通过 write() 系统调用，将 aof_buf 缓冲区的数据写入到 AOF 文件，此时数据并没有写入到硬盘，而是拷贝到了内核缓冲区 page cache，等待内核将数据写入硬盘；
   具体内核缓冲区的数据什么时候写入到硬盘，由内核决定。

2.3 重写

假如 对一个变量做了10次 +1，aof 文件中存在的命令就是10条，重写之后变成一条+10 ，减小文件大小。重写之后不可以恢复，加入执行了FLUSHALL 命令，在没发生重写是可以恢复的。

2.4 触发时机

1. 满足配置文件中的配置自动触发（见上面相关命令中的配置）
2. 手动执行bgrewriteaof命令触发

2.5 优缺点

AOF 优点

1. 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
2. Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。

AOF 缺点

1. 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
2. 恢复速度相对RDB慢。

3. 混合持久化模式

集合RDB和AOF的优点，文件的命名还是 .aof ，不过数据结构是RDB和AOF的组合。

3.1 相关命令

# 开启混合模式。重写时机和aof一样
aof-use-rdb-preamble yes
1
2