Redis持久化

Redis持久化

Redis是内存数据库，如果不将内存中的数据保存到磁盘中，如果服务器因为一些原因进程退出，服务器中的数据也会丢失，所以Redis需要有持久化功能。

Redis提供了RDB持久化和AOF持久两种的方式。

RDB持久化

RDB（Redis DataBase）持久化可以将某个时间点上的数据库状态保存到一个RDB文件中，这个文件是一个经过压缩的二进制文件，通过该文件可以Redis还原生成RDB文件时的数据库状态。

RDB可以按照指定的时间间隔将内存中的数据集快照写入磁盘，也就是保存了内存快照。

RDB持久化时Redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这次生成的这个临时文件替换上次持久化好的文件。整个过程中，主进程时不会进程任何的IO操作，不会阻塞主进程。

启动方式

• save命令及相关配置

  • dbfilename dump.rdb

    设置本地数据库文件名，默认值为dump.rdb

  • dir

    设置存储.rdb文件的目录

  • edbcompression yes

    设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF压缩

  • rdbchecksum yes

    设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程中均会进行

  save指令会阻塞主进程，直到RDB过程完成，如果Redis数据过大，会造成长时间阻塞。

• bgsave

  这个指令会fork一个子进程在后台执行数据快照的保存，不会阻塞服务器主进程。由于Redis是指令是单线程执行的，而现在的主机配置都是多核CPU，因此这种方式对性能的影响很小。

• 自动执行

  在配置文件中增加配置 save second changes

  满足在second时间范围内key变化数量达到changes时就会进行以bgsave的方式持久化操作。

  如save 300 5 表示在300秒内key发生5次变化就会进行RDB持久化。

  save配置要根据实际情况进行设置，频率过高或过低都会出现问题。

• 特殊启动形式

  1. 全量复制

     这种方式在redis主从复制时会进行

  2. redis服务器在运行过程中重启会先进行rdb持久化，然后启动后在加载rdb文件

  3. 关闭redis服务器时指定数据保存shutdown save

优点

1. RDB时一个紧凑压缩的二进制文件，存储效率较高（相比AOF文件）
2. RDB存储的时redis在某个时间点的数据快照，适合数据备份、全量复制等场景
3. RDB数据恢复要比AOF快的多

缺点

1. RDB持久化无法做到实时持久化，会丢失一部分数据
2. 数据量比较大时，效率很低
3. fork创建子进程，内存额外消耗比较大

AOF持久化

AOF（append only file）持久化，以独立日志的方式记录写命令，重启时在重新执行AOF文件中的命令以达到恢复数据的目的，能够实时对数据进行持久化。

通过在配置文件中配置

#  开启AOF持久化，默认为不开启
appendonly yes
#  设置aof文件名
appendfilename name

AOF同步策略

• always（每次）

  每次写入操作均同步到AOF文件中，数据零误差，但性能比较差

• everysec（每秒）

  每一秒将缓冲区中记录的指令同步到AOF文件中，数据准确性较高，性能也较高，最多丢失一秒内的数据

• no（系统控制）

  由系统控制每次同步到AOF文件的周期，整体过程不可控

通过在配置文件中配置

appendsync always|everysec|no

设置AOF的同步策略

AOF重写优化

随着命令不断写入AOF文件，文件会越来越大，AOF重写可以压缩文件体积。

重写规则

• 进程内已经超时的数据不会再写入

• 忽略无效指令，只保留最后数据的的写入指令，如

  set k1 v1
  set k2 v2
  del k1
  del k2
  

  这样的指令会被忽略

• 对同一数据的写命令合并为一条，如

  lpush l1 a
  lpush l1 b
  lpush l1 c
  # 重写后会合并为
  lpush l1 a b c
  

触发条件

• AOF重写也可以通过gbrewriteaof手动调用。

• 自动的重写

RDB VS AOF

• 如果不能承受数分钟以上的数据丢失，对业务数据非常敏感，选用AOF

• 如果能承受一定的数据丢失，且追求大数据的恢复速度，选用RDB，如灾难恢复

• 双保险策略，两种方式同时开启。

RDB VS AOF

• 如果不能承受数分钟以上的数据丢失，对业务数据非常敏感，选用AOF

• 如果能承受一定的数据丢失，且追求大数据的恢复速度，选用RDB，如灾难恢复

• 双保险策略，两种方式同时开启。