阅读 98

Redis总结--持久化

一、Redis持久化必要性

Redis作为内存数据库,为了应对因进程意外退出造成的数据丢失,Redis提供了RDB和AOF两种持久化方式,用于将数据从内存持久化到硬盘文件。Redis进程意外退出后重启时,Redis会自动利用持久化文件恢复数据。

  • RDB (Redis database)快照(snapshot),全量备份,单一文件,文件总量小,恢复快,但数据存在丢失。
  • AOF(Append file only), 增量备份,丢失少量数据,会影响实时性能。

二、RDB

触发机制:
  • 手动触发
    1. save 会阻塞客户端请求命令,影响业务,线上环境不建议使用。
    127.0.0.1:6379> save
    OK
    复制代码
    1. bgsave 是对save做的优化,不会阻塞客户端请求,但是fork过程会造成阻塞(后面详细说明)。这也是目前RDB自动持久化的方式。
    127.0.0.1:6379> bgsave
    Background saving started
    复制代码
  • 自动触发
    1. 配置redis.conf中的save备份规则,或者redis-server启动后,通过config set命令配置save规则。
    127.0.0.1:6379> config set save "3600 1 300 100 60 10000"
    OK
    复制代码
    • save m n表示,表示每m秒内数据集产生了n次修改,将自动触发RDB持久化。
    • 关闭该功能,将save设置为""
    config set save ""
    复制代码
    1. flushall,该命令会产生空的.rdb文件。
    2. debug reload, 执行该命令会自动触发save操作。
    3. shutdown,执行shudown操作,会自动备份,生成.rdb文件。
RDB过程:
  • RDB过程如下:

    1. 执行bgsave,判断当前是否存在RDB子进程,如果存在,则返回。
    2. 父进程通过fork操作创建子进程,父进程造成一定阻塞,通过info命令可以查看latest_fork_usec表示上次fork操作用时。
    3. 父进程执行完fork后,bgsave命令返回“Background saving started”,并不再阻塞,继续响应客户端请求。
    4. 子进程创建rdb文件,根据父进程内存快照生成临时rdb文件,完成后对原有文件进行替换。
    5. 子进程发送信号给父进程表示完成,父进程更新统计信息,可通过info命令查看Persistence信息。
  • 两个要点:fork and cow (copy on write)

    • fork 这个过程不是拷贝父进程的物理内存空间,而是拷贝父进程父进程内存空间页表(记录物理内存空间地址),父子进程共享物理内存空间,此过程会消耗时间,造成阻塞,数据量很大时,对性能会造成影响。
    • copy on write fork出子进程后,父进程继续处理请求,子进程负责将内存数据写入临时文件。不需要完全拷贝出父进程内存,因为linux有写时复制(copy on write)机制。父进程在处理写请求时,会把要修改的内存页创建副本,而不是修改共享的内存页。子进程的地址空间内数据,是fork时刻数据库的快照。
  • .rdb文件默认开启压缩,采用LZF算法,虽然消耗一定性能,不过可以大幅降低文件体积,方便保存到硬盘或通过网络发送给从节点。

config set rdbcompression yes|no
复制代码

三、AOF

开启AOF
  • 配置文件设置 appendonly yes | no , 默认不开启。
AOF文件同步
  • 命令写入时,会先写入aof_buf缓存中,然后同步到磁盘,同步模式有三种:
appendfsync always   // 通过系统调用fsync, 每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
appendfsync everysec    // 通过系统调用write,每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,默认。
appendfsync no    // write操作,完全依赖os,性能最好,持久化没保证,通常不会超过30s。
复制代码
  • 系统调用fsync和write
    • fsync,在操作文件时,强制将高速缓存中的内容同步到硬盘。
    • write,在调用后,数据写入高速缓冲区,此时,系统调用立刻返回。同步硬盘操作依赖于系统调度。如果此时发生宕机,缓存区数据会丢失。
  • .aof文件以直接文本协议格式保存。
AOF重写机制
  • 随着命令的不断写入,.aof文件越来越大,redis通过重写机制压缩.aof文件体积,触发时机由auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参 数确定。此外,redis提供了命令bgrewriteaof手动触发重写机制。
  • 重写的过程如下:
    1. redis执行AOF重写,如果当前正在进行aof重写,则不执行,返回正在进行中的错误响应。如果当前正在进行bgsave,重写命令延迟到bgsave执行完毕进行。
    2. 父进程进行fork创建子进程,开销等于bgsave过程。
    3. 父进程继续响应请求,将新的数据保存到AOF重写缓冲区,由子进程操作共享内存,(同样基于copy on write技术)。
    4. 子进程根据内存快照,按照合并规则写入到新的AOF文件。
    5. 子进程发送信号给父进程表示完成,父进程更新统计信息,可通过info命令查看Persistence信息。
    6. 父进程把AOF缓冲区文件写入到新的AOF文件。
    7. 用新的AOF文件替换老的AOF文件。
  • 可以通过no-appendfsync-on-rewrite,决定是否在重写期间进行磁盘同步,默认不开启,因为本身重写对磁盘IO开销比较大,不过在这可能会造成重写期间的数据丢失。
AOF阻塞
  • 对于采用everysec的配置,AOF线程负责刷盘同步,1s一次。不过redis采取延迟fsync策略,当一次同步超过1s时,会在再等待1s。每次同步前,主线程都会检测上次同步成功时间,如果距离上次同步时间超过2s,主线程会进入阻塞状态,直到同步完成。
  • 极端情况下,AOF最多丢失2s内的数据。
  • 每当发生AOF阻塞,aof_delayed_fsync都会累加,可以通过这个指标查看AOF阻塞问题,主要通过优化磁盘负载解决。

redis重启加载

  1. AOF持久化开启,并且.aof文件存在,优先加载.aof文件,否则不进行AOF恢复。
  2. RDB持久化开启,并且.rdb文件存在,根据.rdb文件进行恢复。
  • 加载.aof和.rdb文件时,都会进行文件校验。文件损坏时,会拒绝启动。对于rdb可以用Redis的redis-check-dump文件进行检测。对于.aof文件,可以通过redis-check-aof --fix进行恢复。
关注下面的标签,发现更多相似文章
评论