Redis持久化 RDB,AOF,混合持久化

redis基础概念描述

  1. Redis中的网络IO和键值对读写是单线程的,但是持久化,异步删除,集群数据同步是多线程的。
  2. 因为数据都在内存中而且是单线程避免了线程上下文切换,所以redis性能很高,但是需要注意的是由于是单线程的需要我们慎用一些耗时的指令,比如keys还有大key问题,一般value不得超过1M,上限是4M。
  3. Redis的IO多路复用,将连接与事件放进队列中然后基于事件分派期转发到对应的事件处理器。

redis持久化

简述:redis的持久化机制有两种:RDB快照(条件触发),AOP(实时记录增删改sql);

RDB快照(snapshot)

  • 默认情况下redis默认将数据保存在dump.rdb的2进制文件中。我们可以在redis.conf配置文件中指定持久化触发条件, “数据集中N秒内有M个改动”则自动保存1次,配置如:save 60 1000,关闭持久化注释掉所有save策列即可。
  • 客户端执行保存dump.rdb文件命令有两种:同步保存(save ),异步保存(bgsave),每次执行都将覆盖原有的rdb快照文件。
  • bgsave是通过写时复制机制在不影响写命令的同时,处理生成rdb快照文件。可以理解为:basave是由主线程fork出来的子线程,子线程与主线程之间互不影响,bgsave子线程读取主线程的内存数据并写入rdb文件。如果在同步过程中主线程需要对数据进行修改则会生成一份副本,basave线程会将这个副本写入,主线程依然可以完成数据修改。
  • 我们RDB持久化机制也是使用的bgsave的方式。

AOF(append-only file)

  1. 由于RDB快照会产生最近写入丢失的情况,比如因为某些情况而导致的宕机那些未保存到快照中的数据就将丢失,所以1.1版本开始,redis增加了一种AOP持久化机制,实时的将每条记录写到appendonly.aof文件中。
  2. 可以修改redis.conf配置文件的:appendonly yes,打开AOF持久化机制。当打开后所有修改数据的命令都会被追加到aof文件的末尾,当redis重启时,就可以加载磁盘中的aof文件到内存中。
  3. 有3种多久持久化一次的策列:
    (1)appendfsync always(每次有新命令就追加到aof,慢但是安全)。
    (2)appendfsync everysec(每秒一次,足够快,即使丢失也是1秒的数据)。
    (3)appendfsync no:从不fsync,将数据交给操作系统处理。更快但是不安全。
    默认使用的的是everysec(每秒一次),兼顾速度与安全。
  4. AOF重写,当aof文件中太多无用的指令,aof会定期生成新的数据,将多个命令编排成一条。 可以通过:auto‐aof‐rewrite‐min‐size 64mb(文件达到64M重写),auto‐aof‐rewrite‐percentage 100(文件增长100%重写)控制AOF自动重写频率。

Redis 4.0混合持久化

  1. RDB快照容易丢失数据,而通过AOF日志重放相当于RDB又慢很多。启动的时候需要花费很多时间。redis4.0为了解决这个问题增加了混合持久化的策略。
  2. 开启混合持久化必须先开启aof,当开启混合持久化之后AOF重写时,不再是只将数据转换为RESP命令写入AOF文件了,而是重写在此之前的内存做RDB快照处理,将其和增量的AOF修改命令存放在一起都写入新的AOF文件,当重写完成后覆盖原有的AOF文件。
  3. 在redis重启的时候,可以先加载RDB的内容,再重放增量AOF日志来提升重启效率。可以说appendonly.aof文件结构中包含了RDB和AOF格式的数据。

redis数据备份策略

  • crontab定时调度,定时复制AOF/RDB文件到指定目录。
  • 人工复制AOF/RDB文件,备份的时候删除旧数据。
  • 当晚将AOF/RDB文件复制到别的机器,以防机器损坏。

你可能感兴趣的:(redis,redis)