【Redis系列6】Redis事务ACID特性和内存回收及RDB和AOF持久化原理分析

前言

经过前面相关文章的介绍，我们已经了解了Redis当中数据类型的底层存储结构，对于Redis也可以算是有了基本的认识，那么从这一篇开始，后面的文章会相继介绍Redis当中的一些高级特性，比如事务，持久化，发布/订阅/事件等等，本文主要会介绍以下两大特性：
1、Redis当中的事务及其ACID特性
2、Redis的两种持久化机制：RDB和AOF

事务

提到事务，我想大多数人的第一感觉就是这是关系型数据库的特性，NoSQL数据库一般都不具有事务，那么Redis作为一款NoSQL数据库有事务吗？

Redis居然有事务？

答案是肯定的。Redis当中的单个命令都是原子操作，但是如果我们需要把多个命令组合操作的时候就需要用到事务。

Redis当中，通过下面4个命令来实现事务：

• 1、multi：开启事务
• 2、exec：执行事务
• 3、discard：取消事务
• 4、watch：监视

下图就是一个完整的事务执行流程：

从上图中，我们可以总结出Redis的事务主要分为以下3步：

• 1、执行命令multi开启一个事务
• 2、开启事务之后执行的命令都会被放入一个队列，并且固定返回"QUEUED"
• 3、执行命令exec提交事务之后，会依次执行队列里面的命令，并依次返回所有命令结果(如果想要放弃事务，可以执行discard命令)。

Redis事务实现原理

Redis中每个客户端都有自己的事务状态multiState,下面就是一个客户端client的数据结构定义：

typedef struct client {
    
    
    uint64_t id;//客户端唯一id
    multiState mstate; //MULTI和EXEC状态(即事务状态)
    //...省略其他属性
} client;

multiState数据结构定义如下：

typedef struct multiState {
    
    
    multiCmd *commands;//存储命令的FIFO队列
    int count;//命令总数
    //...省略了其他属性
} multiState;

multiCmd是一个队列用来接收并存储开启事务之后发送的命令，其数据结构定义如下：

typedef struct multiCmd {
    
    
    robj **argv;//用来存储参数的数组
    int argc;//参数的数量
    struct redisCommand *cmd;//命令指针
} multiCmd;

我们以上面事务的示例截图中事务为例，可以得到如下所示的一个简图：

Redis事务ACID特性

传统的关系型数据库中，一个事务一般都具有ACID特性，想要详细了解事务特性的可以点击这里。那么现在就让我们来分析一下Redis是否也满足这ACID四大特性。

A-原子性

在讨论原子性之前，我们先来看2个例子：
例子一：执行事务前报错(执行exec命令前)：

例子二：执行事务的时候报错(执行exec命令时)：

通过上面两个例子我们发现，如果我们开启事务之后，命令在进入队列之间就报错了，那么事务将会被取消，而一旦命令成功进入队列之后，单个命令的报错就不会影响其他命令的执行，也就是说Redis中的事务并不会回滚。

Redis中的事务为什么不会滚

Redis官网中对这个问题给出了明确的解释：

总结起来主要就是3个原因：

• 1、Redis作者认为发生事务回滚的原因大部分都是程序错误导致，这种情况一般发生在开发阶段，而生产环境很少出现。
• 2、对于逻辑性错误，比如本来应该把一个数加1，但是程序逻辑写成了加2，那么这种错误也是无法通过事务回滚来进行解决。
• 3、Redis追求的是简单高效，而传统事务的实现相对比较复杂，这和Redis的设计思想相违背。

C-一致性

一致性指的就是事务执行前后的数据符合数据库的定义和要求。这一点Redis是符合要求的，上面讲述原子性的时候已经提到，不论是发生语法错误还是运行时错误，错误的命令均不会被执行。

I-隔离性

事务中的所有命令都会按顺序执行，在执行Redis事务的过程中，另一个客户端发出的请求不可能被服务，这保证了命令是作为单独的独立操作执行的。所以Redis当中的事务是符合隔离性要求的。

D-持久性

如果Redis当中没有被开启持久化，那么就是纯内存运行的，一旦重启，所有数据都会丢失，所以不具备持久性，而如果Redis开启了持久化，那么也需要看开启的持久化模式是RDB还是AOF，还要视具体配置具体分析，这一点我们后面讲述持久化的时候会专门分析。

