redis的持久化及优缺点

redis如果将数据仅缓存在内存里面，一旦redis挂了重启，数据就全部丢失了，像RabbitMQ一类的针对这种情况都提供了持久化机制，当然redis肯定也是有自己的持久化机制。

redis提供了两种持久化方式

• RDB：对redis中的数据执行周期性的持久化（默认存储到dump.rdb文件）

//参考配置

save 900 1 #900秒内如果至少有1次key发生了变化，就执行持久化

save 300 10 #300秒内如果至少有10次key发生了变化，就执行持久化

save 60 10000 #含义同上

dbfilename dump.rdb   #持久化的文件名

• AOF：对每条写入命令做日志，以 append-only 的模式写入一个日志文件中（默认写入到appendonly.aof文件），redis在重启的时候通过回放 AOF 日志中的写入指令来重新构建整个数据集

//参考配置:

appendonly yes #开启aof持久化

appendfilename "appendonly.aof"  #aof持久化的日志文件名

appendfsync everysec #每秒flush一次系统内存将日志数据存储到磁盘

如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整 ，如下面在启动 redis 时输出的 DB loaded from append only file: 7.335 seconds 这一行。

D:\redis>redis-server.exe redis.windows.conf
                _._
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 3.2.100 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 1336
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |           http://redis.io
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'
              `-.__.-'

[1336] 02 Nov 08:37:59.708 # Server started, Redis version 3.2.100
[1336] 02 Nov 08:38:07.046 * DB loaded from append only file: 7.335 seconds
[1336] 02 Nov 08:38:07.046 * The server is now ready to accept connections on port 6379
[1336] 02 Nov 08:39:00.004 * 10000 changes in 60 seconds. Saving...
[1336] 02 Nov 08:39:00.014 * Background saving started by pid 4536
[1336] 02 Nov 08:39:01.621 # fork operation complete
[1336] 02 Nov 08:39:01.621 * Background saving terminated with success

RDB的优缺点

优点

• RDB 会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，以预定好的备份策略来定期备份 redis 中的数据。
• RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
• 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。

缺点

• redis 故障时，由于周期性持久化的存在时间间隔的问题，可能会丢失间隔时间内产生的数据，这一点上 RDB 没有 AOF 好。
• RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

AOF的优缺点

优点

• AOF 可以更好的保护数据不丢失，一般从效率和安全方面综合考虑设置 AOF 每隔 1 秒通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。
• AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
• AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
• AOF 日志文件的命令可读性很强，非常适合做灾难性的误删除的紧急恢复。

缺点

• 对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
• AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件，当然，每秒一次 fsync，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）

RDB 和 AOF的选择

• 不要仅仅使用 RDB，那样会导致丢失很多数据。
• 也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug。
• redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。