Redis——持久化

• 持久化 ：
  持久化也就是说Redis所有数据保持在内存中，对数据的更新将异步的保存在磁盘中。
  -持久化方式

  • RDB（快照方式）
    RDB是指在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。示意图如下：

    
    RDB
    • 触发机制：

      • save（同步）

        
        save
        

        因为save是同步的，所以在进行save操作时，如果数据量较大会造成redis的阻塞。

        • 文件策略 ：
          如果存在老的RDB文件，则使用新生成的替代旧的

      • bgsave（异步）

        
        bgsave
        

        此时不会阻塞redis-cli
        对上面两种方式进行对比：

        
        对比

      • auto

        
        auto
        

        在配置文件中配置自动持久化的时间与变化量，redis会自动进行bgsave

        • 配置方式
          一般不使用auto方式进行持久化，在多台redis的服务器上，以端口区分，RDB文件存储路径根据实际情况进行修改，采用压缩方式进行存储

          
          图片.png
  • 其他会触发RDB的方式
    • 全量复制（主从）
    • debug reload
    • shutdown
      RDB总结
      图片.png
    • RDB存在的问题：
      • 耗时、耗性能（fork、cow策略）
      • 不可控、丢失数据
  • AOF（写日志）
    以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF文件，以此达到记录数据库状态的目的。

    • AOF原理 ：

      
      AOF
      

      同步命令到 AOF 文件的整个过程可以分为三个阶段：

1. 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
2. 缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。
3. 文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话，fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。
   • AOF保存模式
     1. AOF_FSYNC_NO ：不保存。
     2. AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。

     3. AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。
        对这三种策略进行比较：

        
        比较

• AOF重写：
  AOF 文件通过同步 Redis 服务器所执行的命令，从而实现了数据库状态的记录，但是，这种同步方式会造成一个问题：随着运行时间的流逝，AOF 文件会变得越来越大。
  为了解决以上的问题，Redis 需要对 AOF 文件进行重写（rewrite）：创建一个新的 AOF 文件来代替原有的 AOF 文件，新 AOF 文件和原有 AOF 文件保存的数据库状态完全一样，但新AOF 文件的体积小于等于原有 AOF 文件的体积。（根据键的类型，使用适当的写入命令来重现键的当前值，AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取，它针对的是数据库中键的当前值，是对当前数据库的回溯）

  • AOF重写作用：
    减少磁盘占用
    加速恢复速度
  • AOF重写实现方式 ：

    • bgrewriteaof ：

      
      bgrewriteaof
      1. 子进程进行 AOF 重写期间，主进程可以继续处理命令请求。
      2. 子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。
  • AOF重写缓存
    因为子进程在进行 AOF 重写期间，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的AOF 文件中的数据不一致。为了解决这个问题，Redis 增加了一个 AOF 重写缓存，这个缓存在 fork 出子进程之后开始启用，Redis 主进程在接到新的写命令之后，除了会将这个写命令的协议内容追加到现有的 AOF文件之外，还会追加到这个缓存中。
    换言之，当子进程在执行 AOF 重写时，主进程需要执行以下三个工作：
    1. 处理命令请求。
    2. 将写命令追加到现有的 AOF 文件中。（下图3-1）
    3. 将写命令追加到 AOF 重写缓存中。（下图3-2）
       这样一来可以保证：
    • 现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。
    • 所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。
      当子进程完成 AOF 重写之后，它会向父进程发送一个完成信号（下图5-1），父进程在接到完成信号之后，会调用一个信号处理函数，并完成以下工作：
      1. 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。（下图5-2）
      2. 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。（下图5-3）
         当（下图5-2） 执行完毕之后，现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了。当（下图5-3）执行完毕之后，程序就完成了新旧两个 AOF 文件的交替。如下图：
         AOF重写过程
         在整个 AOF后台重写过程中，只有最后的写入缓存和改名操作会造成主进程阻塞，在其他时候，AOF 后台重写都不会对主进程造成阻塞，这将 AOF 重写对性能造成的影响降到了最低。

• aof重写配置 ：

  
  重写配置

当满足以下条件时，就会触发AOF的重写：

1. 没有 BGSAVE 命令在进行。
2. 没有 BGREWRITEAOF 在进行。
3. 当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 1 MB）。
4. 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。

• 如何选择持久化方式？

  • RDB与AOF对比 ：

    
    RDB与AOF
    

    启动优先级就是两者都存在时以AOF优先

  • RDB最佳策略 ：
    集中管理
    在集群中，可以考虑从节点开启RDB
  • AOF最佳策略 ：
    在缓存场景中，可以考虑关闭（从数据库中加载）
    集中管理（fork问题）
    采用everysec策略
  • 最佳策略 ：
    小分片（使用maxmemory规划，对每个redis内存分配不要过大）
    根据缓存或者存储采用不同策略
    根据计算机负载（CPU或者内存）采用不同策略