redis持久化rdb和aof区别,redis中持久化策略rdb和aof的区别

redis持久化rdb和aof区别,redis中持久化策略rdb和aof的区别详细介绍

本文目录一览： redis的 rdb 和 aof 持久化的区别

aof，rdb是两种 Redis持久化的机制。用于crash后，redis的恢复。
rdb的特性如下：
Code:
fork一个进程，遍历hash table，利用copy on write，把整个db dump保存下来。
save, shutdown, slave 命令会触发这个操作。
粒度比较大，如果save, shutdown, slave 之前crash了，则中间的操作没办法恢复。
aof有如下特性：
Code:
把写操作指令，持续的写到一个类似日志文件里。（类似于从postgresql等数据库导出sql一样，只记录写操作）
粒度较小，crash之后，只有crash之前没有来得及做日志的操作没办法恢复。
两种区别就是，一个是持续的用日志记录写操作，crash后利用日志恢复；一个是平时写操作的时候不触发写，只有手动提交save命令，或者是关闭命令时，才触发备份操作。
选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

Redis的持久化机制 (RDB&AOF&混合模式)

RDB（Redis DataBase，快照方式） 是将某一个时刻的内存数据，以二进制的方式写入磁盘。 AOF（Append Only File，文件追加方式） 是指将所有的操作命令，以文本的形式追加到文件中。
RDB
RDB 默认的保存文件为 dump.rdb，优点是以二进制存储的，因此 占用的空间更小 、数据存储更紧凑，并且与 AOF 相比，RDB 具备 更快的重启恢复能力 。
AOF
AOF 默认的保存文件为 appendonly.aof，它的优点是存储频率更高，因此 丢失数据的风险就越低 ，并且 AOF 并不是以二进制存储的，所以它的存储信息更易懂。缺点是 占用空间大 ， 重启之后的数据恢复速度比较慢 。
混合
在 Redis 4.0 就推出了混合持久化的功能。Redis 混合持久化的存储模式是， 开始的数据以 RDB 的格式进行存储 ，因此只会占用少量的空间， 并且之后的命令会以 AOF 的方式进行数据追加 ，这样就可以减低数据丢失的风险，同时可以提高数据恢复的速度。
Fork
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时（ 默认值 64M ），Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。Redis 会fork出一条新进程来将 文件重写Rewrite (也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

Redis RDB持久化和AOF持久化详细讲解

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

手动触发分别对应save和bgsave命令：

自动触发

除了执行命令手动触发之外，Redis内部还存在自动触发RDB的持久化机制。如以下场景：

1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点

3）执行debug reload命令重新加载Redis时，也会自动触发save操作。

4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

bgsave是主流的触发RDB持久化方式，它的运作流程如下图：

1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。

2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。

3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。

4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。

5）进程发送信号给父进程表示完成，父进程更新统计信息。

保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir{newDir}和config setdbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。

压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression{yes|no}动态修改。

校验：如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：

这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告。

RDB的优点：

RDB的缺点：

AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。

AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。如下图所示：

流程如下：

1）所有的写入命令会追加到aof_buf（缓冲区）中。

2）AOF缓冲区根据对应的策略向硬盘做同步操作。

3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

AOF命令写入的内容直接是文本协议格式，开启AOF后，所有写入命令都包含追加操作，直接采用文本协议格式，避免了二次处理开销。

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制。

always:命令写入aof_buf后，调用系统ysnyc操作同步到AOF文件，ysnyc完成后线程返回。

everysec:命令写入aof_buf后，调用系统write操作,write完成后线程返回。ysnyc同步文件操作由专门线程每秒调用一次。

no：命令写入aof_buf后，调用系统write操作，不对AOF文件做ysnyc同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。

系统调用write和fsync说明：

Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

AOF重写机制压缩文件体积的原因：

1）进程内已经超时的数据不再写入文件。

2）旧的AOF文件含有无效命令，重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。

3）多条写命令可以合并为一个，为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF重写过程可以手动触发和自动触发：

auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage。其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

AOF重写流程：如下图

流程说明：

1）执行AOF重写请求。如果当前进程正在执行AOF重写，请求不执行并返回如下响应：

如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行，返回如下响应：

2）父进程执行fork创建子进程，开销等同于bgsave过程。

3.1）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。

3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。

4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。

5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。

5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。

5.3）使用新AOF文件替换老文件，完成AOF重写。

AOF和RDB文件都可以用于服务器重启时的数据恢复。Redis持久化文件加载流程如下图：

流程说明：

1）AOF持久化开启且存在AOF文件时，优先加载AOF文件，打印如下日志：

2）AOF关闭或者AOF文件不存在时，加载RDB文件，打印如下日志：

3）加载AOF/RDB文件成功后，Redis启动成功。

4）AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

加载损坏的AOF文件时会拒绝启动，并打印如下日志：

对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。

AOF文件可能存在结尾不完整的情况，Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动，同时打印如下警告日志：

redis中持久化策略rdb和aof的区别

Redis中的数据是存储在计算机内存中的，如果我们不进行配置，就会出现重启Redis后数据丢失的情况，这里就需要Redis中的持久化技术，它是将数据存储到磁盘中的，当Redis重启后仍可以从磁盘中获取数据，从而达到持久化的效果。
RDB和AOF有什么区别呢?
RDB持久化是在指定的时间间隔内，将内存中的数据集快照写入磁盘，实际操作过程是有一个fork子进程，先将数据集写入临时文件中，写入成功后再替换之前的文件，用二进制压缩存储。
而AOF持久化是以日志的形式记录在服务器所处理的每一个写、删操作，查询操作不会被记录，以文本的方式记录，可以打开文件看到详细的操作记录。
RDB的优点在于它的速度比较快，而且存储的是一个二进制文件，传输起来较方便;而缺点是RDB无法保证数据的绝对安全，有时候就是1秒也会造成很大的数据丢失。
AOF的优点在于比RDB更安全，一般不会出现数据丢失的现象，就算出现了数量也不会太大，当然了，官方是推荐同时开启AOF和RDB的;而缺点是AOF持久化的速度相比RDB要慢，存储的是一个文本文件，到了后期文件会比较大，传输困难。
需要注意的是，在重启Redis之后，需要加载一个持久化文件，有限会选择AOF文件，如果先开启了RDB再开启AOF，RDB先执行了持久化，那RDB文件中的内容会被AOF覆盖掉。
当满足条件时，redis单独会fork（创建）一个新的线程，会先将内存中的数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次已经持久化好了的文件，整个过程中，主进程是不进行任何IO操作的，确保了极高的性能
此时的主进程还可以进行读写操作。rdb数据持久化的缺点是最后一次持久化的数据可能丢失，当在最后一次持久化的时间截点内还没有持久化，此时机器宕机了或出故障了，那么最后一次的数据就没有持久化到。

REDIS学习查看redis状态，以及rdb和aof两种持久化方案的区别

命令：redis-cli info //查看redis服务器状态的
rdb : redis database 默认开启的，是将数据从内存备份到硬盘中。
aof：append only f 需要自己根据需要开启，是将执行命令存储在一个文件中。
建议看一下apeit-程序猿IT的文章《redis数据持久化》，讲的简单明了。
当满足条件时，redis单独会fork（创建）一个新的线程，会先将内存中的数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次已经持久化好了的文件，整个过程中，主进程是不进行任何IO操作的，确保了极高的性能
此时的主进程还可以进行读写操作。rdb数据持久化的缺点是最后一次持久化的数据可能丢失，当在最后一次持久化的时间截点内还没有持久化，此时机器宕机了或出故障了，那么最后一次的数据就没有持久化到。

redis的RDB和AOF两种持久化机制优缺点分析

redis持久化的意义主要是为了做 灾难恢复、数据恢复 其实可以把它归类到高可用的一个环节。
RDB持久化机制，对redis中的 数据 执行周期性的持久化。 AOF机制对 每条写入命令 作为日志，以append-only的模式写入一个日志文件，在redis重启对时候，可以通过回放AOF日志中写入的指令来重新构建整个的数据集。 如果同时使用AOF和RDB两种持久化机制 ，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加的完整。
优点： （1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。可以将文件存储到云端，本地磁盘等等。 （2）RDB机制对redis对外提供读写服务时候的影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB的持久化即可。 （3）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加的快速。 缺点： （1）如果想让redis出现故障，尽可能的少丢失数据，那么RDB没有AOF好。因为一般来说，RDB数据快照文件，基本上都是每隔5分钟或者更长的时间，生成一次，这个时候，如果一旦发生宕机，那么就会把这段时间内的数据都丢失掉。 （2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
优点： （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行fsync操作，最多丢失1秒钟的数据。 （2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易受损，即使文件尾部受损，也能很容易恢复，打开文件，把后面损坏的数据删除即可。 （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据对最小日志出来，再创建新日志文件的时候，老日志文件还是会照常写入指令，当新的日志文件生成好之后，会将旧日志文件中后面写入的指令合并到新的日志文件中，这个新的merge后的日志文件，会在ready的时候，与旧的日志文件进行交换。之后就会把旧的日志文件删除掉。 （4）AOF文件中保存的是执行的指令，所以这个特性非常适合做灾难性的误操作紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么久可以立即拷贝这个AOF文件出来，将最后一条flushall命令删除，然后再将AOF文件放回去，就可以通过恢复机制，自动的恢复所有数据了。 缺点： （1）对于同一份数据来说，AOF的日志文件通常要比RDB的数据快照文件要大。 （2）AOF开启之后，Redis服务支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然每秒一次fsync的性能也还是很高的。 （3）以前的AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来，所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge，而是基于当时内存中的数据进行指令的重新构建，这样健壮性能更好一些。
综合使用两者，用AOF来保证数据尽可能的少丢失，作为第一选择，其次在AOP丢失或者损坏的情况下，用RDB来更加快速的恢复数据。

Redis持久化机制ADB和AOF

有save和bgsave两种方式
RDB优点:
RDB缺点：
数据安全性低。如果持久化的时候redis 发生故障， 会丢失最后一次持久化的数据, 所以这种方式更 适合数据要求不高 的时候.
fock子进程过程中redis也是不能执行操作的,所以进行R DB操作的时间间隔一定不能太短 .而且,如果当数据集较大时，也可能会导致整个服务器停止服务?百毫秒，甚至是秒级。
以日志的形式记录服务器所处理的每?个写、删除操作，查询操作不会记录，以文本的方式记录，不断追加,可以打开?件看到详细的操作记录 .
三种追加方式(fsync):
AOF优点：
AOF缺点 ：

Redis持久化方式的区别

? ? 重启redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据。我们通常使用AOF日志重放，但是重放AOF日志性能相对RDB来说要慢很多，这样在redis实例很大的情况下，启动需要花费很长的时间。redis-4.0为了解决这个问题，带来了一个新的持久化选项——混合持久化。将RDB文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志，通常这部分AOF日志很小。aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用。

优点：

????1、当进行RDB持久化时，对redis服务处理读写请求的影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。生成一次RDB文件的过程就是把当前时刻内存中的数据 一次性写入文件 中，而AOF则需要先把当前内存中的小量数据转换为 操作指令，然后把指令写到内存缓存中，然后再刷写入磁盘 。

????2、相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis的数据会更加快速。AOF，存放的是指令日志，做数据恢复的时候，要回放和执行所有的指令日志，从而恢复内存中的所有数据。而RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可。

缺点：

????1、如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。这个问题，也是RDB最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。

? ? 2、RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。所以一般不要让生成RDB文件的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能会有影响。

优点：

????1、AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

????2、AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。

????3、AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite的时候，会对其中的指令进行压缩，会创建出一份需要恢复数据的最小日志出来。

缺点：

????1、对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。

????2、AOF的写性能比RDB的写性能低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的，只不过比起RDB来说性能低，如果要保证一条数据都不丢，也是可以的，AOF的fsync设置成每写入一条数据，fsync一次，但是这样，redis的性能会大大下降。

????3、基于AOF文件做恢复的速度不如基于RDB文件做恢复的速度。

优点：结合了RDB和AOF的优点，使得数据恢复的效率大幅提升

缺点：兼容性不好，redis-4.x新增，虽然最终的文件也是.aof格式的文件，但在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。

面试中问到Redis持久化的原理，本篇在做详细解答

我们知道redis是一个 高效的分布式内存数据库 ，由于是操作内存所以性能非常之快，通常用它来做分布式缓存，用来提高微服务的高性能，但是因为是内存操作，所以当出现服务器故障，断电等情况就会造成 内存数据丢失 ，不可恢复，因此redis 引入了持久化机制来将内存数据写入磁盘，从而保障了Redis的数据不被丢失。
Redis有两种持久化的方式，一种是RDB，另外种是AOF。
RDB是将Redis内存中数据的快照存储在磁盘内，是Redis的默认持久化方案。
RDB持久化默认有三种策略
可在redis.conf中配置，会以一段时间内达到指定修改的次数为规则来触发快照操作，快照文件名为dump.rdb。每当Redis服务重启的时候都会从该文件中把数据加载到内存中。
在60秒内有10000次操作即触发RDB持久化。
没有满足第一种条件时，在900秒内有1次操作即触发RDB持久化。
没有满足第二种条件时，在300秒内有10次操作即触发RDB持久化。
RDB持久化除了可以根据配置中的策略来触发外，还可以使用save和bgsave命令手动来触发。这两个命令的区别在于save会阻塞服务器进程。在执行save命令的过程中，服务器不能处理任何请求，但是bgsave（background save，后台保存）命令会通过一个子进程在后台处理数据RDB持久化。本质上save和bgsave调用的都是rdbSave函数，所以Redis不允许save和bgsave命令同时执行，当然这也是为了避免RDB文件数据出现不一致性的问题。
每次都是一个大文件，备份写入IO操作笔记大，很容易耗时，影响进程资源使用。
如果最近一次进程崩溃，那么最近一次数据备份后的数据就被丢失。
文件直接就可以当冷备使用
AOF（Append Only File）以独立日志的方式记录每次的写命令，可以很好地解决了数据持久化的实时性。系统重启时可以重新执行AOF文件中的命令来恢复数据。AOF会先把命令追加在AOF缓冲区，然后根据对应策略写入硬盘。
AOF的实现流程有三个步骤
步骤一
把命令追加到AOF缓冲区，
步骤二
将缓冲区的内容写入程序缓冲区
步骤三
将程序缓冲区的内容写入文件
当AOF持久化功能处于开启状态时，服务器每执行完一个命令就会将命令以协议格式追加写入redisServer结构体的aof_buf缓冲区。而在服务重启的时候会把AOF文件加载到缓冲区中。
AOF有 三种触发机制
·always：每次发生数据变更都会被立即记录到磁盘，性能较差，但数据完整性比较好。
·everysec：每秒钟将aof_buf缓冲区的内容写入AOF文件，如果宕机，就会有1秒内的数据丢失。
·no：将数据同步操作交给操作系统来处理，性能最好，但是数据可靠性最差。在配置文件中设置appendonly=yes后，若没有指定apendfsync，默认会使用everysec选项。
写入指令随着时间的推移，记录了很多重复的指令，导致数据量非常大。
RDB优先级高于AOF
RDB小，AOF较大
RDB慢，AOF快
RDB快，AOF慢