Redis是一个内存数据库,而内存中的数据及易丢失,所以Redis持久化变得非常重要。在Redis中提供了两种持久化的方式,分别是AOF和RDB,Redis默认采用RDB的方式进行持久化。
一、RDB
Redis Database
1、RDB是将数据库中的数据定期以快照的方式存储到磁盘,保存到rdb文件中,并在启动时自动加载rdb文件,以达到持久化的需要。

  • 可以在redis的配置文件中设置保存快照的时机:
    save [seconds] [changes]:表示在seconds秒内改变changes次数据就会保存快照到磁盘中(注:save可以同时设置多个)
    如图:在这里插入图片描述
    也可以通过SAVE或BGSAVE命令手动设置快照保存:
    ① SAVE命令:运行此命令时,将会阻塞主进程进行快照保存,直至快照保存完毕,主进程才会继续处理Redis的请求
    ② BGSAVE命令:运行此命令时,将会产生一个子进程进行快照保存,快照保存时不会阻塞主进程,主进程仍然可以处理Redis请求

2、优点

  • 会产生一个完整的快照文件,数据可靠
  • RDB保存快照时会创建子进程,保存快照时基本不会影响主进程处理请求
  • 进行数据恢复时比AOF方式快

3、缺点

  • RDB产生的快照并不是实时产生,而是根据配置文件中save的条件定期生成,可能会丢失数据。------(例:配置文件设置的是当有操作时每60秒保存一次快照,但是在59秒时断电了,导致这次的快照没有生成,因此丢失了这次的数据)

二、AOF
Append-Only File(追加写文件)
采用AOF进行持久化时,Redis会把每一次操作都记录到一个文件中,当Redis进行重启时会把AOF产生的文件中的所有操作执行一遍,确保数据恢复到最新。
1、开启AOF
AOF操作默认是关闭,在Redis配置文件中设置appendonly yes即可开启AOF持久化
在这里插入图片描述
2、配置AOF

AOF提供了三种fsync配置,在Redis的配置文件中,默认开启第三种:

  • appendfsync no:不进行fsync,将flush文件的时机交给OS决定,速度最快
  • appendfsync always:每写一条日志就进行一次fsync操作,数据安全性最高,速度最慢
  • appendfsync everysec:线程在后台每秒fsync一次

如图:
在这里插入图片描述

2、产生的问题及解决方法

  • 问题:由AOF介绍可知,每次操作都会放入到AOF产生的文件中,将会产生大量冗余数据。(例:如果我插入a,再接着删除a,重复一百万次,将会产生在AOF文件中产生大量数据,而实际执行这些操作后Redis中一条数据都没有。)

  • 解决方法:Redis提供了AOF rewrite功能,可以重写AOF文件,只保留能够把数据恢复到最新状态的最小写操作集。

    在Redis的配置文件中设置这两个属性:

    auto-aof-rewrite-min-size 10mb 
    auto-aof-rewrite-percentage 100  
    

    意思是AOF文件达到10MB的100%的倍数时,即达到20MB时,会调用AOF rewrite功能,将文件进行压缩(例:压缩后会去掉插入a,又删除a这类操作),比如这次将文件压缩到了14MB,下一次将会在文件为28MB时再进行压缩。不断重复以上操作。

    (例:10MB–涨到–>20MB—压缩—>14MB–涨到–>28MB—压缩—>19MB–涨到–>38MB—压缩—>…)

    auto-aof-rewrite-min-size:最开始的AOF文件大小必须要触发这个条件才可以,后面的每次重写就不会根据这个变量了。

3、AOF的优点

  • AOF下在配置文件中设置appendfsync为always时,任何已写入的数据都不会丢失,即使设置了appendfsync为everyse,最多也只会丢失1秒的数据

4、AOF的缺点

  • 文件比RDB大
  • 耗能比RDB高
  • 数据恢复比RDB慢
Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