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
  

  2. 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 ""
  

  2. flushall，该命令会产生空的.rdb文件。
  3. debug reload， 执行该命令会自动触发save操作。
  4. 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进行恢复。