Redis是一个支持持久化的内存数据库，即redis需要频繁的将内存中的数据同步到磁盘来保证持久化，这样可以避免因进程的退出而造成数据的丢失，Redis提供了两种持久化方式：快照方式与AOF方式
快照持久化是把当前进程数据生成快照（.rdb）文件保存到硬盘的过程 接下来我们看看快照生成的几种情况：
手动执行bgsave命令 客户端向redis发送bgsave命令来创建一个快照。redis调用fork创建一个子进程将快照写入硬盘，而父进程继续处理客户端的请求config set dir /usr/local/ bgsave 命令执行完在/usr/local/目录下会发现生成了dump.rdb快照文件 我们可以看下dump.rdb文件具体是什么样的 此时redis是没有任何数据的，插入数据（set name sywms）再执行bgsave后看看变化 我们看出dump.rdb文件中存入了我们插入的数据手动执行save命令 客户端向Redis发送save命令来创建一个快照，接到save命令后，Redis服务器在快照创建完成之前不会再响应客户端的其他任何命令，因此save命令的使用要谨慎 插入数据（set age 18）后执行save命令查看dump.rdb文件的变化 save配置 Redis中配置了save选项，当条件满足时，redis就会自动的触发bgsave命令，如果设置了多个save配置选项，那么当任意一个条件被满足时，Redis就会触发bgsave命令 我们看看redis配置文件中save的配置： 以save 900 1为例，该配置的意思是说再900s内，只要一个key发生变化就会执行bgsaveshutdown命令 当Redis接收到shutdown命令后，会执行save命令，并在执行完成后关闭服务器复制操作 当一个Redis服务器连接另外一个Redis服务器，并发送sync命令开始复制时，如果主服务器目前或者刚刚没有执行bgsave命令，那么主服务器就会立即执行bgsave命令使用快照方式，必然会丢失最近一次快照生成后产生的数据，由于快照方式不适合实时的持久化，Redis提供了AOF持久化的方式来解决
AOF（append-only file）就是将被执行的命令写到AOF文件的末尾，记录数据发生的变化，Redis只需要执行完一遍aof文件中的写命令，就可以恢复Redis的数据集
AOF持久化流程如下所示：
所有的写命令都会追加到aof缓冲区内aof缓冲区会向硬盘做同步操作当aof文件越来越大时，需要对aof文件进行重写压缩redis服务重启时，会优先加载aof文件AOF方式默认是关闭的，那么aof开启及如何操作的呢，接下来看看aof的配置项
# 默认为no 设置为yes开启aof持久化方式 appendonly yes # 每收到写命令时会强制立即写入磁盘，最慢，但是保证完全持久化，不推荐使用 # appendfsync always # 每秒强制写入磁盘一次，性能和持久化做了折中，推荐使用 appendfsync everysec # appendfsync no # 正在导出rdb快照的过程中,要不要停止同步aof no-appendfsync-on-rewrite yes # aof文件大小比起上次重写时的大小,增长率100%时,重写 auto-aof-rewrite-percentage 100 # aof文件,至少超过64M时,重写 auto-aof-rewrite-min-size 64mb配置完成后执行写命令set sex boy后查看appendonly.aof文件 可以看出aof文件保存了写命令
AOF文件与RDB文件同时存在时，优先加载AOF文件
通常，在我们的开发中，这两种持久化方式是配套使用的，充分利用他们的特性
快照AOF全量备份，一次保存整个数据库增量备份，一次保存一个修改数据库的命令保存时间间隔比较长保存时间间隔默认一秒数据还原块数据还原慢适合数据备份，默认开启适合保存数据，默认关闭save阻塞，bgsave不会阻塞不会阻塞启动优先级低启动优先级高体积小体积较大恢复速度快恢复速度慢数据安全性低，会丢失数据数据安全性：根据策略决定轻重：重轻重：轻