Redis持久化
有两种持久化方式：
- RDB （Redis DB；默认开启；类比于 HDFS 的 fsimage）
- AOF （Append Only File；类比于 HDFS 的 edits log）
1. RDB
在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。
1.1 持久化策略
-
自动执行：
按照配置文件中的条件满足就执行 BGSAVE-
默认配置
save 900 1
save 300 10
save 60 10000只要上面三个条件满足一个，就自动执行备份。
创建RDB文件之后，时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的 持久化文件默认目录
dir /var/lib/redis/6379
-
-
手动执行：
客户端发起 SAVE、BGSAVE 命令。
1.2 具体方式
- save（阻塞）
- bgsave（非阻塞）
（1）SAVE
阻塞 Redis 服务，无法响应客户端请求，创建新的 dump.rdb 替代旧文件；生产环境很少这样做，一般都是停机维护时期才考虑
（2）BGSAVE
非阻塞，Redis 服务正常接收处理客户端请求，Redis 会 fork()一个新的子进程来创建 RDB 文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕，父进程用新的 dump.rdb 替代旧文件。BGSAVE 是一个异步命令。
1.3 RDB的工作流程：
（1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
（2）父进程执行fork操作创建子进程（拷贝父进程所有数据的引用），fork操作过程中父进程被阻塞。
（3）父进程fork完成后，bgsave命令返回“* Background saving started by pid xxx”信息，并不再阻塞父进程，可以继续响应其他命令。
（4）父进程创建新的RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。根据lastsave命令可以获取最近一次生成RDB的时间，对应info Persistence中的rdb_last_save_time。
（5）子进程完成持久化操作后，通知父进程完成，父进程更新统计信息。
对于大多数操作系统来说，fork都是个重量级操作，虽然创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。子进程通过fork操作产生，占用内存大小等同于父进程，理论上需要两倍的内存来完成持久化操作。
但Linux有写时复制机制（copy-on-write），子进程拷贝父进程所有数据的引用而不是复制数据本身，如果在 bgsave 过程中客户端修改了父进程的内存，比如发生了写操作，那么父进程将开辟一个新的空间来存储修改的这个数据。
1.4 配置
[root@node01 redis]# vi /etc/redis/6379.conf
#默认情况下 redis 不是作为守护进程运行的，设置为 yes 让它在后台运行
daemonize yes
#端口号
port 6379
#日志级别
loglevel notice
#日志位置
logfile /var/log/redis_6379.log
#一个 redis 实例最多可以包含多少个数据库
databases 16
# Save the DB on disk:
save 900 1
save 300 10
save 60 10000
# The filename where to dump the DB
dbfilename dump.rdb
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
dir /var/lib/redis/6379
#如果启动多个 redis，最好指定每个占用的内存
# maxmemory <bytes>
1.5 RDB持久化优缺点
优点：
- 完全备份，不同时间的数据集备份可以做到多版本恢复
- 紧凑的单一文件，方便网络传输，适合灾难恢复
- 恢复大数据集速度较AOF快
缺点：
- 会丢失最近写入、修改的而未能持久化的数据
- fork过程比较耗时，会造成毫秒级不能响应客户端请求
1.6 生产环境操作
由于RDB模式备份不会保留旧版本，每次都会覆盖，所以，在实际运用中需要将备份文件定时拷贝至其他目录，大致操作如下：
（1）创建一个定时任务cron job，每小时或者每天将 dump.rdb 复制到指定目录确保备份文件名称带有日期信息，便于管理和还原对应的时间点的快照版本。
（2）定时任务删除过期的备份
（3）如果有必要，跨物理主机、跨机架、异地备份
2. AOF
Append only file，采用追加的方式保存，默认文件 appendonly.aof，记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库。调整 AOF 持久化策略，可以在 服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于 RDB 损失小得多。
2.1 AOF 写入机制
AOF 方式不能保证绝对不丢失数据，目前常见的操作系统中，执行系统调用 write 函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里 面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行 fsync 调用和 fdatasync 调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失 。
2.2 写入磁盘的策略*
appendfsync 选项： append file synchronize 这个选项的值可以是 always、everysec 或者 no 。
always： 服务器每写入一个命令，就调用一次 fdatasync，将缓冲区里面的命令写入到硬 盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据 。
everysec（默认）： 服务器每一秒重调用一次 fdatasync，将缓冲区里面的命令写入到硬 盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据（缓冲区的量） 。
no： 服务器不主动调用 fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。 这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的 。
运行速度： always 的速度慢，everysec 和 no 都很快。
2.3 AOF 重写机制
- AOF 文件过大
-
合并重复的操作，AOF 会使用尽可能少的命令来记录
AOF文件重写前后
2.3.1 AOF重写触发
一旦使用AOF，RDB持久化方式即使开启也将不采纳，恢复的时候也是使用AOF文件恢复。
- 手动： 客户端向服务器发送 BGREWRITEAOF 命令
-
自动： 配置文件中的选项，以自动执行 BGREWRITEAOF 命令
auto-aof-rewrite-min-size <size> ：
触发 AOF 重写所需的最小体积（默认64MB），只要在 AOF 文件的 体积大于等于 size 时，才会考虑是否需要进行 AOF 重写，这个选项用于避免对体积过小的 AOF 文件进行重写，但随着精简后文件的增长，很可能会超过64MB，此时会陷入无限精简中，所以还行配置下面的参数。-
auto-aof-rewrite-percentage <percent>：
指定触发重写所需的 AOF 文件体积百分比（避免重写陷入死循环），当 AOF 文件的体积大于 auto-aof-rewrite-min-size 指定的体积，并且超过上一次重写之后的 AOF 文件体积的 percent %时，就会触发 AOF 重写。（如果服务器刚刚启动不久，还没有进 行过 AOF 重写，那么使用服务器启动时载入的 AOF 文件的体积来作为基准值）。将这个值 设置为 0 表示关闭自动 AOF 重写。比如： auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 当 AOF 文件大于 64MB 时候，可以考虑重写 AOF 文件 # 只有当 AOF 文件的增量大于起始 size 的 100%时（就是文件大小翻了一倍），启动重 appendonly yes # 默认关闭，请开启
2.3.2 重写过程
- 1 执行 AOF 重写请求
- 2 父进程执行 fork 创建子进程，开销等同于 bgsave 过程
- 3.1 主进程 fork 操作完成后，继续响应其他命令。所有修改命令依然写入 AOF 缓冲区，并根据appendfsync 策略同步到磁盘，保证原有 AOF 机制正确性。
- 3.2 由于 fork 操作运用写时复制技术，子进程只能共享 fork 操作时的内存数据。由于父进程依然响应命令，redis 使用“ AOF 重写缓冲区”保存这部分新数据，防止新 AOF 文件生成期间丢失这部分数据。
- 4 子进程根据内存快照，按照命令合并规则写入到新 AOF 文件。每次批量写入硬盘数据量由 aof-rewrite-incremental-fsync 控制，默认是32MB，防止单词刷盘数据过多造成硬盘阻塞。
- 5.1 新 AOF 文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
- 5.2 父进程把 AOF 重写缓冲区数据写入到新的 AOF 文件。
- 5.3 使用新AOF文件替换老文件，完成AOF重写。
注： 如果写入操作的时候出现故障导致命令写了“半截”，可以使用 redis-check-aof 工具修复
2.3.3 AOF 优缺点
-
优点
- 写入机制，默认 fysnc 每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
- 重写机制，优化 AOF 文件
- 如果误操作了（FLUSHALL 等），只要 AOF 未被重写，停止服务移除 AOF 文件尾部 FLUSHALL 命令，重启 Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
-
缺点
- 相同数据集，AOF 文件体积较 RDB 大了很多
- 恢复数据库速度比 RDB 慢（文本，命令重演）
