redis 持久化存储

我是大龄程序员
139 阅读23分钟

redis 是存到内存上的key-value 形式 noSql数据库, 进行身份验证的token通常就可以存储到redis缓存中。

通过brew安装的redis，配置文件在/opt/homebrew/etc/redis.conf

redis.conf是隐藏文件，MAC下通过终端下执行命令 defaults write com.apple.finder AppleShowAllFiles -bool false 去掉文件的隐藏。方便更改conf文件

为了预防redis服务因其它问题（比如断电故障停机）导致的内存中数据丢失带来问题，采用持久化存储，可以恢复redis缓存中的数据

方式： RDB（Redis DataBase）与AOF（Append Only File）

RDB

  • 定义 ：在指定的时间间隔内生成数据集的时间点快照

  • RDB 的优点:

    1. RDB 是一个非常紧凑的文件（全量复制）

      它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

    2. RDB 非常适用于灾难恢复

      它只有一个文件，内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3中。

    3. RDB 可以最大化 Redis 的性能

      父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

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

  • RDB 的缺点

    如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

    每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF

  • 定义: 通过使用追加操作的日志文件恢复数据

    AOF (Append Only File) 持久化默认是关闭的，通过将 redis.conf 中将 appendonly no，修改为 appendonly yes 来开启AOF 持久化功能，如果服务器开始了 AOF 持久化功能，服务器会优先使用 AOF 文件来还原数据库状态。只有在 AOF 持久化功能处于关闭状态时，服务器才会使用 RDB 文件来还原数据库状态。如图：

image.png

  • 概述 AOF 持久化功能则提供了一种更为可靠的持久化方式。 每当 Redis 接受到会修改数据集的命令时，就会把命令追加到 AOF 文件里，当你重启 Redis 时，AOF 文件里的命令会被重新执行一次，重建数据，如下图

    举个例子，如果我们对空白的数据库执行以下写命令，那么数据库中将包含三个键值对：

    redis> SET msg "hello"
OK
redis> SADD fruits "apple" "banana" "cherry"
(integer)3
redis> RPUSH numbers 128 256 512 
(integer)3

    RBD 持久化保存数据库状态的方法是将 msg、fruits、numbers 三个键的键值对保存到 RDB 文件中，而 AOF 持久化保存数据库状态的方法则是将服务器执行的SET、SADD、RPUSH三个命令保存到 AOF 文件中。

    被写入 AOF 文件中的所有命令都是以 Redis 的命令请求协议格式保存的，因为 Redis 的命令请求协议是纯文本格式，所以我们可以直接打开一个 AOF 文件，观察里面的内容。

    例如，对于之前执行的三个写命令来说，服务器将产生包含以下内容的AOF文件：

    *2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
*3\r\n$3\r\nSET\r\n$3\r\nmsg\r\n$5\r\nhello\r\n
*5\r\n$4\r\nSADD\r\n$6\r\nfruits\r\n$5\r\napple\r\n$6\r\nbanana\r\n$6\r\ncherry\r\n
*5\r\n$5\r\nRPUSH\r\n$7\r\nnumbers\r\n$3\r\n128\r\n$3\r\n256\r\n$3\r\n512\r\n

    服务器在启动时，可以通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态，以下就是服务器载入AOF文件并还原数据库状态时打印的日志：

    [8321] 07 Aug 11:58:50.448 # Server started, Redisversion 2.9.11
[8321] 07 Aug 11:58:50.449 * DB loaded from append only file: 0.000 seconds
[8321] 07 Aug 11:58:50.449 * The server is now ready to accept connections on port 6379

  • AOF 持久化的实现

    AOF 持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。

    1.2.1 命令追加 当 AOF 持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

    举例：如果客户端向服务器发送以下命令：

    redis> SET KEY VALUE
OK

    那么服务器在执行这个命令之后，会将以下协议内容追加到 aof_buf 缓冲区的末尾：

    redis> SET KEY VALUE

    又例如，如果客户端向服务器发送以下命令：

    redis> RPUSH NUMBERS ONE TWO THREE
