redis是一个支持持久化的内存数据库，经常用到的持久化方式有2种，一种是snapshotting(快照)，这种方式也是redis默认的持久化方式；另一种是Append-only-flie（AOF）。下面分别介绍这两种持久化方式。
快照持久化是默认的，这种方式就是将内存中的数据以快照的方式写到二进制文件中，文件默认的名字是dump.rdb。默认的快照保存配置如下：
save 900 1#900秒内如果超过1个key被修改，则发起快照保存
save 300 10#300秒内容如超过10个key被修改，则发起快照保存
save 60 10000
当然，这个配置是可以修改的。客户端也可以通过save命令或者bgsave命令通知redis强制进行一次快照持久化，这个操作是在主进程中进行的，由于redis是在主进程中处理客户端的请求，所以save命令会阻塞客户端请求，所以不推荐使用。另外需要注意的是，每次快照持久化都是讲内存中的数据全部写入到磁盘中，这势必会引起大量的磁盘IO操作，可能会引起性能问题。
快照持久化有个问题，那就是如果redis服务器down掉的话，最后一次快照持久化的所有修改都会丢失。如果应用想不丢失任何数据的话，可以采用AOF进行持久化
下面就来说说AOF持久化方式。AOF持久化方式会把每一次的写操作命令写到文件末尾(appendonly.aof),当redis服务器重启时会执行文件中的每个写命令，从而恢复数据。同步命令有三种方式：(默认为每秒同步一次)
appendonly yes#启用aof持久化方式。注意：默认是不启动的
# appendfsync always#每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec#每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
# appendfsync no#完全依赖os，性能最好,持久化没保证
对于AOF这种方式，可以举个简单的例子，如果不小心执行了flushall 命令，可以暂停redis服务器，把AOF文件末尾的FLUSHALL命令移除掉，就会把数据恢复到FLUSHALL命令之前的状态
