Redis数据持久化方式
RDB 全称Redis DataBase
AOF 全称 Append Of File
RDB和AOF工作原理
RDB
RDB工作原理是借助后台的bgsave命令去fork()一个子线程，fsync保存文件到磁盘上，是当前系统的一个快照
a. Redis执行bgsave命令，Redis判断是否有正在执行的bgsave命令
b. fork子进程
c. fork完成
d. 子进程对内存数据进行快照生成文件
e. 子进程告诉父进程完成
实现rdb的方式
a. save
b. bgsave
c. 自动执行 bgsave
配置方式
save 900 1 #在九百秒内有一个触发我就执行
save 300 10
save 60 10000
AOF
AOF是追加Redis的操作日志到文件中，可以类比Mysql的binlog文件
a. 所有命令写入追加到aof缓冲区
b. AOF缓冲区根据对应appendsync配置向硬盘做同步操作
c. 定期对AOF文件重写
d. Redis重启加载AOF文件进行恢复
可以手动执行bgrewriteaof 触发AOF,或定义自动rewrite 策略
手动执行AOF重写 BGREWRITEAOF 命令
BGREWRITEAOF
时间复杂度： O(N)， N 为要追加到 AOF 文件中的数据数量。
执行一个 AOF文件 重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
即使 BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 BGREWRITEAOF 成功之前不会被修改。
重写操作只会在没有其他持久化工作在后台执行时被触发，也就是说：
如果 Redis 的子进程正在执行快照的保存工作，那么 AOF 重写的操作会被预定(scheduled)，等到保存工作完成之后再执行 AOF 重写。在这种情况下， BGREWRITEAOF 的返回值仍然是 OK ，但还会加上一条额外的信息，说明 BGREWRITEAOF 要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本，可以使用 INFO [section] 命令查看 BGREWRITEAOF 是否被预定。
如果已经有别的 AOF 文件重写在执行，那么 BGREWRITEAOF 返回一个错误，并且这个新的
BGREWRITEAOF 请求也不会被预定到下次执行。
从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。
RDB和AOF区别
- AOF文件大小会比RDB要大
- RDB配置
RDB比较适合全量备份模式保存了某个时间点的数据,可以通过脚本执行redis指令bgsave(非阻塞,后台执行)或者save(会阻塞写操作,推荐)命令自行定义时间点的备份,可以保留多个备份,当出现问题时候方便恢复到不同时间节点,很适合备份,并且此文件格式支持不少第三方工具可以进行后续的数据分析
比如:可以在最近24小时内,没小时进行一次备份RDB文件，并且在每个月的每一天，也备份一个RDB文件，这样的话，即便遇上问题，也可以随时将数据集还原到不同的版本
RDB可以最大化Rｅｄｉｓ的性能，父进程在保存ＲＤＢ文件时候，唯一要做的就是ｆｏｒｋ出一个子进程，然后这个子进程就会处理接下来所有保存的工作，父进程无须执行任何磁盘ｉ／ｏ操作
REB在大量数据,比如几个G的数据,恢复速度比AOF的快
RDB的缺点
REB方式不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据
如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为ROB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
版本兼容RDB格式问题当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或者秒，取决于磁盘IO性能在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失
AOF 模式优点
数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求)
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决数据一致性的问题
Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发停机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数据的重建AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件也非常简单:
举个例子，如果你不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只要停止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到
FLUSHALL执行之前的状态。
AOF模式的缺点
即使有些操作是重复的也会全部记录，AOF 的文件大小要大于 RDB 格式的文件
AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
根据fsync策略不同,AOF速度可能会慢于RDB
bug 出现的可能性更多
