Redis提供了不同的持久化选项：
- RDB持久化，数据集的时间点快照
- AOF持久化，服务器收到的每一个写操作
- 可以同时使用AOF和RDB。在这种情况下，当Redis重启的以后，AOF将用于重新构建原始数据集，因为它保证是最完整的数据。
RDB的优点：
- RDB是数据的时间点快照。对于备份而言，RDB文件是完美的。你可能想要归档最近的24小时内每个小时的RDB文件，并且每个归档保存30天。这允许你再灾难发生的时候开业轻松地恢复数据集到不同版本。
- RDB对于灾难恢复非常好，因为一个紧凑的文件可以传输到远程数据中心
- RDB最大化了Redis的性能，因为Redis父进程为了持久化需要做的唯一工作就是分配一个子进程，而子进程可以完成所有的工作。
- 与AOF相比，RDB允许使用大数据集更快地重新启动。
RDB的不足：
- 如果你希望当Redis停止工作的时候能把数据丢失减少到最小，那么RDB不是一个好主意。假设你设置每5分钟创建一个RDB快照，那么当Redis非正常退出是，你可能会丢失最近几分钟的数据。
- 为了持久化到磁盘，RDB需要fork()一个子进程。如果数据很大，fork()可能会很耗时，如果数据非常大，CPU性能不太好，那么可能在几毫秒甚至一秒内停止为客户端提供服务。AOF也许fork()，但是你可以调整写日志的频率，而不需要在持久性上进行权衡
AOF的优点：
- 你可以有不同的fsync策略：完全不fsync，每秒fsync，每个查询都fsync。fsync的默认策略是每秒执行一次，但是你最多只会丢失一秒钟内的写操作。
- AOF日志是追加的，不用担心断电的问题，即使日志写到一半，使用redis-check-aof工具也可以轻松修复。
- 当AOF文件变得太多时，Redis可以自动重写AOF
- AOF以一种易于理解和解析的格式，一个接一个地包含所有操作的日志。你可以很容易的导出一个AOF文件。
AOF的不足：
- 对于相同的数据，AOF文件通常比RDB文件更大
- AOF可能会比RDB更慢，当然这取决于fsync策略。一般而言，fsync设置为每秒性能是最高的。
RDB配置方式
默认情况下，是快照RDB的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb
redis.conf默认配置：
save 900 1
save 300 10
save 60 10000配置含义：
900秒内，如果超过1个key被修改，则发起快照保存
300秒内，如果超过10个key被修改，则发起快照保存
60秒内，如果1万个key被修改，则发起快照保存
默认配置不方便看效果，可将快照频率设大一点，在redis.conf中增加一行：
save 10 1保存后，启动redis服务端和客户端。在客户端输入命令：
输入完，发现dump.rdb文件的修改日期变了，并且redis服务端增加了保存日志：
接下来，重启redis服务端和客户端，看数据是否真的持久化了：
妥妥的~，说明使用RDB快照持久化成功了
AOF 配置方式
redis.conf默认配置：
appendonly no配置文件中的appendonly修改为yes，开启AOF持久化。开启后，启动redis服务端，发现多了一个appendonly.aof文件
使用AOF做持久化，每一个命令以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写，使得 AOF文件的体积不会超出保存数据集状态所需的实际大小。实际上，AOF持久化并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失
# appendfsync always
appendfsync everysec
# appendfsync no配置含义：
always: 每次操作都会立即写入aof文件中
everysec: 每秒持久化一次(默认配置)
no: 不主动进行同步操作，默认30s一次
当然always一定是效率最低的，个人认为everysec就够用了，数据安全性能又高。Redis也允许我们同时使用两种方式，再重启redis后会从AOF中恢复数据，因为AOF比RDB数据损失小嘛
配置好后，启动redis客户端，输入命令：
最后的flushall是清除所有的键值。打开appendonly.aof文件，可以看到：
去掉最后面的flushall(也可以按照redis协议增加命令)，重启客户端和服务端，看数据是否真的持久化了：
说明使用AOF持久化也成功了