【Redis】持久化

2024-04-10 1012阅读

文章目录

  • 一、RDB
    • 1.1、RDB的自动备份与手动备份
      • 1.1.1、自动备份
      • 1.1.2、手动备份
      • 1.2、RDB优点
      • 1.3、RDB缺点
      • 1.4、RDB快照
      • 1.5、RDB优化配置项
      • 二、AOF
        • 2.1、AOF工作流程
        • 2.2、AOF写回策略
        • 2.3、MP-AOF实现
        • 2.4、AOF优缺点
        • 2.5、AOF重写机制
        • 三、RDB+AOF混合持久化
          • 3.1、数据恢复顺序和加载流程
          • 四、纯缓存模式

            一、RDB

            RDB持久化是以指定的时间间隔,将内存中的数据集快照写入磁盘。其保存的文件是 dump.rdb文件。

            1.1、RDB的自动备份与手动备份

            1.1.1、自动备份

            RDB触发备份

            将配置修改如下

            save 5 2
            dir /myredis/dumpfiles
            dbfilename dump.rdb
            

            redis中执行两次操作时会保存一次dump.rdb文件。

            此时若使用FLUSHDB,redis会保存空数据到dump.rdb中

            此时若使用SHUTDOWN,redis会把当前的数据保存到dump.rdb中

            RDB 恢复备份

              重启redis时,redis会通过加载redis.conf中的dump.rdb的文件路径来恢复redis数据库。

            注:不可以把备份文件dump.rdb和生产redis服务器放在同一台机器,必须分开各自存储,以防生产机物理损坏后备份文件也挂了。

            1.1.2、手动备份

              Redis手动生成了两个命令来生成RDB文件,分别是SAVE和BGSAVE,其中一般使用BGSAVE

              由于使用SAVE会在主程序中执行会阻塞当前redis服务器,直到持久化工作完成。执行SAVE命令期间,Redis不能处理其他命令,所以在线上禁止使用SAVE。

              使用BGSAVE会在后台异步进行快照操作,不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程。

              并且还可以使用LASTSAVE命令获取最后一次成功执行快照的时间。

            1.2、RDB优点

            • RDB非常适合灾难恢复,它是一个可以传输到远程数据中心的压缩文件。
            • RDB最大限度地提高了Redis的性能,因为Redis父进程为了持久化而需要做的唯一工作就是派生一个将所有其余工作都完成的子进程。父进程永远不会执行磁盘I/O或类似操作。
            • 与AOF相比,RDB允许使用大数据集更快地重启。
            • 在副本上,RDB支持重启和故障转移后的部分重新同步。

              1.3、RDB缺点

              • 如果Redis由于任何原因没有在正常关闭的情况下停止工作,那最新分钟的数据可能会丢失。
              • 内存数据的全量同步,如果数据量太大会导致I/O严重影响服务器性能。
              • RDB需要经常fork()以便使用子进程在磁盘上持久化。如果数据集很大,fork()会很耗时。

                1.4、RDB快照

                  触发RDB快照的操作有:

                • 配置文件中默认的快照配置
                • 手动SAVE/BGSAVE命令
                • 执行FLUSHDB/FLUSHALL命令
                • 执行SHUTDOWN且没有设置开启AOF持久化
                • 主从复制时,主节点自动触发

                  禁用快照的方法:

                  • 动态停止RDB保存规则的方法:redis-cli config set save ""
                  • 快照禁用,在配置文件redis.conf中修改save ""

                    1.5、RDB优化配置项

                      RDB的优化配置项在配置文件redis.conf的SNAPSHOTTING模块中

                    save  
                    # 在规定的时间内或者几次修改后自动保存到磁盘
                    dbfilename  # dump.rdb的文件名
                    dir # dump.rdb所在的路径
                    stop-writes-on-bgsave-error
                    # 默认为yes,在bgsave报错后停止写入
                    # no表示在快照写入失败时,也能确保redis继续接受新的写请求。
                    rdbcompression
                    # 对于存储到磁盘的快照是否压缩存储。
                    # yes,redis会使用LZF算法进行压缩
                    # no,减少CPU在这方面的消耗
                    rdbchecksum
                    # 合法性校验
                    # 默认yes,redis使用CRC64算法进行数据校验
                    # no,关闭校验,提高性能
                    rdb-del-sync-files
                    # 默认no,禁用此选项
                    

                    二、AOF

                      AOF是以日志形式来记录每个写操作,将Redis执行过的所有写指令记录下来,并且只允许追加文件不允许改写文件,在redis启动的时候读取该文件并且将写指令从前往后执行一遍以完成数据的恢复工作。

                      默认情况下,redis没有开启AOF,通过appendonly yes来开启。它保存的文件名为appendonly.aof。

                    2.1、AOF工作流程

                    【Redis】持久化

                    序号详细步骤
                    1客户端会产生请求命令发送至服务端
                    2命令到达服务端后,并没有直接写入AOF文件,先保存在AOF缓存中,AOF缓存的目的是当这些命令到达一定数量后再写入磁盘,避免频繁的磁盘IO操作
                    3AOF缓存根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘的AOF文件
                    4由于AOF文件内容的增加,为了避免膨胀,进行AOF重写完成命令的合并,从而达到AOF文件压缩的目的
                    5服务端重启后,会从AOF文件载入数据

                    2.2、AOF写回策略

                      AOF有三种写回策略,默认是everysec

                    配置项写回时机优点缺点
                    always同步写回可靠性高、数据不丢失每个写命令都要写磁盘,IO量大,性能影响较大
                    everysec每秒写回性能适中宕机时丢失1秒内的数据
                    no由操作系统控制写回性能好宕机时丢失的数据较多

                    2.3、MP-AOF实现

                      MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件。AOF的类型有:

                    • BASE:基础AOF,由子进程通过重写产生,最多只有一个
                    • INCR:增量AOF,一般会在AOFRW开始执行时创建,可能存在多个
                    • HISTORY:AOFRW成功完成后,所有的BASE和INCR AOF都变成HISTORY,该类型的AOF会被Redis自动删除。

                        为了管理这些AOF文件,还引入了manifest文件来追踪管理这些AOF,总的来说,Redis7以后的AOF文件结构如下:

                      // 几种类型文件的前缀,后面跟着有关序列和类型的附加信息
                      appendfilename "appendonly.aof"
                      //新版本增加的目录配置项目
                      appenddirname "appendonlydir"
                      //具体文件
                      1、基本文件
                      	appendonly.aof.1.base.aof
                      2、增量文件
                      	appendonly.aof.1.incr.aof
                      	appendonly.aof.2.incr.aof
                      3、清单文件
                      	appendonly.aof.manifest
                      

                      2.4、AOF优缺点

                      优势

                      • 使用AOF Redis更加持久,使用每秒fsync策略既可以保证写入性能,也可以减少redis宕机时丢失的数据。
                      • AOF日志是一个仅附加的日志,因此不会出现寻道问题,也不会在断电时出现损坏问题,即使日志以写一半的命令结尾,redis-check-aof工具也能轻松修复。
                      • Redis能够自动重写AOF,从而减少AOF的磁盘占用空间。
                      • 即使使用FLUSHALL命令刷新了所有内容,也可以通过删除AOF中的最新内容来恢复数据。

                        劣势

                        • AOF文件通常比相同数据集的RDB文件大,回复速度慢于RDB
                        • AOF运行效率低于RDB,每秒同步策略效率好,不同步的话效率和RDB相同。

                          2.5、AOF重写机制

                            重写机制通过启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。它并不是对源文件进行重新整理,而是直接读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件去替换原来的AOF文件。

                          触发机制

                            手动方式通过命令bgrewriteaof命令触发

                            自动方式通过配置文件的选项触发

                          auto-aof-rewrite-percentage 100
                          auto-aof-rewrite-min-size 64mb
                          # 这里表示被重写的aof文件既要达到之前大小的一倍又要超过64mb才会自动重写
                          

                            触发重写后,相应AOF文件的序号会增加,例如:

                          appendonly.aof.1.base.aof
                          appendonly.aof.1.incr.aof
                          ## 变成
                          appendonly.aof.2.base.aof
                          appendonly.aof.2.incr.aof
                          

                          重写原理

                          • 在重写开始前,redis会创建一个“重写子进程”,这个子进程会读取现有的AOF文件,并将其包含的指令分析压缩并写入一个临时文件中。
                          • 主进程将新接收到的写指令一边累计到内存缓冲区中,一边继续写入到原有的AOF文件中,保证了AOF文件的可用性,避免在重写过程中出现意外。
                          • 当“重写子进程”完成重写工作后,它会给父进程发送一个信号,父进程收到信号后将内存中缓存的写指令追加到新AOF文件中。
                          • 追加结束后,redis使用新的aof文件替换旧的aof文件,之后新的写指令都会追加到新的aof文件中。
                          • 重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库用命令的方式重写了一个新的aof文件

                            三、RDB+AOF混合持久化

                              结合了RDB和AOF的优点,既能快速加载又能避免丢失过多的数据。这种混合方式的具体流程是先使用RDB进行快照存储,然后使用AOF持久化记录所有写操作,当重写策略满足或手动触发重写的时候,将最新的数据存储为新的RDB记录。这样重启服务的时候会从RDB和AOF两方恢复数据,兼具了数据完整性和性能。

                              简单来说,混合持久化使得AOF=RDB头部+AOF混写

                            3.1、数据恢复顺序和加载流程

                              在RDB和AOF都启用的情况下,AOF的优先级高于RDB,redis会先判断AOF文件是否存在,如果不存在的话才会使用RDB

                            【Redis】持久化


                            四、纯缓存模式

                              纯缓存模式是关闭redis服务器的持久化功能从而提高服务器性能的方式。主要方法是同时关闭RDB和AOF

                            禁用rdb

                              修改配置文件参数save "",禁用rdb持久化模式下,我们仍然可以使用命令save、bgsave生成rdb文件

                            禁用aof

                              修改配置文件参数appendonly no,禁用aof持久化模式下,我们仍然可以使用命令bgwriteaof生成aof文件

VPS购买请点击我

免责声明:我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理! 图片声明:本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库和百度,360,搜狗等多加搜索引擎自动关键词搜索配图,如有侵权的图片,请第一时间联系我们,邮箱:ciyunidc@ciyunshuju.com。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!

目录[+]