redis系列--redis4.0深入持久化
前言在之前的博文中已经详细的介绍了,并且在memcache和redis对比中提及redis提供可靠的数据持久化方案,而memcache没有数据持久化方案,本篇博文将详细介绍redis4.0所提供的持久化方案:RDB持久化和AOF持久化以及redis4.0新特性混合持久化。这里将从原理到配置以及相关实践进行说明,希望能对你有所帮助。 一、RDB持久化简介RDB持久化方式是通过快照(snapshotting)完成的,当符合一定条件时,redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。当redis重启时,并且AOF持久化未开启时,redis会读取RDB持久化生成的二进制文件(默认名称dump.rdb,可通过设置dbfilename修改)进行数据恢复,对于持久化信息可以用过命令“info?Persistence”查看。 快照文件位置RDB快照文件存储文件位置由dir配置参数指明,文件名由dbfilename指定,如下: 快照触发条件RDB生成快照可自动促发,也可以使用命令手动触发,以下是redis触发执行快照条件,后续会对每个条件详细说明:
save命令触发客户端执行save命令,该命令强制redis执行快照,这时候redis处于阻塞状态,不会响应任何其他客户端发来的请求,直到RDB快照文件执行完毕,所以请慎用。 实践操作: 首先使用info?Persistence查看最近一次持久化时间: 此时我们执行save命令,并再次查看最新快照保存时间已经是最新一次时间: 当然你也可以直接查看RDB数据文件目录下的RDB文件最新时间: bgsave命令触发bgsave命令可以理解为background save即:“后台保存”。当执行bgsave命令时,redis会fork出一个子进程来执行快照生成操作,需要注意的redis是在fork子进程这个简短的时间redis是阻塞的(此段时间不会响应客户端请求,),当子进程创建完成以后redis响应客户端请求。其实redis自动快照也是使用bgsave来完成的。 为了能清楚了解bgsave工作过程,以下将图文详细描述其工作过程: 对上述过程描述:
实践操作: 执行bgsave 查看日志,能看到6MB文件内存副本写到了磁盘上,同时打印“Background saving terminated with success”代表文件bgsave操作完成。 此时我们查看统计信息最后一次RDB保存时间已经更新: ?save m n规则触发?save m n规则说明:在指定的m秒内,redis中有n个键发生改变,则自动触发bgsave。该规则默认也在redis.conf中进行了配置,并且可组合使用,满足其中一个规则,则触发bgsave,在上篇博文也进行了解释,如下: 以save 900 1为例,表明当900秒内至少有一个键发生改变时候,redis触发bgsave操作。 实践操作: 我们改变一个键,满足save 900 1 : 此时查看redis日志,会发现redis立即响应开始bgsave操作: FLUSHALL触发flushall命令用于清空数据库,请慎用,当我们使用了则表明我们需要对数据进行清空,那redis当然需要对快照文件也进行清空,所以会触发bgsave。 实践操作: 日志: shutdown触发shutdown命令触发就不用说了,redis在关闭前处于安全角度将所有数据全部保存下来,以便下次启动会恢复。 实践操作: 可以使用客户端连入执行shutdown命令,也可以直接使用脚本关闭redis,这里我使用init脚本(系统centos6.X)。 查看日志: 主从触发在redis主从复制中,从节点执行全量复制操作,主节点会执行bgsave命令,并将rdb文件发送给从节点,该过程会在复制篇中进行阐述。 故障恢复上面提及到过,当redis意外崩溃或者关闭再次启动时,此时AOF持久化未开启时(默认未开启),将使用RDB快照文件恢复数据。 下面我们停用redis服务来模拟故障情况,让再启动redis服务: 观察日志会发现,启动时候load RDB文件。 RDB持久化配置?二、AOF持久化简介当redis存储非临时数据时,为了降低redis故障而引起的数据丢失,redis提供了AOF(Append Only File)持久化,从单词意思讲,将命令追加到文件。AOF可以将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中,在redis启动时候优先选择从AOF文件恢复数据。由于每一次的写操作,redis都会记录到文件中,所以开启AOF持久化会对性能有一定的影响,但是大部分情况下这个影响是可以接受的,我们可以使用读写速率高的硬盘提高AOF性能。与RDB持久化相比,AOF持久化数据丢失更少,其消耗内存更少(RDB方式执行bgsve会有内存拷贝)。 开启AOF默认情况下,redis是关闭了AOF持久化,开启AOF通过配置appendonly为yes开启,我们修改配置文件或者在命令行直接使用config set修改,在用config rewrite同步到配置文件。通过客户端修改好处是不用重启redis,AOF持久化直接生效。 AOF持久化过程?redisAOF持久化过程可分为以下阶段: 1.追加写入 redis将每一条写命令以redis通讯协议添加至缓冲区aof_buf,这样的好处在于在大量写请求情况下,采用缓冲区暂存一部分命令随后根据策略一次性写入磁盘,这样可以减少磁盘的I/O次数,提高性能。 2.同步命令到硬盘 当写命令写入aof_buf缓冲区后,redis会将缓冲区的命令写入到文件,redis提供了三种同步策略,由配置参数appendfsync决定,下面是每个策略所对应的含义:
3.文件重写(bgrewriteaof) 当开启的AOF时,随着时间推移,AOF文件会越来越大,当然redis也对AOF文件进行了优化,即触发AOF文件重写条件(后续会说明)时候,redis将使用bgrewriteaof对AOF文件进行重写。这样的好处在于减少AOF文件大小,同时有利于数据的恢复。 为什么重写?比如先后执行了“set foo bar1 set foo bar2 set foo bar3” 此时AOF文件会记录三条命令,这显然不合理,因为文件中应只保留“set foo bar3”这个最后设置的值,前面的set命令都是多余的,下面是一些重写时候策略:
重写触发条件?AOF文件触发条件可分为手动触发和自动触发: 手动触发:客户端执行bgrewriteaof命令。 自动触发:自动触发通过以下两个配置协作生效:
redis开启在AOF功能开启的情况下,会维持以下三个变量
每次当serverCron(服务器周期性操作函数)函数执行时,它会检查以下条件是否全部满足,如果全部满足的话,就触发自动的AOF重写操作:
重写过程AOF文件重写过程与RDB快照bgsave工作过程有点相似,都是通过fork子进程,由子进程完成相应的操作,同样的在fork子进程简短的时间内,redis是阻塞的,以下图文说明其重写过程: 过程说明: aof_rewrite_buf 代表重写缓冲区? ? ? aof_buf代表写写命令存放的缓冲区 1.开始bgrewriteaof,判断当前有没有bgsave命令(RDB持久化)/bgrewriteaof在执行,倘若有,则这些命令执行完成以后在执行。 2.主进程fork出子进程,在这一个短暂的时间内,redis是阻塞的。 3.主进程fork完子进程继续接受客户端请求,所有写命令依然写入AOF文件缓冲区并根据appendfsync策略同步到磁盘,保证原有AOF文件完整和正确。由于fork的子进程仅仅只共享主进程fork时的内存,因此Redis使用采用重写缓冲区(aof_rewrite_buf)机制保存fork之后的客户端的写请求,防止新AOF文件生成期间丢失这部分数据。此时,客户端的写请求不仅仅写入原来aof_buf缓冲,还写入重写缓冲区(aof_rewrite_buf)。 4.子进程通过内存快照,按照命令重写策略写入到新的AOF文件。 4.1子进程写完新的AOF文件后,向主进程发信号,父进程更新统计信息。 4.2主进程把AOFaof_rewrite_buf中的数据写入到新的AOF文件(避免写文件是数据丢失)。 5.使用新的AOF文件覆盖旧的AOF文件,标志AOF重写完成。 AOF实现本质AOF实现本质是基于redis通讯协议,将命令以纯文本的方式写入到文件中。 redis协议: 首先Redis是以行来划分,每行以rn行结束。每一行都有一个消息头,消息头共分为5种分别如下: (+) 表示一个正确的状态信息,具体信息是当前行+后面的字符。 (-) ?表示一个错误信息,具体信息是当前行-后面的字符。 (*) 表示消息体总共有多少行,不包括当前行,*后面是具体的行数。 ($) 表示下一行数据长度,不包括换行符长度rn,$后面则是对应的长度的数据。 (:) 表示返回一个数值,:后面是相应的数字节符。 我们可以直接查看AOF文件中的格式,如下图: 数据恢复之前已经提到当AOF开启时候,redis数据恢复优先选用AOF进行数据恢复,以下使用停止redis来模拟redis故障,然后在重写启动进行恢复。 查看日志会发现数据恢复已经变成从AOF(append only file)文件中恢复: AOF配置参数auto-aof-rewrite-min-
-aof-rewrite-percentage 100
-load-
/etc/
实践实践操作这里使用手动执bgrewriteaof演示重写。 查看日志: 三、RDB-AOF混合持久化简介redis4.0相对与3.X版本其中一个比较大的变化是4.0添加了新的混合持久化方式。前面已经详细介绍了AOF持久化以及RDB持久化,这里介绍的混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点,快速加载同时避免丢失过多的数据,缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式,可读性差。 开启混合持久化4.0版本的混合持久化默认关闭的,通过aof-use-rdb-preamble配置参数控制,yes则表示开启,no表示禁用,默认是禁用的,可通过config set修改。 混合持久化过程了解了AOF持久化过程和RDB持久化过程以后,混合持久化过程就相对简单了。 混合持久化同样也是通过bgrewriteaof完成的,不同的是当开启混合持久化时,fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件,然后在将重写缓冲区的增量命令以AOF方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说:新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据,如下图: 数据恢复当我们开启了混合持久化时,启动redis依然优先加载aof文件,aof文件加载可能有两种情况如下:
实践??开启混合持久化,并在开启后立马执行写操作,为了证实混合持久化的后半部分AOF过程 查看日志: 此时的aof文件已经和只开启AOF持久化文件不一样了,上半部分是RDB持久化的数据,下半部分是AOF格式数据。
四、优缺点??RDB优点:
缺点:
AOF优点:
缺点:
混合持久化优点:
缺点:
五、相关命令aof文件检查 redis-check-aof /etc/redis/appendonly.aof
rdb文件检查 redis-check-rdb /etc/redis/dump.rdb
查看持久化信息 info Persistence
查看状态信息 info stats
以上是所有内容,希望对你有帮助~ (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |