Rides中RDB与AOF

redis持久化

由于 Redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，
这与传统的MySQL，Oracle等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。为了解决这个缺点，Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。
Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）

RDB快照

概述

RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。
触发方式：
RDB 有两种触发方式，分别是自动触发和手动触发

自动触发

################################ 快照 #################################
#保存数据到磁盘，格式如下:
#save
#指出在多长时间内，有多少次更新操作，就将数据同步到数据文件rdb。
#相当于条件触发抓取快照，这个可以多个条件配合
#比如默认配置文件中的设置，就设置了三个条件
#save 900 1 900秒内至少有1个key被改变
#save 300 10 300秒内至少有10个key被改变
#save 60 10000 60秒内至少有10000个key被改变
save 900 1
save 300 10
save 60 10000
#存储至本地数据库时（持久化到rdb文件）是否压缩数据，默认为yes
rdbcompression yes
#本地持久化数据库文件名，默认值为dump.rdb
dbfilename dump.rdb
#工作目录
#数据库镜像备份的文件放置的路径。
#这里的路径跟文件名要分开配置是因为redis在进行备份时，先会将当前数据库的状态写入到一个临时文件中，
等备份完成时，
#再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路
径当中。
#AOF文件也会存放在这个目录下面
#注意这里必须制定一个目录而不是文件
dir ./

save： 这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如：
“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍，手动触发RDB持久化的命令）。
rdbcompression ：默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了。
rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
dbfilename ：设置快照的文件名，默认是 dump.rdb
dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录

手动触发

手动触发Redis进行RDB持久化的命令有两种：
save：该命令会阻塞当前Redis服务器，执行save命令期间，redis不能处理其他命令，直到RDB过程完成为止。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，redis提供了第二种方式。(不建议使用)
bgsave：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在创建子进程fork阶段，一般时间很短。
基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

还有两种特殊的操作也能触发RDB的持久化，但是因为情况特殊，所以不作为手动触发条件
#执行执行 flushall.flushdb 命令，也会产生dump.rdb文件，但里面是空的，无意义
#关闭redis 服务同样会生成 — 规则使用 bgsave 保存数据

RDB的数据恢复

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。
Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。
启动服务器的当前目录一定是redis-*** 否则快照生成的路径就会发生错误！

停止RDB持久化

有些情况下，我们只想利用Redis的缓存功能，并不像使用 Redis 的持久化功能，那么这时候我们最好停掉RDB 持久化。可以通过上面讲的在配置文件 redis.conf 中，可以注释掉所有的 save 行来停用保存功能或者直接一个空字符串来实现停用：save""

RDB 的优势和劣势

1. RDB是一个非常紧凑的文件(默认压缩)，它保存redis 在某个时间点上的数据集。这种文件非常适合用于备份和灾难恢复。
2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
   劣势
4. RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进
   程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影
   响性能)
5. RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
6. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

RDB自动保存的原理

AOF优势

AOF的概述

Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF则是通过保存Redis服务器所执行的写命令来记录数据库状态。
AOF以协议文本的方式，将所有对数据库进行写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。
用日志的形式来记录每个操作，将redis执行过的所有的指令都记录下来(读操作不记录)，只许追加文件但不可以写文件，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次，已完成数据文件的恢复工作。

AOF配置

位置：cd /opt/redis-7.0.5/redis.conf

大概：

解析：

############################## AOF ###############################
#默认情况下，redis会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频
繁，
#如果发生诸如拉闸限电、拔插头等状况，那么将造成比较大范围的数据丢失。
#所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式。
#开启append only模式之后，redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中，
#当redis重新启动时，会从该文件恢复出之前的状态。
#但是这样会造成appendonly.aof文件过大，所以redis还支持了BGREWRITEAOF指令，对appendonly.aof
进行重新整理。
#你可以同时开启asynchronous dumps 和 AOF
appendonly no
#AOF文件名称 (默认: “appendonly.aof”)
appendfilename appendonly.aof
#Redis支持三种同步AOF文件的策略:
#no: 不进行同步，系统去操作 . Faster.
#always: always表示每次有写操作都进行同步. Slow, Safest.
#everysec: 表示对写操作进行累积，每秒同步一次. Compromise.
#默认是"everysec"，按照速度和安全折中这是最好的。
#如果想让Redis能更高效的运行，你也可以设置为"no"，让操作系统决定什么时候去执行
#或者相反想让数据更安全你也可以设置为"always"
#如果不确定就用 “everysec”.
#appendfsync always
appendfsync everysec
#appendfsync no
#AOF策略设置为always或者everysec时，后台处理进程(后台保存或者AOF日志重写)会执行大量的I/O操作
#在某些Linux配置中会阻止过长的fsync()请求。注意现在没有任何修复，即使fsync在另外一个线程进行处理
#为了减缓这个问题，可以设置下面这个参数no-appendfsync-on-rewrite
#This means that while another child is saving the durability of Redis is
#the same as “appendfsync none”, that in pratical terms means that it is
#possible to lost up to 30 seconds of log in the worst scenario (with the
#default Linux settings).
If you have latency problems turn this to “yes”. Otherwise leave it as
#“no” that is the safest pick from the point of view of durability.
no-appendfsync-on-rewrite no
#Automatic rewrite of the append only file.
#AOF 自动重写
#当AOF文件增长到一定大小的时候Redis能够调用 BGREWRITEAOF 对日志文件进行重写
#它是这样工作的：Redis会记住上次进行些日志后文件的大小(如果从开机以来还没进行过重写，那日子大小在开
机的时候确定)
#基础大小会同现在的大小进行比较。如果现在的大小比基础大小大制定的百分比，重写功能将启动
#同时需要指定一个最小大小用于AOF重写，这个用于阻止即使文件很小但是增长幅度很大也去重写AOF文件的情况
#设置 percentage 为0就关闭这个特性
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

**

文件的解释：

**

appendonly：默认值为no，也就是说redis 默认使用的是rdb方式持久化，如果想要开启 AOF 持久化方式，需要将appendonly 修改为 yes。
appendfilename ：aof文件名，默认是"appendonly.aof"
appendfsync：aof持久化策略的配置；

1. no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
2. always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
3. everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。(默认)
   no-appendfsync-on-rewrite：在aof重写或者写入aof文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。
   auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
   auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
   aof-load-truncated：**aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。

开启AOF

默认不开启，需要手动开启 - AOF和RDB同时开启 ，默认走AOF策略

注意配置完成后重启redis，并set几个值，# vim查看aof文件
#7.04 版本 aof文件存储已经更改到appendonlydir文件夹下，对应去查找 appendonly.aof.1.incr.aof

AOF文件故障修复

通过redis-check-aof --fix 工具 修复文件

redis-check-aof --fix appendonly6379.aof.2.incr.aof

修复后重启redis

AOF文件重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof 来重写。

bgrewriteaof 

也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
AOF 重写触发机制：
通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewrite-minsize：64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

AOF的优缺点

优点：

1. AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，最多也就丢失1秒的数据而已。
2. AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
3. AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF来恢复数据。
   缺点：
4. 对于具有相同数据的的 Redis，AOF 文件通常会比 RDB 文件体积更大。
5. 虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis的负载较高时，RDB 比 AOF 具好更好的性能保证。
6. RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在RDB 没有存在。

关于RDB和AOF的思考和选择

如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，而且使用 RDB 还可以避免 AOF 一些隐藏的 bug；否则就使用 AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。Redis后期官方可能都有将两种持久化方式整合为一种持久化模型