redis 系列：五、持久化策略

持久化概述

Redis 的高性能是由于将其所有的数据都存储在了内存中。但是为了使Redis在重启之后保证数据不丢失，这就需要将数据写入到磁盘中进行持久化操作。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。使用时，可以单独使用一种，或者两种方式结合使用。

RDB

概述

Redis默认支持，无需配置
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘

优点

方便备份和恢复。采用此种方式，Redis将只包含这一个数据文件。我们可以采用不同的备份策略，一旦出现设备故障，就能快速恢复数据。
方便迁移。如果需要将Redis的服务器进行切换，只需要将数据文件压缩后移植到目标服务器上就ok了。
性能最大化。对于Redis的服务进程而言，开始进行数据持久化时，只需要fork出一个子进程，从而由子进程完成数据持久化的任务，从而极大的避免IO操作。
相比于AOF，当数据库较大时，RDB的启动效率更高。

缺点

如果要保证数据的高可用性，即最大限度的保证数据不丢失，那么RDB将不是一个最好的选择。因为如果在数据持久化之前出现服务器故障，此前没有来得及写入磁盘的数据就会丢失。
由于RDB是通过fork子进程来协助完成数据持久化的，因此如果数据库较大时，可能会导致整个服务器停止几百毫秒，设置一秒钟

配置

在redis.conf文件中配置：

// 保存的周期
save 900 1   // 每900秒（15分钟），至少有一个key发生变化，则dump快照进行保存

// 保存的文件名称
dbfilename dump.rdb

// 保存的文件位置
dir ./

AOF

概述

该机制是指以日志的形式记录服务器所处理的每一个写操作。在Redis服务器启动时，会读取该日志记录，以保证启动后数据库的数据是完整的

优点

更高的数据安全性。Redis中提供了三种同步策略：每秒同步、每修改同步和不同步。每秒同步，因为每秒同步也是异步完成的，所以效率不是问题，唯一的问题是如果出现服务器问题，有可能造成一秒钟之内修改的数据没有完成同步；每修改同步，数据安全性最高，基本不会造成数据丢失，但是效率最低
AOF机制对日志文件的写入操作时采用的append模式。如果服务器出现故障，也不会破坏日志文件。即使出现数据不一致问题，也可以使用redis-check-of工具来解决。
如果日志文件过大，Redis自动启动rewrite机制。Redis继续采用append模式不断的将修改数据的命令写入老的磁盘文件中，同时创建一个新的文件用于此期间有哪些命令被执行，从而更好的保证数据安全性。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。

劣势

对于相同数量的数据，AOF文件一般大于RDB文件
AOF的运行效率一般低于RDB

配置

在redis.conf文件中配置：

// 开启aof
appendonly yes		// yes，开启；no：关闭

// 配置同步策略
# appendfsync always		// 每修改同步
# appendfsync everysec		// 每秒同步
# appendfsync no			// 不同步
# bgrewriteaof				// 如果命令不满足，可以自己重写