(integer) 3

    那么服务器在执行这个RPUSH命令之后，会将以下协议内容追加到aof_buf缓冲区的末尾：

    redis> RPUSH NUMBERS ONE TWO THREE

    以上就是AOF持久化的命令追加步骤的实现原理。

  • AOF 文件的写入与同步

    Redis的服务器进程就是一个事件循环（loop），这个循环中的文件事件负责接受客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像 serverCron 函数这样需要定时运行的函数。

    因为服务器在处理文件事件时可能会执行写命令，使得一些内容被追加到 aof_buf 缓冲区里面，所以在服务器每次结束一个事件循环之前，它都会调用 flushAppendOnlyFile 函数，考虑是否需要将 aof_buf 缓冲区的内容写入和同步到 AOF 文件里，这个过程可以用伪代码表示：

     def evenLoop () :
 while True :

  # 处理文件事件，接受命令请求以及发送命令回复
  # 处理请求时可能会有新内容被追加到 aof_buf 缓冲区
  processFileEvents ()

  # 处理时间事件
  processTimeEvents ()
  
  # 考虑是否要将 aof_buf 中的内容写入和保存到 AOF 文件里
  flushAppendOnlyFile ()

    flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 选项的值来决定，各个不同值产生的行为如下表：

    image.png

    • 关于文件的写入和同步说明：

      为了提高文件的写入效率，在现代的操作系统中，当用户调用 write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正的将缓冲区中的数据写入到磁盘里。

      这种做法虽然提高了效率，但是也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里的写入数据将会丢失。

      为此，系统提供了 fsync 和 fdatafync 两个同步函数，它们可以强制让操作系统立即将缓冲区的数据写入到磁盘里面，从而确保写入数据的安全性。

      AOF 文件的写入与同步，就好比你在 window 系统打开一个 word 文档，当你写一些内容时就相当于写入，但是你写的内容并没有真正的保存，而是放在一个缓冲区，如果这时关闭的话内容就会丢失。只有当你点击保存时内容才真正的保存（同步）到磁盘，点击保存就好比调用同步函数 fsync 和 fdatafync。

    • 关于 AOF 持久化的效率和安全性：

      服务器配置 appendfsync 选项的值直接决定 AOF 持久化功能的效率和安全性。

      当 appendfsync 的值为 always 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 appendfsync 选项三个值当中最慢的一个，但从安全性来说，always 也是最安全的，因为即使出现故障停机，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。

      当 appendfsync 的值为 everysec 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，并且每隔一秒就要在子线程中对 AOF 文件进行一次同步。从效率上来讲，everysec 模式足够快，并且就算出现故障停机，数据库也只丢失一秒钟的命令数据。

      当 appendfsync 的值为 no 时，服务器在每个事件循环都要将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，至于何时对 AOF 文件进行同步，则由操作系统控制。因为处于 no 模式下的 flushAppendOnlyFile 调用无须执行同步操作，所以该模式下的 AOF 文件写入速度总是最快的，不过因为这种模式会在系统缓存中积累一段时间的写入数据，所以该模式的单次同步时长通常是三种模式中时间最长的。从平摊操作的角度来看，no 模式和 everysec 模式的效率类似，当出现故障停机时，使用 no 模式的服务器将丢失上次同步 AOF 文件之后的所有写命令数据。

    • AOF文件的载入与数据还原

      因为 AOF 文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍 AOF 文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

      Redis读取 AOF 文件并还原数据库状态的详细步骤如下：

      1）创建一个不带网络连接的伪客户端（fake client）：因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所使用的命令直接来源于 AOF 文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行 AOF 文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样。

      2）从 AOF 文件中分析并读取出一条写命令。

      3）使用伪客户端执行被读出的写命令。

      4）一直执行步骤2和步骤3，直到 AOF 文件中的所有写命令都被处理完毕为止。

      当完成以上步骤之后，AOF 文件所保存的数据库状态就会被完整地还原出来

