redis redis的两种持久化机制

Redis 提供了两种方式，实现数据的持久化到硬盘。

• 一、【全量】RDB 持久化，是指在指定的时间间隔内将内存中的数据集快照写入磁盘。实际操做过程是，fork 一个子进程，先将数据集写入临时文件，写入成功后，再替换以前的文件，用二进制压缩存储。 - 默认开启rdb持久化
• 二、【增量】AOF持久化，以日志的形式记录服务器所处理的每个写、删除操做，查询操做不会记录，以文本的方式记录，能够打开文件看到详细的操做记录。 - 默认关闭 每次写，删除操做就同步或者每秒同步

（1）RDB 优缺点

优势：

• 灵活设置备份频率和周期。你可能打算每一个小时归档一次最近 24 小时的数据，同时还要天天归档一次最近 30 天的数据。经过这样的备份策略，一旦系统出现灾难性故障，咱们能够很是容易的进行恢复。
• 很是适合冷备份，对于灾难恢复而言，RDB 是很是不错的选择。由于咱们能够很是轻松的将一个单独的文件压缩后再转移到其它存储介质上。推荐，能够将这种完整的数据文件发送到一些远程的安全存储上去，好比说 Amazon 的 S3 云服务上去，在国内能够是阿里云的 OSS 分布式存储上。
• 性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它惟一须要作的只是 fork 出子进程，以后再由子进程完成这些持久化的工做，这样就能够极大的避免服务进程执行 IO 操做了。也就是说，RDB 对 Redis 对外提供的读写服务，影响很是小，可让 Redis 保持高性能。
• 恢复更快。相比于 AOF 机制，RDB 的恢复速度更更快，更适合恢复数据，特别是在数据集很是大的状况。

缺点：

• 若是你想保证数据的高可用性，即最大限度的避免数据丢失，那么 RDB 将不是一个很好的选择。由于系统一旦在定时持久化以前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

  因此，RDB 实际场景下，须要和 AOF 一块儿使用。

• 因为 RDB 是经过 fork 子进程来协助完成数据持久化工做的，所以，若是当数据集较大时，可能会致使整个服务器中止服务几百毫秒，甚至是 1 秒钟。

  因此，RDB 建议在业务低估，例如在半夜执行。

（2）AOF 优缺点

优势：

• 该机制能够带来更高的数据安全性，即数据持久性。Redis 中提供了 3 种同步策略，即每秒同步、每修改(执行一个命令)同步和不一样步。事实上，每秒同步也是异步完成的，其效率也是很是高的，所差的是一旦系统出现宕机现象，那么这一秒钟以内修改的数据将会丢失。而每修改同步，咱们能够将其视为同步持久化，即每次发生的数据变化都会被当即记录到磁盘中。能够预见，这种方式在效率上是最低的。至于无同步，无需多言，我想你们都能正确的理解它。
• 因为该机制对日志文件的写入操做采用的是 append 模式，所以在写入过程当中即便出现宕机现象，也不会破坏日志文件中已经存在的内容。由于以 append-only 模式写入，因此没有任何磁盘寻址的开销，写入性能很是高。另外，若是咱们本次操做只是写入了一半数据就出现了系统崩溃问题，不用担忧，在 Redis 下一次启动以前，咱们能够经过 redis-check-aof 工具来帮助咱们解决数据一致性的问题。
• 若是日志过大，Redis能够自动启用 rewrite 机制。即便出现后台重写操做，也不会影响客户端的读写。由于在 rewrite log 的时候，会对其中的指令进行压缩，建立出一份须要恢复数据的最小日志出来。再建立新日志文件的时候，老的日志文件仍是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件便可。
• AOF 包含一个格式清晰、易于理解的日志文件用于记录全部的修改操做。事实上，咱们也能够经过该文件完成数据的重建。

缺点：

• 对于相同数量的数据集而言，AOF 文件一般要大于 RDB 文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
• 根据同步策略的不一样，AOF 在运行效率上每每会慢于 RDB 。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和 RDB 同样高效。
• 之前 AOF 发生过 bug ，就是经过 AOF 记录的日志，进行数据恢复的时候，没有恢复如出一辙的数据出来。因此说，相似 AOF 这种较为复杂的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug 。不过 AOF 就是为了不 rewrite 过程致使的 bug ，所以每次 rewrite 并非基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的从新构建，这样健壮性会好不少。

（3）如何选择

• 不要仅仅使用 RDB，由于那样会致使你丢失不少数据

• 也不要仅仅使用 AOF，由于那样有两个问题，第一，你经过 AOF 作冷备，没有 RDB 作冷备，来的恢复速度更快; 第二，RDB 每次简单粗暴生成数据快照，更加健壮，能够避免 AOF 这种复杂的备份和恢复机制的 bug 。

• Redis 支持同时开启开启两种持久化方式，咱们能够综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，做为数据恢复的第一选择; 用 RDB 来作不一样程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可使用 RDB 来进行快速的数据恢复。

  • 若是同时使用 RDB 和 AOF 两种持久化机制，那么在 Redis 重启的时候，会使用 AOF 来从新构建数据，由于 AOF 中的数据更加完整。

    通常来讲， 若是想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。若是你很是关心你的数据， 但仍然能够承受数分钟之内的数据丢失，那么你能够只使用 RDB 持久化。

    有不少用户都只使用 AOF 持久化，但并不推荐这种方式：由于定时生成 RDB 快照（snapshot）很是便于进行数据库备份， 而且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此以外，使用 RDB 还能够避免以前提到的 AOF 程序的 bug。