Redis持久化的取舍和选择

持久化的作用

• 什么是持久化

  • redis所有数据保持在内存中,对数据的更新将异步地保存到磁盘上。

• 持久化的实现方式

  • 快照(eg. Mysql Dump、Redis Rdb)
  • 写日志(eg. Mysql Binlog、Hbase Hlog、Redis AOF)

RDB

• 什么是RDB

  • RDB是Redis内存到硬盘的快照 ,用于持久化。

    • redis内存数据通过创建RDB文件到硬盘(二进制)
    • redis启动时硬盘中的RDB文件(二进制)载入到内存

    

• 触发机制-主要三种方式

  • save(同步)

    • 通过客户端save创建RDB文件到硬盘(二进制)

      

    • 大家知道redis是单线程运行的,save的时候会堵塞其他进程，如客户端连接进来

      

    • 文件策略

      

  • bgsave(异步)

    • 通过客户端bgsave 创建RDB文件到硬盘(二进制)时，redis 通过linux的fork创建redis子进程来完成备份， 一般情况下fork创建子进程很快，不会堵塞
      
    • 文件策略和save相同
      
  • save和bgsave对比

自动备份

• 修改redis配置文件中的以下参数

             save 900 1                      #900秒（15分钟）内有1个更改
             save 300 10                     #300秒（5分钟）内有10个更改
             save 60 10000                   #60秒内有10000个更改
             #以上条件满足其一，便会触发自动备份
            
             dbfilename dump-${port}.rdb     #文件名称
             dir /bigdiskpath                #文件存储路径
             stop-writes-on-bgsave-error yes #bgsave出现错误，停止写入
             rdbcompression yes              #文件采用压缩格式
             rdbchecksum yes                 #对文件检查

触发机制 不容忽略方式

• 全量复制 (save、bgsave、以及自动备份都未打开，还会生成RDB文件，考虑主从复制中的主服务器会自动生成RDB文件)
• debug reload (debug reload 重启会触发RDB文件生成)
• shutdown (触发RDB文件生成)

总结

• save通常 会阻塞Redis.
• bgsave不会阻塞Redis ,但是会fork新进程。
• save自动配置满足任一 就会被执行。

• 触发机制不容忽视

  AOF

  • RDB现存的问题

  • 耗时、耗性能

    • redis内存的数据dump到硬盘的RDB文件
    • O(n)数据 : 耗时
    • fork() : 消耗内存、虽然是copy-on-write策略,但是数据大依然会影响性能
    • Disk I/O : I/O性能
  • 不可控、丢失数据

  

  • 什么是AOF
  • 根据策略写入,重启载入

  

  • AOF三种策略

  • always(时时备份,不丢失数据,IO开销较大，一般的sata盘只有几百TPS)

    

    • everysec(每秒一次备份，丢失1秒数据，redis默认值)

    

  • no(根据操作系统备份,不用管但是不可控)

    

  • AOF重写
  • AOF重写就是把过期的数据，无用的数据、重复的数据以及可以优化的命令化简

  • AOF重写作用

    • 减少硬盘用量
    • 加速恢复速度

  • AOF重写实现两种方式

    • bgrewriteaof(类似于RDB的ngsave,fork出子进程去实现重写)
      

    • AOF重写配置

      • 配置

        • auto-aof-rewrite-min-size (AOF文件重写需要的尺寸)
        • auto-aof-rewrite-percentage (AOF文件增长率)

      • 统计

        • aof_current_size (AOF当前尺寸 单位:字节)
        • aof_base_size (AOF上次启动和重写的尺寸 单位:字节)

      • 同时满足 自动触发

        • aof_current_size > auto-aof-rewrite-min-size
        • (aof_current_size - aof_base_size)/aof_base_size > auto-aof-rewrite-percentage
    • 具体配置

  appendonly yes                              #开启AOF
  appendfilename "appendonly- ${port} .aof"   #aof文件名称
  appendfsync everysec                        #同步策略 
  dir /bigdiskpath                            #AOF文件存储目录
  no-appendfsync-on-rewrite yes               #重写AOF时是否要做正常的添加操作(yes 不做添加操作)
  auto-aof-rewrite - percentage 100           #增长率
  auto- aof-rewrite-min-size 64mb             #最小尺寸
  aof-load-truncated yes                      #加载AOF文件时是否加载错误的文件

RDB和AOF的抉择

• RDB和AOF比较

  • 同时使用RDB和AOF文件，redis挂掉之后，首先加载的是AOF文件，数据级别高，数据新
  • 体积：因为RDB使用了二进制的形式，且数据采用了压缩，所以体积更小，恢复速度快
  • 数据安全性：RDB使用快照的方式，会丢失数据；AOF是根据策略决定的
  • 轻重：操作RDB将全部数据写入内存，bgsave是子进程消耗内存AOF是追加操作

• RDB最佳策略

  • 把RDB关掉，redis主从复制影响，其实关不掉
  • 集中管理 (对数据备份有用有优势)
  • 主从复制，从节点开(控制力度)

• AOF最佳策略

  • 开缓存和存储，只会丢一秒的数据，大部分使用redis做缓存，如果数据丢失在从数据源获取
  • AOF集中管理，发生大量fork()，分配给redis百分之60
  • 建议使用eveysec策略，每秒刷新

• 最佳策略

  • 小分片 (设置小的redis的内存)
  • 缓存或存储
  • 监控：硬盘，内存，负载，网络
  • 足够内存，不要布满，注意有些操作需要额外内存