redis持久化

       今天小编就来和大家一起分享一下redis持久化，不知道大家一般使用redis是在什么场景下呢，小编使用redis多数用在缓存的功能上。redis被称为非关系型数据库，以键值结构进行存储，并且基于内存进行，采用的时非阻塞的IO模式，IO多路复用，这使redis的读写效率都非常的高。在redis 6之前的版本中redis一直是单线程的，在redis 6版本后，redis编程的多线程，不过小编还没有用过这么高的版本哈。有使用过的小伙伴们可以和小编分享一下使用心得和感受哈。

        下面小编就和大家分享一下小编的redis持久化心得，所谓持久化，就是将数据写入磁盘进行记录，因为redis是基于内存运行的，所以redis要将内存的数据写入磁盘，redis在进行持久化，redis会单独创建（fork）一个和原进程一模一样的子进程。子进程内存数据写入临时文件中，最后将临时文件把原rbd文件替换。这个进程中，主进程不会进行io操作。那么下面我们就来一试验一下，看看redis是不是fork了一个子进程。首先我们要进行造数，因为redis是基于内存的，所以速度非常快，我们需要大量的数据，小编准备采用java脚本对redis进行造数。（记得关闭Linux系统的防火墙哦）。

 我们这里准备了5000005条数据，下面我们就开始验证啦。

当我们执行bgsave进行持久化时，可以看到关于redis会出现一条redis-rdb-bgsave的子进程，当bgsave执行结束后，子进程又消失了

 

当然redis不仅仅可以使用bgsave来进行持久化操作，还有其他方法可以进行持久化操作，下面我们就具体聊聊redis的持久化机制吧

redis的持久化分为三种，一种是rbd另一种是aof，而另一种是在redis 4版本才新加入的一种模式，叫做混合持久化。

RBD持久化：

我们先来了解一下在什么情况下会进行rbd的持久化：

       1、redis正常关机（shutdown）且没有开启aof备份机制

       2、执行save和bgsave操作时，save会阻塞，而bgsave不会阻塞（上面我们提到过，redis的IO是非阻塞的，并且是fork一个子进程来完成持久化操作，但是如果我们执行的命令是save而不是bgsave，那么这个时候redis是用主进程类进行持久化操作的，并非fork一个子进程，所以会阻塞），下面我们来进行一个实验

我们可以看到，这个save的操作执行了1.77s，在执行save操作后立即执行一个set test test，执行了0.98秒，是存在延迟的，在save操作执行结束，又执行了一个set test1 test1，这个是没有延迟的

        3、执行flushall操作时，会进行rbd的持久化操作

        4、配置文件中进行配置  例如 save 300 10 意为300秒内有10个更改时，执行rbd持久化机制，将配置更改为save “”，或将save全部删除，会将rbd持久化关闭。（若存在主从复制，则无法关闭rbd持久化）

当然，rbd持久化是存在一定的缺点的，因为redis是基于内存工作的，那么最大的缺点就是不能及时的进行持久化，容易造成数据丢失。

AOF持久化：

        在进行aof持久化时，会生成aof文件，aof文件与rbd文件记录数据的方式不同，aof记录的是操作命令，而rbd记录的是数据。图一是aof持久化生成的持久化文件，图二是rbd持久化生成的持久化文件。

对于这两个文件而言，很显然AOF文件是我们可以看的懂的，那么小编就为大家解读一下，*3代表的含义是一共有3个参数，$3代表参数有3个字节，之后set是这个参数的参数值。小编一共执行了三个set命令，之后生成了这个aof文件，大家可以自行对照阅读一下哈，但是对于rbd的文件，小编是真的读不懂哈（三个命令如下图）

上面我们了解了rbd文件的持久化方式，现在我们来了解一下aof持久化机制，aof持久化主要靠配置，首先需要配置appendonly为yes，配置appendfilename为aof文件的名称，格式是以.aof结尾，之后就是aof持久化的触发条件了，一共有三个：appendfsync no：表示等操作系统进行数据缓存同步到磁盘（快但持久化没保证，由操作系统控制，多长时间进行一次持久化操作不清楚）。appendfsync always 同步持久化：表示每次发生更改时立即记录磁盘（慢，但是持久化安全）。appendfsync everysec ：表示每秒同步一次（很快，但可能丢失一秒以内的数据）。

注意：当rbd和aof持久化同时开启时，以aof持久化为准。并不会加载rdb文件。并且以aof文件覆盖rdb文件。（需先将aof关闭，再启动redis，再启动aof。此时会生成aof文件。因为redis4.0后存在混合持久化机制，故进行此操作后，aof和rbd文件大小相同）

       下面说的就是aof的重写机制，因为当aof已经很大的时候，则会将aof文件进行重写，小编在这里敲了4条命令

生成的aof文件是这个样子的，见下图

那么现在小编手动执行以下aof重写的命令bgrewriteaof

我们再来看一下重写后的aof文件

我们发现set aof aof的命令和del aof命令都不见了，就好像没有执行过这两个命令，对了就是这个样子，所谓重写aof文件，就是将可以相互抵消的两个命令进行合并，只留下还需要的命令。

aof重写我们还可以通过配置文件进行配置，就是配置这两个参数想，上一章博文也有提到过，auto-aof-rewrite-min-size和auto-aof-rewrite-percentage（auto-aof-rewrite-min-size 64mb 当aof文件达到64mb时，重写aof文件（第一次触发），auto-aof-rewrite-percentage 100 当比例达到64mb的一倍时再次重写）

（注意：开启aof持久化时，会先将数据写入aof缓存区，再写入硬盘，当aof重写时，先会检查是否存在重写子进程。若当前不存在子进程，则主进程会fork一个新的子进程。重写的数据从内存中获得，重写时，将数据先写入aof缓存区，在写入aof重写缓存区，再替换原有的aof文件。（aof只有重写时会fork子进程））

混合持久化：

        所谓混合持久化就行aof和rbd一起进行持久化的一个方式，关于混合持久化的配置是这个参数aof-use-rbd-preamble，将这个参数配置成yes后就可以进行混合持久化啦。下面为大家演示一下。

混合持久化的记录方式就是这样子的哦，上面一部分是以rbd形式进行的持久化方式，而下面一部分是以aof方式来进行的持久化方式，当混合持久化被开启，aof重写时，会将记录的aof重写后并转化为rbd持久化的方式进行记录，操作后，继续以aof持久化的方式记录后续的内容，如此循环。

（最后小编把造好数的rbd文件上传至CSDN博客了哈，地址：CSDNhttps://mp.csdn.net/mp_download/manage/download/UpDetailed想手动尝试的小伙伴们自行去下载吧）

如果小编的内容对您有帮助，就请您帮忙点关注和赞吧，点关注，不迷路！