之前项目是直接使用阿里云的Redis服务，需要负责的运维部分其实很少，有问题直接提工单，所以自己操心很少。一旦被人问到基础的问题，一下子给问懵了。所以今天记录一下经常会被问到的一个问题：redis的持久化问题。
总所周知，Redis是一个内存数据库，数据是放到内存里的，所以性能非常快。但是，这数据只要没落磁盘，服务器一重启，数据就全没了，非常不安全，所以Redis会有自己的一套逻辑，选择把数据存储到磁盘中，防止意外情况的发生。
先附一个官方文档的地址：http://www.redis.cn/topics/persistence.html
redis提供两种持久化的方案：RDB和AOF.↓↓
“RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.”
简单来讲，RDB就是你自己设定一个规则，间隔几秒，就让redis从内存中落地磁盘一次，直接保存原数据。AOF就是只要有更改数据集的操作的时候，就把这个操作命令写到日志文件里，等服务器重启了，再依次执行这些命令，从而把数据进行恢复。
如果再用mysql做一个简单类比，说明一下他们的逻辑，RDB就像是加了一个定时任务，导出导入了数据，而AOF就是存储了包括插入，更新，删除在内的sql语句，恢复数据的时候，顺序执行这些sql语句就行。
RDB和AOF都采用的写时复制机制，即redis会fork出一个子进程来专门做数据持久化。
RDB的是设定好规则后（比如一小时一次），到了时间，redis的子进程会新建一个RDB临时文件，往临时文件里写入数据，完成后，用这个新的RDB文件替换旧的RDB文件。但是这种方式，假如时间间隔比较长，然后服务器重启了，比如一个小时，那就会丢掉这一个小时内的数据。即使把时间间隔调整到1秒，等到项目后期，或者高并发的情况下，子进程频繁的保存RDB文件，势必会影响线上服务。
AOF 的运作方式是不断地将命令追加到文件的末尾，一般建议一秒落地磁盘一次。 而随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。但是也有解决方法：redis可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。来不断给AOF文件瘦身和优化。
一般都采用RDB+AOF一块用的方式，最大程度的保证数据安全性。
另外再补充说明一下，为什么RDB一秒保存一次影响性能，而AOF一秒落地磁盘一次影响不大。是因为RDB是每一秒都对整个的数据进行一次新建RDB文件，完整的写入，然后替换掉旧文件的操作。而AOF只是间隔一秒给AOF格式的日志最后边，追加一条“sql语句”的字符串，纯记录文本不执行的那种。对比下来，这两种方式的资源开销就非常明朗了。