redis 9.Redis持久化之AOF (AOF和RDB同时开启统默认取AOF的数据、AOF启动/修复/恢复)， redis如何选择使用哪种持久化方式 ？

---

一.AOF

1.1 AOF概念

  以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只追加文件但不改写文件，redis启动之初会读取aof文件重新构建数据，即redis 重启是根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

aof持久化流程:

  （1）客户端发送请求（写命令）会被append追加到AOF缓冲区内；
  （2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的aof文件中；
  （3）aof文件大小超过重写策略或手动重写时，进程rewrite重写，压缩aof文件容量；
  （4）Redis服务重启时，会重新load加载aof文件中的写操作达到数据恢复的目的；

1.2 AOF配置

  在redis.conf中修改appendonly参数为yes，启用AOF;可配置文件名称，默认为 appendonly.aof（aof文件的保存路径，同rdb的路径一致）

重启redis，此时数据持久化存在2种机制AOF和RDB, 同时启用aof和rdb默认会使用aof文件加载数据

连接redis发现无数据，不会读取rdb文件数据

1.3 AOF启动/修复/恢复

  AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下

（1）正常恢复：
  修改默认的appendonly no，改为yes
  将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

  恢复：重启redis然后重新加载

（2）异常恢复：
  如遇到AOF文件损坏，通过 /usr/local/bin/redis-check-aof --fix appendonly.aof 进行恢复

如：
破坏appendonly.aof，在文件末尾加上字符串

重新启动redis,失败

修复文件：

乱加的字符串被处理

重启redis 连接正常

1.4 AOF同步频率设置

appendfsync always
  始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec
  每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no
  redis不主动进行同步，把同步时机交给操作系统。

1.5 Rewrite压缩

1.5.1 概念：

  AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可恢复数据的最小指令集.

使用命令:

bgrewriteaof

1.5.2 重写流程

  Redis 执行 fork() ，同时拥有父进程和子进程
  子进程开始将新 aof 文件的内容写入到临时文件
  对于所有新执行的写入命令，父进程一边累积到内存缓存中，一边继续追加到现有 AOF 文件的末尾,这样即使在重写过程中发生停机，不影响现有的 AOF 文件
  当子进程完成重写工作时，给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾
  用新文件替换旧文件，之后所有命令直接追加到新 AOF 文件的末尾

no-appendfsync-on-rewrite：

   no-appendfsync-on-rewrite参数设置为yes ， 只写入缓存，不写入aof文件，用户请求不会阻塞，但是如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
   no-appendfsync-on-rewrite参数设置为no ，仍然把数据写入磁盘里，可能会发生阻塞。（数据安全，但是性能降低）

1.5.3 重写触发机制

  Redis会记录上次重写时aof文件大小，当 aof文件大小 >上次rewrite后aof文件大小 *（1+auto-aof-rewrite-percentage）且aof文件大小>auto-aof-rewrite-min-size时触发重写

auto-aof-rewrite-percentage：设置重写的基准值，默认文件超出100%时开始重写
auto-aof-rewrite-min-size：设置重写的基准值，默认最小文件64MB

如：
aof文件达到70MB开始重写，降到50MB，默认情况下，下次什么时候开始重写？（100MB）

  系统载入时或者上次重写完毕时，Redis会记录此时aof文件大小，设为base_size。若Redis的aof当前文件大小>= base_size *（1+100%）且大于64mb的情况下，Redis会对AOF进行重写。

1.6 优势劣势

优势：
  使用不同的fsync策略,Redis的性能保持的非常好(fsync是由后台线程进行处理的,主线程处理客户端请求)。一旦出现故障，默认采用appendfsync everysec策略，最多丢失1秒的数据

  aof文件是一个只进行追加的日志文件,即使由于某些原因(磁盘空间已满，写的过程中宕机等)未执行完整的写入命令，可使用redis-check-aof工具修复

  Redis 在 aof 文件体积变得过大时，自动地在后台对 AOF 进行bgrewriteaof：重写后的新aof文件包含恢复当前数据集所需的最小命令集合。 整个重写操作绝对安全，子进程重写aof不影响主进程AOF追加日志

  aof文件以 Redis 协议的格式有序地保存了对数据库执行的所有写入操作， 因此 aof 文件的内容容易被人读懂。 假设不小心执行了 FLUSHALL 命令， 只要 AOF 文件未被重写， 那么只要停止服务器， 移除 aof 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态

劣势：
  对于相同的数据集来说，aof文件的体积通常要大于rdb 文件的体积
  根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下，appendfsync everysec的性能依然非常高， 不过在处理海量的写入时，rdb更有保证

---

二. 如何选择使用哪种持久化方式 ？

  一般来说， 如果想媲美 PostgreSQL 的数据安全性， 应同时使用两种持久化功能

  如果可以承受数分钟以内的数据丢失， 那么可以只使用 RDB 持久化

  有许多用户只使用 AOF 持久化， 但并不推荐： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 可避免 AOF 程序的 bug

---

三.怎样从RDB方式切换为AOF方式?

  在 Redis 2.2 或以上版本，可在不重启的情况下，从 RDB 切换到 AOF ：

(1) 为最新的 dump.rdb 文件创建一个备份,并存储备份到文件服务器；

(2) 关闭rdb

执行以下两条命令:

config set appendonly yes
config set save ""

  执行的第一条命令开启AOF 功能, Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求并开始将写入命令追加到 AOF 文件末尾。
  执行的第二条命令关闭 RDB 功能。 这一步是可选的， 也可以同时使用 RDB 和 AOF 这两种持久化功能

保存修改的配置

config rewrite