redis学习七-持久化

最新推荐文章于 2022-04-07 13:18:50 发布

孟诸

最新推荐文章于 2022-04-07 13:18:50 发布

阅读量725

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/qq_35930102/article/details/108379151

版权

redis 专栏收录该内容

10 篇文章 1 订阅

订阅专栏

1 RDB

1.1 触发机制

1.1.1 手动触发

通过执行save或bgsave命令来执行

1.1.2 自动触发

使用save相关配置，save m n，表示m秒内有n次数据修改的时候自动触发bgsave
执行debug reload重新加载redis时也会触发bgsave命令
执行shutdown时，如果没有开启AOF，也会自动执行bgsave

1.2 流程说明

1）执行bgsave命令，父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在直接返回
2）父进程执行fork命令创建子进程，fork命令执行过程中父进程会阻塞，通过执行info stats命令查看latest_fork_usec选项，可以查看最后一次fork命令耗时，单位微秒
3）父进程fork完后，bgsave命令返回“Background saving started”信息表示不再阻塞父进程，父进程可以继续响应其他命令
4）子进程创建RDB文件，根据父进程内存临时生成的快照文件，完成对原有文件的原子替换。执行lastsave命令可以获取最后一次RDB时间，对应info统计的rdb_last_save_time
5）子进程发送信号给父进程表示完成，父进程更新统计信息

1.3 RDB文件处理

RDB文件保存在dir配置的指定目录下，文件名通过dbfilename配置指定。
dir ./
dbfilename dump.rdb

1.4 优缺点

1.4.1 优点

1）RDB是一个紧凑压缩的二进制文件，代表redis某个时间的快照，适用于备份、全量复制场景。如每6h执行一次bgsave保存一下RDB文件，用于容灾恢复
2）redis加载RDB速度远高于AOF

1.4.2 缺点

RDB方式没办法达到秒级持久化/实时持久化。因为bgsave每次运行都要执行fork操作创建子进程，这是个重量级操作，频繁执行成本太高
RDB文件用二进制格式保存，新老版本可能存在兼容问题

1.5 日志

RDB日志如下
2669:C 03 Sep 2020 11:08:58.384 * DB saved on disk
2669:C 03 Sep 2020 11:08:58.386 * RDB: 8 MB of memory used by copy-on-write
2657:M 03 Sep 2020 11:08:58.420 * Background saving started by pid 2669
2657:M 03 Sep 2020 11:08:58.433 * Background saving terminated with success

2 AOF

2.1 使用AOF

开启AOF需要设置配置：appendonly yes
AOF文件名：appendfilename "appendonly.aof"
保存路径同RDB

2.2 流程说明

1）所有的命令会追加到aof缓冲区
2）aof缓冲区根据对应的策略向硬盘同步
   通过appendfsync控制
   always：命令写入aof_buf中后调用系统fsync操作同步到aof文件，fsync完成后线程返回
   everysec：命令写入aof_buf中后调用系统write操作，write完成后返回，fsync同步文件操作由专门线程每秒钟调用一次
   no：命令写入aof_buf中后调用系统write操作，不对aof文件做fsync同步，同步硬盘操作由操作系统负责，同步周期最长30s
3）随着aof文件越来越大，需要定期对aof进行重写压缩
4）redis重启后可以加载aof文件进行恢复

2.3 aof重写说明

aof重写降低了文件占用空间，同时，更小的aof文件可以被更快加载

2.3.1 aof重写文件变小

重写后的aof文件比原文件要小，主要有以下几个原因

进程内已经超时的数据不再写入文件
旧的aof文件有无效命令，如del，hdel等，重写使用进程内的数据直接生成，这样aof文件只保留最终数据写入命令
将多个命令合成一个，如lpush list a，lpush list b，lpush list c合成lpush list a b c，为了防止单条命令过大造成客户端缓冲区溢出，以64个元素为界拆分成多条

2.3.2 触发机制

1）自动触发
auto-aof-rewrite-min-size 64mb：运行aof重写时文件最小体积
auto-aof-rewrite-percentage 100：当前aof文件空间和上一次重写后aof文件空间的比值(aof_current_size/aof_base_size)，这两个信息可以在info persistence中查看
当两个条件都满足的时候会进行重写
2）手动触发
执行bgrewriteaof命令

2.3.3 aof重写过程

1）执行aof重写请求，如果当前进程正在执行aof重写则直接返回；如果当前进程正在执行bgsave则等待bgsave完成后再执行
2）父进程执行fork命令创建子进程
3）主进程fork操作完成后继续响应其他命令，所有操作依然写入aof缓冲区和同步到硬盘，确保原有aof机制。由于fork操作运用写时复制技术，子进程只能共享fork时刻的快照，新的命令需要同步到aof重写缓冲区保存新数据
4）子进程根据内存快照，按照命令合并规则写入到新的aof文件。
5）新aof文件写入完成后子进程发送信号给父进程，父进程更新统计信息
6）父进程把aof重写缓冲区的数据写入到新aof文件
7）使用新aof文件替换老aof文件，完成aof重写

2.4 优缺点

2.4.1 优点

数据更完整，秒级数据丢失(取决于设置fsync策略)。
兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容，再者aof文件是明文的，可阅读性较好。

2.4.2 缺点

数据文件体积较大,即使有重写机制，但是在相同的数据集情况下，AOF文件通常比RDB文件大。
相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB。
由于频繁地将命令同步到文件中，AOF持久化对性能的影响相对RDB较大，但是对于我们来说是可以接受的。

2.5 日志

aof日志如下
2657:M 03 Sep 2020 11:04:42.836 * Background append only file rewriting started by pid 2666
2657:M 03 Sep 2020 11:04:43.057 * AOF rewrite child asks to stop sending diffs.
2666:C 03 Sep 2020 11:04:43.057 * Parent agreed to stop sending diffs. Finalizing AOF...
2666:C 03 Sep 2020 11:04:43.057 * Concatenating 0.00 MB of AOF diff received from parent.
2666:C 03 Sep 2020 11:04:43.057 * SYNC append only file rewrite performed
2666:C 03 Sep 2020 11:04:43.058 * AOF rewrite: 6 MB of memory used by copy-on-write
2657:M 03 Sep 2020 11:04:43.144 * Background AOF rewrite terminated with success
2657:M 03 Sep 2020 11:04:43.144 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
2657:M 03 Sep 2020 11:04:43.144 * Background AOF rewrite finished successfully

3 混合模式

redis4.0之后支持混合持久化。混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据，缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性

3.1 开启混合持久化

配置aof-use-rdb-preamble参数，yes表示开启

3.2 混合持久化过程

混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据