【Redis】Redis的Cí久化策略选择

23次阅读
一条评论

持久化

最近在看《Redis实战》,里面有讲到持久化,自己做个总结。同时想到自己曾经也和Redis有过一些故事(怎么可能会是因为没设置密码导致redis被挖矿呢绝对不是hhhh

redis持久化分为快照持久化(RDB)追加持久化(AOF),两种策略可以都进行。

  • 快照持久化的方式:

    BGSAVE

【Redis】Redis的Cí久化策略选择

1:执行bgsave命令,Redis父进程判断当前是否存在正在执行的子进程,如RDB/AOF子进程,如果存在直接退出

2:父进程执行fork操作创建子进程,fork操作过程中父进程会阻塞

3:父进程fork完成后,不再阻塞父进程,可以继续响应其他命令

4:子进程创建RDB文件,根据父进程内存生成临时快照文件,完成后对原有文件进行原子替换

5:进程发送信号给父进程表示完成,父进程更新统计信息

SAVE命令:

分为两种,save命令 或者save配置选项( 如 save 60 10000 “自从上一次创建完快照开始算起,60秒内有10000次写”)

  1. 直接父进程开始写数据,创建RDB文件,阻塞所有请求。

复制或者SHUTDOWN:

​ 复制时候 主服务器会执行BGSAVE ,SHUTDOWN命令的时候 会执行完SAVE再关闭。

缺点:

  1. 如果真的redis挂了,如果只有快照持久化,那么会丢失自从上次保存之后的所有数据,
  2. fork子进程的过程中 阻塞所有请求,redis实战作者提到 如果在50G的redis上操作,fork会花费15秒以上,生成快照要20分钟。但是一般不会这么大
  3. 费内存,有可能会大量使用虚拟内存,导致redis性能降低到不能用的程度

优点;

  1. 就一个dump.rdb文件 存到别的地方对心智负担比较低 比较适合做冷备
  2. 数据特大的情况下,重启时候读的比AOF快

AOF持久化:

(原理就是把所有的写操作记录下来 说是持久化 更像是复制一份增量)

【Redis】Redis的Cí久化策略选择

1.所有的写入命令追加到aof_buf(缓存区)中

2.AOF缓存区根据对应的策略向磁盘做同步操作 也能手动flush 像是操作IO(fsync)

3.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的

4.当Redis服务器重启时,可以加载AOF文件进行数据恢复

磁盘同步策略:

  1. always会受限于磁盘IO 废弃
  2. everysecond 写入每一秒内的写入操作
  3. no模式 同步操作由系统控制

AOF重写机制 (BG REWRITE AOF)

因为aof文件过大1.会占满磁盘 2.重启之后读取的时间太长了

会导致redis读取慢 可以重写进行压缩

因为很多写命令可以合成一条

AOF命令写入的内容直接是文本协议格式

Q: AOF为什么直接采用文本协议格式?

A:文本协议格式具有很好的兼容性;开启AOF后,所有写入命令都包含追加操作,直接采用协议格式,避免了二次处理开销 ;文本协议具有可读性,方便直接修改和处理

Q: AOF为什么把命令追加到aof_buf中

A: Redis是单线程响应命令,如果每次写AOF文件命令都直接追加到磁盘,那么性能完全取决于当前硬盘负载。如果是用的固态,那么会大大提升固态硬盘的寿命。 先写入缓冲区aof_buf中,还有一个好处,Redis可以提供多种缓冲区同步硬盘策略,在性能和安全性上做出平衡

【Redis】Redis的Cí久化策略选择

缺点:

  1. AOF虽然好,但是前提是使用好它的Buffer同步写盘策略重写AOF机制,大部分缺点都来自于设置了不合适的策略,比如追加策略选择了每个请求 在redis写入很频繁的场景下,会导致磁盘IO拉满,redis读写性能大大降低;如果没有设置重写AOF机制,那么AOF会把磁盘全吃干净;重写机制设置的很不频繁的话,删除一个10G+的redis会导致redis挂起数秒(重写AOF需要同到子线程,所以BGSAVE的缺点 在这儿也有)
  2. 其实设置好了缺点不太多,不然也不会重启的时候 存在aof文件 优先加载aof文件

总结

关于RDB 查询了一些最佳实践得出的结论是:

RDB最佳策略

  • 关闭
  • 集中手动管理RDB操作
  • 在从节点打开自动执行配置,但是不宜频繁执行RDB

AOF最佳策略

  • 建议打开,但是如果只是纯作为缓存使用可不开
  • AOF重写集中管理
  • everysec

抉择RDB & AOF

  1. 不要仅使用RDB,因为那样会导致你丢失很多数据
  2. 也不要仅使用AOF
    • 你通过AOF做冷备,没有RDB做冷备,来的恢复速度更快
    • RDB每次简单粗暴生成数据快照,更加健壮,可以避免AOF这种复杂的备份和恢复机制的bug
  3. 综合使用AOF和RDB
    • 用AOF保证数据不丢失,作为数据恢复的第一选择
    • 用RDB做不同程度的冷备,在AOF文件都丢失或损坏不可用时,还可使用RDB快速实现数据恢复

如果要我为我们项目选择,我会选择AOF设置每秒写盘+设置自动重写AOF文件 ,再用cron去定时RDB

如果为我自己的博客使用,我会选择Cron每天凌晨生成RDB快照,我不太怕丢数据,我更想降低我的心智负担(逃

参考: