Redis 数据持久化 - RDB 和 AOF 简单介绍

大纲

1. 为何要作数据持久化
2. 数据持久化方式（RDB 和 AOF 介绍）
3. RDB 的优缺点
4. AOF 的优缺点

开篇

本文着重讲得是 redis 数据持久化，不会去介绍 redis 是什么，它的特性是什么，以及安装方式，使用场景等等。

正文

一. 为何要作数据持久化

或者咱们还能够这样问，什么状况下须要作数据持久化？

这须要结合你的业务场景去选择，固然大部分状况下，仍是建议你们去作 redis 的数据持久化。

回到原题，咱们作数据持久化的目的是用于故障恢复。

举个例子：

我最近接手到的 xx 系统，它的数据就直接存在 redis 中，或者说咱们就是把 redis 看成一个持久化数据库在用，这样作的缘由就先不说了。根据这样一个应用场景，假设咱们不作数据持久化，万一 redis 挂掉，咱们的数据就全没了，如何跟客户去交代？？？ ～～～～～ 只能跑路～～～

那么问题又来了，

1. redis 是怎么作数据持久化的？

2. 若是咱们作了数据持久化，就能保证一条数据都不会丢了吗？

请接着往下看 ⬇️️️

二. redis 数据持久化方式

redis 提供了两种不一样的持久化方式： RDB 和 AOF。

1. RDB ： 按期保存一份 redis 快照数据到 rdb 文件当中

2. AOF ： 把每个写操做都记录在一个日志文件里

说的通俗一点就是：

RDB 就是将 redis 的数据保存到一份 rdb 文件中，当咱们启动 redis 时，redis 会把这个文件的数据 load 到内存中。（这里先不要管 redis 如何 load 的）

AOF 就是记录每个 redis 写指令， 好比 set key value。当须要恢复数据时，redis 会把这个文件的这些写指令，全都执行一遍。

也许到这里你仍是会有不少疑问，好比：

1. 写文件写到一半，redis 挂掉怎么办？ 由于文件不完整了
2. 生成数据快照的时候，若是 redis 挂掉，不也是会丢数据吗？

这些下面会提到，另外只凭上面讲得那些设计，你也应该要想到会出现这样那样的问题。

三. RDB 数据持久化的优缺点

优势

1. RDB 很是适合作冷备，它会把每一个时间点的完整数据保存到一份 rbd 文件中。好比把过去 24 小时的数据按每 1 小时保存一次，或者过去 30 天的数据，每隔一天保存一次
2. RDB对于灾难恢复很是有用，它是一个紧凑的文件，能够传输到远程的安全存储上
3. RDB对 redis 对外提供的读写服务影响很是小，可让 redis 保持高性能，由于 redis 主进程只须要 fork 一个子进程，让子进程执行磁盘IO操做来进行RDB持久化便可
4. 相比于 AOF，直接基于 RDB 数据文件来重启和恢复 redis 进程，会更快

缺点

1. 相比于 AOF， 当 redis 由于某种缘由（好比停电）忽然不能工做后，要想保证数据尽量少丢失，RDB 可能表现的没有那么多好
2. RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，若是数据文件特别大，可能会致使对客户端提供的服务暂停数毫秒，或者甚至数秒。虽然 AOF 也须要 fork ，可是你能够调整要重写日志的频率，而无需在持久性上进行权衡（这点能够先不用理解，后面讲 AOF， 再说）

四. AOF 数据持久化的优缺点

优势

1. AOF 能够更好的保护数据不丢失，默认策略是 AOF 会每隔1秒，经过一个后台线程执行一次 fsync 操做。redis进程挂了，最多丢失1秒钟的数据

三个 fsync 策略

1. no fsync at all
2. fsync every second（默认）
3. fsync at every query

简单来说，fsync 操做，就是保证操做系统 cache 中的数据写入磁盘中（多说无益）

2. AOF日志文件以 append-only 模式写入，因此没有任何磁盘寻址的开销，写入性能很是高，并且文件不容易破损，即便文件尾部破损，也很容易修复

如何修复？

假如本次操做只是写入了一半数据就出现了系统崩溃问题，不用担忧，
在 Redis 下一次启动以前，咱们能够经过 redis-check-aof 工具来帮助咱们解决数据一致性的问题。

3. 当 AOF 日志文件过大的时候，redis 可以在后台自动进行 rewrite 操做，而且不会影响客户端的读写。

什么是 rewrite 操做？

AOF采用文件追加方式，为避免文件会愈来愈大，新增了重写机制。
 
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留能够恢复数据的最小指令集.（可使用命令bgrewriteaof）

重写原理

AOF文件持续增加而过大时，会 fork 出一条新进程来将文件重写(也是先写临时文件最后再rename)，
重写 AOF 文件的操做，并不会读取旧的 AOF 文件（所以不会影响旧的 AOF 文件的写入）。
而是将整个内存中的数据用命令的方式生成一个新的 AOF 文件.

4. AOF 包含一个格式清晰、易于理解的日志文件，用于记录全部的修改操做。所以很是适合作灾难性的误删除的紧急恢复。好比有人不当心用 FLUSHALL 命令清空了全部数据，只要这个时候后台 rewrite 尚未发生，那么就能够中止服务，将最后一条 FLUSHALL 命令给删了，而后重启 redis ，就能够自动恢复全部数据

缺点

1. 对同一份数据来讲，AOF日志文件一般比 RDB 数据快照文件更大

2. 根据确切的 fsync 策略，AOF 可能比 RDB 慢。可是在将fsync设置为每秒的状况下，性能仍然很高，而且在禁用 fsync 的状况下，即便在高负载下，它也应与RDB同样快。即便在巨大的写负载状况下，RDB 仍然可以提供有关最大延迟的更多保证。

3. 之前 AOF 发生过 bug，就是经过 AOF 记录的日志，进行数据恢复的时候，没有恢复如出一辙的数据出来。因此说，相似 AOF 这种基于命令日志回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过 AOF 就是为了不 rewrite 过程致使的 bug，所以每次 rewrite 并非基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的从新构建，这样健壮性会好不少。

总之，AOF 惟一的比较大的缺点，其实就是作数据恢复的时候，会比较慢，还有作冷备，按期的备份，不太方便，可能要本身手写复杂的脚本去作。

未完待续

看到这里，你也许期待会有具体的持久化方案，以及持久化配置等等。这些会在后面的文章补充，由于我的不喜欢篇幅过长，讲得东西一大堆，消化不了～～～

总结

本文主要说了 redis 数据持久化的两种方式以及对应的优缺点。固然文章也出现了对部分人来讲相对陌生的名词，好比 fsync，冷备等，以及难以理解，或者很绕的解释，好比讲 AOF 优缺点时，提到的 rewrite 方面的东西。 这都须要多看，多理解，也能够参考他人的文章。（没讲明白的地方，请见谅）

读完此文，能够转入

Redis 持久化方式 - RDB 和 AOF 配置及 rewrite 机制