Redis持久化方案(RDB/AOF)

RDB持久化方案

• rdb持久化配置

  # 时间策略，表示900s内若是有1条是写入命令，就触发产生一次快照，能够理解为就进行一次备份
  save 900 1
  save 300 10  # 表示300s内有10条写入，就产生快照
  save 60 10000
  # redis servercron 相似于linux的crontab，默认每隔100毫秒执行一次
  
  # 文件名称
  dbfilename dump.rdb
  
  # 若是持久化出错，主进程是否中止写入
  stop-writes-on-bgsave-error yes
  
  # 是否压缩
  rdbcompression yes
  
  # 导入时是否检查
  rdbchecksum yes
  
  # 文件保存路径
  dir /usr/local/redis-4.0.6

• save的含义

  ​ 实际生产环境每一个时段的读写请求确定不是均衡的，为此redis提供一种根据key单位时间操做次数来触发一次备份到磁盘，咱们能够自由定制什么状况下触发备份，此功能起到平衡性能与数据安全的做用

• 在Redis中RDB持久化的触发分为两种：本身手动触发与Redis定时触发

  • 针对RDB方式的持久化，手动触发可使用：
    • save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
    • bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，所以阻塞只会发生在fork子进程的时候

• 而自动触发的场景主要是有如下几点

  • 根据咱们的 save m n 配置规则自动触发
  • 从节点全量复制时，主节点发送rdb文件给从节点完成复制操做，主节点会触发 bgsave
  • 执行 debug reload 时
  • 执行 shutdown时，若是没有开启aof，也会触发

• 禁用RDB

  • 只须要在save的最后一行写上：save ""

AOF持久化方案

• AOF持久化配置

  # 是否开启aof
  appendonly yes
  
  # 文件名称
  appendfilename "appendonly.aof"
  
  # 同步方式
  appendfsync everysec
  
  # aof重写期间是否同步
  no-appendfsync-on-rewrite no
  
  # 重写触发配置
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb
  
  # 加载aof时若是有错如何处理
  aof-load-truncated yes # yes表示若是aof尾部文件出问题，写log记录并继续执行。no表示提示写入等待修复后写入
  
  # 文件重写策略
  aof-rewrite-incremental-fsync yes

• appendfsync 同步模式有三种模式，通常状况下都采用 everysec 配置，在数据和安全里面作平衡性选择，最多损失1s的数据

  • always：把每一个写命令都当即同步到aof，很慢，可是很安全

  • everysec：每秒同步一次，是折中方案

  • no：redis不处理交给OS来处理，很是快，可是也最不安全

• AOF的整个流程大致来看能够分为两步，一步是命令的实时写入（若是是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写。

  • 步骤：

    • 命令写入=》追加到aof_buf =》经过时间事件调用flushAppendOnlyFile函数同步到aof磁盘

  • 缘由：

    • 实时写入磁盘会带来很是高的磁盘IO，影响总体性能

• AOF持久化的效率和安全性分析

  always：每一个时间事件循环都将AOF_BUF缓冲区的全部内容写入到AOF文件，而且同步AOF文件，这是最安全的方式，但磁盘操做和阻塞延迟，是IO开支较大。
  everysec：每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。若是遇到物理服务器故障，有可能致使最近一秒内aof记录丢失(可能为部分丢失)。
  no：redis并不直接调用文件同步，而是交给操做系统来处理，操做系统能够根据buffer填充状况/通道空闲时间等择机触发同步；这是一种普通的文件操做方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。处于no模式下的flushAppendOnlyFile调用无须执行同步操做

Redis两种持久化方案对比

• Redis提供了不一样的持久性选项：

  • RDB持久性以指定的时间间隔执行数据集的时间点快照。
  • AOF持久性记录服务器接收的每一个写入操做，将在服务器启动时再次播放，重建原始数据集。使用与Redis协议自己相同的格式以仅追加方式记录命令。当Redis太大时，Redis可以重写日志背景。

• RDB的优缺点

  • 优势：
    • RDB最大限度地提升了Redis的性能，父进程不须要参与磁盘I/O
    • 与AOF相比，RDB容许使用大数据集更快地重启
  • 缺点：
    • 若是您须要在Redis中止工做时（例如断电后）将数据丢失的可能性降至最低，则RDB并很差
    • RDB常常须要fork（）才能使用子进程持久存储在磁盘上。若是数据集很大，Fork（）可能会很是耗时

• AOF的优缺点

  • 优势：

    • 数据更加安全
    • 当Redis AOF文件太大时，Redis可以在后台自动重写AOF ## INCRE 1 执行10万 = INCREBY10万执行一次
    • AOF以易于理解和解析的格式一个接一个地包含全部操做的日志 # flushdb相似于rm -rf /*

  • 缺点：

    • AOF文件一般比同一数据集的等效RDB文件大

    • 根据确切的fsync策略，AOF可能比RDB慢

• RDB 和 AOF ,我应该用哪个？
  通常来讲,若是想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。若是你很是关心你的数据,但仍然能够承受数分钟之内的数据丢失， 那么你能够只使用 RDB 持久化。有不少用户都只使用 AOF 持久化， 但咱们并不推荐这种方式： 由于定时生成 RDB 快照（snapshot）很是便于进行数据库备份， 而且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快

• 在线上咱们到底该怎么作？

  • RDB持久化与AOF持久化同步使用

  • 若是Redis中的数据并非特别敏感或者能够经过其它方式重写生成数据，能够关闭持久化，若是丢失数据能够经过其它途径补回；

  • 本身制定策略按期检查Redis的状况，而后能够手动触发备份、重写数据；

  • 采用集群和主从同步