Redis 是一个开源（ BSD 许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。它支持的数据类型很丰富，如字符串、链表、集合、以及散列等，并且还支持多种排序功能。

一、什么叫持久化

将数据（内存中的）保存到可永久保存的设备中。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、 XML 数据文件中等等。

从应用层与系统层理解持久化

同时，也可以从应用层和系统层这两个层面来理解持久化：

应用层：如果关闭( Close )你的应用然后重新启动则先前的数据依然存在。

系统层：如果关闭( Shutdown )你的系统（电脑）然后重新启动则先前的数据依然存在。

二、为什么要持久化

用我个人的话说就是：redis是存在缓存中的，如果不持久化，redis服务宕机或者关闭服务后，再启动服务，数据就恢复不了了，为了能够让数据长期存在redis中，就需要持久化。

三、如何实现持久化

在设计之初，Redis 就已经考虑到了这个问题。官方提供了多种不同级别的数据持久化的方式：

1.RDB（Redis DataBase）,能够在指定的时间间隔对redis服务器的数据进行快照存储；

2.AOF（Append Only File）,记录每次对redis服务器的写操作，当服务器重启时会重新执行这些命令来恢复原始数据。AOF以redis协议追加保存写操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

3.如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。

4.也可以同时开启两种持久化方式，这种情况，redis会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

四、RDB方式与AOF方式优势对比

4.1 RDB的优点

RDB是一个非常紧凑的文件，它保存了服务器某个时间点的数据集。
RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心，非常适用于灾难恢复。
RDB在保存RDB文件时，父进程会fork一个子进程，接下来的备份工作全由子进程进行，父进程不需要再做其他的IO操作，所以RDB持久化方式可以最大化redis的性能。
与AOF相比，在恢复大的数据集的时候，RDB速度会快些。

当RDB需要保存dump.rdb文件时，服务器工作工程：

redis调用forks，同时拥有父进程和子进程
子进程将数据写到一个临时的rdb文件
当子进程完成对新rdb文件的写入时，redis用新的rdb文件代替旧的rdb文件，并删除旧的rdb文件

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

4.2 AOF的优点

使用AOF可以使数据保存的更全面

你可以使用不同的 fsync 策略：无fsync，每秒fsync，每次fsync。默认fsync是每秒fsync，使用这种策略Redis性能依然很好（fsync是使用后台线程进行处理的，主线程会尽力处理客户端请求），一旦出现故障，最多丢失1秒的数据。
AOF是一个只进行追加的日志文件，即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也可使用redis-check-aof工具修复这些问题。
Redis可以在AOF文件体积变得过大时，自动的在后台对AOF文件进行重写：重写后的AOF文件包含了恢复当前数据集所需要的最小命令集合。整个重写操作是绝对安全的，因为在创建新的AOF文件的过程中，会继续将命令追加到现有的AOF里面，即使在重写过程中redis发生了停机，也不会覆盖现有的AOF文件。而一旦新的AOF文件创建完成，就会替代旧的AOF文件，并在新的AOF文件中进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

    正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复。

AOF重写：1、redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。比如对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就可以顶之前的100局调用，AOF重写功能就是干这个事情的。重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。2、重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（太大了）。最后替换旧的aof文件3、重写触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

AOF工作过程：

Redis 执行 fork() ，现在同时拥有父进程和子进程。
子进程开始将新 AOF 文件的内容写入到临时文件。
对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

4.3 优缺点对比总结

RDB是保存某个时间段的数据，并且保存的是单一文件，可以将文件备份到其他服务器，在恢复大量数据时，RDB要比AOF要快。

AOF 方式默认每秒钟备份1次，频率很高，它的操作方式是以追加的方式记录日志而不是数据，并且它的重写过程是按顺序进行追加，所以它的文件内容非常容易读懂。可以在某些需要的时候打开 AOF 文件对其编辑，增加或删除某些记录，最后再执行恢复操作。

五、RDB方式与AOF方式缺点对比

5.1 RDB方式的缺点

