redis持久化机制（redis持久化原理）

本篇文章给大家谈谈redis持久化机制，以及redis持久化原理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、面试中问到Redis持久化的原理，本篇在做详细解答
• 2、Redis持久化的方式选择与原理
• 3、Redis持久化策略(看这篇,你肯定会有所获)
• 4、Redis 持久化 ★
• 5、Redis的持久化机制 (RDBamp;AOFamp;混合模式)
• 6、redis的RDB和AOF两种持久化机制优缺点分析

面试中问到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慢

Redis持久化的方式选择与原理

通常Redis将数据存储在内存中或虚拟内存中，但它提供了数据持久化功能可以把内存中的数据持久化到磁盘。持久化有什么好处呢？比如可以保证断电后数据不会丢失，升级服务器也会变得更加方便。

1.RDB 持久化机制 ：是对 redis 数据执行周期性的持久化。

这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dump.rdb。客户端也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写操作会比较多，必然会引起大量的磁盘IO操作，可能会严重影响性能。

2.AOF持久化机制 ：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。当宽仿差然由于操作系统会在内核中缓存write做的大蔽修改，所以可能不是立即写到磁盘上。这样的持久化还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis我们想要通过fsync函数强制操作系统写入到磁盘的时机。

appendonly yes //启用日志追加持久化方式

（1）appendfsync always //收到写命令就立即强制写入磁盘。最慢的，但是保证完全持久化，不推荐使用。

（2）appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐使用。

（3）appendfsync no //完全依赖操作系统，性能最好,持久化没保证。

通过 RDB 或 AOF，都可以将 redis 内存中的数据持久化到磁盘上面来，然后可以将这些数据备份到别的地方去。

1.RDB方式

优点：

缺点：

2.AOF方式

优点:

缺点：

不要仅仅使用 RDB，因为那样会导致你丢失很多数据；也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加慎皮健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

出处：

[img]

Redis持久化策略(看这篇,你肯定会有所获)

RDB：Redis DataBase ， 记录快照

        RDB是redis 默认的持久化方案. RDB 是当满足一定条件时, 就会将redis内存中的数据写入磁盘,并生成一个快照文件dump.rdb 文件.Redis 重启会通过加载dump.rdb文件恢复数陪缓据.

        一定条件分为以下几种情况: 1.自动触发  2. 手动触发 . 下面分开说明下:

a).redis.conf 中 SNAPSHOTTING 其中定义了触发把数据保存到磁盘的触发频率.

        如果不需要rdb 方案, 注释save 或者配置成空字符串" ".

        save 900 1 #900秒内至少有一个key被修改(包括添加)

        save 300 10 #400秒内至少10个key被修改

        save 10000 #60秒内至少有10000个key 被修改.

        这三条配置不冲突, 只要满足一条就神岁触发.

        rdb 文件位置和目录 (默认在安装根目录下) 

        #文件路径

        dir ./

        #文件名称

        游乱睁dbfilename dump.rdb

        #是否以LZY压缩rdb 文件

        rdbcompression yes 

        #开启数据校验

        rdbchecksum yes

b) shutdown触发 ,保证服务器正常关闭.

c) flushall , rdb文件是空的, 会生成一个空的文件,所以这种情况也没有什么意义.但需要知道,这种情况下

会触发生成rdb文件.

Redis 提供了两条命令: save 和 bgsave

a). save 命令

        save 在生成快照的时候会阻塞当前Redis 服务器,Redis不能处理其他命令.如果内存数据较多,会造成

b).bgsave 命令

        执行bgsave命令时,   Redis会在后台进行异步快照操作,快照同时还可以响应客户端请求.

具体操作

        具体操作:Redis进程会执行fork操作创建子进程(copy-on-write),RDB 持久化过程由子进程负载,完成后自动结束.它不会记录fork之后产生的记录.阻塞只发送在fork阶段,一般时间较短.

一.优势

    1.RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集.这种文件非常适合进行备份和

灾难恢复.

    2.生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存的工作,主进程不需要进行任何

IO操作.

    3.RDB在恢复大数据集时的速度比AOF的恢复速度要快

二.劣势

    1).RDB 没办法做到实时持久化/妙级持久化.因为bgsave每次运行都要执行fork创建子进程,频繁执行成本过高.    

    2).在一定间隔时间做一次备份,所以如果Redis 以为down掉的话,就会丢失最后一次快照之后所有修改

(数据有丢失)

AOF：Append Only File ， 记录日志

Redis 默认不开启.AOF采用日志的形式来记录每个写操作,并追加到文件中.开启后,执行更改Redis    命令时,就会把命令写入到AOF文件中.