WATCH命令

上面我们讲述事务的时候还提到了一个WATCH命令，这个又是做什么用的呢？我们还是先来看一个例子。
首先打开客户端1，并开启事务：

上面事务中，如果这时候去执行exec，那么正常是第一句话返回nil，第二句话ok，第三句话lonely_wolf。
但是这个时候我在另一个客户端2执行一个set name zhangsan命令：

执行成功，这时候再返回到客户端1执行exec命令：

可以发现，第一句话返回了zhangsan，也就是说，name这个key值在入队之后到exec之前发生了变化，这种在有些场景可能会导致数据被覆盖等问题的发生，那么如何解决呢？这时候watch命令就可以闪亮登场了。

watch命令的作用

watch命令可以为Redis事务提供CAS乐观锁行为，它可以在exec命令执行之前，监视任意key值的变化，也就是说当多个线程更新同一个key值的时候，会跟原值做比较，一旦发现它被修改过，则拒绝执行命令，并且会返回nil给客户端。
下面还是通过一个示例来演示一下：
首先客户端1监视key值name，然后开启事务：

客户端2执行set name zhangsan命令：

这时候客户端1再提交事务,会发现，事务中所有的命令都没有被执行（也就是说，只要检测到一个key值被修改过，那么整个事务都不会被执行）：

watch原理分析

下面是一个Redis服务的数据结构定义：

typedef struct redisDb {
    
    
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    int id;                     /* Database ID */
    //省略了其他属性
} redisDb;

可以看到，redisDb中的watched_keys存储了一个字典，这个字典当中的key存的就是被监视的key，然后字典的值存的就是客户端id
然后每个客户端还有一个标记属性CLIENT_DIRTY_CAS：

一旦我们执行了一些如set，sadd等能修改key值对应value的命令，那么CLIENT_DIRTY_CAS标记将会被修改，后面执行事务提交命令exec时一旦发现这个标记被修改过，则会拒绝执行事务。

内存回收

Redis当中我们可以通过4个命令来给一个键设置过期时间：

• expire key ttl：将key值的过期时间设置为ttl秒
• pexpire key ttl：将key值的过期时间设置为ttl毫秒
• expireat key timestamp：将key值的过期时间设置为指定的timestamp秒数
• pexpireat key timestamp：将key值的过期时间设置为指定的timestamp毫秒数

PS:不管使用哪一个命令，最终Redis底层都是使用pexpireat命令来实现的，另外，set等命令也可以设置key的同时加上过期时间，这样可以保证设值和设过期时间的原子性。

最后我们可以通过ttl和pttl两个命令来查询剩余过期时间：

• ttl key 返回key剩余过期秒数，
• pttl key 返回key剩余过期的毫秒数

如果未设置过期时间则上面两个命令返回-1，如果设置了一个非法的过期时间，则都返回-2。

过期策略

如果将一个过期的键删除，我们一般都会有三种策略：

• 1、定时删除：为每个键设置一个定时器，一旦过期时间到了，则将键删除。这种策略对内存很友好，但是对CPU不友好。因为每个定时器都会占用一定的CPU资源。
• 2、惰性删除：不管键有没有过期都不主动删除，等到每次去获取键时再判断是否过期，如果过期就删除该键，否则返回键对应的值。这种策略对内存不够友好，可能会浪费很多内存。
• 3、定期扫描：系统每隔一段时间就定期扫描一次，发现过期的键就进行删除。这种策略相对来说是上面两种策略的折衷方案，但是这个定期的频率需要结合实际情况掌控好，但是这种方案也可能会出现过期的键也被返回。

在Redis当中，其选择的是策略2和策略3的综合使用。不过Redis的定期扫描只会扫描设置了过期时间的键，因为设置了过期时间的键Redis会单独存储，所以不会出现扫描所有键的情况：

typedef struct redisDb {
    
    
    dict *dict; //所有的键值对
    dict *expires; //设置了过期时间的键值对
   dict *blocking_keys; //被阻塞的key,如客户端执行BLPOP等阻塞指令时
   dict *watched_keys; /* WATCHED keys for MULTI/EXEC CAS */
   int id; /* Database ID */
   //省略了其他属性
} redisDb;

