Redis 持久化

1. Redis 的 两种持久化方式

RDB （Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

AOF （Append Of File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

 

 

2. RDB 

1. RDB相关配置

# save <seconds> <changes>, save n m, N 秒内 M 个键发生改变则自动保存
# 默认以下三个规则,多个规则可组合使用,满足其中一个规则,则触发bgsave
save 900 1
save 300 10
save 60 10000

# 当Redis无法写入磁盘的话,直接关掉Redis的写操作,no表明忽略错误继续写文件
stop-writes-on-bgsave-error yes

# 进行rdb保存时,将文件压缩
rdbcompression yes

# 在存储快照后使用CRC64算法进行数据校验，在写和读取文件时都开启rdb文件检查,如果启动时发现损坏,则会停止启动
# 但这样会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdbchecksum yes

# 默认文件名dump.rdb,可以修改
dbfilename dump.rdb

# 默认为Redis启动时命令行所在的目录下,可以修改为固定目录
dir ./

2. RDB的保存的文件

# 默认文件名dump.rdb,可以修改
dbfilename dump.rdb

# 默认为Redis启动时命令行所在的目录下,可以修改为固定目录
dir ./

3. RDB的保存策略

save N M。N 秒内 M 个键发生改变则自动触发bgsave。

# 默认以下三个规则,多个规则可组合使用,满足其中一个规则,则触发bgsave
save 900 1
save 300 10
save 60 10000

另外：手动保存快照 save 和 bgsave

# save命令，该命令强制redis执行快照，redis处于阻塞状态(基本不使用)
save

# 后台执行保存,redis会fork一个子进程来执行快照操作,阻塞时间较短,redis自动快照也是使用bgsave来完成的
bgsave

# 查看最近一次持久化时间
info Persistence

4. RDB的手动备份和恢复

备份

1. 查询rdb文件的目录。

config get dir

2. 将 *.rdb 的文件拷贝到其他目录。

恢复

1. 正常关闭 Redis。

2. 把备份的文件拷贝到工作目录下。

3. 启动Redis，备份数据会自动加载。

4. RDB的优点

1. 节省磁盘空间

2. 恢复速度快

5. RDB的缺点

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

2. 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

 

 

3. AOF 

1. AOF 相关配置

# AOF默认不开启，需要手动修改
appendonly no

# AOF文件的保存路径，同RDB的路径一致
appendfilename appendonly.aof

# appendfsync always / everysec / no
# 自动同步策略：每一次写操作 / 每秒 / 不自动操作,Linux刷新缓存时再保存
appendfsync everysec

# 是否开启自动保存及重写
no-appendfsync-on-rewrite no


# 当前AOF文件大小和最后一次重写后的大小之间的比率,100表示当前AOF文件是上次重写时的两倍,开启重写
auto-aof-rewrite-percentage 100
# AOF文件最小重写大小，当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb
auto-aof-rewrite-min-size 64mb

# redis如果崩溃,AOF文件出现不完整的情况,启动时是否继续加载AOF文件
# 如果为no,则需要启动前使用redis-check-aof脚本,修复AOF文件后才能启动
aof-load-truncated yes

# redis4.x 之后提供的混合持久化,同时将RDB及AOF混合写入AOF文件
# 会先加载RDB部分,然后再加载AOF部分,结合了RDB和AOF的优点,快速加载同时避免丢失过多的数据
# 但是AOF文件里的RDB部分的压缩格式不是AOF格式,可读性差。
aof-use-rdb-preamble yes

2. AOF同步频率设置

# 始终同步，每次Redis的写入都会立刻记入日志
appendfsync always

# 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync everysec

# 把不主动进行同步，把同步时机交给操作系统。
appendfsync no

3. Rewrite

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

bgrewriteaof

4. Redis 重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。

重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size，如果Redis的

AOF当前大小 >=  base_size + base_size * 100% (默认两倍) 且 AOF当前大小 >= 64mb(默认) 的情况下，Redis会对AOF进行重写。

# 当前AOF文件大小和最后一次重写后的大小之间的比率,100表示当前AOF文件是上次重写时的两倍
auto-aof-rewrite-percentage 100
# AOF文件最小重写大小，当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb
auto-aof-rewrite-min-size 64mb

5. AOF手动备份和恢复

1. AOF和RDB同时开启，系统默认取AOF的数据。

2. AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

3. AOF文件的保存路径，同RDB的路径一致。

4. 如遇到AOF文件损坏，可通过redis-check-aof进行恢复（基本不使用）。

redis-check-aof --fix appendonly.aof

6. AOF的优点

1. 备份机制更稳健，丢失数据概率更低。

2. 可读的日志文本，通过操作AOF稳健，可以处理误操作。

7. AOF的缺点

1. 比起RDB占用更多的磁盘空间。

2. 恢复备份速度要慢。

3. 每次读写都同步的话，有一定的性能压力。

 

4. RDB和AOF使用场景

1. 官方推荐两个都启用。

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

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

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