Redis 重启时会根据日志文件的内容把写指令从前往后执行一次以完成数据的恢复工作.

#开关

appendonly no

#文件名

appendfilename "appendonly.aof"

        由于操作系统缓存机制,AOF数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存.什么时候

把缓冲区的内容写入到AOF文件中? 由下面参数决定

appendfsync :  值: no  \ always \everysec 

        no: 表示不执行fync, 由操作系统保证数据同步到磁盘,速度最快,但是不安全.

        always:表示每次写入都执行fync,以保证数据同步到磁盘,效率很低

        everysec:表示每秒执行以fync ,可能会导致丢失1s数据.通常选择everysec,兼顾效率和安全性.

    因为AOF文件只有一个, 随着redis 不断进行,AOF 的文件会越来越大,文件越大, 文件占用服务器内存

以及AOF恢复要求时间越长.

    为了解决这个问题,可以使用bgwriteaof来重写.那什么时候重写? 又是怎样重写?

    一. 什么时候重写?

    #重写触发机制

    auto-aof-rewrite-percentage 100 默认值是100. 当前aof 文件大小超过 上一次重写的aof文件大小百分之多少进行重写,即当aof文件增长到一定大小时,Redis能够调用bgwriteaof对日志文件进行重写.当前aof文件大小是上次日志重写得到aof文件大小的二倍时, 自动启动新的日志重写过程.

    auto-aof-rewrite-min-size 默认是64M.设置允许重写的最小aof文件大小,避免达到了约定百分比 但尺寸

仍然很小的情况还要重写.

   二. 怎样重写?

    并不是对原文件进行重新整理,而是直接读取服务器上现有的键值对,然后用一条命令去代替之间记录这

个键值对的多条命令,生成一个新的文件后去替换原来的 AOF文件.

    看下面这两个参数:

        no-appendfsync-on-rewrite

        aof-load-truncated

   AOF 数据恢复

        重启Redis之后就会进行AOF文件恢复.

   AOF 的优势和劣势

优点:

1.AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis最多也就丢失

1秒的数据.

缺点:

1.对于具有相同数据的Redis, AOF文件通常比RDF文件体积更大(RDB存的是数据快照)

2.虽然AOF提供了多种同步的频率,默认的情况下,没秒同步一次的频率也具有较高的性能.在高并发的情况下,RDB比AOF具有更好的性能.

        如果可以忍一小段时间数据的丢失,毫无疑问使用RDB 是最好的,定时生成RDB快照非常便于进行数据备份,而且RDB恢复数据集的速度也要比AOF恢复速度要快.

        否则就要使用AOF重写.但是一般情况下建议不要单独使用某一种持久化机制,而是两种一起用.

本文内容来自咕泡学院-青山老师,感谢青山老师!!

Redis 持久化 ★

1、RDB

2、AOF

3、两种的使用场景

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

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

（1）Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

（2）在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

（3）一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才缺袜会将父进程的内容复制一份给子进程。

在redis.conf中配置文件名称，默认为dump.rdb

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下

dir "/myredis/"

dir ./ 表示在当前配置文件的文件夹下生成 .rdb文件

（1）配置文件中默认的快照配置

（2）命昌茄令save VS bgsave

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

可以通过lastsave 命令获取最后一次成功执行快照的时间

（3）save（禁用）

格式：save 秒钟 写操作次数

RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。(短时间内越多越快)

不设置save指令，或者给save传入空字符串

（4）stop-writes-on-bgsave-error

如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制

（5）rdbcompression 压缩文件

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能：

（6）rdbchecksum

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能：

（7）rdb的备份

1）将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

2）CONFIG GET dir获取目耐扮察录

（1）优点：

适合大规模的数据恢复

对数据完整性和一致性要求不高更适合使用

节省磁盘空间

恢复速度快

（2）缺点：

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

可以在redis.conf中配置文件名称，默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复：

修改默认的appendonly no，改为yes

将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

恢复：重启redis然后重新加载

异常恢复：

修改默认的appendonly no，改为yes

如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复

备份被写坏的AOF文件

恢复：重启redis，然后重新加载

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

（1）是什么

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

（2）重写原理，如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

（3）重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）

1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。

2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

备份机制更稳健，丢失数据概率更低。

可读的日志文本，通过操作AOF稳健，可以处理误操作。

比起RDB占用更多的磁盘空间。

恢复备份速度要慢。

每次读写都同步的话，有一定的性能压力。

存在个别Bug，造成恢复不能。

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

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

Redis的持久化机制 (RDBamp;AOFamp;混合模式)

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持久化机制，对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持久化机制和redis持久化原理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。