Redis十一个内存数据库，数据时存储在内存中的，因此缓存数据丢失问题一直是程序员们相当关注的话题，因此对缓存中的数据定时进行持久化的必要性就相当突出了，redis提供了两种持久话方案，分别是rdb(redis database)和aof(append od file)
一、rdb持久化
redis持久化是redis默认的持久话方案，不许要通过修改redis.conf配置文件来启动，默认redis是会以快照的形式将数据持久化到磁盘的（dump.rdb，这个文件名字可以指定），在配置文件中的格式是：save N M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave（异步）做快照。
工作原理:
- Redis forks 一个子进程开始将数据写到临时RDB文件中，当子进程完成写RDB文件，用新文件替换老文件
1.1 修改配置文件redis.conf, 120秒内对redis进行5修改
redis.conf配置文件： 1) # save "" save 900 1 save 120 5 save 60 10000 2) # The filename where to dump the DB dbfilename dump.rdb #rdb文件名称配置 3) # Note that you must specify a directoryhere, not a file name. dir ./ #rdb文件路径配置
二、aof持久化方案
2.1 简介
当rdb方法进行持久化方案进行持久化时，当redis突然异常死掉时，最近的数 据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的。aof方法可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到 redis关闭前的最后时刻。
2.2 配置
AOF文件刷新的方式，有三种，参考配置参数appendfsync ：
appendfsync always 每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；
appendfsync everysec 每秒钟都调用 fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；
appendfsync no 依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。
appendonly yes //启用aof持久化方式 # appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用 appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐 # appendfsync no //完全依赖os，性能最好,持久化没保证
2.3.当appendonly.aof损坏时
当 appendonly.aof损坏，导致redis无法启动时，可以通过 ./redis-check-aof --fix appendonly.aof 来恢复appendonly.aof文件，但是有可能会丢失部分数据
2.4 aof文件重写(压缩)
在实际生产中，aof往往会特别大，redis提供了对aof进行重写的方案，默认情况下redis会记录上次写aof文件时，aof文件的大小，当aof的文件大小是上次写的时候的两倍，而且aof文件爱你的大小大于64mb时候，就会对aof文件进行重写压缩，默认配置
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
另外还可配置重写aof文件时，是否启动 ppendfsync（时间间隔），按默认配置，为no时就行，保证数据安全性
no-appendfsync-on-rewrite no