redis的持久化方式详解

目录

一、redis为什么要持久化？

二、redis的持久化值怎么实现的？

三、redis持久化的三种实现方式

        1、RDB

                实现原理：

                特点：

                触发方式:

                优缺点：

        2、AOF

                实现原理：  

                触发机制：

                优缺点：

        3、混合模式

一、redis为什么要持久化？

        redis是开源的，使用 C语言编写，支持网络交互，可以是基于内存可以持久化的key value 的数据库（非关系型的数据库），但是对于redis的存储方式，是存储在内存的，如果遇到如宕机等，存放在内存的数据救回丢失，所以就需要实现持久换来保证数据的完整性，安全性。

二、redis的持久化值怎么实现的？

        redis的持久化通过三种方式，来实现持久化。

三、redis持久化的三种实现方式

        1、RDB

                实现原理：

                在指定的时间间隔对数据进行快照，恢复时会将快照文件直接读取到内存中。redis会单独的创建一个fork子进程进行持久化，将数据写入到一个临时文件中，等待持久化操作结束之后将这个临时文件替换上次的临时文件， 这个过程不执行熊操作，能够保证极高的性能。如果需要进行大量的数据恢复，而且对数据 恢复完整性要求不非常敏感的话。【RDB模式户比AOP模式更加的高效】

                特点：

                 rdb模式的特点是使用二进制的格式全量的保存redis中的数据,在存储上非常的紧凑,从而使可以控制文件的大小不至于太大.

                触发方式:

                       1、 save

　　　　　　　　该命令使用主线程进行快照生成,所以在命令执行期间redis不能处理其他命令,直到rdb过程结束,所以在生产环境中尽量少使用该命令.

                        2、bgsave

　　　　　　　　bgsave命令执行的时候会fork出子线程,主线程会直接返回,生成rbd快照的工作交由子线程处理,所以该命令只会在fork子线程的时候阻塞,这个过程一般很短,所以如果想要生成rdb快照,可以考虑使用bgsave命令代替save命令,减少阻塞时间.执行shutdown命令关闭服务器时，如果没有开启AOF持久化功能，那么会自动执行一次bgsave

  save和bgsave的区别                   

                  3、自动触发

                        在redis.conf中配置了save m n 参数.即在m秒内有n次修改则自动生成rdb文件.

　　　　　　   主从复制.当从服务器第一次连接上主服务器时,首先需要一次全量的复制,这时候会在主服务器上触发rdb生成快照

　　　　　　   在优雅的关闭redis服务的时候,如果没有开启其他持久化机制,redis会默认进行 bgsave操作.

                优缺点：

                        优点：             

                                适合大规模的数据；

                                对数据的要求不高。

                       缺点：

                                需要一定时间间隔进行操作，如果redis以外宕机的话最后一次的修改就会没有

                       fork 会占用一定的空间。

 

        2、AOF

                实现原理：  

                 记录每次对服务器写操作，当服务器重启是就会重新执行命令恢复原有的数据。将我们写入全部记录，恢复时将文件再执行一次。AOP保存文件名为 appdendonly.aof，以日志的形式写入操作（读不记录），只允许文件大数据的情况下需要很久，默认是不开启的 。

AOF Rewrite 虽然是“压缩”AOF文件的过程，但并非采用“基于原AOF文件”来重写或压缩，而是采取了类似RDB快照的方式：基于Copy On Write，全量遍历内存中数据，然后逐个序列到AOF文件中。因此AOF rewrite能够正确反应当前内存数据的状态。

AOF重写（bgrewriteaof）和RDB快照写入（bgsave）过程类似，二者都消耗磁盘IO。Redis采取了“schedule”策略：无论是“人工干预”还是系统触发，快照和重写需要逐个被执行。

重写过程中，对于新的变更操作将仍然被写入到原AOF文件中，同时这些新的变更操作也会被Redis收集起来。当内存中的数据被全部写入到新的AOF文件之后，收集的新的变更操作也将被一并追加到新的AOF文件中。然后将新AOF文件重命名为appendonly.aof，使用新AOF文件替换老文件，此后所有的操作都将被写入新的AOF文件

                触发机制：

                和RDB类似，AOF触发机制也分为：手动触发和自动触发

                  手动触发 直接调用bgrewriteaof命令

redis-cli -h ip -p port bgrewriteaof

                自动触发

                根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB（我们线上是512MB）。

auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值

自动触发时机：

(aof_current_size > auto-aof-rewrite-min-size ) && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

       

                优缺点：

                         优点：每次更新时间不同步，文件的完整性好。

                          缺点：相对于rdb文件，修复的速度很快，效率没有rdb高

        3、混合模式

                重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小.于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。