码迷,mamicode.com
首页 > 其他好文 > 详细

<Redis> 入门五 持久化RBD/AOF

时间:2018-12-25 16:56:16      阅读:155      评论:0      收藏:0      [点我收藏+]

标签:span   间隔   redis   style   几分钟   自己   缓冲   通知   dfs   

RDB

  RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘(默认是 dump.rdb)。

  默认持久化机制,就是将内存中的数据以快照的方式写入二进制文件dump.rbd中。

  触发快照的条件

    1.自己配置快照规则

      save <second> <exchanges>

      second 秒内,key的修改数量大于exchanges时,执行快照

      save的关系是或的关系,都满足

      技术分享图片

      默认文件名为 dump.rdb

      默认路劲为配置文件下的当前路径

      技术分享图片

      获取配置文件中的快照规则 config get save

      添加新规则,服务器重启后失效,config set save "second exchanges"

      技术分享图片

 

    2.save或bgsave

      save:执行内存的数据同步到磁盘的操作,这个操作会阻塞客户端的请求。(不要轻易执行,数据量大,阻塞时间差)

      bgsave:在后台异步执行快照操作,这个操作不会阻塞客户端的请求。

    3.执行flushall

      清除内存中的所有数据,只要快照规则不为空,那么redis就会执行快照。

      技术分享图片

    4.执行复制的时候(集群)

  快照的实现原理

     redis会使用fork函数复制一份当前进程的副本(子进程)

    父进程继续处理客户端请求。

    fork进程负责把内存的数据同步到磁盘的临时文件,当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。

    缺点:由于子进程是复制父进程,两个内存大小相同的redis进程在系统上运行,会造成内存使用率大幅增加。

   使用rdb的优缺点

    优点:

      1.只包含一个dump.rdb文件,方便备份移动。

      2.rdb回复大数据集的速度比aof快。

      3.rdb可以最大化redis性能,因为是子进程去处理保存工作,父进程无需执行io操作。

    缺点:

      1.rbd的规则是单位时间内改变多少个键,才会触发,而在为改变之前,一旦服务器故障,就会丢失几分钟的数据

      2.当数据量大时,fork子进程会非常耗时,会造成服务器在某毫秒或长达一秒的时间停止处理客户端。并且子进程和父进程两个进程会消耗更多的内存。

AOF

  redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

  如何配置

    appendonly 改为yes

    appendfilename:保存的文件名

    技术分享图片

     当修改了值后,可以看到生成了新的文件appendonly.aof

    技术分享图片

    vim appendonly.aof文件,可以看到每条记录都被写入aof文件中

     技术分享图片

  同步磁盘数据出现的问题

    redis每次更新数据时,aof机制都会将命令写入aof文件中。

    但是实际上由于操作系统的缓存机制,数据并没有实时写到磁盘,而是先写入磁盘的缓冲区,再通过硬盘缓存机制刷新保存到文件中。

    这样就可能回出现数据丢失。

  配置同步策略

    appendfsync always:每次收到命令就立刻强制写入磁盘,最慢,但是完全持久化,不推荐使用

    appendfsync everysec:每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐

    appendfsync no  :完全依赖os,性能最好,持久化没保障。

    技术分享图片

    每一秒都将命令写入文件中,aof文件越来越大,并且很多语句会出现多余,所以引入了重写策略。

  重写策略(优化aof文件)

    auto-aof-rewrite-percentage 100 :当aof文件大小超过上一次aof文件大小的百分之多少会重写。如果之前没重写过,以启动时aof文件大小为准。

    auto-aof-rewrite-min-size 64mb :限制允许重写最小aof文件大小,也就是文件大小小于64mb,不需要进行优化。

     技术分享图片

  重写的实现原理

    1.redis调用fork函数,复制一个子线程

    2.父进程继续处理client请求,将请求追加到aof文件,同时收到的命令缓存起来,这样保证子进程重写失败不会出问题。

    3.子进程根据内存中的数据快照,往临时文件中写入重建数据库状态的命令

    4.当子进程将快照的命令写入临时文件后,通知父进程,然后父进程把缓存的写命令也写入临时文件

    5.当父进程写完后,将临时文件替换老的aof文件,后续命令往新的aof文件中追加

  aof文件的修复

     1.先复制原有的aof   cp appendonly.aof   appendonly.aof.bak

     2.执行 redis-check-aof --fix appendonly.aof 完成修复

   aof的优缺点

    优点:  

      1.aof的同步策略,可以让aof安全性变的非常高,并且使用每秒同步一次,redis依然可以保证很好的性能,就算发生故障,也最多只丢失一秒的数据。

      2.aof采用末尾追加的方式写入文件,即便出现问题,aof-check-aof也可以修复文件。同时aof提供了重写策略,来优化aof文件

      3.aof有序保存了对数据库执行写的操作,以redis协议数据保存,易于读和解析,并且不小心执行了flushall,也可以移除aof文件末尾的flushall命令,恢复之前的状态。

      缺点:

      1.对于相同的数据集来说,aof文件体积大于rdb文件的体积。

      2.因为采用了同步策略,aof的速度相比rdb还是要慢一些。

 

  两种持久化的策略可以同时使用,也可以使用其中的一种,如果同时使用的时候,那么Redis重启时,会优先使用aof文件来还原数据。

 

<Redis> 入门五 持久化RBD/AOF

标签:span   间隔   redis   style   几分钟   自己   缓冲   通知   dfs   

原文地址:https://www.cnblogs.com/mapleins/p/10174546.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!