image.png 例如，对于以下 AOF 文件来说：

    redis> SELECT 0
    redis> SET msg hello
    redis> SADD fruits apple banana chaerry
    redis> RPUSH number 128 256 512

服务器首先读入并执行 SELECT 0 命令，之后是 SET msg hello 命令，再之后是 SADD fruits apple banana chaerry 命令，最后是 RPUSH numbers 128 256 512 命令，当这些命令都执行完毕之后，服务器的数据库就被还原到之前的状态了。

  • AOF 重写

    因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 服务器、甚至整个宿主计算机造成影响，并且 AOF 文件的体积越大，使用 AOF 文件来进行数据还原所需的时间就越长。

    举个例子，如果客户端执行以下命令：

    redis> RPUSH list "A" "B"          // ["A", "B"]
(integer) 2
redis> RPUSH list "C"              // ["A", "B", "C"]
(integer) 3
redis> RPUSH list "D" "E"          // ["A", "B", "C", "D", "E"]
(integer) 5
redis> LPOP list                   // ["B", "C", "D", "E"]
"A"
redis> LPOP list                   // ["C", "D", "E"]
"B"
redis> RPUSH list "F" "G"          // ["C", "D", "E", "F", "G"]
(integer) 5

    那么只是为了记录这个 list 键的状态，AOF 文件就需要保存六条命令。

    对于实际的应用来说，写命令执行的次数和频率会比上面的简单示例要高得多，所以造成的问题也严重得多。

    为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写（rewirte）功能。通过该功能，Redis 服务器可以创建一个新的 AOF 文件，新旧两个 AOF 文件所保存的数据库状态相同，但新 AOF 文件不会包含任何浪费空间的冗余命令，所以新 AOF 文件的体积通常会比旧 AOF 文件的体积小很多。

  • AOF 文件重写的实现

    虽然 Redis 将生成新 AOF 文件替换旧 AOF 文件的功能命名为 “AOF 重写”，但实际上，AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。

    例如上面的 list 的例子，服务器为了保存 list 键的状态，必须在 AOF 文件中写入六条命令。

    如果服务器想要尽量少的命令记录 list 键的状态，那么最简单高效的办法不是去读取和分析现有 AOF 文件的内容，而是直接从数据库中读取键 list 的值，然后用一条 RPUSH list "C" "D" "E" "F" "G" 命令来代替保存在 AOF 文件中的六条命令，这样就可以保存 list 键所需的命令从六条减少为一条了。

    再举例，如果服务器对 animals 键执行了一下命令：

    redis> SADD animals "Cat"                  // {"Cat"}
(integer) 1
redis> SADD animals "Dog" "Panda" "Tiger" // {"Cat", "Dog", "Panda", "Tiger"}
(integer) 3
redis> SREM animals "Cat"                 // {"Dog", "Panda", "Tiger"}
(integer) 1
redis> SADD animals "Lion" "Cat"          // {"Dog", "Panda", "Tiger", "Lion", "Cat"}
(integer) 2

    那么为了记录 animals 键的状态，AOF 文件必须保存上面列出的四条命令。

    如果服务器想减少保存 animals 键所需命令的数量，那么服务器可以通过读取 animals 键的值，然后用一条SADD animals "Dog" "Panda" "Tiger" "Lion" "Cat"命令来代替上面的四条命令，这样就将保存 animals 键所需的命令从四条减少为一条了。这就是指令合并

    除了上面列举的列表键和集合键之外，其他所有类型的键都可以用同样的方法去减少 AOF 文件中的命令数量。首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写功能的实现原理

    def aof_rewrite(new_aof_file_name):

    # 创建新 AOF 文件
    f = create_file(new_aof_file_name)

    # 遍历数据库
    for db in redisServer.db:

        # 忽略空数据库
        if db.is_empty(): continue

        # 写入SELECT命令，指定数据库号码
        f.write_command("SELECT" + db.id)

        # 遍历数据库中的所有键
        for key in db:

            # 忽略已过期的键
            if key.is_expired(): continue

            # 根据键的类型对键进行重写
            if key.type == String:
                rewrite_string(key)
            elif key.type == List:
                rewrite_list(key)
            elif key.type == Hash:
                rewrite_hash(key)
            elif key.type == Set:
                rewrite_set(key)
            elif key.type == SortedSet:
                rewrite_sorted_set(key)

            # 如果键带有过期时间，那么过期时间也要被重写
            if key.have_expire_time():
                rewrite_expire_time(key)

    # 写入完毕，关闭文件
    f.close()


