Redis持久化

　　redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一但服务器进程退出，服务器中的数据库状态也会消失，所有redis提供了持久化功能
redis 提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
　　RDB，简而言之，就是在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介质上；
　　AOF，则是换了一个角度来实现持久化，那就是将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
　　其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。
　　如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一个纯内存数据库，就像 memcache 一样。

redis持久化RDB

　　RDB 方式，是将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
　　redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
对于 RDB 方式，redis 会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何 IO 操作的，这样就确保了 redis 极高的性能。
　　如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。
　　虽然 RDB 有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么 RDB 方式就不太适合你，因为即使你每 5 分钟都持久化一次，当 redis 故障时，仍然会有近 5 分钟的数据丢失。所以，redis 还提供了另一种持久化方式，那就是 AOF。

测试

触发机制

1、save的规则满足的情况下，会自动触发rdb规则
2、执行flushall命令也会触发rdb规则
3、退出redis,也会产生rdb文件
备份就会自动产生一个dump.rdp

如何恢复rdb文件

1、只需要rdb文件放在我们redis启动目录就可以了 redis会自动检查dump.rdp恢复其中的数据
2、检查需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

优点：
适合大规模的数据恢复
对数据完整性要求不高
缺点：
需要一定的时间间隔进程操作，如果redis宕机，这个最好一次修改数据就没有了
fork进程的时候，会占用一定的内容空间

redis持久化AOF

　　AOF，英文是 Append Only File，即只允许追加不允许改写的文件。
　　如前面介绍的，AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。
　　我们通过配置 redis.conf 中的 appendonly yes 就可以打开 AOF 功能。如果有写操作（如 SET 等），redis 就会被追加到 AOF 文件的末尾。
　　默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync 是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis 仍然可以保持很好的处理性能，即使 redis 故障，也只会丢失最近 1 秒钟的数据。
如果在追加日志时，恰好遇到磁盘空间满、inode 满或断电等情况导致日志写入不完整，也没有关系，redis 提供了 redis-check-aof 工具，可以用来进行日志修复。
　　因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis 提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了 100 次 INCR 指令，在 AOF 文件中就要存储 100 条指令，但这明显是很低效的，完全可以把这 100 条指令合并成一条 SET 指令，这就是重写机制的原理。
在进行 AOF 重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响 AOF 文件的可用性，这点大家可以放心。
　　AOF 方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作 redis 时，不小心执行了 FLUSHALL，导致 redis 内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要 redis 配置了 AOF 持久化方式，且 AOF 文件还没有被重写（rewrite），我们就可以用最快的速度暂停 redis 并编辑 AOF 文件，将最后一行的 FLUSHALL 命令删除，然后重启 redis，就可以恢复 redis 的所有数据到 FLUSHALL 之前的状态了。是不是很神奇，这就是 AOF 持久化方式的好处之一。但是如果 AOF 文件已经被重写了，那就无法通过这种方法来恢复数据了。
虽然优点多多，但 AOF 方式也同样存在缺陷，比如在同样数据规模的情况下，AOF 文件要比 RDB 文件的体积大。而且，AOF 方式的恢复速度也要慢于 RDB 方式。
　　如果你直接执行 BGREWRITEAOF 命令，那么 redis 会生成一个全新的 AOF 文件，其中便包括了可以恢复现有数据的最少的命令集。
　　如果运气比较差，AOF 文件出现了被写坏的情况，也不必过分担忧，redis 并不会贸然加载这个有问题的 AOF 文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的 AOF 文件
2.运行 redis-check-aof –fix 进行修复
3.用 diff -u 来看下两个文件的差异，确认问题点
4.重启 redis，加载修复后的 AOF 文件

redis持久化 – AOF重写

　　AOF 重写的内部运行原理，我们有必要了解一下。
　　在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
　　与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。
　　当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中。
　　当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了。

测试

如果aof文件有错误，这个时候redis是启动不起来的，需要修复这个aof文件redis-check-aof

[root@cs bin]# redis-check-aof --fix appendonly.aof 
0x               4: Expected prefix '$', got: 'e'
AOF analyzed: size=122, ok_up_to=0, diff=122
This will shrink the AOF from 122 bytes, with 122 bytes, to 0 bytes
Continue? [y/N]: y
Successfully truncated AOF

优点：
每次修改都同步，文件的完整性更好
每秒同步一次可能会丢失一秒数据
从不同步，效率最高
缺点：
相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化