Redis数据库-数据持久化一看就懂

今天给伙伴们分享一下Redis数据库-数据持久化，希望看了有所收获。

我是公众号「想吃西红柿」「云原生运维实战派」的作者，对云原生运维感兴趣，也保持时刻学习，后续会分享工作中用到的运维技术，在运维的路上得到支持和共同进步！

如果伙伴们看了文档觉得有用，欢迎大家关注我的公众号，获取相关文档。爱运维，爱生活。

一、持久化策略

• redis 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF.

1、RDB 持久化

• 可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。

2、AOF 持久化

• 记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以Redis 协议的格式来保存，新命令会被追加到文件的末尾。

• Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

• 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

二、RDB 持久化

1、RDB 的优点

• RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

• RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心用于备份恢复。

• RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2、RDB 的缺点

• 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。

• 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

• 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时，fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

三、AOF 持久化

1、AOF 优点

• 使用 AOF 会让你的 Redis 更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性