def rewrite_string (key) :

    # 使用 GET 命令获取字符串的值
    value = GET (key)

    # 使用 SET 命令重写字符串键
    f.write_command(SET, key, value)


def rewrite_list (key) :

    # 使用 LRANG 命令获取列表键包含的所有元素
    item1, item2, ..., itemN = LRANG(key, 0, -1)

    # 使用 RPUSH 命令重写列表键
    f.write_command(RPUSH, key, item1, item2, ..., itemN)


def rewrite_hash (key) :

    # 使用 HGETALL 命令获取哈希键包含的所有键值对
    field1, value1, field2, value2, ..., fieldN, valueN = HGETALL(key)

    # 使用 HMSET 命令重写哈希键
     f.write_command(HMSET, key, field1, value1, field2, value2, ..., fieldN, valueN)


def rewrite_set (key) :

    # 使用 SMEMBERS 命令获取集合包含的所有元素
    elem1, elem2, ..., elemN = SMEMBERS(key)

    # 使用 SADD 命令重写集合键
    f.wirte_command(SADD, key, elem1, elem2, ..., elemN)


def rewrite_sort_set (key) :

    # 使用 ZRANG 命令获取有序集合包含的所有元素
    member1, score1, member2, score2, ..., memberN, scoreN = ZRANG(key, 0 , -1, "WITESCORES")

    # 使用 ZADD 命令重写有序集合键
    f.write_command(ZADD, key, score1, member1, score2, member2, ..., scoreN, memberN)


def rewrite_expire_time (key) :

    # 获取毫秒精度的键过期时间戳
    timestamp = get_expire_time_in_unixstamp(key)

    # 使用 PEXPIREAT 命令重写键的过期时间
    f.write_command(PEXPIREAT, kye, timestamp)

    因为 aof_rewrite 函数生成的新 AOF 文件只包含还原当前数据库状态所必须的命令，所以新 AOF 文件不会浪费任何硬盘空间。

    注意：在实际中，为了避免在执行命令是造成客户端输入缓冲区溢出，重写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元素的键时，会先检查所包含的元素数量，如果元素数量超过了 redis.h/REDIS_AOF_REWRITE_ITEMS_PRE_CMD 常量的值，那么重写程序将使用多条命令来记录键的值，而不单单使用一条命令。

    在目前版本中，REDIS_AOF_REWRITE_ITEMS_PRE_CMD 常量的值是64，也就是说，如果一个集合键包含了超过64个元素，那么重写程序会用多条 SADD 命令来记录这个集合，并且每条命令设置的元素数量也为64个

    • AOF 后台重写

    上面介绍的 AOF 重写程序 aof_rewrite 函数可以很好的创建一个新 AOF 文件的任务，但是因为这个函数会进行大量的写入操作，所以调用这个函数的线程将被长时间阻塞，因为 Redis 服务器使用单个线程来处理命令请求，所以如果由服务器直接调用aof_rewrite 函数的话，那么在重写 AOF 文件期间，服务器将无法处理客户端发来的命令请求。

    所以 Redis 决定将 AOF 重写程序放到子进程里执行，这样做可以同时达到两个目的：

    1.子进程进行 AOF 重写期间，服务器（父进程）可以继续处理命令请求。

    2.子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

    但是，使用子进程也有一个问题需要解决，因为子进程在进行 AOF 重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的 AOF 文件所保存的数据库状态不一致。

    为了解决数据不一致问题，Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当 Redis 服务器执行完一个写命令之后，它会同时将这个写命令发送给 AOF 缓冲区和 AOF 重写缓冲区，

    这样一来可以保证：

    AOF 缓冲区的内容会定期被写入和同步到 AOF 文件，对现有 AOF 文件的处理工作会如常进行。

    从创建子进程开始，服务器执行的所有写命令都会被记录到 AOF 重写缓冲区里面。

    当子进程完成 AOF 重写工作之后，它会向父进程发送一个信号，父进程在接到该信号后，会调用一个信号处理函数，并执行一下工作：

    将 AOF 重写缓冲区中的所有内容写入到新 AOF 文件中，这是新的 AOF 文件所保存的数据库状态将和服务器当前的数据库状态一致。

    对新的 AOF 文件进行改名，原子地（atomic）覆盖现有的 AOF 文件，完成新旧两个 AOF 文件的替换。

    这个信号处理函数执行完毕之后，父进程就可以继续像往常一样接受命令请求了。

    在整个 AOF 后台重写过程中，只有信号处理函数执行时会对服务器进程（父进程）造成阻塞，在其他时候，AOF 后台重写不会阻塞父进程，这将 AOF 重写对服务器性能造成的影响降到了最低。

