Redis基础

Redis持久化

redis虽然是一种内存型数据库，但也提供持久化方案，将内存中的数据保存到磁盘中，避免数据丢失。

redis支持两种持久化方案：

RDB：在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF：记录每次对redis服务器写的操作，当服务器重启时会重新执行这些命令来恢复原始数据。

Redis 还支持同时使用 AOF 持久化和 RDB 持久化。在这种情况下，当 Redis 重启时，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

RDB持久化

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。

RDB命令

RDB文件可以通过两个命令创建：

SAVE：执行一个同步保存操作（会阻塞redis的服务进程），将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
BGSAVE：主进程fork一个子进程来创建新的RDB文件，记录接收到的BGSAVE时刻的数据库状态，父进程继续处理接收到的命令。当子进程完成写临时文件后，用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

一般来说，在生产环境很少执行 SAVE 操作，因为它会阻塞所有客户端，保存数据库的任务通常由 BGSAVE 命令异步地执行。然而，如果负责保存数据的后台子进程不幸出现问题时， SAVE 可以作为保存数据的最后手段来使用。

优点

RDB 文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输，非常适合用于进行备份。
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点

使用 RDB 方式实现持久化，一旦 Redis 异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。

AOF持久化

快照功能并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF（append-only file）持久化。

具体来说，RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令，所有被写入AOF的命令都是以redis的协议格式来保存的。

AOF文件重写机制

AOF（append-only file）的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。但AOF 文件体积变得过大时，Redis自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF文件修复机制

服务器可能在程序正在对 AOF 文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么 Redis 在重启时会拒绝载入这个 AOF 文件，从而确保数据的一致性不会被破坏。

当发生这种情况时，可以用以下方法来修复出错的 AOF 文件：

为现有的 AOF 文件创建一个备份。
使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
```
$ redis-check-aof --fix
```
（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

优点

使用 AOF 的优点是会让 Redis 变得非常耐久。可以设置不同的 fsync 策略，AOF的默认策略是每秒钟 fsync 一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。

缺点

AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。

RDB 和 AOF ，我应该用哪一个?

一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能。

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。

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

性能与实践

通过上面的分析，我们都知道RDB的快照、AOF的重写都需要fork，这是一个重量级操作，会对Redis造成阻塞。因此为了不影响Redis主进程响应，我们需要尽可能降低阻塞。

降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
控制Redis最大使用内存，防止fork耗时过长；
升级硬件设备，如更快的内存、ssd硬盘；
结合业务特点搭建不同的redis服务：
- 对数据持久性要求不高的业务，如数据库的数据缓存，搭建不需要持久化的redis服务
- 对数据持久性和安全性要求高的，如将redis当数据库使用或者消息队列，搭建需要持久化的redis服务
搭建redis集群，启用主从模式。

总结

资料来源

文章材料摘抄自：

http://oldblog.antirez.com/post/redis-persistence-demystified.html

http://redisdoc.com/topic/persistence.html

http://redis.io/topics/persistence