共计 1502 个字符，预计需要花费 4 分钟才能阅读完成。
1.Redis 的长久化机制之 RDB
2.Redis 的长久化机制之 AOF
3. 总结
4. 应用倡议
1.Redis 的长久化机制之 RDB
咱们都晓得，Redis 的所有数据都保留在 内存里，然而 redis 的数据必定要进行长久化，不然当 redis 宕机的时候，数据就复原不回来了。
RDB 是什么：
RDB 是在指定的工夫距离内将内存中的数据集快照写入磁盘。
运行原理：
Redis会独自创立（fork）一个子线程来进行长久化 ，会将数据写入到一个 临时文件 中，期待将数据及快照写入 都完结 了，再用这个临时文件替换上次长久化好的文件。
整个过程中，主过程是不进行任何 IO 操作的 ，这就确保了极高的性能。如果 要进行大规模的数据恢复 ，且 对数据恢复的完整性不是很敏感 （能够失落一部分数据），那 RDB 形式比 AOF（下文会解释）形式更加高效，RDB 的 毛病 就是 最初一次长久化的数据可能会失落。
配置地位：
save 秒钟 写操作次数
默认值：save 60 10000 是 1 分钟内改了 1 万次，save 300 10 是 5 分钟内改了 10 次，save 900 1 是 15 分钟内改了 1 次。如何触发 rdb 长久化：
咱们能够期待它到点触发，也能够应用 save 或者 bgsave 被动触发。保留的文件地位，默认是和 redis 一起的。
不过生产上的备份文件，个别都会在另外一台机器上备份，如果备份文件也在 redis 服务器，就达不到容灾的目标了。
| 长处 | 毛病 |
|---|---|
| 适宜大规模的数据恢复 | 会失落最初一次的批改 |
| 对数据完整性和一致性不高 | fork 的时候，内存中的数据要被克隆一倍，大抵 2 倍的膨胀性须要思考 |
2.Redis 的长久化机制之 AOF
Redis 的 AOF 是以日志的模式来记录 每个写操作 （RDB 只记录各个键值对的最终值）， 将 Redis 执行过程中的所有写操作指令记下来（读操作不记录）。在文件的尾部减少内容，redis 重启后依据日志文件的内容将写指令从头到尾执行一次实现复原工作。
如果 aof 的文件越写越大怎么办？
AOF 的重写机制：
在备份文件越写越大的时候，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留能够复原数据的最小指令集。
AOF 的重写原理：
AOF 文件持续增长而过大时，会 fork 出一条新线程来将文件重写，遍历新过程的内存中的数据，每条记录有一条 set 语句。
重写 aof 的操作，并不会读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的形式重写了一个新的 aof 文件，这点和 rdb 有点相似。
| 长处 | 毛病 |
|---|---|
| 实时性高 | aof 文件大，同步速率慢 |
3. 总结
1）RDB长久化形式可能在 指定的工夫距离对你的数据进行长久化。
2）AOF长久化形式 记录每次对服务器的写操作，当服务器重启的时候就会从新执行这些命令来复原原始的数据，AOF 命令以 redis 协定追加每次保留的写操作到文件开端，Redis 还能够对大的 aof 文件进行压缩重写。
3）咱们能够 同时开启两种长久化形式，在这种状况下，redis 会优先载入 aof 来复原数据，因为 aof 比 rdb 的文件数据集要残缺。
4. 应用倡议
RDB 文件只用作后备用处，倡议 只在 slave 上长久化 rdb 文件，且只有 15 分钟备份一次就能够，保留 save 900 1.
如果咱们开启了 aof，益处就是在最顽劣的状况下也只失落不超过两秒的数据 ，启动脚本较简略。 代价就是带来了继续的 IO，而是 AOF 压缩 aof 文件的时候，造成的阻塞时不可避免的，应该尽量减少 aof 的频率，AOF 重写的根底大小默认值 64m 太小了， 应该设置到 5G 以上，默认超过原大小的 100% 大小时就能够重写到适当的数值。
如果不开启 aof，仅仅依附正从复制也能够，就节俭了很多 IO，代价失落 master/slave 同时宕机，会失落十几分钟的数据。
