一文读懂Redis持久化方式

Redis持久化

RDB快照

在默认状况下，Redis将内存数据库快照保存到dump.rdb的二进制文件中。
能够对Redis进行设置，让它在“N秒内数据集至少有N个改动”， 这一条件被知足时，自动保存一次数据集。好比说：让Redis知足“60秒内至少有1000个键被改动”这一个条件时，自动保存一次数据集。

save 60 1000

除了在配置文件中使用save关键字设置RDB快照，还能够在命令行中手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave能够生成dump.rdb文件。
每次执行命令都会将全部redis内存快照保存到一个rdb文件里，并覆盖原有的rdb快照文件。
save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork出一个子进程专门用来生成rdb二进制文件。

AOF（append only file）

快照功能并非很是durable，若是redis由于某些缘由而形成故障停机，那么服务器将丢失最近写入且未保存到快照中的那些数据。从1.1版本，redis增长了一种彻底durable的方式：AOF持久化，将修改的每一条指令记录进appendonly.aof中。修改配置文件来打开aof功能：

appendonly yes

打开aof功能，每当redis执行一个改变数据集的命令时，这个命令就会追加到aof文件的末尾。这样的话，当redis从新启动时，程序就会经过执行aof文件中的命令来达到重建数据集的目的。
能够配置redis多久才将命令持久化到磁盘一次。

appendfsync always：每次有新命令追加到aof文件时就执行一个持久化，很是慢可是安全
appendfsync everysec：每秒执行一次持久化，足够快（和使用rdb持久化差很少）而且在故障时只会丢失1秒钟的数据
appendfsync no：从不持久化，将数据交给操做系统来处理。redis处理命令速度加快可是不安全。

默认状况下 ，每秒执行一次fsync， 这种fsync策略能够兼顾安全性和速度。
rdb和aof的区别：

redis启动时若是既有rdb文件又有aof文件则优先选择aof文件恢复数据，由于aof文件通常来讲数据更安全一点。

2、AOF重写
aof文件里可能有太多“琐碎”指令，因此aof会按期根据内存的最新数据从新生成aof文件
有两个配置能够控制aof自动重写的频率：

auto-aof-rewrite-min-size 64mb： aof文件至少要达到64m才会触发制动重写，文件过小恢复速度原本就很快，重写的意义不大

auto-aof-rewrite-percentage 100：aof文件上一次重写后文件大小增加了100%则再次触发重写

固然aof还能够手动重写，进入redis客户端执行命令bgrewriteaof重写aof。
触发aof重写时，redis会fork一个子进程去作，不会对redis正常命令处理有太多影响。

Redis 4.0混合持久化

重启redis恢复数据集时，不多会使用rdb来恢复内存状态，由于会丢失大量数据。一般会使用aof日志恢复数据，可是重放aof日志性能相对rdb来讲要慢不少，这样在redis实例很大的状况下，启动须要花费很长时间。Redis4.0为了解决这个问题，带来了新的持久化选项——混合持久化。

aof-use-rdb-preamble yes

混合持久化aof文件结构：

若是开启了混合持久化，aof在重写时，再也不是单纯将内存数据转换为RESP命令写入aof文件，而是将重写这一刻以前的内存作rdb快照处理，而且将rdb快照内容和增量的aof修改内存数据的命令存在一块儿，都写入新的aof文件，新的aof文件一开始不叫appendonly.aof，等到重写完成后，新的aof文件才会进行更名，原子的覆盖原有的aof文件，完成新旧两个aof文件的替换。
因而在redis重启的时候，能够先加载rdb文件，而后再重放增量的aof日志就能够彻底替代以前的aof全量文件重放，所以重启效率大幅获得提升。

还没关注个人公众号？

• 扫文末二维码关注公众号【小强的进阶之路】可领取以下:
• 学习资料： 1T视频教程：涵盖Javaweb先后端教学视频、机器学习/人工智能教学视频、Linux系统教程视频、雅思考试视频教程；
• 100多本书：包含C/C++、Java、Python三门编程语言的经典必看图书、LeetCode题解大全；
• 软件工具：几乎包括你在编程道路上的可能会用到的大部分软件；
• 项目源码：20个JavaWeb项目源码。