淘汰策略

假如Redis当中所有的键都没有过期，而且此时内存满了，那么客户端继续执行set等命令时Redis会怎么处理呢？Redis当中提供了不同的淘汰策略来处理这种场景。

首先Redis提供了一个参数maxmemory 来配置Redis最大使用内存

maxmemory <bytes>

或者也可以通过命令config set maxmemory 1GB来动态修改。

如果没有设置该参数，那么在32位的操作系统中最多使用3GB内存，而在64位的操作系统中不作限制。

Redis中提供了8种淘汰策略，通过参数maxmemory-policy进行配置：

淘汰策略	说明
volatile-lru	根据LRU算法删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
allkeys-lru	根据LRU算法删除所有的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
volatile-lfu	根据LFU算法删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
allkeys-lfu	根据LFU算法删除所有的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
volatile-random	随机删除设置了过期时间的键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
allkeys-random	随机删除所有键，直到腾出可用空间。如果没有可删除的键对象，且内存还是不够用时，则报错
volatile-ttl	根据键值对象的ttl属性， 删除最近将要过期数据。 如果没有，则直接报错
noeviction	默认策略，不作任何处理，直接报错

PS：淘汰策略也可以根据命令config set maxmemory-policy <策略>进行动态删除

LRU算法

LRU：Least Recently Used，即：最近最长时间未被使用。这个主要针对的是使用时间。

Redis改进后的LRU算法

在Redis当中，并没有采用传统的LRU算法，因为传统的LRU算法存在2个问题：

• 1、需要额外的空间进行存储。
• 2、可能存在某些key值使用很频繁，但是最近没被使用，从而被LRU算法删除。

为了避免以上2个问题，Redis当中对传统的LRU算法进行了改造，通过抽样的方式进行删除。

配置文件中提供了一个属性maxmemory_samples 5，默认值就是5，表示随机抽取5个key值，然后对这5个key值按照LRU算法进行删除，所以很明显，key值越大，删除的准确度越高。

对抽样LRU算法和传统的LRU算法，Redis官网当中有一个对比图：

• 浅灰色带是被删除的对象。
• 灰色带是未被删除的对象。
• 绿带是添加的对象
  
  左上角第一幅图代表的是传统LRU算法，可以看到，当抽样数达到10个(右上角)，已经和传统的LRU算法非常接近了。

Redis如何管理热度数据

前面我们讲述字符串对象的SDS原理时，提到了redisObject对象中存在一个lru属性：

typedef struct redisObject {
    
    
    unsigned type:4;//对象类型（4位=0.5字节）
    unsigned encoding:4;//编码（4位=0.5字节）
    unsigned lru:LRU_BITS;//记录对象最后一次被应用程序访问的时间（24位=3字节）
    int refcount;//引用计数。等于0时表示可以被垃圾回收（32位=4字节）
    void *ptr;//指向底层实际的数据存储结构，如：SDS等(8字节)
} robj;

这个注释上写了，这个值是相对于全局变量lru_clock而言的
lru属性是创建对象的时候会写入，对象被访问到时也会进行更新。正常人的思路就是最后决定要不要删除他肯定是用当前时间戳减去lru，差值最大的就优先被删除。

但是Redis里面并不是这么做的，Redis中维护了一个全局属性lru_clock，这个属性是通过一个全局函数serverCron每隔100毫秒执行一次来更新的，记录的是当前unix时间戳，

最后决定删除的数据是通过lru_clock全局属性减去对象的lru属性得出的。那么为什么Redis要这么做呢？直接取全局时间不是更准确吗？这是因为这么做可以避免每次更新对象的lru属性的时候可以直接取全局属性，而不需要去调用系统函数来获取系统时间，从而提升效率（Redis当中有很多这种细节考虑来提升性能，可以说是对性能尽可能的优化到极致）。

不过这里还有一个问题，我们看到，redisObject对象中的lru属性只有24位，24位只能存储194天的时间戳大小，一旦超过194天之后就会重新从0开始计算，所以这时候就会出现redisObject对象中的lru属性大于全局的lru_clock属性的情况。

