对于Redis来说是存储在缓存之中的，因此缓存数据丢失问题一直是程序员们相当关注的话题，因此对缓存中的数据定时进行持久化的必要性就相当突出了，以下是Redis持久化的相关配置：
### 1 第一种: RDB持久化方式
### 1.1概述
默认redis是会以快照的形式将数据持久化到磁盘的（一个二进制文件，dump.rdb，这个文件名字可以指定），在配置文件中的格式是：save N M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave（异步）做快照。
### 1.2实现机制
当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write
### 1.3 相关配置
redis.conf配置文件：
1)
# save ""
save 900 1
save 300 10
save 60 10000
2)
# The filename where to dump the DB
dbfilename dump.rdb
3)
# Note that you must specify a directoryhere, not a file name.
dir ./
# 2 第二种:AOF持久化方式
### 2.1概述
还有一种持久化方法是Append-only：filesnapshotting方法在redis异常死掉时，最近的数据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的。Append-only方法可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。
LOG Rewriting随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。
AOF文件刷新的方式，有三种，参考配置参数appendfsync ：appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；appendfsynceverysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。
可能由于系统原因导致了AOF损坏，redis无法再加载这个AOF，可以按照下面步骤来修复：首先做一个AOF文件的备份，复制到其他地方；修复原始AOF文件，执行：$ redis-check-aof –fix ;可以通过diff –u命令来查看修复前后文件不一致的地方；重启redis服务。
### 2.2实现机制
1)Redis将数据库做个快照，遍历所有数据库，将数据库中的数据还原为跟客户端发送来的指令的协议格式的字符串，
2)然后Redis新建一个临时文件将这些快照数据保存，待快照程序结束后将临时文件名修改为正常的aof文件名，原有的文件则自动丢弃。
由于在快照进行的过程中可能存在新增的命令修改了数据库中的数据，则在快照程序结束后需要将新修改的数据追加到aof文件中，后续的从客户端过来的命令都会不断根据不同的安全级别写到磁盘里面去。这样就支持了实时的持久化，只是可能会有短时间内的数据丢失，对一般系统还是可以容忍的。
### 2.3 相关配置
redis 127.0.0.1:6380> config get*append*
1) "appendonly"
2) "yes"
3) "no-appendfsync-on-rewrite"
4) "no"
5) "appendfsync"
6) "everysec"
redis 127.0.0.1:6380> config get*aof*
1) "auto-aof-rewrite-percentage"
2) "100"
3) "auto-aof-rewrite-min-size"
4) "67108864"
