Redis的持久化

持久化过程保存：

1.RDB 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

2.AOF 将数据的操作过程进行保存，日志形式，存储操作过程（指令），关注点在数据的操作过程

一、RDB方式

1.1 概念

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

1.2 RDB手动指令

save 手动执行一次保存

save的相关配置

• dbfilename dump.rdb         设置本地数据库文件名，默认为dump.rdb，可设置为dump-端口号.rdb

• dir         设置存储rdb文件的路径

• rdbcompression yes         设置存储在本地数据库时是否压缩数据，默认yes，采用LZF算法压缩；若设置为no，可节省CPU运行时间，但会使存储的文件变大。

• rdbchecksum yes         设置是否进行CRC64算法RDB文件格式校验，该校验过程在写文件和读文件过程均进行；若设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

save的工作原理：单线程任务执行序列

save指令的执行会阻塞当前Redis服务器，指导当前RDB过程完成为止，有可能会造成长时间阻塞

bgsave 手动启动后台保存操作，但不是立即执行

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

Fork         复制一个与当前进程一样的进程。

新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

1.3 RDB自动指令

save second changes 在满足限定时间范围内（second）key的变化数量达到指定数量（changes）即可以进行持久化

位置：在conf文件中进行配置

注意：

• save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
• save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
• save配置启动后执行的是bgsave操作

save 900 1

若在900秒内修改1次则进行持久化操作

1.4 RDB优点

• RDB是一个紧凑压缩的二进制文件，存储效率较高RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多
• RDB节省磁盘空间

1.5 RDB缺点

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。虽然Redis在fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能
• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

二、AOF方式

2.1 概念

以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的；

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

2.2 AOF执行过程

• 客户端的请求写命令会被append追加到AOF缓冲区内；
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
• AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
• Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2.3 AOF写数据三种策略(appendfsync)

• always(每次）

每次写入操作均同步到AOF文件中，数据零误差，性能较低

• everysec（每秒）

每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高

在系统突然宕机的情况下丢失1秒内的数据

• no（系统控制）

由操作系统控制每次同步到AOF文件的周期，整体过程不可控

2.4 AOF相关配置

• appendonly yes|no         是否开启AOF持久化功能，默认为不开启状态

• appendfsync always|everysec|no         AOF写数据策略

• appendfilename filename         AOF持久化文件名，默认为appendonly.aof，建议配置为appendonly-端口号.aof

• dir         AOF持久化文件保存路径，与RDB持久化文件保持一致即可

2.4 AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

• 降低磁盘占用量，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高IO性能
• 降低数据恢复用时，提高数据恢复效率

AOF重写规则

• 进程内已超时的数据不再写入文件；
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令，如del key1、set num 3等 ；
• 对同一数据的多条写命令合并为一条命令，如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
• 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
• AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF重写方式

bgrewriteaof         手动重写

自动重写

触发机制，何时重写

• Redis会记录上次重写时的AOF大小，默认配置是：当AOF文件大小是上次重写后大小的一倍且文件大于64M时触发；
• 重写虽然可以节约大量磁盘空间，减少恢复时间，但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-min-size         设置重写的基准值，最小文件64MB。达到这个值开始重写。

auto-aof-rewrite-percentage         设置重写的基准值,文件达到100%时开始重写（文件是原

来重写后文件的2倍时触发）

3.RDB和AOF的区别

持久化方式	RDB	AOF
占用存储空间	小（数据级；压缩）	大（指令级；重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略决定
资源消耗	高（重量级）	低（轻量级）
启动优先级	低	高

总结：

官方推荐两个都启用，如果对数据不敏感，可以选单独用RDB，不建议单独用 AOF，因为可能会出现Bug 。

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