正因为如此，计算的时候也需要分为2种情况，下面就是源码的计算方式(evict.c内)：

• 1、当全局lruclock>lru，则使用lruclock-lru得到空闲时间。
• 2、当全局lruclock<lru，则使用lruclock_max-lru+lruclock得到空闲时间。
  
  需要注意的是，这种计算方式并不能保证抽样的数据中一定能删除空闲时间最长的。

这是因为首先超过194天还不被使用的情况很少，再次只有lruclock第2轮继续超过lru属性时，计算才会出问题。比如对象A记录的lru是1天，而lruclock第二轮都到10天了，这时候就会导致计算结果只有10-1=9天，实际上应该是194+10-1=203天。但是这种情况可以说又是更少发生，所以说这种处理方式是可能存在删除不准确的情况，但是我们只需要达到基本准确就可以了。

LFU算法

LFU：Least Frequently Used，即：最近最少频率使用，这个主要针对的是使用频率。
这个属性也是记录在redisObject中的lru属性内。

当我们采用LFU回收策略时，lru属性的高16位用来记录访问时间（last decrement time：ldt，单位为分钟），低8位用来记录访问频率（logistic counter：logc），简称counter。

访问频次递增

LFU计数器每个键只有8位，它能表示的最大值是255，所以Redis使用的是一种基于概率的对数器来实现counter的递增。

给定一个旧的访问频次，当一个键被访问时，counter按以下方式递增：

• 1、提取0和1之间的随机数R
• 2、概率P计算为1/(old_value*lfu_log_factor+1)。
• 3、当R<P时，频次进行递增

公式中的lfu_log_factor称之为对数因子，默认是10，可以通过参数来进行控制：

lfu_log_factor 10

下图就是对数因子lfu_log_factor和频次counter增长的关系图：

可以看到，当对数因子lfu_log_factor为100时，10M(1000万)次访问才会将访问counter才增长到255，而默认的10也能支持到1M(100万)次访问counter才能达到255上限，这在大部分场景都是足够满足需求的。

访问频次递减

如果访问频次counter只是一直在递增，那么迟早会全部都到255，也就是说counter一直递增不能完全反应一个key的热度的，所以当某一个key一段时间不被访问之后，counter也需要对应减少。

counter的减少速度由参数lfu-decay-time进行控制,默认是1，单位是分钟，默认值1表示：N分钟内没有访问，counter就要减N。

lfu-decay-time 1

具体算法如下：

• 1、获取当前时间戳，转化为分钟后取低16位（为了方便后续计算，这个值记为now）。
• 2、取出对象内的lru属性中的高16位（为了方便后续计算，这个值记为ldt）。
• 3、当lru>now时，默认为过了一个周期(16位，最大65535)，则取差值65535-ldt+now；当lru <=now时，取差值now-ldt（为了方便后续计算，这个差值记为idle_time）。
• 4、取出配置文件中的lfu_decay_time值，然后计算：idle_time / lfu_decay_time（为了方便后续计算，这个值记为num_periods）。
• 5、最后将counter减少：counter - num_periods

看起来这么复杂，其实计算公式就是一句话，就是取出当前的时间戳对比对象中的lru属性，计算出当前多久没有被访问到，比如计算得到的结果是100分钟没有被访问，然后再去除配置参数lfu_decay_time，如果这个配置默认为1也即是100/1=100，代表100分钟没访问counter就减少100。

下面3幅图就是源码内的主要计算方法
源码db.c内：

源码evict.c内：

Redis持久化机制

Redis虽然是定义为一个内存数据库，但是为了防止数据丢失，其仍然提供了两种持久化机制：RDB和AOF。

RDB机制

RDB即：Redis DataBase，是Redis当中默认的持久化方案，当触发持久化条件时，Redis会生成一个dump.rdb文件，Redis在重启的时候就会通过解析dump.rdb文件进行数据恢复。

RDB机制触发条件

RDB持久化机制有两种触发方式：自动触发和手动触发。

自动触发

自动触发方式也可以分为三种：

• 1、执行flushall命令(flushdb命令不会触发)时，不过此时生成的读，dump文件内的数据是空的（dump文件还会存储一些头信息，所以文件本身是有内容的，只是没有数据），没有什么太大的意义。
  
