Rides 持久化

Rides有两种持久化机制：

一、RDB（把当前数据生成快照保存到硬盘上）

RDB的持久化可以手动触发也可以自动触发

1.手动触发：

使用save或者bgsave命令可以手动触发持久化，但是使用save命令会阻塞rides线程，会对rides效率产生一些影响。使用bgsave命令一般不会阻塞线程，因为rides会执行fork操作创建一个子进程，将持久化的操作交给子进程，rides的阻塞只会发生在执行fork操作时，一般情况下时间很短。具体流程如下:

1.执行ogsave命令，Redisi进程先判断当前是否存在
正在执行的RDB或AOF子线程，如果存在就是直
接结束。
2.Redisi进程执行fork操作创建子线程，在fork操作
的过程中Redis进程会被阻塞。
3.Redisi进程fork完成后，bgsave命令就结束了，自
此Redis进程不会被阻塞，可以响应其他命令。
4.子进程根据Redisi进程的内存生成快照文件，并
替换原有的RDB文件。
5.子进程通过信号量通知Redisi进程已完成。

2.自动触发：

1.在配置文件中设置了save的相关配置，如sava m
n,它表示在m秒内数据被修改过次时，自动轴
发bg3ave操作。
2.当从节点做全量复制时，主节点会自动执行
bg3ave操作，并且把生成的RDB文件发送给从节
点。
3.执行debug reloadi命令时，也会自动触发bg3ave
操作。
4.执行shutdown命令时，如果没有开启AOF持久化
也会自动触发bgsavef操作。

3.优缺点

RDB文件是一个紧凑的二进制压缩文件，是Redis在某个时间点的全部数据快照。所以使用RDB恢复数据的速度远远比AOF的快，非常适合备份、全量复制、灾难恢复等场景。但是每次进ogsave操作都要执行fork操作创建子经常，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化，或者秒级持久化。另外，由于Redis版本的不断迭代，存在不同格式的RDB版本，有可能出现低版本的RDB格式无法兼容高版本RDB文件的问题。

二、AOF（记录每次对数据的操作到硬盘上）

1.持久化流程

1.命令追加(append)：所有写命令都会被追加到AOF缓存区(aof buf)中。
2.文件同步(sync)：根据不同策略将AOF缓存区同步到AOF文件中。
3.文件重写(rewrite):定期对AOF文件进行重写，以达到压缩的目的。
4.数据加载(1oad)：当需要恢复数据时，重新执行AOF文件中的命令。

2.文件同步策略

AOF持久化流程中的文件同步有以下几个策略：
1.awys:每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Reds高并发，不建议配置。
2.n0:每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件
的周期不可控，而且增大了每次同步的硬盘的数据量。
3.eversec:每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建
议的同步策略，也是默认的策略。

3.触发文件重写

1.手动触发：使用bgrewriteao:命令。
2.自动触发：根据auto-aof-rewrite--min-size和auto-aof-rewrite-percentage配置确定自动触发的时机.auto-aof-rewrite-min-size表示运行AOF重写时文件大小的最小值，默认为64MB;auto-aof
rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为
100。只用前两者同时超过时才会自动触发文件重写。

4.AOF持久化配置

AOF持久化默认是不开启的，需要修改配置文件，如：

# appendonly改为yes，开启AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 运行AOF重写时AOF文件大小的增长率的最小值
auto-aof-rewrite-percentage 100
# 运行AOF重写时文件大小的最小值
auto-aof-rewrite-min-size 64mb