【Redis 5 教程 Redis持久化 】 Redis的数据到底放在哪儿？如何保存数据？

概述

• Redis与传统数据库的一个主要区别在于，Redis把所有数据都存储在内存中，而传统数据库通常只会把数据的索引存储在内存中，并将实际的数据存储在硬盘中。
• 为了满足不同的持久化需求，Redis提供了RDB持久化、AOF持久化和RDB-AOF混合持久化等多种持久化方式以供用户选择。如果用户有需要，也可以完全关闭持久化功能，让服务器处于无持久化状态。
• RDB持久化是全量持久化，AOF持久化是增量持久化

持久化方式

• RDB(Redis DataBase) 持久化
• AOF（append only file）持久化
• RDB-AOF混合持久化
• 如果用户有需要，也可以完全关闭持久化功能，让服务器处于无持久化状态。

RDB 持久化

简介

• RDB持久化是Redis默认使用的持久化功能
• 该功能可以创建出一个经过压缩的二进制文件，其中包含了服务器在各个数据库中存储的键值对数据等信息。RDB持久化产生的文件都以．rdb后缀结尾，其中rdb代表Redis DataBase（Redis数据库）。

命令

SAVE：阻塞服务器并创建RDB文件

• 用户可以通过执行SAVE命令，要求Redis服务器以同步方式创建出一个记录了服务器当前所有数据库数据的RDB文件

BGSAVE：以非阻塞方式创建RDB文件

• Redis提供了SAVE命令的异步版本BGSAVE命令：BGSAVE
• 它与SAVE命令的不同之处在于，BGSAVE不会直接使用Redis服务器进程创建RDB文件，而是使用子进程创建RDB文件。
• 因为BGSAVE命令是以异步方式执行的，所以Redis服务器在BGSAVE命令执行期间仍然可以继续处理其他客户端发送的命令请求。

通过配置选项自动创建RDB文件

• 通过设置save选项，让Redis服务器在满足指定条件时自动执行BGSAVE命令

save <seconds> <changes>

• save选项接受seconds和changes两个参数，简单来说，如果服务器在seconds秒之内，对其包含的各个数据库总共执行了至少changes次修改，那么服务器将自动执行一次BGSAVE命令。

同时使用多个save选项

• Redis允许用户同时向服务器提供多个save选项，当给定选项中的任意一个条件被满足时，服务器就会执行一次BGSAVE

save 6000 100
save 600 1000
save 60 10000

• 那么当以下任意一个条件被满足时，服务器就会执行一次BGSAVE命令：
  • 在6000s（100min）之内，服务器对数据库执行了至少1次修改。
  • 在600s（10min）之内，服务器对数据库执行了至少100次修改。
  • 在60s（1min）之内，服务器对数据库执行了至少10000次修改。

默认设置

RDB持久化是Redis默认使用的持久化方式，如果用户在启动Redis服务器时，既没有显式地关闭RDB持久化功能，也没有启用AOF持久化功能，那么Redis默认将使用以下save选项进行RDB持久化：

save 60 10000
save 300 100
save 3600 1

SAVE命令和BGSAVE命令的选择

• SAVE命令在创建RDB文件期间会阻塞Redis服务器，所以如果我们需要在创建RDB文件的同时让Redis服务器继续为其他客户端服务，那么就只能使用BGSAVE命令来创建RDB文件。
• 因为SAVE命令无须创建子进程，它不会因为创建子进程而消耗额外的内存，所以在维护离线的Redis服务器时，使用SAVE命令能够比使用BGSAVE命令更快地完成创建RDB文件的工作。

数据丢失

SAVE命令的停机情况

• SAVE命令是一个同步操作，它的开始和结束都位于同一个原子时间之内，所以如果用户使用SAVE命令进行持久化，那么服务器在停机时将丢失最后一次成功执行SAVE命令之后产生的所有数据。

BGSAVE命令的停机情况

• 因为BGSAVE命令是一个异步命令，它的开始和结束并不位于同一个原子时间之内，所以如果用户使用BGSAVE命令进行持久化，那么服务器在停机时丢失的数据量将取决于最后一次成功执行的BGSAVE命令的开始时间。

注意