• 2、执行shutdown命令时会触发生成dump文件。
  
  下面就是我这边重启之后的一个例子，数据全部都可以正常恢复：
  
  Redis启动之后日志如下，第一行就是显示了Redis从硬盘中进行了数据恢复：
  
• 3、通过配置文件自动生成，Redis中配置文件默认配置如下：

save 900 1 //900秒内至少有1个key被添加或者更新
save 300 10 //300秒内至少有10个key被添加或者更新
save 60 10000 //60秒内至少有10000个key被添加或者更新

也就是说只要达到这三个条件中的任意一个，就会触发Redis的RDB持久化机制。

手动触发

除了自动触发，Redis中还提供了2个手动触发RDB机制的命令。

• save：这个命令会阻塞Redis服务器进程，直到成功创建RDB文件，也就是说在生成RDB文件之前，服务器不能处理客户端发送的任何命令。
  
• bgsave：父进程会执行fork操作来创建一个子进程。RDB文件由子进程来负责生成，父进程可以正常处理客户端发送的命令
  
  如果想要知道上一次成功执行save或者bgsave命令的时间，可以执行lastsave命令进行查看，lastsave命令返回的是一个unix时间戳。
  
  PS：需要注意的是这两个命令不能同时被执行，一旦一个命令正在执行中，另一个命令会被拒绝执行。

RDB机制相关配置文件

除了上面提到的触发生成rdb的配置参数，RDB持久化机制还有如下一些相关命令：

• dir：rdb文件生成目录。默认是./(当前目录)，可以执行命令：config get dir进行查看
  
• dbfilename：rdb文件名。默认是dump.rdb
• rdbcompression：rdb文件是否是LZF压缩文件。默认是yes
• rdbchecksum：是否开启数据校验。默认是yes

RDB机制优点

• 1、RDB是一个非常紧凑的压缩文件，保存了不同时间点上的文件，非常适合用来灾备和数据恢复。
• 2、RDB最大限度地提高了Redis的性能，因为Redis父进程需要做的唯一的工作就是派生一个子进程来完成剩下的工作。父进程永远不会执行磁盘I/O或类似的操作。
• 3、与AOP机制想必，RDB方式恢复数据的速度更快

RDB机制缺点

• 1、RDB无法做到实时备份，所以如果Redis停止工作而没有正确的关机，那么从上一次备份的到异常宕机的这一段时间的数据将会丢失。
• 2、RDB通常需要父进程来执行fork()操作创建子线程，所以如果频繁执行fork()的而CPU性能又不是很高的话可能会造成短时间内父进程不可用。

AOF机制

AOF即：Append Only File，是Redis当中提供的另一种持久化机制。AOF采用日志的形式将每个写操作追加到文件中。开启AOF机制后，只要执行更改Redis数据的命令时，命令就会被写入到AOF文件中。在Redis重启的时候会根据日志内容执行一次AOF文件中的命令来恢复数据。

AOF和RDB最大的不同时AOF记录的是执行命令（类似于MySQL中binlog的statement格式），而RDB记录的是数据（类似于MySQL中binlog的row格式）。

需要注意的是，假如同时开启了RDB和AOF两种机制，那么Redis会优先选择AOF持久化文件来进行数据恢复。

下图就是同时开启了RDB和AOF两种机制的情况，Redis选择了使用AOF机制来进行数据恢复：

AOF机制如何开启

AOF机制默认是关闭的

appendonly no  //是否开启AOF机制，默认是no
appendfilename "appendonly.aof"  //AOF文件名

把appendonly参数修改为yes则可以开启AOF持久化机制。

PS：和RDB机制一样，其路径也是通过dir配置文件进行配置。

AOF机制数据是否实时写入磁盘

AOF机制下数据是否实时写入磁盘，这个和MySQL的redo log机制很类似，也是需要通过参数来进行控制。

AOF数据何时写入磁盘通过参数appendfsync来进行控制：

appendfsync	描述	Redis作者描述
always	写入缓存的同时通知操作系统刷新(fsync)到磁盘(但是也可能会有部分操作系统只是尽快刷盘，而不是实时刷盘)	Slow, Safest
everysec	先写入缓存，然后每秒中刷一次盘(默认值)，这种模式极端情况可能会丢失1s的数据	Compromise
no	只写入缓存，什么时候刷盘由操作系统自己决定	Faster

