Redis-持久化

Posted on | In | | 浏览 次

前言

Redis提供了持久化功能，将内存中的数据定期备份或通过命令导出到硬盘上，启动时，若检测到备份文件，会首先从备份文件中恢复数据到内存。

redis提供两种持久化方式：

  • 快照：RDB
  • 日志（append only file）：AOF

快照 RDB

使用方法

  1. 通过命令显式地导出

    • SAVE：阻塞式，切勿在生产环境使用
    • BGSAVE：非阻塞式
    • 默认导出到安装目录
    • 可通过CONFIG GET dir命令查看安装目录

  2. 在.conf文件中配置规则定期备份

    • SAVE <seconds> <changes>
    • 含义：在seconds秒内，发生了至少changes次修改，则备份一次
    • 可以配置多条
    • 备份是非阻塞的

    默认配置：

    1
    2
    3
    save 900 1
    save 300 10
    save 60 10000

    含义：满足以下三个条件中的任意一个，BGSAVE命令就会被执行：

    • 服务器在900秒之内，对数据库进行了至少1次修改
    • 服务器在300秒之内，对数据库进行了至少10次修改
    • 服务器在60秒之内，对数据库进行了至少10000次修改

时点性

含义：快照的数据就是执行持久化指令时刻的数据，在持久化过程中的数据变化，不会体现到快照中。

实现：

  • 阻塞式：停止对外服务
  • 非阻塞式：
    1. redis进程使用fork创建子进程，并将要持久化的数据export给子进程
    2. 子进程拿到的数据副本，不会随着父进程的修改而改变
    3. 底层机制是操作系统层面的写时复制机制。父子进程的数据开始时是指向同一块内存的，一旦父子进程的任意一方试图修改数据，就会触发写时复制机制，重新创建一份副本，修改值，并将指针指向新的修改后的副本，这样，修改的值不会影响到另一个进程

弊端

丢失数据的可能性相对较大，时点与时点之间的数据容易丢失

优点

字节流序列化，恢复的速度较快

日志 AOF

AOF持久化将redis的写操作记录到文件中。

使用方法

.conf文件中配置，开启AOF备份：

1
appendonly yes

注：redis配置文件中，若同时开启了rdb和aof，两种备份文件都会生产，但只会以AOF恢复。

优点

丢失数据的可能性相对小

弊端

时间长了之后，日志体量过大；

恢复相对较慢

解决方案

重写日志文件：

  • redis4.0之前：删除抵消的命令，合并重复的命令，最终仍是一个纯指令文件
  • redis4.0之后：先将旧数据以rdb格式存到aof文件中，再将增量数据以指令的格式追加到aof文件中，最终是快照和日志的混合体，利用了rdb的快和aof的全

详细配置

  1. 开启AOF：appendonly yes

  2. AOF文件名：appendfilename "appendonly.aof"

  3. 写磁盘频率：appendfsync always/everysec/no

    • always：每次写完，都flush到磁盘
    • everysec：每秒调一次flush，这是默认配置
    • no：不主动flush，操作系统的写文件缓冲区满了自动写到磁盘，一般缓冲区4k大小

  4. 开启rdb和aof混合模式：aof-use-rdb-preamble yes

  5. 自动重写触发的条件：

    auto-aof-rewrite-percentage 100：当aof文件大小是上一次重写时的aof文件大小的200%时，触发重写

    auto-aof-rewrite-min-size 64mb：aof文件小于64mb大小时，不会触发重写