redis是存在内存里面的一个数据库，而内存虽然在速度上对磁盘来说有绝对优势，但是它在重启或者断电等突发状况上导致数据的丢失，因而redis实际上是有数据丢失的可能，针对这种情况，redis有一个整体的持久化方式，方便快速的从磁盘上还原数据到内存之中去。
redis目前两种方式来进行持久化，分别是RDB的持久化和AOF的持久化，下面分别简介下两种的持久化方式。
RDB持久化
RDB持久化是存储数据库中的键值对的。在redis的配置里里面，有两段需要注意：
#redis的save类型
save 900 1
save 300 10
save 60 10000
#rdb名称
dbfilename dump.rdb
这两段的内容是指促发redis进行rdb存储的方式和存储的名称，当满足其中的任何一个条件的时候，redis就会执行save命令，讲内存数据库里面的信息持久化到磁盘上面去，命名为dump.rdb。
rdb可以显式的执行，在redis命令行里面，执行save或者bgsave即可执行rdb的存储，不同的是save是堵塞现有请求，而bgsave是后台fork一份主进程进行保存，配置中的save执行的bgsave命令。
redis在载入rdb文件的时候，是一直处于堵塞情况，所以rdb文件很大的时候，会堵塞比较长的时间。
redis怎样来触发配置里面的save条件呢？在redis服务器上面，维持了一个dirty计数器和lastsave的属性，dirty计数器记录上一次save或者bgsave之后，redis数据库有了多少次更改（插入、更新、删除等操作），而lastsave属性是上一次服务器save或者bgsave执行的时间戳，redis还有一个serverCron函数，每100毫秒就检查下服务器的状态，如果满足save配置里面的条件，则除非bgsave请求，进行持久化的存储。
redis的结构：
redis|db_version|databases|EOF|check_sum
rdb对于不同类型的键值对，采用了不同的方式来进行存储。
AOF持久化
AOF(Append Only File)持久化，AOF是保存redis执行写命令来记录数据库状态的。vi aof文件，可以看到里面是存储了redis的操作命令。
在配置文件中，有两个地方需要注意:
appendonly yes
appendfilename appendonly.aof
# appendfsync always
appendfsync everysec
# appendfsync no
第一段代表开启aof持久化，生成名称为appendonly.aof的文件，第二部分代表每秒钟执行一次aof持久。aof还原数据理解起来很简单，就是把数据按命令写进去而已。 因为我们经常操作的可能都是同一条key，所以会存在aof出现很多重复数据的情况，导致无谓的体积增大，aof提供了一个bgrewriteaof命令，将原来的数据去掉重复值。
RDB和AOF简要说明对比
rdb的体积占用小，恢复快，但是数据量很大的时候，频繁的bgsave很占用内存，浪费性能，当如果redis对数据的使用率很高，更新很快的时候，可以适当调整参数，优化redis服务器的性能。aof占用体积大，但是数据完整，使用appendfsync everysec恢复数据的时候，最多只丢失一秒的数据，但是aof是写入的，效率也比rbd恢复慢。相信在不久的将来，redis应该会有新的存储方式来综合两者的优点。