Redis持久化
@
Redis有两种持久化方式
RDB和AOF
RDB是快照方式，是⼀次全量备份；AOF是命令日志方式，连续的增量备份。redis默认采用RDB持久化方式
RDB
Snapshot 快照，在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时是将快照文件直接读到内存里
配置
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
save
Redis 默认配置文件中提供了三个条件
save 900 1 【表示 900秒（15分钟）内有1个更改】
save 300 10【表示 300秒（5分钟）内有10个更改】
save 60 10000【表示 60秒（1分钟）内有10000个更改】
如果同时满足以上三个默认的条件 redis 就是自动缓存数据到 dump.rdb 这个文件中，此条件可以修改
原理
fork和cow。fork 是指 redis间隔一段时间会 fork 一个子进程，子线程将数据写到磁盘上一个临时RDB文件中，当子进程写完临时文件后，将原来的RDB替换掉，这样的好处是可以 cow（copy-on-wirte）。使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证 redis 的高性能。
优缺点
优点：
方便持久化，只有一个文件 dump.rdb容灾性好，一个文件可以保存到安全的磁盘中性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。
缺点：
数据安全性低，RDB是间隔一段时间来进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失，所以这种方式更适合数据要求不严谨的时候用保存时间长，如果数据量很大，保存快照的时间会很长
AOF
AOF（Append-Only-File），是将 Redis 执行的每次写命令记录到单独的日志文件中，当重启 Redis 会重新将持久化的日志中文件恢复数据。保存的文件是appendonly.aof
原理
AOF ⽇志存储的是 Redis 服务器的顺序指令序列，AOF ⽇志只记录对内存进⾏修改的指令记录。
AOF ⽇志是以⽂件的形式存在的，当程序对 AOF ⽇志⽂件进⾏写操 作时，实际上是将内容写到了内核为⽂件描述符分配的⼀个内存缓存 中，然后内核会异步将数据刷写到磁盘。
Linux 提供了fsync(int fd)函数可以将指定⽂件的内容强制从内核缓存刷到磁盘。只要 Redis 进程实时调⽤ fsync 函数就可以保证 aof ⽇志不丢失。但是 fsync 是⼀个磁盘 IO 操作，它很慢！如果 Redis 执⾏⼀条指令就要 fsync ⼀次，那么 Redis ⾼性能的地位就不保了。
所以在⽣产环境的服务器中，Redis 通常是每隔 1s 左右执⾏⼀次 fsync 操作，周期 1s 是可以配置的。这是在数据安全性和性能之间 做了⼀个折中，在保持⾼性能的同时，尽可能使得数据少丢失。
优缺点
优点：
数据安全，AOF 持久化可以配置 appendfsync 属性中的always，每进行一次写命令操作就记录到 AOF 文件中一次一致性，通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题
缺点：
- AOF 文件比RDB文件大，而且恢复速度慢
- 数据集大的时候比 RDB 启动效率低
两者比较
- AOF 文件比 RDB 更新频率高，优先使用 AOF 还原数据
- AOF 比 RDB 更安全也更强大
- RDB 性能比 AOF 好
- 如果两个都配了优先加载 AOF
Redis 4.0 混合持久化
重启Redis时，我们很少使⽤rdb来恢复内存状态，因为会丢失⼤量数据。我们通常使⽤AOF⽇志重放，但是重放AOF⽇志性能相对rdb来说要慢很多，这样在Redis实例很⼤的情况下，启动需要花费很⻓的时间。
Redis4.0之后——混合持久化。将rdb⽂件的内容和增量的AOF⽇志⽂件存在⼀起。新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。
在Redis重启的时候，可以先加载rdb的内容，然后再重放增量AOF⽇志就可以完全替代之前的AOF全量⽂件重放，重启效率因此⼤幅得到提升。
数据恢复
开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况：
- aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。
- aof文件开头不是rdb的格式，直接以aof格式加载整个文件。
