• 【Redis】大白话聊聊Redis如何实现持久化


    Redis两种持久化方式:

    1》RDB(snapshotting快照)

    • Redis的默认持久化方式(把数据做一个备份,将数据存放到磁盘中)

    这种方式是将内存中的数据,以快照的方式写入到二进制文件中,存放默认文件是【dump.rbd】。

    可以通过配置文件来配置这个持久的方式,说白了就是持久化频率,缓存数据我多久做一个持久化,每次持久化多少数据。

    主要就是通过遍历所有缓存数据,通过【save】,已被废弃,现主要用【bgsave】,全部持久化到一个【.rdb】格式结尾的文件中。

    • 话不多说,看看操作规则就秒懂了:
    Save 900 1 //900秒后有1个key发生变化,执行bgsave
    
    Save 300 10 //300秒后有10个key发生变化,执行bgsave
    
    Save 60 10000 //60秒后有10000个key发生变化,执行bgsave
    • RDB持久化流程是什么呢?
    1》redis根据配置去尝试生成一个【.rdb】快照
    
    2》redis-server会fork一个子进程
    
    3》子进程将数据dump到一个临时【.rdb】文件中
    
    4》然后通过临时文件来覆盖替换之前的持久化文件,并且每一次生一个新的临时文件都会做替换
    • 那么RBD有什么弊端呢:
    如果redis服务一不小心宕掉的话,那么最后一次save持久化之后的数据,有可能全部丢失掉。
    • 触发方式:
    
    
    1. 如果从节点执行全量复制操作,主节点自动执行BGSAVE生成RDB文件并发送给从节点。
    2. 执行debug reload命令重新加载Redis时,也会自动触发save操作。
    3. 默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行BGSAVE。

    2》AOF(Append-onlyfile)

    • 简单来说,就是把所有的写命令保存起来

    AOF就是将Redis每一次写命令都追加到持久化文件中,然后重启系统的时候,都会运行这个文件中的写命令。

    • 当然由于os会在内核中缓存写命令,所以可以不会缓存那么快,这样导致aof也会造成数据丢失。所以我们也可以修改配置文件来配置aof缓存机制:
    // 表示Redis写操作后不回有【fsync()】操作调用,而是有操作系统自动调度刷新磁盘,性能是最好的
    Appendfsync no 
    
    // 表示Redis每次写操作后都会手动调用【fsync()】,将数据强制写入操盘,性能是最慢的,但是持久化效果最好
    Appendfsync always 
    
    // 表示每秒同步一次,即每秒强制写一次,在性能和持久化方面做了很好的这种 
    Appendfsync Everysec 
    • AOF中有一个【AOF Rewrite】,那什么是【AOF Rewrite】呢?

    一般Redis中数据是有限的,很多数据都会自动过期,或者被用户删除,又或者被Redis的清除算法清理,从而淘汰。

    Redis中数据会不断淘汰旧的,只有一部分常用的数据会存放在内存中。

    所以可能之前很多被清理的数据,都保留在AOF日志中,因为AOF日志只有一个,会不断的膨胀变大,

    所以AOF会每隔一段时间,进行一次【rewrite】操作。举个例子:

    比如AOF日志中已经存放了100w的数据指令,但我们的Redis中,由于过期或被用户删除,
    
    实际上只剩下了10w数据,此时基于这10w数据我们重新构建一个新的日志并覆盖之前的AOF日志,
    
    从而确保日志文件不会过大,并与内存中尽量一致。
    • 我们可以在redis配置文件中配置rewrite策略:
    /**
    
    比如说上一次AOF rewrite之后,是128mb,然后就会接着128mb继续写AOF的日志,
    
    如果发现增长的比例,超过了之前的100%,256mb,就可能会去触发一次rewrite
    
    但是此时还要去跟min-size,64mb去比较,256mb > 64mb,才会去触发rewrite
    
    **/
    
    auto-aof-rewrite-percentage 100
    
    auto-aof-rewrite-min-size 64mb
    • AOF具体过程是什么?
    1》Redis-Server先fork一个子进程;
    
    2》子进程基于当前的内存数据,构建日志,开始往新的临时AOF文件中写入日志;
    
    3》Redis主进程,接到客服端的写操作时,继续往旧的AOF日志中追加数据,此时Redis中有两个日志文件,一个是子进程创建的临时日志,一个是主进程的AOF日志
    
    4》子进程写完创建完临时AOF日志后,将Redis主进程新追加的日志写入到临时日志中;
    
    5》用临时日志覆盖主进程的旧AOF日志
    • AOF的有什么弊端呢?
    如果一个业务的并发上万,那么AOF日志系统可以说是非常庞大的,所以恢复重建功能就会很漫长

    Redis中的AOF和RDB如何选择呢:

    1》不要仅仅使用RDB,那样会导致丢失数据;
    
    2》也不要仅仅使用AOF,如果AOF中出现指令bug或文件损坏,那么可能会造成数据恢复失败;
    
    3》综合使用AOF和RDB两种持久化机制,用AOF来保证数据不丢失,作为数据恢复的第一选择;
    
    因为RDB更具有健壮性,用RDB来做不同程度的冷备,在AOF文件都丢失或损坏不可用的时候,还可以使用RDB来进行快速的数据恢复
  • 相关阅读:
    Ext JS 6应用程序Build后出现“c is not a constructor return new c(a[0])”的处理
    安卓四大组件总览
    摆脱命令行,Ubuntu下配置Android开发环境
    【翻译】使用Sencha Ext JS创建美丽的图画(1)
    linux后台运行springboot项目
    AES地址栏传参加密
    最全的常用正则表达式大全——包括校验数字、字符、一些特殊的需求等等
    阿里云服务器+ftp文件操作+基于Centos7的vsftpd配置
    解决服务器发回了不可路由的地址。使用服务器地址代替的问题
    解决vsftpd的refusing to run with writable root inside chroot错误
  • 原文地址:https://www.cnblogs.com/boluopabo/p/13061467.html
Copyright © 2020-2023  润新知