一、Redis持久化必要性
Redis作为内存数据库，为了应对因进程意外退出造成的数据丢失，Redis提供了RDB和AOF两种持久化方式，用于将数据从内存持久化到硬盘文件。Redis进程意外退出后重启时，Redis会自动利用持久化文件恢复数据。
- RDB （Redis database）快照（snapshot），全量备份，单一文件，文件总量小，恢复快，但数据存在丢失。
- AOF（Append file only）， 增量备份，丢失少量数据，会影响实时性能。
二、RDB
触发机制：
- 手动触发
- save 会阻塞客户端请求命令，影响业务，线上环境不建议使用。
127.0.0.1:6379> save OK- bgsave 是对save做的优化，不会阻塞客户端请求，但是fork过程会造成阻塞（后面详细说明）。这也是目前RDB自动持久化的方式。
127.0.0.1:6379> bgsave Background saving started - 自动触发
- 配置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 ""- flushall，该命令会产生空的.rdb文件。
- debug reload， 执行该命令会自动触发save操作。
- shutdown，执行shudown操作，会自动备份，生成.rdb文件。
RDB过程：
-
RDB过程如下：
- 执行bgsave，判断当前是否存在RDB子进程，如果存在，则返回。
- 父进程通过fork操作创建子进程，父进程造成一定阻塞，通过info命令可以查看latest_fork_usec表示上次fork操作用时。
- 父进程执行完fork后，bgsave命令返回“Background saving started”，并不再阻塞，继续响应客户端请求。
- 子进程创建rdb文件，根据父进程内存快照生成临时rdb文件，完成后对原有文件进行替换。
- 子进程发送信号给父进程表示完成，父进程更新统计信息，可通过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手动触发重写机制。
- 重写的过程如下：
- redis执行AOF重写，如果当前正在进行aof重写，则不执行，返回正在进行中的错误响应。如果当前正在进行bgsave，重写命令延迟到bgsave执行完毕进行。
- 父进程进行fork创建子进程，开销等于bgsave过程。
- 父进程继续响应请求，将新的数据保存到AOF重写缓冲区，由子进程操作共享内存，（同样基于copy on write技术）。
- 子进程根据内存快照，按照合并规则写入到新的AOF文件。
- 子进程发送信号给父进程表示完成，父进程更新统计信息，可通过info命令查看Persistence信息。
- 父进程把AOF缓冲区文件写入到新的AOF文件。
- 用新的AOF文件替换老的AOF文件。
- 可以通过no-appendfsync-on-rewrite，决定是否在重写期间进行磁盘同步，默认不开启，因为本身重写对磁盘IO开销比较大，不过在这可能会造成重写期间的数据丢失。
AOF阻塞
- 对于采用everysec的配置，AOF线程负责刷盘同步，1s一次。不过redis采取延迟fsync策略，当一次同步超过1s时，会在再等待1s。每次同步前，主线程都会检测上次同步成功时间，如果距离上次同步时间超过2s，主线程会进入阻塞状态，直到同步完成。
- 极端情况下，AOF最多丢失2s内的数据。
- 每当发生AOF阻塞，aof_delayed_fsync都会累加，可以通过这个指标查看AOF阻塞问题，主要通过优化磁盘负载解决。
redis重启加载
- AOF持久化开启，并且.aof文件存在，优先加载.aof文件，否则不进行AOF恢复。
- RDB持久化开启，并且.rdb文件存在，根据.rdb文件进行恢复。
- 加载.aof和.rdb文件时，都会进行文件校验。文件损坏时，会拒绝启动。对于rdb可以用Redis的redis-check-dump文件进行检测。对于.aof文件，可以通过redis-check-aof --fix进行恢复。
