Redis的RDB和AOP总结

目录

1.RDB和AOF是什么

2.RBD

     2.1 配置参数

          2.1.1 配置文件位置

          2.1.2 save

          2.1.3 stop-writes-on-bgsave-error

          2.1.4 rdbcompression

          2.1.5 rdbchecksum

          2.1.6 dbfilename

          2.1.7 dir

     2.2 fork

     2.3 如何触发RDB快照

          2.3.1 配置文件中默认的快照配置

          2.3.2 客户端使用命令save或者bgsave

          2.3.3 客户端shutdown会立刻刷新dump.rdb文件

     2.4 如何恢复

     2.5 RBD的优势

     2.6 RBD的劣势

3.AOF

     3.1 配置参数

          3.1.1 配置文件位置

          3.1.2 appendonly

          3.1.3 appendfilename

          3.1.4 appendfsync

          3.1.5 no-appendfsync-on-rewrite

          3.1.6 auto-aof-rewrite-percentage

          3.1.7 auto-aof-rewrite-min-size

          3.1.8 aof-load-truncated

     3.2 AOF修复

     3.3 AOF恢复

     3.4 Rewrite重写机制

          3.4.1 Rewrite是什么

          3.4.2 重写原理

          3.4.3 触发机制

     3.5 AOF的优势

     3.6 AOF的劣势

---

1.RDB和AOF是什么

       其实很多答案技术官网都有写而且写的非常详细，官网地址：https://redis.io/topics/persistence

       RDB (Redis Database)：按指定的时间间隔执行数据集的时间点快照

       AOF (Append Only File)：记录服务器接收的每个写入操作，采用仅追加方式将命令写入AOF文件，服务启动时再重新执行AOF文件中的命令以达到恢复数据的目的。使用与Redis协议本身相同的格式记录命令，具有很好的可读性。当日志太大时，Redis可以在后台重写日志（rewrite机制）。 

2.RBD

     2.1 配置参数

          2.1.1 配置文件位置

       redis.conf中SNAPSHOTTING部分

          2.1.2 save

       如果给定的秒数和对数据库执行的写入操作数都达到设定的阈值，则执行数据库持久化，通俗易懂的讲：配置RBD备份频率，默认行为：

1. 900秒（15分钟）后，如果至少有一个键更改
2. 300秒（5分钟）后，如果至少有10个键更改
3. 60秒后，如果至少10000个键发生更改

          2.1.3 stop-writes-on-bgsave-error

默认情况下，如果启用RDB快照，Redis将停止接受写操作。这将使用户意识到（通过报错的方式）数据没有持久化。如果后台保存过程将重新开始工作，Redis将自动允许再次写入。但是，如果您已经设置了对Redis服务器的适当监视和持久性，您可能希望禁用此功能。通俗易懂的讲：此参数设为no，表示在进行RDB持久化时主进程将停止接受读写操作；设置成yes，表示在进行RDB持久化时主进程将继续接受读写操作，数据不一致的问题交由用户自己处理。

          2.1.4 rdbcompression

       对于存储到磁盘中的快照文件，设置是否进行压缩，redis采用LZF压缩算法，如果想节省CPU性能可以关闭此功能，默认yes。

          2.1.5 rdbchecksum

       存储快照后，还可以让redis使用CRC64算法进行数据校验，但是这样做大约会增加10%性能损耗，如果想获得最大性能可关闭此功能，默认yes。

          2.1.6 dbfilename

       将数据库转储到的文件名，默认dump.rdb

          2.1.7 dir

       工作目录，数据库中的数据将被写入这个目录，请注意必须在此处指定目录，而不是文件名，默认当前路径。

     2.2 fork

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

     2.3 如何触发RDB快照

          2.3.1 配置文件中默认的快照配置

save 900 1
save 300 10
save 60 10000

          2.3.2 客户端使用命令save或者bgsave

       save：执行save命令时只管保存，其他命令阻塞

       bgsave：bgsave命令会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间

          2.3.3 客户端shutdown会立刻刷新dump.rdb文件

       客户端使用shutdown会立刻刷新dump.rdb文件，前提是开启了RBD持久化

     2.4 如何恢复

       如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。获取 redis 目录可以使用 CONFIG 命令：

CONFIG GET dir

     2.5 RBD的优势

（1）RDB是Redis数据的非常紧凑的单文件时间点表示。例如，您可能希望在最近24小时内每小时归档一次RDB文件，并在30天内每天保存一个RDB快照。这允许您在发生灾难时轻松恢复数据集的不同版本。

（2）RDB对于灾难恢复非常好，它是一个单一的压缩文件，可以传输到远端的数据中心，或者传输到AmazonS3（可能是加密的）。

（3）RDB最大限度地提高了Redis的性能，因为Redis父进程要持久化，唯一需要做的工作就是派生一个子进程来完成其余的工作。父实例永远不会执行磁盘I/O或类似操作。

（4）与AOF相比，RDB允许使用大数据集更快地重新启动。

     2.6 RBD的劣势

