wordpress去顶部文字,山东seo费用多少,在什么网站上可以做中学数学家教,专业网站建设 公司排名Redis持久化
Redis的读写操作都是在内存上#xff0c;所以Redis性能高。 但是当重启的时候#xff0c;或者因为特殊情况导致Redis崩了#xff0c;就可能导致数据的丢失。 所以Redis采取了持久化的机制#xff0c;重启的时候利用之间持久化的文件实现数据的恢复。
Redis提…Redis持久化
Redis的读写操作都是在内存上所以Redis性能高。 但是当重启的时候或者因为特殊情况导致Redis崩了就可能导致数据的丢失。 所以Redis采取了持久化的机制重启的时候利用之间持久化的文件实现数据的恢复。
Redis提供了三种持久化的机制
RDB将某一段时间的内存数据以二进制的方式写到磁盘中AOF每次执行写操作都将命令以追加的方式写到文件中混合持久化方式结合了RDB和AOF的优势
RDB机制
RDB持久化是把当前进程数据生成快照保存到硬盘的过程触发RDB持久化过程分为手动触发和自动触发。 ps 执行快照是一种比较重的操作如果频率太低那么当服务器崩了那么丢失的数据就多如果频率高那么就会对性能造成影响。
手动触发
手动触发分别对应save和bgsave命令
save命令阻塞当前Redis服务器直到RDB过程完毕为止对于内存比较大的实例会造成长时间的阻塞。这很不推荐bgsaveRedis过程执行fork之后会创建子进程RDB的持久化工作就是让子进程负载完成后自动结束。
自动触发机制
使用save配置。 如“save m n” 表示m秒内数据发送了n次修改自动RDB持久化从节点进行全量复制操作的时候主节点自动进行RDB持久化随后将文件内容发送给从节点执行shutdown命令关闭Redis时执行RDB持久化
下图是bgsave命令的过程
执行bgsave的时候Redis父进程判断当前进程是否存在其他进程的子进程如RDB/AOF子进程如果存在bgsave命令直接返回如果不存在父进程创建子进程fork过程中父进程阻塞可以通过info stat命令查看latest_fork_user选项可以获取最近一次fork操作的耗时单位是毫秒父进程fork完毕后bgsave命令返回“Background saving started”信息并不再阻塞父进程可以继续响应其他命令子进程会创建RDB文件根据父进程内存生成一个临时快照文件完成后对原有的文件进行替换。最后子进程发送信号给父进程父进程更新统计结果
Redis默认的配置文件中提供了bgsave的方式
save 900 1
save 300 10
save 60 10000
900s之内对数据进行一次修改300s之内对数据进行10次修改60s之内对数据进行1000修改
如果触发了上面的条件那么就会触发RDB机制。
RDB文件的处理
保存RDB⽂件保存在dir配置指定的⽬录默认/var/lib/redis/下⽂件名通过dbfilename配置默认dump.rdb指定。可以通过执⾏config set dir {newDir} 和 config set dbfilename {newFilename}运⾏期间动态执⾏当下次运⾏时RDB⽂件会保存到新⽬录。
RDB的优缺点
RDB是一个紧凑压缩的二进制文件代表Redis在某个时间上的数据快照。 使用于备份全量复制等场景。Redis加载RDB文件恢复数据远远快于AOF文件因为RDB文件是以二进制存储的。RDB方式数据没办法做到实时持久化/秒级持久。 因为bgsave每次运行都要执行fork创建子进程属于重量操作频繁操作成本高。
AOF机制
AOF持久化以独立日志的方式记录每次写操作重启的时候执行AOF文件中的命令达到恢复数据的目的。
可以在配置文件中开启appendonly yes选项默认是不开启。 下图是AOF的工作流程
将所有的写入操作追加到aof_buf缓冲区中AOF缓冲区根据对应的策略向硬盘做同步操作随着AOF文件越来越大需要定期的AOF文件进行重写达到压缩的目的当Redis启动的时候可以加载AOF文件进行数据的恢复
AOF命令写入的内容是以文本协议格式。 例如set hello world 这条命令在AOF缓冲区追加如下文本所示
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\nAOF是选择文本协议来进行存储的Redis以这种方式存储有可能的原因如下
文本协议有较好的兼容性实现简单可读性好
看了AOF的工作流程后想一想为什么AOF需要aof_buf这个缓冲区呢 Redis使用单线程响应命令如果每次写AOF文件都直接同步到硬盘上性能从内存到IO读写性能会下降。 所以先将数据写入到aof_buf中会有效降低IO的次数同时Redis提供了3种缓冲区的同步策略。 如下图所示
文件同步
Redis提供了3种AOF缓冲区同步文件策略。由参数appendfsync控制 系统调用write和fsync
write操作会触发延迟写机制。Linux在内核中提供了页缓冲区来提供硬盘IO性能。write在写入系统缓冲区后立即返回。同步硬盘操作依赖于系统调度机制。fsync是对单个文件进行操作做强制硬盘同步fsync将阻塞直到数据写入到硬盘上。
当Redis同步策略为always时每次写都要同步AOF文件性能很差。 配置为no的时候同步策略不可控虽然提高了性能但数据丢失的可能性增大了 当配置为everysec的时候是默认配置兼顾了数据安全和性能。
所以不同的策略如果发送数据丢失数据丢失的程度是不一样的如果是always那么每次都会进行同步操作数据不会丢失但是如果设置为no那么数据丢失就可能很多而everysec数据只会丢失1s内的数据。
AOF重写机制
随着命令不断地写入到AOF文件中文件会越来越大为了解决这个问题Redis引入了重写机制来解决。
什么是重写机制
Redis会将旧的命令删除掉只会保留数据的最新版本。 并且多条写操作会合并成一条。
而较小的AOF文件一方面降低了硬盘的空间一方面可以提高启动Redis恢复数据的速度。
AOF重写过程也分为手动触发和自动触发
手动触发调用bgrewriteof命令自动触发根据auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。
auto-aof-rewrite-min-size 表示触发时AOF的最小文件大小默认是64MB auto-aof-rewrite-percentage代表当前AOF占用大小相比较上次重写时增加的比例
AOF重写的流程图如下
执行AOF重写请求 如果当前进程正在执行AOF重写请求不执行。如果当前进程正在执行bgsave操作重写命令延迟到bgsave操作完毕后执行父进程执行fork创建子进程重写 a.主进程fork之后继续响应其他命令。所有的修改写入到AOF的缓冲区中并根据appendfsync策略同步到硬盘保证旧的AOF文件机制正确 b. 子进程只有fork之前的所有内存信息。父进程需要将fork之后的这段时间的写操作写入到AOF重写缓冲区中子进程根据内存快照将命令合并到新的AOF文件完成子进程重写新文件写入后子进程发送信号给父进程。父进程将AOF重写缓冲区的数据追加到新的AOF文件中。 最后将新的AOF文件替换旧的AOF文件
所以Redis持久化的机制为下图所示
为什么会有混合持久化
RDB的优势就是恢复速度快因为是以二进制存储的但是快拍的频率不好把握。频率太低丢失的数据量就多频率太多就会导致性能降低
AOF的优点丢失的数据少但是恢复的速度不快。
所以结合了RDB和AOF的优点Redis4.0推出了混合持久化的机制保证了Redis的重启速度又降低了数据丢失的风险。 混合持久化最大的差别就是AOF文件不再是以文本来存储的了而是以二进制的方式来存储。这就导致了恢复数据的时候速度会比AOF快。
