docker 中 redis数据持久化配置
环境
Centos 7.4 ; docker-ce.19.03.8; kernel-5.6.5; redis-4.0
持久化模式
- 快照模式
RDB持久化是通过创建快照来获得数据副本，即简单粗暴的直接保存键值对数据内容
要启用RDB（并关闭AOF），我们需要修改Redis的配置文件
redis.conf:
requirepass password
save 60 1000
stop-writes-on-bgsave-error no
rdbcompression no
dbfilename dump.rdb
appendonly no #是否启用AOF
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
dir /data/
- aof日志模式
修改redis配置文件，使AOF生效，并关闭RDB
启动redis服务，并观察redis_data目录下是否有dump.rdb文件生成，有生成，则证明备份成功
数据恢复，只要确保该dump.rdb存在，redis便会自动去读取其中的数据
AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化。
因此，Redis 只要从头到尾重新执行一次AOF 文件包含的所有写命令，就可以恢复AOF文件所记录的数据集。
redis.conf:
requirepass password
save 60 1000
stop-writes-on-bgsave-error no
rdbcompression no
dbfilename dump.rdb
appendonly yes #是否启用AOF
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
dir /data/
配置文件说明
- RDB配置说明
* save: 多久执行一次自动快照操作
比如设置为 ```save 60 1000``` ，那么就表示在60秒之内，如果有1000次写入的话，Redis就会自动触发BGSAVE命令
* stop-writes-on-bgsave-error: 在创建快照失败后是否仍然继续执行写命令
* rdbcompression: 是否对快照文件进行压缩
* yes: 开启，这种情况下，Redis会采用LZF算法对rdb文件进行压缩
* no: 关闭
* dbfilename: 快照文件名
* dir: 快照文件存放目录
### RDB触发条件
RDB的触发条件会比AOF麻烦，大致可以分为以下几种：
* 通过redis-cli等客户端直接发送指令: ```BGSAVE```
BGSAVE指令，会让Redis调用fork创建一个子进程在后台运行，子进程将会负责创建快照到磁盘中
在演示案例中，启动redis的docker容器后，在redis-cli中输入 ```BGSAVE``` 后，能够在./redis_data目录下生成一个temp-17.rdb文件（或者其他以rdb结尾的）
* 通过redis-cli等客户端直接发送指令：```SAVE```
SAVE指令**（注意跟配置中的save没有半毛钱关系）**，会让Redis主进程直接开始创建快照，但在创建快照的过程中，Redis不会响应其他命令请求
在演示案例中，启动redis的docker容器后，在redis-cli中输入 ```SAVE``` 后，能够在./redis_data目录下生成一个temp-17.rdb文件（或者其他以rdb结尾的）
* 通过配置项```save```进行触发
具体请参照上文的参数说明
* 通过SHUTDOWN命令关闭Redis服务器时，Redis会自动触发一个SAVE指令
* 通过标准TERM信号kill掉Redis服务时，Redis也会自动触发一个SAVE指令
* 通过Redis主从服务器的复制请求
主服务器收到从服务器的复制请求时，会触发一次BGSAVE指令(当且仅当主服务器没有子进程在执行BGSAVE)
* 通过docker-compose启动Redis容器
我将Docker容器中的redis服务所产生的备份文件，映射在宿主机的./redis_data目录下
* 修改redis配置文件，使AOF生效，并关闭RDB
这里将上面的redis.conf内容复制替换到./redis_config/redis.conf文件中即可
* 启动redis服务，并观察redis_data目录下是否有dump.rdb文件生成，有生成，则证明备份成功
* 数据恢复的话，我们不需要做其他操作，只要确保该dump.rdb存在，redis便会自动去读取其中的数据
上述配置会通过docker-compose的配置，映射到Redis容器中并启用
- AOF配置说明
上述配置中与AOF相关的配置如下
* appendonly: 是否启用AOF
* yes: 启用AOF
* no: 关闭AOF
* appendfsync: 启用AOF后的数据同步频率
* alaways: 每个Redis写命令都要同步写入硬盘。这样做会严重降低Redis 的速度 （不建议）
* everysec: 每秒执行一次同步，显式地将多个写命令同步到硬盘 （推荐，对性能没有太大影响）
* no: 让操作系统来决定应该何时进行同步。（不建议）
Redis将不对AOF文件执行任何显式的同步操作，如果用户的硬盘处理写入操作的速度不够快的话，那么当缓冲区被等待写入硬盘的数据填满时，Redis的写入操作将被阻塞，并导致Redis处理命令请求的速度变慢
* no-appendfsync-on-rewrite：在对AOF进行压缩（也被称为重写机制）的时候能否执行同步操作
* yes: 不允许
* no: 允许
* auto-aof-rewrite-percentage：多久执行一次AOF压缩，单位是百分比
* auto-aof-rewrite-min-size：需要压缩的文件达到多少时开始执行
auto-aof-rewrite-percentage跟auto-aof-rewrite-min-size需要配套使用，比如当我们设置auto-aof-rewrite-percentage为100，设置auto-aof-rewrite-min-size为64mb时
redis会在AOF产生的文件比64M大时，并且AOF文件的体积比上一次重写之后至少增大了一倍（100%）才执行BGREWRITEAOF重写命令
如果觉得AOF重写执行得过于频繁，我们可以把auto-aof-rewrite-percentage设置100以上，比如200，就可以降低重写频率
这里可以参考Redis的官方手册，写的非常清楚：[https://redislabs.com/ebook/part-2-core-concepts/chapter-4-keeping-data-safe-and-ensuring-performance/4-1-persistence-options/4-1-3-rewritingcompacting-append-only-files/](https://redislabs.com/ebook/part-2-core-concepts/chapter-4-keeping-data-safe-and-ensuring-performance/4-1-persistence-options/4-1-3-rewritingcompacting-append-only-files/)
* dir：备份文件存放目录
### AOF触发条件
直接根据appendfsync的设置进行触发
### AOF重写机制
在上面的配置中，已经通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数，简单介绍了Redis的BGREWRITEAOF重写命令
那么，为什么要用AOF重写机制呢？
因为AOF持久化是通过保存被执行的写命令来记录Redis数据库状态的，所以AOF文件随着时系统运行会越来越大
而过于庞大的AOF文件会产生以下不良影响
* 影响Redis服务性能；
* 占用服务器磁盘空间；
* AOF还原数据状态的时间增加；
所以Redis提供了一套AOF重写机制，通过创建一个新的AOF文件来替换掉旧的AOF文件，这两个文件所保存的数据状态是相同的，但新的AOF文件不会包含冗余命令，所以体积会较旧AOF文件小很多
但在实际的使用中，我们需要非常小心，不能让Redis的重写命令执行的过于频繁 **(注意：auto-aof-rewrite-percentage的单位是百分比，值越大，重写频率越低，也千万别出现0这种值)** 因为BGREWRITEAOF的工作原理和BGSAVE创建快照的工作原理非常相似：Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写，因为AOF文件重写也需要用到子进程，所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在AOF持久化中也同样存在
更具体的AOF重写工作原理：
* Fork主进程，产生一个带有数据副本的子进程在后台执行
Redis这样设计可以确保在重写过程中，不影响Redis主进程的服务正常运行，同时通过处理数据副本来保证数据的安全性**(注意，重写是针对数据副本来进行处理，而不是针对旧的AOF文件)**
* 子进程Fork完成后，Redis将启用AOF重写缓冲区，此刻开始，新的写入命令会被写入AOF缓冲区和AOF重写缓冲区中
这里启用的AOF重写缓冲区可以确保：在执行AOF重写的过程中，任何新的写入命令产生，都不会导致新AOF文件的数据状态与Redis数据库状态不一致
* 子进程完成对AOF文件的重写后，通知父进程
* 父进程收到通知后，将AOF重写缓冲区的内容全部写入新的AOF文件中
* 父进程将新的AOF文件替换掉旧的AOF文件**(注意，这一步会造成Redis阻塞，但问题不大)**
