序言
在上一篇博客中，博客介绍了redis的数据类型使用场景和redis分布式锁的正确姿势。我们知道一旦Redis重启，存在redis里面的数据就会全部丢失。所以这篇博客中向大家介绍Redis的磁盘持久化。
REDIS持久化
以每隔一段时间对redis进行快照的方式实现持久化
RDB持久化
优点：1、对redis性能影响小。
2、数据集比较大的时候，恢复速度比AOF快。
3、RDB是一个非常紧凑的单一文件，很方便传到第三方数据中心（亚马逊S3），以便日后的灾难恢复。
缺点：1、因为RDB的快照持久化方式，所以一旦出现宕机，你可能丢失几分钟的数据。
2、RDB需要fork一个子进程来保存数据集到磁盘上，所以当数据集比较大的时候，就会造成redis在毫秒级内对客户端没反应。
配置文件：在redis.conf文件中，有这样一段话。
################################ SNAPSHOTTING ################################ # # Save the DB on disk: # # save <seconds> <changes> # # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed # # Note: you can disable saving completely by commenting out all "save" lines. # # It is also possible to remove all the previously configured save # points by adding a save directive with a single empty string argument # like in the following example: # # save "" save 900 1 save 300 10 save 60 10000
说明在三种策略下，RDB会执行快照来将数据保存在磁盘上。例如 save 60 10000 意思是，"60秒内至少有1000个键被改动"，这自动保存一次数据集。
notice：当redis刚启动，这时你使用redis-cli向redis中存入一条数据，会发现并没有生成dump.rdb。这是因为这时候还没有满组以上三种策略，所以不会执行bgsave命令，这时要么你等900秒，要么你进入redis-cli，主动执行bgsave命令。
这样就会生成dump.rdb。
工作方式：当需要数据持久化的时候，会执行一下操作
1、Redis调用forks.同时拥有父进程和子进程。(这个过程是阻塞的)
2、子进程将数据集写入一个临时的rdb文件中。
3、Redis用新的rdb文件替换旧的rdb文件，并删除旧的rdb文件。
AOF持久化
以向AOF文件中追加redis写操作方式实现持久化
优点：1、AOF有三种策略：无fsync(完全依赖系统,性能很接近RDB)、每秒fsync、写时fsync(数据完全同步，但性能比较差)。默认使用每秒fsync，这种策略，即使redis宕机，最多也只会丢失一秒中的数据，兼顾性能和数据实时性。
2、当向AOF文件写入命令时，由于某些问题(磁盘已满或写时宕机等)造成未写入完整的命令，可以使用redis-check-aof命令修复这些问题。
3、当AOF文件过大时，会自动重写AOF文件。(例如我们只能了一百次incr count,就会在AOF文件中追加100次这个命令，那么重写后，就只会有一条类似set count 100的命令)。
4、AOF 文件有序地保存了对redis执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存，非常的容易读懂。因此当我们执行一些误操作(FLUSHALL)的时候，也可以通过修改AOF文件来修复数据。
缺点：1、相同的数据集情况下，体积会比rdb大。
2、除非使用无fsync，不然AOF的性能都慢于RDB。
配置文件：同样去看redis.conf文件中的配置注释。主要配置如下
appendonly yes 是否开启AOF持久化 appendfilename "appendonly.aof" AOF文件名
# appendfsync always 每次写入时都追加的AOF文件中
appendfsync everysec 每秒同步一次AOF文件
# appendfsync no 不同步AOF文件，完全依赖操作系统
下面还有一些其他参数配置，详细的可以去官网下载一份对应版本的redis.conf文件。
工作原理：AOF重写和RDB创建快照一样，都巧妙的利用了redis写时复制机制：
1、redis执行fork()，同时拥有父进程和子进程。
2、子进程将新AOF命令写入到临时文件中。
3、所有新执行的写入命令，redis一边将其放入内存缓存中，一边写入现有的AOF文件中，这样即使AOF重写中redis发生宕机，现有AOF文件也是安全的。
4、当子进程完成AOF重写时，会给父进程发送一个信号，父进程在接收到信号后，会将内存缓存中的所有命令追加到新的AOF文件中。
5、Redis用新的AOF替换原有的AOF。
如何选择使用哪种持久化
1、如果你对数据的安全性要求非常高，那么建议两种都适用。
2、如果你可以承受数分钟的数据损失，那么就可以使用rdb
3、使用AOF
notice：redis官网有这样一段话：因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。或许很快，我们就不用纠结使用哪种持久化了。
从RDB切换到AOF
1、为现有的rdb文件创建一个备份，并将备份放到一个安全的地方
2、redis-cli: config set appendonly yes 执行这个命令时，redis会阻塞，知道AOF文件创建完成，然后新的写入命令会被追加到新的AOF文件中。
3、redis-cli: config set save "" 关闭RDB持久化是可选的，因为你完全可以同时开启RDB和AOF这两种持久化功能。
4、记得把前面的修改同步到redis.conf配置文件中，否则redis重启后，config set设置的配置就失效了。
备份redis数据及容灾
牢记：确保你的数据由完整的备份。 磁盘故障，节点失效， 诸如此类的问题都可能让你的数据消失不见， 不进行备份是非常危险的。
因为RDB的工作原理，所以redis对于数据备份是非常友好的。无论何时，复制RDB文件是绝对安全的。
1、创建一个定期任务（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹。
2、确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照： 比如说， 你可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照。
3、至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服务器的物理机器之外。
数据备份了之后，为了做到容灾，你可以将备份后的数据放到第三方数据中心。