redis持久化机制

目录

前言

一、持久化是什么？

二、RDB

三、AOF

总结

---

前言

今天介绍一下redis的持久化机制，redis的持久化机制主要包括两种，一个是RDB（Redis DataBase），另一个是AOF（Append Only File）。下面具体介绍一下两者的区别。

一、持久化是什么？

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。

二、RDB

1、RDB （Redis DataBase）
    把当前的数据生成快照保存到硬盘，它的触发过程可以分为两种：
        1）手动触发
            1.save：会阻塞当前的Redis服务，直到RDB过程完成，根据数据量的不同，阻塞时间会不一样，如果数据量过大，阻塞时间会很长，因此不建议生产环境使用
            2.bgsave：执行fork操作创建子进程，持久化过程由子进程负责，完成后自动退出
        2）自动触发
            1.save m n   m秒内数据集存在n次修改自动触发bgsave（配置规则触发）
                redis.conf 的保存策略
                    save 900 1
                    save 300 10 
                    save 60 10000
            2.从节点执行全量复制操作，主节点会自动执行bgsave
            3.执行debug reload命令会重新加载Redis，会触发save
            4.默认执行shutdown时候，如果没有开启AOF也会执行bgsave
            5.flushall 命令用于清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空。
    

2、工作流程
        
    3、通过info status查看状态信息
    4、文件的处理
        1）保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定
            redis.conf  dbfilename 文件名
        2）压缩：默认采用LZF压缩算法
            配置redis.conf文件，rdbcompression yes   表示打开压缩 
        3）校验：如RDB文件损坏，则拒绝启动
            redis.conf   rdbchecksum yes   表示打开校验
    5、优点
        1）内容紧凑，适合全量备份，用于灾难恢复
        2）加载RDB数据的速度快于AOF
        3）后台运行，不影响主进程
    6、缺点
        1）无法实现实时或秒级持久化，执行bgsave需要fork子进程，频繁执行成本过高
        2）使用额定的二进制格式保存，可能不兼容新版本

三、AOF

1、AOF(Append Only File)
    1）配置
        AOF默认不开启，通过appendonly yes 打开，默认文件名是appendonly.aof
    2）工作流程
       1. 命令写入append
            （1）使用文本格式写入。文本协议兼容性好，可读性强
            （2）把命令追加到aof_buf中，可以避免二次处理的开销，由于redis是单线程的，直接写入磁盘，效率取决于磁盘的性能，所以可以先写入缓冲区中，然后再从缓冲区写入磁盘。redis可以提供多种缓冲区同步磁盘的策略，性能上是优于直接写如磁盘的
       2.文件同步sync，由appendfsync控制，策略有这几种
                （1）always命令写入aof_buf后调用系统的fsync同步到AOF
                （2）everysec命令写入aof_buf后调用系统write。fsync同步文件由专门的线程每秒调用一次（默认使用）
                （3）no命令写入aof_buf后调用系统的write，不对AOF做fsync同步，同步硬盘由操作系统负责，一般周期30秒
       3.文件重写rewrite， 随着不停的写入命令，文件越来越大，AOF使用重写机制把进程中的数据转为写命令同步到新的AOF文件，可以配置为自动和手动两种触发方式
                （1）直接调用：bgrewiteaof；
                （2）自动触发 根据auto-aof-rewrite-min-size（运行AOF重写时文件最小体积，默认是64MB）和auto-rewrite-percentage（代表当前AOF文件空间（aof_current_size）和上一次重写AOF文件空间（aof_base_size）的比值）确定触发机制。

自动触发的时机 = aof_current_size>auto-aof-rewrite-min size&&(aof_current_size-aof_base_size) / aof_base_size>=auto-aof-rewrite percentag
            
        4.重载reload
      5. 对于加载损坏的AOF文件会拒绝启动并输出日志,当遇到错误的 AOF 文件，可以先使用redis-check-aof-fix 进行修复。修复后使用diff-u 对比数据差异，找出丢失数据进一步进行修复。
当突然掉电,AOF 的文件结尾可能存在不完整的情况，可以使用aof-load-truncated 配置解决。

    6.AOF优先于RDB，当我们开启了AOF，会优先使用AOF的数据，如果我们AOF开启之后，AOF还是空的，我们重启之后会基于空的AOF恢复数据，会导致所有的数据都被清空，所以再我们在重启之前，一定要先执行bgrewriteaof命令，对AOF进行重写。其次，使用AOF的时候，依然要用RDB进行备份。

---

总结

RDB和AOF的选择，通常情况是两种配合使用，当然，如果可以忍受一段时间内的数据丢失，使用RDB效率是更高的，恢复也更快；如果对数据的要求比较严格就要使用AOF。