（1）数据风险大，RDB采用在一定时间间隔内做一次备份，如果redis服务意外down掉，就会丢失最后一次未备份的修改

（2）fork子进程进行备份时，内存中的数据被克隆了一份，需要考虑数据2倍膨胀的问题

3.AOF

     3.1 配置参数

          3.1.1 配置文件位置

          3.1.2 appendonly

       仅附加文件是一种提供更好的耐用性。例如，使用默认数据fsync策略（请参阅后面的配置文件）Redis在一段时间内只会丢失一秒钟的写操作。AOF和RDB持久性可以同时启用而不会出现问题。如果启动时启用了AOF，Redis将加载AOF，即文件具有更好的耐久性保证。通俗易懂的讲：启用AOF持久化

          3.1.3 appendfilename

       仅附加文件的名称，默认：appendonly.aof

          3.1.4 appendfsync

       fsync（）调用告诉操作系统在磁盘上实际写入数据，而不是在输出缓冲区中等待更多的数据。appendfsync有三个参数，默认：everysec

       no：不要fsync，只要让操作系统在需要时刷新数据即可，更快。

       always：每次执行写入操作后进行fsync。慢，最安全。

       everysec：每秒同步一次。

          3.1.5 no-appendfsync-on-rewrite

       重写时（下面会讲到rewrite）是否可以使用appendfsync，默认：no，可以保证数据安全性。

          3.1.6 auto-aof-rewrite-percentage

       设置重写规则（下面会讲到rewrite）的文件大小倍率基准值，默认：100，代表含义为AOF文件大小超过上次重写AOF文件的一倍时则进行重写

          3.1.7 auto-aof-rewrite-min-size

       设置重写规则（下面会讲到rewrite）的文件大小基准值，默认：64mb，代表含义为AOF文件大小超过64mb则进行重写

          3.1.8 aof-load-truncated

       在Redis过程中，可能会发现AOF文件在末尾被截断的情况。如果aof load truncated设置为yes，则加载并删除一个截断的aof文件，Redis服务器会发出一个日志来通知用户该事件。否则，如果该选项设置为“否”，则服务器将中止并返回一个错误。当选项设置为“否”时，用户需要在重新启动之前，使用“redis check AOF”实用程序修复AOF文件。如果在加载过程中发现AOF文件已损坏，那么服务器仍将退出并出现错误。默认：yes

     3.2 AOF修复

       运行根目录下redis-check-aof --fix进行修复

     3.3 AOF恢复

       将appendonly.aof文件移动到redis根目录并启动服务

     3.4 Rewrite重写机制

          3.4.1 Rewrite是什么

       AOF采用文件追加的方式，会导致文件越来越大，为了避免出现此种情况，新增了持久化重写机制，当AOF文件大小超过了所设定的阈值，redis就会启用AOF的文件压缩，使得AOF文件只保留可以恢复数据的最小指令集，客户端可以使用bgrewriteaof命令来启动AOF重写

          3.4.2 重写原理

       随着AOF文件持续增长过大时，redis会fork 出一条新进程来将文件重写（也是先写临时文件最后rename ) , 遍历新进程的内存中数据，每条记录有一条的 Set 语句。重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据内容用命令的方式重写了一个新的 aof 文件。

          3.4.3 触发机制

       redis会记录上次重写时AOF文件的大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大小大于64M时触发。也就是上文3.1.6、3.1.7的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数

     3.5 AOF的优势

（1）使用AOF可以设置不同的fsync策略：完全不fsync，每秒fsync，每次查询fsync。使用fsync every second的默认策略，对于服务器执行写操作依旧可以保持不错的性能（fsync是使用后台线程执行的，当没有fsync进行时，主线程将努力执行写操作），但是您可能损失1秒的写操作。

（2）AOF日志是一个只附加的日志，因此在断电的情况下没有查找和损坏问题。即使由于某种原因（磁盘已满或其他原因）日志以半写命令结束，redis check aof工具也能够轻松地修复它。

（3）Redis能够在后台自动重写AOF。重写是完全安全的，因为当Redis继续附加到旧文件时，用创建当前数据集所需的最小操作集生成一个完全新的文件，并且一旦第二个文件准备就绪，Redis就会切换这两个文件并开始附加到新文件。

（4）AOF以易于理解和解析的格式存储了每个写操作日志记录，可以轻松导出AOF文件。例如，即使您不小心用FLUSHALL命令刷新了所有内容，只要在此期间没有重写日志，您仍然可以通过停止服务器、删除最新命令并重新启动Redis来保存数据集。

     3.6 AOF的劣势

（1）对于相同的数据集，AOF文件通常比等效的RDB文件大。

（2）AOF可能比RDB慢，具体取决于fsync策略。一般来说，fsync设置为每秒一次时，性能仍然非常高，禁用fsync时，即使在高负载下，它也应该与RDB一样快。

（3）在使用AOF时可能遇到十分罕见的错误（几乎可忽略不计），使用RDB持久性几乎不可能出现这种错误。