最详细Redis之持久化 RDB，AOF详解

一。总体介绍

所谓持久化，就是备份。Redis跟我们提供了两种备份的方式，一个是RDB(Redis Datebase)，另一种是AOF(Append only file).
本篇使用的是windows下的redis（作者不太会Linux，抱歉）

二。RDB (Redis Database)

1.官网介绍：将指定时间内的数据集快照写入磁盘内，也就是行话讲的SnapsShot。它恢复时是将快照文件直接读到内存中。

为什么最后一次备份有可能丢失呢？

原因是假如我们每五分钟备份一次，但是最后一个五分钟 ，我们将内存中的数据清空了，然而 redis出了故障 立即将空的数据集生成了rdb文件，那么最后一次的rdb文件没有数据，我们在下一次启动redis的时候会发现无法恢复之前的数据了。这是RDB方式的缺点之一。解决这个办法我们只能拷贝出来一份rdb文件放在其他机器上。

2.Fork：拷贝一个新的进程，去做备份的工作，原来的进程继续提供服务。互不干扰，提高了性能
3.RDB持久化之后的文件是dump.rdb
4.RDB的持久化策略 SnapsShot

我们在配置文件中找到了关于快照的配置，这个意思就是说我们可以通过改变参数实现，不同的持久化策略。

命令为： save (seconds) (changes)

seconds 是设置一个时间范围
changes 意思是更改的次数
那么这两个参数合起来就是如果达到某一时间区间内更改的次数就会触发快照进行持久化。
例如: save 120 5 如果在120秒内更改了五次数据，就将触发快照.
如果想要禁用 SnapsShot 就使用 save " "

请注意：在改动了配置文件后请以cmd 方式 进行启动 ，具体方式为 进入redis安装目录 启动conf 文件。或者 新建一个 start.bat文件 里面输入 redis-server.exe redis.windows.conf ，用之前直接点解redis-server 的方法启动是不会生效的（它貌似仍然以出场配置启动）

在正式开发的时候，几乎每天会把这个dump文件拷贝出来放到另一台机器做备份，不可能只把备份文件放在同一台机器，因为这台机器由于物理原因损坏的话，就没法恢复了。不过这一般是运维哥们儿干的活。我们只做了解即可。

redis在恢复数据时是将rdb文件重新读取回内存。

如果想手动备份 直接 输入命令 save 即可，但注意该命令是会让redis阻塞
5.下面说的是 如果系统出问题了就停止向内存写数据

6.对于快照文件知否要启动压缩 ，如果yes的话 redis会启动 LZF算法进行压缩。但是这样会占用一点cpu。

7.BgSave ： 异步快照。在进行快照保存的同时还可以处理前台的业务。可以用lastsave获取最后一次快照的时间

RDB总结：

优势：适合大规模的数据恢复
对数据一致性要求不高时 可以使用
劣势：最后一次的快照有可能丢失数据
Fork时会拷贝一次内存中的数据，需要考虑数据膨胀性

三。AOF (Append only file ) 只进行数据追加的文件

1.官网简介：

以日志的形式，记录redis每个写操作（读操作不管）只追加文件不改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis在启动时就会从前到后的读取一遍日志文件，完成数据的恢复。（记录日志时是以异步的形式）

在这里我们可以看到AOF是默认关闭的。现在我们把它修改为 yes ，重新启动。

可以发现aof文件已经生成了。

当我在客户端输入 set k1 v1 的时候，打开aof文件就会发现 ，日志已经被记录了。

关闭服务，重新启动会发现数据被恢复。

注意：如果客户端执行饿了FLUSHALL的话，他也会记录。那么在数据恢复的时候，就会是空的。可以在AOF文件中将flushall命令删除掉（但是一般情况下最好不要修改）

思考:假设在有dump.rdf 文件的情况下，但是 AOF文件损坏，redis还能启动吗？
为了解决这个疑问我们就模拟这个个情况进行演示.

首先此时我的rdb 和 aof文件是都存在的，且内容没有问题。
现在我将aof中的命令进行搞破坏。。。。（瞎打一通）

再次启动时发现连接被拒了！(弹出的太快了，截不到图请谅解。。。。)

那么设想一下，难道是AOF 与 RDB同时存在的时候会优先选择AOF来恢复数据吗？？
带着这个疑问，我们将配置文件中的 appendonly 设置为no （关闭AOF服务），如果它能去启动，就说明它使用了 rdb文件来帮我们恢复了数据。

如上图所示，redis又成功启动了！

由此我们得出结论：
当AOF与RDB同时存在的时候，redis会优先选择AOF方式帮我们恢复好数据，但如果AOF出错的话，启动也会随之失败而告终（并不会继续用RDB来启动的）

那么AOF文件损坏的话我们其实是可以修复的，因为这种情况其实很常见，在我们日常运行中有可能在向redis写数据的时候遇到某种断电情况或者不可预防的情况，对AOF的操作也会中断，那么有可能就写了一半（出现了乱码等情况），我们可以cmd执行安装目录下的 redis-check-aof.exe来修复AOF文件。


这时AOF文件中的乱码已经消失了！再次启动redis发现，启动成功。

2.AOF持久化策略

可以看到AOF一共有三种持久化策略：

• Always :同步持久化，每次执行写操作都记录到磁盘（比较影响性能，但数据不会丢失）
• everysec：异步操作，每一秒记录一次，如果一秒内宕机 则一秒内的数据丢失（出厂设置，推荐。就算数据丢失了也好恢复，性能好。）
• no：不写（一般不会用这个。。。）

3.Rewrite

上面这段话已经将Rewrite机制说的很清楚了。就是为了避免文件过大而使用的。
或者有黑客想要恶意攻击你得AOF文件。
Redis重写触发的条件：当AOF文件是上次重写后的AOF文件大小的两倍且大于64M时触发

AOF总结：

• 优势：配置灵活，数据安全性比较好，在文件过大时会进行重写。
• 劣势：AOF用的时间久了以后AOF文件可能会很大（远大于RDb），效率不高，在使用每秒异步时效率会有提升。恢复时效率较低。
  

最后，使用总结：

- 如果你的系统不需要非常高的数据完整性和数据一致性，并且追求较高的恢复效率，你可以选择RDB来执行。如果对数据精度要求很高，推荐使用AOF，AOF文件重写阀值建议设置3G以上。第三种，只做缓存的话可以不用持久化。