内容概要
持久化的作用
1.什么是持久化
redis所有数据保存在内存中，对数据的更新将异步地保存到磁盘上。
将数据持久化到硬盘中，这样redis重启数据也不会丢失。当需要恢复数据时，就可以从硬盘中读取数据到内存中，然后进行数据恢复。
2.持久化方式
快照 --> 某个时刻的完整数据备份
写日志 --> 记录数据的变化信息
RDB持久化
1.什么是RDB
RDB方式其实是通过一条命令将当前redis内存数据完整的生成一个快照然后写入到RDB文件中，RDB文件有自身的一些格式，是采用二进制形式来保存的，当需要对redis数据进行恢复，比如redis做了一次重启，那么就可以将该文件重新载入到redis中，将某个时刻的redis数据备份恢复到redis当中。
在主从复制中RDB还充当了复制的媒介作用。
2.触发机制 - 主要三种方式
主要三种方式包括：save(同步)、bgsave(异步)、自动
save命令
在客户端执行save命令，redis就会帮我们生成一个RDB文件。
执行这个命令有个问题就是它是一个同步命令，如果save命令执行比较慢，其他所有命令都需要排队，也就是说数据量大的时候可能造成redis服务器阻塞。
文件策略是当存在老的RDB文件时，执行命令会先生成一个临时文件，当命令执行完毕后将老的文件替换掉。
bgsave命令(异步)
首先客户端执行 bgsave 命令，它不会像save命令一样去同步生成RDB，而是会在后台单独开启一个线程去执行。
即使用了linux的fork()函数生成了主进程的一个子进程，由redis子进程去生成RDB文件，当RDB文件生成完毕后会通知主进程文件已经生成成功了。
注意：fast说明子进程是执行非常快的(大多数情况)，但是极少数情况下fork执行慢的话依然会阻塞redis
其文件策略和复杂度与save命令相同，对于客户端而言执行完第一和第二步之后服务器就可以正常响应客户端了。
两种方式对比
自动生成RDB
通过配置实现，达到某些条件情况下自动生成RDB文件。
如图所示的配置代表，如果60s改变了1万次数据，300s改变了10次数据，900s内改变了一条数据，三个条件任意满足一条即会自动生成RDB文件，当然它的自动生成实际是执行了bgsave命令。
自动生成问题
那么自动生成是否真的很好呢，显然不是。因为这样我们无法控制它生成RDB的频率。或者说它生成RDB文件频率有可能太高了。
比如60s有1万条改变，对于写入量非常大的应用也是非常容易达到这样的条件，或者达到前两条，那么就会频繁的去生成RDB。
这里姑且不讨论RDB文件生成可能带来的一些问题，姑且认为一个内存中的数据写一个快照到硬盘当中，如果数据非常大的话，或者说很频繁去做这样的操作，肯定会对硬盘造成一定的压力。而且生成的规则也不太好控制，因为写入量我们无法控制。
3.相关配置
默认配置(左图)
除了save的三个配置外，redis提供的配置还包括
dbfilename: 配置生成的文件名
dir: 包括rdb/aof和日志文件存放在哪，默认是当前目录
stop-writes-on-bgsave-error: 如果bgsave发生错误是否停止写入
rdbcompression: rdb文件是否采用压缩格式
rdbchecksum: 是否对rdb文件的校验和进行检验
最佳配置(右图)
- 将save配置全部关闭
- 使用端口号区分文件
- 选用大硬盘目录作为保存路径
- bgsave发生错误选择停止写入
- 选用压缩格式，因为文件会比较小
- 采用校验和方式
4.触发机制 - 不容忽略方式
全量复制(主从复制介绍)
有时候没有执行save和bgsave，也没有配置自动生成策略，为什么还会生成RDB文件？这就要考虑到全量复制，也就是主从之间要进行复制的时候，主会自动生成RDB文件
debug reload
Redis还提供了debug reload来进行debug级别的重启，也就是不需要将内存(数据)进行清空的重启，这时候这个机制仍然会触发RDB文件的生成
shutdown
我们在执行shutdown时候，它会有一个参数叫shutdownsave会执行RDB文件的生成
5.RDB总结
- RDB是Redis内存到硬盘的快照，用于持久化
- save通常会阻塞Redis
- bgsave不会阻塞Redis，但是会fork新进程
- save自动配置满足任一条件就会被执行(通常不使用)
- 有些触发机制不容忽视
AOF持久化
1.RDB现存问题
耗时、耗性能
RDB生成过程就是内存中的Redis数据dump到硬盘当中，形成一个RDB文件。
因为需要将所有数据进行dump，所以是比较耗时的，写比较消耗CPU资源，fork消耗内存。如果数据量很大，写入硬盘也会消耗IO性能。
不可控、丢失数据
无论是定时执行save/bgsave命令，还是使用自动生成策略，都存在数据丢失的可能性
2.AOF运行原理
创建：基于日志的原理，客户端执行每条写入命令都会追加到AOF文件中，当然存入命令时肯定是使用AOF特定的格式
恢复：当redis发生宕机之后，就可以使用AOF将redis中的数据进行完整的恢复，而且恢复基本是实时的。因为有记录到每个写入命令，当然根据不同AOF的策略也会决定写入的频率
3.AOF的三种策略
三种策略: always、everysec、no
在记录写入命令时，通常会先存放在缓冲区中，可以提高写入的效率，缓冲区再根据生成策略刷新到AOF文件中。
always: 每条命令都会fsync到硬盘中，这样redis的写入数据就不会丢失
everysec: 每秒都会刷新缓冲区到硬盘中(默认值)
在高写入量时候会适当保护到硬盘，但是如果redis出现故障，有可能会丢失1秒的数据
no: 根据当前操作系统的规则决定什么时候刷新到硬盘中，不需要我们来考虑
三种策略选择
通常采用默认配置：everysec，第一种如果redis写入量非常大，硬盘压力也会非常大。
4.AOF重写
AOF存在的问题是随着时间逐步推移，AOF文件也会逐渐变大，那就会出现很多问题，比如如果使用AOF文件来进行恢复会非常慢。
如果文件无限制的增大，无论是对硬盘的管理还是写入命令的速度都会有一定影响，所以redis提供了AOF重写的方式来解决这个问题。
AOF重写作用
其实AOF重写就是将一些过期的、没有用的、重复的以及一些可优化的命令都可以进行化简，化简成一个很小的AOF文件。
从而达到如下目的：减少硬盘占用量、加速恢复速度
比如对一个key执行了一亿次incr key操作，那么对于AOF文件来说就有一亿次的incr，可以想像文件量是非常大的，会占用很多的磁盘空间，如果做了AOF文件重写的话，实际上就是一条命令set key 一亿。
对于文件恢复来说也是一样的，如果写了一亿次的incr到文件当中，当redis需要使用AOF来进行恢复的时候，需要执行一亿次命令实际上是没有任何意义的，而且速度会非常慢，所以AOF文件重写就是用来解决上面这两个问题。
AOF重写实现两种方式
bgrewriteaof命令(类似bgsave)
客户端发送此命令到redis，redis返回OK结果，并异步执行命令，会fork出一个子进程来完成AOF的重写。
注意这里的AOF重写实际上就是将redis内存当中的数据进行一次回溯，回溯成AOF文件，而不是真的去将AOF文件抽象成去做重写，然后抽象成一个新的AOF文件。(而是从redis内存中进行重写)
AOF重写配置(自动重写，实际也是执行命令)
第一个配置就是说当AOF文件多大时进行重写，第二个就是说下一次增长率是多少进行重写。
比如达到100M进行重写，并且文件增长率为100%，即200M，400M后会再次进行重写。
AOF统计项
自动触发时机：当达到以下两个条件才可以进行自动重写
1.当前尺寸 > 重写需要的最小尺寸
aof_current_size > auto-aof-rewrite-min-size
2.当前尺寸 - 上次重写尺寸 / 上次重写尺寸 > 增长率
aof_current_size - aof_base_size/aof_base_size > auto-aof-rewrite-percentage
AOF重写流程
- 客户端发送
bgrewriteaof命令，由redis主(父)进程执行 - 父进程会
fork出一个子进程
- 子进程去完成AOF重写过程，其实是将内存中的数据进行回溯，然后写到新的AOF文件中
- 父进程仍然会进行正常的客户端的读写以及3.1和3.2过程
① redis仍然会将写命令写入到aof_buf当中，然后去写入到旧的AOF文件当中
② 除此之外，redis还会将这期间的写命令写入到aof_rewrite_buf当中 - 子进程去完成AOF重写过程，其实是将内存中的数据进行回溯，然后写到新的AOF文件中
- ① 当新文件生成之后，子进程会发送信号通知父进程
② 当新文件生成之后，会将这个buffer(在重写期间新的增长数据)补充到新的AOF文件当中
③ 最终会用新的AOF文件来替换老的AOF文件完成AOF重写过程
AOF相关配置
appendonly: 要使用AOF功能需要设置为yes，默认为no
appendfilename: AOF文件名
appendfsync: AOF生成策略
dir: 保存RDB、AOF文件以及日志文件的目录
no-appendfsync-on-rewrite: 在AOF重写的时候，是否要做正常的append操作，yes代表不做这个操作
auto-aof-rewrite-percentage: AOF文件增长率
auto-aof-rewrite-min-size: AOF文件重写需要的尺寸