AOF重写

AOF机制主要是通过记录执行命令的方式来实现的，那么随着时间的增加，AOF文件不可避免的会越来越大，而且可能会出现很多冗余命令。比如同一个key值执行了10000次set操作，实际上前面9999次对用户来说都是没用的，用户只需要最后一次执行命令，所以AOF机制就提供了重写功能。

重写原理分析

AOF重写时Redis并不会去分析原有的文件，因为如果原有文件过大，分析也会很耗时，所以Redi选择的做法就是重新去Redis中读取现有的键值，然后用一条命令记录键值对的值。

源码server.h中定义了1个常量，常量值等于64：

#define AOF_REWRITE_ITEMS_PER_CMD 64

如果在AOF重写的时候，如果一个集合键或者列表键或者哈希键内包含的元素超过64个，那么也会采用多条命令来进行重写。

AOF重写的时候一般都会有大量的写操作，所以为了不阻塞客户端的命令请求，Redis会把重写操作放入到子进程中执行，但是放入子进程中执行也会带来一个问题，那就是重写期间如果有其他命令被执行了，如何保证数据的一致性？

为了解决数据不一致问题，Redis中引入了一个AOF重写缓冲区。当开始执行AOF重写之后接收到的命令，不但要写入原本的AOF缓冲区(根据上面提到的参数刷盘)，还要同时写入AOF重写缓冲区：

一旦子进程完成了AOF文件的重写，此时会向父进程发出信号，父进程收到信号之后会进行阻塞（阻塞期间不执行任何命令），并进行以下两项工作：

• 1、将AOF重写缓冲区的文件刷新到新的AOF文件内
• 2、将新AOF文件进行改名并原子的替换掉旧的AOF文件

完成了上面的两项工作之后，整个AOF重写工作完成，父进程开始正常接收命令。

AOF机制触发条件

AOF机制的触发条件同样也分为自动触发和手动触发两种：

• 自动触发：自动触发可以通过以下参数进行设置：

auto-aof-rewrite-percentag //文件大小超过上次AOF重写之后的文件的百分比。默认100，也就是默认达到上一次AOF重写文件的2倍之后会再次触发AOF重写
auto-aof-rewrite-min-size //设置允许重写的最小AOF文件大小,默认是64M。主要是避免满足了上面的百分比，但是文件还是很小的情况。

• 手动触发：执行bgrewriteaof命令。

注意：bgrewriteaof命令也不能和上面RDB持久化命令bgsave`同时执行，否则会创建两个子进程来同时执行大量写磁盘操作，影响性能。

AOF机制机制优点

• 1、使用AOF机制，可以自由选择不同fsync(刷盘)策略，而且在默认策略下最多也仅仅是损失1s的数据
• 2、AOF日志是一个仅追加的日志，因此如果出现断电，也不存在查找或损坏问题。即使由于某些原因(磁盘已满或其他原因)，日志以写了一半的命令结束，redis-check-aof工具也能够轻松地修复它。
• 3、当AOF变得太大时，Redis能够在后台自动重写。
• 4、不通过与RDB的文件格式，AOF是一种易于理解和解析的格式，依次包含所有操作的日志。

AOF机制机制缺点

• 1、对于相同的数据集，AOF文件通常比等效的RDB文件大。
• 2、根据fsync的具体策略，AOF可能比RDB慢。但是一般情况下，fsync设置为每秒的性能仍然很高，禁用fsync后，即使在高负载下，它的速度也应该和RDB一样快。
• 3、因为AOF文件是追加形式，可能会遇到BRPOP、LPUSH等阻塞命令的错误，从而导致生成的AOF在重新加载时不能复制完全相同的数据集，而RDB文件每次都是重新从头创建快照，这在一定程度上来说RDB文件更加健壮。

总结

本文主要介绍了Redis中提供的事务支持，并从传统事务的角度上分析了Redis事务的ACID特性，然后我们介绍了Redis的内存淘汰策略，着重介绍了LRU和LFU两种算法，最后我们介绍了Redis的两种持久化机制，并分别介绍了RDB和AOF两种持久化机制的优缺点。