五、redis rbd和aof持久化
参考https://www.cnblogs.com/mapleins/p/10174546.html
一、简介
1、RDB机制的策略
RDB持久化是指在指定的时间间隔内将内存中的数据和操作通过快照的方式保存到redis 设置的dir目录下的一个默认名为 dump.rdb的文件，可以通过配置设置自动的快照持久化的方式，我们可以配置redis在n秒内进行快照的时间，如果超过这个时间节点，将会自动执行快照操作。虽然这种方式方便快捷，但是无法保证数据的绝对安全可靠，如果服务器在非备份时间跨度内发生了故障，无法做到对当前状态的实时保存，导致数据丢失。而且每次保存 RDB文件时， Redis都需要 fork()出一个子进程，由子进程来执行具体的持久化工作，对资源消耗较大。
2、AOF机制的策略
redis 的 AOF 持久化是在每次接受到的命令通过 write函数追加到文件中（默认是 appendonly.aof），但是由于操作系统在写入文件时使用了缓存来提高写入效率，还是可能会出现因服务器突然故障而导致的数据丢失，故我们可以通过配置文件告诉redis我们同步数据的时间间隔（默认间隔是每秒同步一次）
二、RBD
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。默认持久化机制，就是将内存中的数据以快照的方式写入二进制文件dump.rbd中。
1.配置快照规则
在redis.conf文件中，默认的规则为：每900s修改一次或每300s修改10次或每60s修改10000次
save
second 秒内，key的修改数量大于exchanges时，执行快照
save的关系是或的关系，都满足
rdbcompression no #rdb压缩最好关闭，影响cpu
默认文件名为 dump.rdb
默认路劲为配置文件下的当前路径./，我这里修改为/data/redis/
2、save或bgsave执行数据同步到磁盘
save：执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求。（不要轻易执行，数据量大，阻塞时间差）
bgsave：在后台异步执行快照操作，这个操作不会阻塞客户端的请求。
执行save，文件时间执行的时间
127.0.0.1:6379> save
OK
[root@localhost ~]# ll /data/redis/dump.rdb
-rw-r--r--. 1 root root 661 9月 29 15:44 /data/redis/dump.rdb
执行bgsave，文件时间更新了
127.0.0.1:6379> bgsave
Background saving started
[root@localhost ~]# ll /data/redis/dump.rdb
-rw-r--r--. 1 root root 661 9月 29 15:46 /data/redis/dump.rdb
3、执行flushall清除内存中的所有数据时，只要快照规则不为空，那么redis就会执行快照。
4.执行复制的时候（集群）
5、快照的实现原理
- redis会使用fork函数复制一份当前进程的副本（子进程）
- 父进程继续处理客户端请求。
- fork进程负责把内存的数据同步到磁盘的临时文件，当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
- 缺点：由于子进程是复制父进程，两个内存大小相同的redis进程在系统上运行，会造成内存使用率大幅增加。
6、使用rdb的优缺点
优点：
1.只包含一个dump.rdb文件，方便备份移动。
2.rdb恢复大数据集的速度比aof快。
3.rdb可以最大化redis性能，因为是子进程去处理保存工作，父进程无需执行io操作。
缺点：
1.rbd的规则是单位时间内改变多少个键，才会触发，而在为改变之前，一旦服务器故障，就会丢失几分钟的数据
2.当数据量大时,fork子进程会非常耗时，会造成服务器在某毫秒或长达一秒的时间停止处理客户端。并且子进程和父进程两个进程会消耗更多的内存。
7、设置开启或者关闭rdb
Redis Config rewrite 命令对启动 Redis 服务器时所指定的 redis.conf 配置文件进行改写。
CONFIG SET 命令可以对服务器的当前配置进行修改， 而修改后的配置可能和 redis.conf 文件中所描述的配置不一样， CONFIG REWRITE 的作用就是通过尽可能少的修改， 将服务器当前所使用的配置记录到 redis.conf 文件中。
127.0.0.1:6379> config set save "" #关闭rdb存储
OK
127.0.0.1:6379> config rewrite
OK
127.0.0.1:6379> config set save "180 1 120 10 60 10000" #开启rdb存储
OK
127.0.0.1:6379> config rewrite
OK
查看修改成功
三、AOF
redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。
1、配置 redis.conf
appendonly yes #改为yes
appendfilename "appendonly.aof" #保存的文件名
2、修改后重启redis，然后写入值再查看，可以看到有aof文件，查看文件可以看到每条记录都被写入aof文件中
[root@localhost ~]# redis-cli
127.0.0.1:6379> get name
"wangxiaoyu"
127.0.0.1:6379> set name wangxiaoyu
OK
127.0.0.1:6379> set name wangxiaoyu2
OK
[root@localhost ~]# ll /data/redis/appendonly.aof
-rw-r--r--. 1 root root 63 9月 29 16:08 /data/redis/appendonly.aof
[root@localhost ~]# cat /data/redis/appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$10
wangxiaoyu
3、同步磁盘数据出现的问题
redis每次更新数据时，aof机制都会将命令写入aof文件中。
但是实际上由于操作系统的缓存机制，数据并没有实时写到磁盘，而是先写入磁盘的缓冲区，再通过硬盘缓存机制刷新保存到文件中。这样就可能回出现数据丢失。
4、同步策略
appendfsync always：每次收到命令就立刻强制写入磁盘，最慢，但是完全持久化，不推荐使用
appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐，默认使用
appendfsync no ：完全依赖os，性能最好，持久化没保障。
5、重写策略（优化aof文件）
auto-aof-rewrite-percentage 100：当aof文件大小超过上一次aof文件大小的百分之多少会重写。如果之前没重写过，以启动时aof文件大小为准。 默认为100%，也就是增加一倍后考虑aof rewriteauto-aof-rewrite-min-size 64mb：限制允许重写最小aof文件大小，也就是文件大小小于64mb，不需要进行优化。默认为64mb，也就是达到64M后再rewrite。跟上一个条件要同时满足(config set auto-aof-rewrite-min-size 100000观察)
重写的实现原理
1.redis调用fork函数，复制一个子线程
2.父进程继续处理client请求，将请求追加到aof文件，同时收到的命令缓存起来，这样保证子进程重写失败不会出问题。
3.子进程根据内存中的数据快照，往临时文件中写入重建数据库状态的命令
4.当子进程将快照的命令写入临时文件后，通知父进程，然后父进程把缓存的写命令也写入临时文件
5.当父进程写完后，将临时文件替换老的aof文件，后续命令往新的aof文件中追加
6、aof文件的修复
- 先复制原有的aof cp appendonly.aof appendonly.aof.bak
- 执行 redis-check-aof --fix appendonly.aof 完成修复
7、aof的优缺点
优点：
- aof的同步策略，可以让aof安全性变的非常高，并且使用每秒同步一次，redis依然可以保证很好的性能，就算发生故障，也最多只丢失一秒的数据。
- aof采用末尾追加的方式写入文件，即便出现问题，aof-check-aof也可以修复文件。同时aof提供了重写策略，来优化aof文件
- aof有序保存了对数据库执行写的操作，以redis协议数据保存，易于读和解析，并且不小心执行了flushall，也可以移除aof文件末尾的flushall命令，恢复之前的状态。
缺点：
- 对于相同的数据集来说，aof文件体积大于rdb文件的体积。
- 因为采用了同步策略，aof的速度相比rdb还是要慢一些。
两种持久化的策略可以同时使用，也可以使用其中的一种，如果同时使用的时候，那么Redis重启时，会优先使用aof文件来还原数据。