如果你希望服务中断时，保存最多的数据，RDB不适合你，虽然你可以配置不同的save时间点(例如每隔 5 分钟并且对数据集有 100 个写的操作），但是万一在 Redis 意外宕机,你可能会丢失几分钟的数据。
RDB需要经常需要fork子进程来保存数据到硬盘，当数据量大的时候，fork过程是非常耗时的，可能导致redis不能毫秒级响应客户端。如果数据集巨大并且 CPU 性能不是很好的情况下,这种情况会持续1秒, AOF重写也需要 fork ,但是你可以调节重写日志文件的频率来提高数据集的耐久度。

5.2 AOF方式的缺点

对于相同数据集来说，AOF文件体积通常要大于RDB文件
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB速度更快。

5.3 缺点对比总结

RDB 由于备份频率不高，所以在回复数据的时候有可能丢失一小段时间的数据，而且在数据集比较大的时候有可能对毫秒级的请求产生影响。

AOF 的文件提及比较大，而且由于保存频率很高，所以整体的速度会比 RDB 慢一些，但是性能依旧很高。

六、RDB与AOF的实现

6.1 RDB 方式持久化的开启与配置

Redis 默认的持久化方式是 RDB ，并且默认是打开的。RDB 的保存有方式分为主动保存与被动保存。主动保存可以在 redis-cli 中输入 save 即可；被动保存需要满足配置文件中设定的触发条件，目前官方默认的触发条件可以在 redis.conf 中看到：

save 900 1
save 300 10
save 60 10000

其含义为：

服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改。
服务器在60秒之内，对数据库进行了至少10000次修改。

满足触发条件后，数据就会被保存为快照，正是因为这样才说 RDB 的数据完整性是比不上 AOF 的。

触发保存条件后，会在指定的目录生成一个名为 dump.rdb 的文件，等到下一次启动 Redis 时，Redis 会去读取该目录下的 dump.rdb 文件，将里面的数据恢复到 Redis。

这个目录在哪？

如下图是我本机运行redis后产生的dump.rdb文件所在目录：

所以dump.rdb在redis安装根路径下。

6.1.1 RDB 被动触发保存测试

我将配置改成每10秒修改一次则触发

save 10 1
save 300 10
save 60 10000

客户端输入:

服务端出现日志：

且redis根路劲下dump.rdb文件更新：

证明被动保存生效。

现在将redis进程kill（window版直接关掉服务界面窗口），哪些数据会被保存？
不会触发save命令。

6.1.2 shutdown 保存

shutdown命令也是可以触发保存数据的。

6.2 AOF 方式持久化的开启与配置

1、redis 默认关闭，开启需要手动把no改为yes配置：appendonly yes
2、指定本地数据库文件名，默认值为 appendonly.aof配置：appendfilename "appendonly.aof"
3、指定更新日志条件配置：# appendfsync always appendfsync everysec（默认值）# appendfsync no配置说明：always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）everysec：出厂默认推荐，每秒异步记录一次（默认值）no：不同步
4、配置重写触发机制配置：auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb配置说明：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

Redis的持久化机制：RDB和AOF相关推荐

redis的持久化方式RDB和AOF的区别
https://blog.csdn.net/m0_38110132/article/details/76906422 博客学院下载图文课论坛 APP 问答商城 VIP会员活动招聘 ITe ...
redis缓存架构-02-两种持久化机制(RDB和AOF)
1.两种持久化机制的介绍 1.1 RDB 周期性的生成redis内存数据的一份完整的快照 1)根据配置的检查点,生产rdb快照文件,fork一个子线程,将数据dump到rdb快照文件中,完成rdb文件 ...
16. Redis 持久化机制-RDB与AOF
Redis 是一款基于内存的Nosql 数据库, 提供高速存取服务,通常会被用做高速缓存中间件.但是,Redis 除了将数据库存储在内存,也可以将数据存储在磁盘. Redis 提供了两种持久化方式: ...
Redis的持久化机制-RDB方式和AOF方式
场景 Redis的持久化策略持久化可以理解为存储,就是将数据存储到一个不会丢失的地方. 如果把数据存储在内存中,电脑关闭或者重启数据就会丢失,所以放在内存中的数据不是持久化的,而放在磁盘中就算是一种 ...
Redis的两种持久化机制RDB和AOF
目录 RDB 原理触发时机 AOF 原理开启AOF aof日志文件说明触发时机 aof的重写机制 redis4.0的混合持久化机制总结 rdb持久化文件的名称:dump.rdb.存储在配置文件 ...
Redis中两种持久化机制RDB和AOF
redis是一个内存数据库,数据保存在内存中,但是我们都知道内存的数据变化是很快的,也容易发生丢失.幸好Redis还为我们提供了持久化的机制,分别是RDB(Redis DataBase)和AOF(Ap ...
Redis持久化机制 RDB、AOF
目录一.RDB(Redis DataBase) 1.配置快照资格,在redis.conf文件中 2.如何触发RDB快照 3.执行flushall命令 4.快照的实现原理 5.优势与劣势 6.如何恢复 ...
redis的持久化（RDB与AOF）未完待续
1.为什么redis要实现持久化? 避免因宕机.断电等场景导致进程退出后数据丢失,如果redis的数据都只存放于内存,那么进程退出后数据就丢失了.持久化机制可以持久化内存数据到硬盘,重启redis后基 ...
Redis之持久化机制和实现原理
1.Redis 持久化的意义 redis的数据全部在内存中,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证redis的数据在发生突发状况时不会丢失.或者只丢失少量,于是必须根据一些策略来把r ...
redis rdb aof区别_理解Redis的持久化机制：RDB和AOF
什么是Redis持久化? Redis作为一个键值对内存数据库(NoSQL),数据都存储在内存当中,在处理客户端请求时,所有操作都在内存当中进行,如下所示: 这样做有什么问题呢? 注意文末有:362 ...

Redis的持久化机制：RDB和AOF