• 注意，为了避免由于同时使用多个触发条件而导致服务器过于频繁地执行BGSAVE命令，Redis服务器在每次成功创建RDB文件之后，负责自动触发BGSAVE命令的时间计数器以及修改次数计数器都会被清零并重新开始计数：无论这个RDB文件是由自动触发的BGSAVE命令创建的，还是由用户执行的SAVE命令或BGSAVE命令创建的，都是如此。

ROF的缺点

• 无论用户使用的是SAVE命令还是BGSAVE命令，停机时服务器丢失的数据量将取决于创建RDB文件的时间间隔：间隔越长，停机时丢失的数据也就越多。
• RDB持久化是一种全量持久化操作，它在创建RDB文件时需要存储整个服务器包含的所有数据，并因此消耗大量计算资源和内存资源
• 用户如果想要保证服务器的性能处于合理水平，就不能过于频繁地创建RDB文件，这样一来，也就不可避免地会出现因为停机而丢失大量数据的情况

AOF 持久化

简介

• 服务器每次执行完写命令之后，都会以协议文本的方式将被执行的命令追加到AOF文件的末尾。这样一来，服务器在停机之后，只要重新执行AOF文件中保存的Redis命令，就可以将数据库恢复至停机之前的状态。
  
• 可以看到，随着服务器不断地执行命令，被执行的命令也会不断地被保存到AOF文件中，这样一来，即使服务器在T4停机，它也可以在重启时通过重新执行AOF文件包含的命令来恢复数据。

打开AOF持久化功能

• 用户可以通过服务器的appendonly选项来决定是否打开AOF持久化功能

appendonly <value>

设置AOF文件的冲洗频率

• AOF文件的冲洗机制将直接影响AOF持久化的安全性。为了消除上述机制带来的不确定性，Redis向用户提供了appendfsync选项，以此来控制系统冲洗AOF文件的频率

appendfsync <value>

• appendfsync选项拥有always、everysec和no 3个值可选

  • always — 每执行一个写命令，就对AOF文件执行一次冲洗操作。
  • everysec — 每隔1s，就对AOF文件执行一次冲洗操作。
  • no — 不主动对AOF文件执行冲洗操作，由操作系统决定何时对AOF进行冲洗。

• 这3种不同的冲洗策略不仅会直接影响服务器在停机时丢失的数据量，还会影响服务器在运行时的性能：

  • always，服务器在停机时最多只会丢失一个命令的数据，但使用这种冲洗方式将使Redis服务器的性能降低至传统关系数据库的水平。
  • everysec，服务器在停机时最多只会丢失1s之内产生的命令数据，兼顾性能和安全性的折中方案，是Redis默认选项
  • no，服务器在停机时将丢失系统最后一次冲洗AOF文件之后产生的所有命令数据，至于数据量的具体大小则取决于系统冲洗AOF文件的频率。

AOF重写

• 随着服务器不断运行，被执行的命令将变得越来越多，而负责记录这些命令的AOF文件也会变得越来越大。如果服务器曾经对相同的键执行过多次修改操作，那么AOF文件中还会出现多个冗余命令。
• Redis提供了AOF重写功能，该功能能够生成一个全新的AOF文件，并且文件中只包含恢复当前数据库所需的尽可能少的命令。

• 用户可以通过执行BGREWRITEAOF命令或者设置相关的配置选项来触发AOF重写操作
  • BGREWRITEAOF命令
  • AOF重写配置选项

AOF 优缺点

优点

• 与RDB持久化可能会丢失大量数据相比，AOF持久化的安全性要高得多：通过使用everysec选项，用户可以将数据丢失的时间窗口限制在1s之内。

缺点

• 因为AOF文件存储的是协议文本，所以它的体积会比包含相同数据、二进制格式的RDB文件要大得多，并且生成AOF文件所需的时间也会比生成RDB文件所需的时间更长。
• 因为RDB持久化可以直接通过RDB文件恢复数据库数据，而AOF持久化则需要通过执行AOF文件中保存的命令来恢复数据库（前者是直接的数据恢复操作，而后者则是间接的数据恢复操作），所以RDB持久化的数据恢复速度将比AOF持久化的数据恢复速度快得多，并且数据库体积越大，这两者之间的差距就会越明显。
• 因为AOF重写使用的BGREWRITEAOF命令与RDB持久化使用的BGSAVE命令一样都需要创建子进程，所以在数据库体积较大的情况下，进行AOF文件重写将占用大量资源，并导致服务器被短暂地阻塞。

参考链接

黄健宏| Redis使用手册
redis持久化的几种方式