大数据必学：深入了解 Redis 的持久化机制

因为 redis是一个内存数据库，所有数据都存储在内存中，而且内存中的数据非常容易丢失，所以 redis的数据持久化就变得非常重要， redis提供了两种数据持久化方法，分别用于 RDB和 AOF，而 redis默认用于 RDB的数据持久化方法。

一、RDB持久性方案简介

RDB方案简介：

Redis将定期将数据快照保存到 rdb文件中，并在启动时自动装入 rdb文件，以恢复之前保存的数据。可将 Redis配置为在配置文件中保存快照。

save [seconds] [changes]

意思是[seconds]秒内如果发生了[changes]次数据修改，则进行一次RDB快照保存，例如：

save 60 100

每隔60秒 Redis就会检查一次数据更改，如果发生了100次或更多的数据更改，将保存 RDB快照。多个 save指令可以进行配置， Redis可以执行多层快照保存策略。默认打开 RDB快照。RDB快照保存还可以通过 SAVE或 BGSAVE命令手动触发。

在 SAVE和 BGSAVE命令中， rdbSave函数都被调用，但是它们以不同的方式调用：

1、在保存完成之前， SAVE直接调用 rdbSave来阻塞 Redis主进程。服务器无法在主进程阻塞期间处理客户机的任何请求。

2、而 BGSAVE则把子进程 fork出来，该进程负责调用 rdbSave，并在保存完成后向主进程发出通知，告知保存完成。在 BGSAVE执行过程中， Redis服务器仍可继续处理客户机请求。

RDB方案好处：

1、最低限度的性能影响。如前所述，当保存 RDB快照时， Redis将对 fork出子进程执行，这几乎不会影响 Redis处理客户机请求的效率。

2、每一张快照都会产生一个完整的数据快照文件，因此可以用其他方法来同时保存多个时间点的快照(例如将每天0点的快照备份到其他存储介质)，作为非常可靠的灾难恢复方法。

3、与 AOF相比，使用 RDB文件的数据恢复更快

RDB模式缺陷：

1、快照是定期生成的，因此当使用 Redis crash时，数据的一部分或多或少会丢失。

2、当数据集非常大， CPU不够强时(例如单核 CPU), Redis可能会花费相对较长的 fork子进程时间，从而影响 Redis外部服务的提供。

RDB方案配置：

修改redis的配置文件：

重启 redis Service

每生成一个新的 dump. rdb，就覆盖以前的旧快照

二、AOF持久化方案简介

1、AOF方案简介：

AOF (append only file)持久化：将每个写入命令以独立日志的方式记录下来，重启后再重新执行 AOF文件中的命令，以实现数据恢复。AOF的主要功能是处理数据持久的实时性，目前， AOF已成为 Redis持久性的主流方式。了解掌握 AOF的持久性机制对于我们处理数据安全和性能方面非常有帮助。

2、运用AOF：

打开 AOF功能要求进行设置配置： appendonlyyes，默认不启用。通过 appendfilename配置设置 AOF文件名，默认的文件名是appendonly.ao f。通过 dir配置指定，保存路径与 RDB持久化方式一致。AOF工作流程操作 ：命令写入(append)，文件同步(sync)，文件重写(rewrite)，重新启动装载(load)，如图所示。

执行流程：

1、所有的写入命令会追加到aof_buf（缓冲区）中。

2、根据相应的策略， AOF缓冲区对硬盘进行同步操作。

3、当 AOF文件变得更大时，需要定期重写 AOF文件，以实现压缩。

4、重启 Redis服务器后，可以加载用于数据恢复的 AOF文件。

3、文件同步：

Redis提供了多种 AOF缓冲同步文件策略，这些策略由 appendfsync参数控制，图中显示了不同值的含义。

3.1、当配置为 always时，每次写入都会同步 AOF文件，而在普通 SATA硬盘上， Redis只支持大约数百 TPS写入，这显然与 Redis的高性能特性背道而驰，因此不推荐使用。

3.2、配置为 no，因为操作系统对 AOF文件的每一次同步都是不可控制的周期，并且会增加每一次同步硬盘的数据量，虽然提高了性能，但是数据安全没有保障。

3.3、配置为 everysec，建议采用同步策略和默认策略，以兼顾性能和数据安全。

4、重写机制：

AOF会随着命令的执行而变大，为了解决这个问题， Redis引入了 AOF覆盖机制来压缩文件。AOF文件覆盖是将 Redis进程中的数据转换成写入命令，使其与新 AOF文件同步的过程。

为什么覆盖了 AOF的文件可以变小？原因如下：

1、已在进程中超时的数据不再写入文件。

2、以前的 AOF文件中包含诸如 delkey1, hdelkey2, srem keys,seta111, seta222等等无效命令。覆盖直接使用进程中的数据生成，因此新的 AOF文件只保存最终数据的写入命令。

3、可以将多个写命令合并成一个，例如： lpush list a,、lpush list b、lpush list c可转换为： lpush list a b c 。为避免单个命令太大导致客户端缓冲区溢出，对于 list, set, hash, zset之类的类型操作，将多个元素分割成64个界限。

AOF重写减少了文件占用空间，除此之外，还有另外一个目的： Redis可以更快地加载更小的 AOF文件。

可手动或自动触发 AOF重写过程：

手动触发：直接调用命令 bgrewriteaof。

自动触发：Auto-aof-rewrite-min-size和Auto-aof-rewrite-percentage参数决定了自动触发的时间点。

解释：

1、auto-aof-rewrite-min-size：表示在运行 AOF覆盖时，文件的最小体积，默认值为64 MB。

2、auto-aof-rewrite-percentage：表示 AOF文件空间(aof_current_size)与上次重写后的 AOF文件空间之间的比值。

3、自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

AOF场景配置：

1、在 redis中， aof的持久化机制默认关闭

2、AOF持久化默认为关闭的 ，RDB持久化默认为打开

3、appendonly yes，能够打开 AOF持久机制，在生产环境中，通常 AOF都会被打开，除非你不介意数据被随意丢失几分钟

4、在打开 AOF持久化机制后， redis每次收到写命令时，都会将其写入日志文件，当然是先写入 os cache，然后每隔一段时间再进行 fsync

5、当 AOF和 RDB都打开并且 redis重新启动时，优先使用 AOF恢复数据，因为 aof数据比较完整

AOF的 fsync策略可以进行配置，有三种策略可供选择：

1、一种是每次写入数据时都执行一次 fsync。

2、另一种是每隔一秒执行一次 fsync。

3、另一种是不主动执行 fsync。

always：每写一次，就把相应于该数据的写日志 fsync放到磁盘上，性能非常糟糕，吞吐量也很低；要确保说 redis中的一个数据不会丢失，只能这样。

redis中的默认 AOF持久性机制全部关闭

Redis的AOF持久化机制配置：

重新启动 redis实例，并在执行简单操作后关闭该实例，重新启动 redis实例。

三、重启加载流程：

如果觉得对你有所帮助。记得收藏和关注呦！（每日更新各种大数据框架）

如需转载请注明出处（创作不易请见谅）

和巨婴程序猿一起成长。让自己变得更优秀

想了解更多精彩内容，快来关注跟着巨婴去逆袭

我最近一直在思考（大数据通俗讲解）的问题，你的看法是什么呢？关注我快说出来一起交流一下吧~