redis的持久化
redis相比传统的memcache优势之一，即redis支持持久化操作。这也保证了redis挂掉之后，当重启redis的时候，可以恢复数据。
redis的配置文件 redis.conf 中 也已经标明了有两种持久化的机制，RDB和AOF， 这两种机制各有不同，而redis默认开启的是RDB，如果想要开启AOF， 可以在配置文件中，将appendonly 改为yes。
RDB
RDB，snapshotting，即快照。在指定的时间间隔内将内存中的数据集快照写入磁盘中。而恢复的时候会将快照文件直接读到内存。
备份是如何进行的？ redis会单独fork一个子进程来进行持久化。将数据先写入一个临时文件中，等到持久化过程结束了，在用这个临时文件替换上一次持久化的临时文件。整个过程，redis的主进程都不会IO，所以可以保证性能，可以保证高效。 但是由于每隔一段时间进行持久化，所以如果redis挂掉了，那么最后一次持久化会导致数据丢失。
注： fork的作用是复制一个与当前进程一样的进程，变量、环境变量、程序计数器等都是一致的。fork出来的进程是一个新的进程，来作为原进程的子进程。
redis是默认开启的，有如下配置
1 | save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 |
注： bgsave命令： save命令只管保存，所以在进行save时，是全部阻塞的，而bgsave可以在后台异步操作。快照可以在后台相应客户端的请求。
AOF
AOF， appendonly， 追加，以日志的形式来记录每个写操作，并且会把redis所有的写指令记录下来，只可以追加文件，不可以改写文件。 当redis启动后，就会根据日志里面的指令，从前到后执行一次来恢复数据。
持久化流程。1.写命令会被追加到AOF的缓冲区； 2. 缓冲区会根据持久化策略来操作sync同步到磁盘的AOF文件中； 3.当AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写； 4.当redis服务重启时，会重新加载aof文件来恢复数据。
当AOF和RDB都开启的时候，系统会优先取AOF的数据。这是因为AOF不会导致数据丢失。
AOF同步频率设置。在持久化流程中，缓冲区会根据持久化策略进行同步。主要有三种策略。
appendfsync always 始终同步，即每次有写入操作都会立刻记录到aof文件中，可想而知，性能会很差，但是能保证数据不丢失。
appendfsync everysec 每秒同步， 不过这种方式如果某一时刻redis挂掉，那么那一秒的数据就会丢失；
appendfsync no 不主动同步，交给操作系统来做。
如何使用RDB和AOF
AOF更加稳健，丢失数据的概率相对较低。但是需要占用更多的磁盘空间，需要写入同步，也会降低性能。用哪个更好呢？
官方推荐两个都开启。