image.png

RDB和AOF的优缺点

  • RDB的优点

  1. 体积更小：相同的数据量rdb数据比aof的小，因为rdb是紧凑型文件

  2. 恢复更快：因为rdb是数据的快照，基本上就是数据的复制，不用重新读取再写入内存

  3. 性能更高:父进程在保存rdb时候只需要fork一个子进程，无需父进程的进行其他io操作，也保证了服务器的性能。

  • RDB的缺点

  1. 故障丢失:因为RDB是全量的，我们一般是使用shell脚本实现30分钟或者1小时或者每天对redis进行rdb备份，但是最少也要5分钟进行一次的备份，所以当服务死掉后，最少也要丢失5分钟的数据。

  2. 耐久性差:相对AOF的异步策略来说，因为RDB的复制是全量的，即使是fork的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork的时间也会延长，导致cpu吃紧，耐久性相对较差。

  • AOF的优点

    使用 AOF 持久化会让 Redis 变得非常耐久：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

    AOF 文件是一个只进行追加操作的日志文件， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。

    Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

    AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析也很轻松。 导出 AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

  • AOF 的缺点

    对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

    根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间。

    AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

  • 简略描述AOF的优点

  1. 数据保证：我们可以设置fsync策略，一般默认是everysec，也可以设置每次写入追加，所以即使服务死掉了，咱们也最多丢失一秒数据

  2. 自动缩小：当aof文件大小到达一定程度的时候，后台会自动的去执行aof重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的aof中，旧的就会被删除掉。

  • 简略描述AOF的缺点

  1. 性能相对较差：它的操作模式决定了它会对redis的性能有所损耗

  2. 体积相对更大：尽管是将AOF文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。

  3. 恢复速度更慢(根据日志文件对mysql进行操作）

最后的总结

redis有两种持久化方式，aof和rdb，aof相当于日志记录操作命令，rdb相当于数据的快照。安全性来讲由于aof的记录能够精确到秒级追加甚至逐条追加，而rdb只能是全量复制，aof明显高于rdb。但是从性能来讲rdb就略胜一筹，rdb是redis性能最大化的体现，它不用每秒监控是否有数据写入，当达到触发条件后就自动fork一个子进程进行全量更新，速度也很快。容灾恢复方面rdb更是能够快速的恢复数据，而aof需要读取再写入，相对慢了很多。

avatar
文章
阅读
粉丝