redis高可用之持久化
一、redis持久化概述
1、redis高可用：
在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%
redis的高可用含义更加宽泛，正常服务是指标之一，数据容量的扩展，数据的安全性
在redis中实现高可用的技术：持久化，主从复制，哨兵模式，cluster集群。
持久化：持久化是最简单的高可用方法，主要作用是数据实现备份，也就是把redis缓存在内存中的数据保存到本地的硬盘中（冷备份）
2、redis持久化的两种方式：
- RDB持久化：redis在内存中的数据定时保存到磁盘。（自动执行，手动执行）
- AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于MySQL的binlog
由于AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AOF是目前主流的持久化方式，
不过RDB持久化仍然有其用武之地。
二、RDB的持久化：
指在指定的时间间隔内，将内存中当前进程中的数据生成快照，保存到硬盘（快照持久化），用二进制压缩存储，保存的文件名的后缀是.rdb。只要redis启动时，可以直接读取快照文件，实现数据恢复
1、RDB的触发机制：
是冷备份：每次同步要关闭服务
1.1、手动机制：save、bgsave
save
用save创建RDB文件时，redis服务的主进程将被阻塞，期间redis将无法再进行读写操作，直到RDB文件创建完成为止
生产中禁止用save保存，都用bgsave
文件位置：/var/lib/redis/6379
冷备份：要关闭服务
每一次重启自动读取文件
bgsave
fork子进程，子进程创建RBD文件
特点：主进程会通过fork机制来创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕之后，主进程会解除阻塞。由子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息
1.2、bgsave执行流程：
1、redis主进程判断是否执行save或bgsave、bgrewriteaof的子进程。如果在执行则bgsave命令直接返回。bgsave/bgwriteaof的子进程不能同时执行
原因：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题
2、主进程执行fork操作创建子进程，这个过程中主进程是阻塞的，redis不能执行来自客户端的任何命令
3、子进程创建完毕之后，主进程会解除阻塞。
4、由子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息
1.3、恢复过程：
1、执行完数据之后：bgsave
2、cp /var/lib/redis/6379/dump.rdb /opt
3、删除原文件，将备份文件恢复。
1.4、自动触发机制：
在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化。
vim /etc/redis/6379.conf
219行 默认的三个机制
save m n
自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。
save 900 1
900秒，当时间到900秒时，redis的数据至少发生一次变化，就执行bgsave
save 300 10
300秒内，redis数据至少发生10次变化，就执行bgsave
save 60 10000
60秒内，redis数据至少发生10000次变化，就执行bgsave
工作中：
save 120 1000 bgsave
save 60 10000 bgsave
数据变动越多，执行的时间要越短。数据变动不大，时间间隔要长一点。
242行
rdbcompression yes
开启RDB到达文件压缩功能，在高并发场景建议关闭（改成no）
264行
dir /var/lib/redis/6379
保存持久化文件的位置，可自定义
除了配置文件中的save m n之外，还有哪些自动触发机制：
主从复制，从节点执行的是全量复制操作，主节点会执行bgsave，把RDB文件传送给从节点
关闭主进程，shutdown之后，会自动执行RDB的持久化
启动时加载：
启动时，如果RDB文件被损坏，日志中会打印错误，redis会拒绝启动
redis-check-rdb工具 会修复RDB的持久化文件
恢复过程：
1、执行完数据之后：bgsave
2、cp /var/lib/redis/6379/dump.rdb /opt
3、删除原文件，将备份文件恢复。
三、AOF持久化：
AOF持久化是将redis的每一次读、写、删除命令记录到一个单独的以.aof结尾的文件（查询操作不记录，查询操作是由主进程记录）
当redis重启时，再次执行AOF文件中的命令来恢复数据。
AOF的实时性更好，也是主流的持久化方案
1、配置
vim /etc/redis/6379.conf
700行
appendonly on改成yes，开启AOF功能
704行 默认的文件名
名字可以自定义，但是后缀不能改，要.aof
796行
aof-load-truncated yes
用于判断AOF文件，如果被截断时的行为
截断：写入过程中出现异常，导致文件未能完全写入
yes：发现被截断，redis在启动时会尽可能的修复数据，redis会继续运行
no：发现AOF文件被截断，redis将拒绝启动
数据的完整性的要求高，选no
注重数据服务器的可用性，选yes。一般要保证可用
vim /var/lib/redis/6379/aof文件
自己进去删
RDB是redis的默认持久化文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级
2、重写：
AOF的重写功能：
- 随着时间的增长，AOF文件中的户数也会不断增加。AOF的文件也会越来越大。过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长。
- 文件重写是指定期的重写AOF文件，目的是减小AOF文件的体积。AOF重写是把redis进程内的数据转化为写的命令，同步到新的AOF文件当中（不会额外的生成新的文件，只是在原内容中进行压缩）。不会对原有的AOF文件进行任何读、写操作
*文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写并不影响redis启动时的读取数据。在实际工作中，会关闭自动的文件重写。通过定时任务来完成。
AOF同步文件的策略：三种方式
策略的三种方式
配置文件
729行
appendfsync always
写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，每次写入都执行同步，硬盘的性能有瓶颈，硬盘的寿命也会大大降低
appendfsync everysec
命令写入，调用write操作，write操作结束之后，线程会返回。FSYNC同步文件操作由专门的线程每秒调用一次。这是一个折中的策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置
appendfsync no
写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证。
重写的触发条件：
- 手动触发
命令：
redis-cli bgrewriteaof
手动触发的工作流程：
1、Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程，
如果存在则bgrewriteaof命令直接返回，如果存在 bgsave命令则等bgsave执行完成后再执行。
2、父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。
3.1、父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，
并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
3.2、由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，
因此Redis使用AOF重写缓冲区(aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。
也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。
4、子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
5.1、子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
5.2、父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
5.3、使用新的AOF文件替换老文件，完成AOF重写。
- 自动触发
看配置文件
vim /etc/redis/6379.conf
771行 772行
自动触发rewrite机制
auto-aof-rewrite-percentage 100
文件的大小超过基准的百分比，默认值就是100(%)，文件的大小超过两倍时，执行bgrewrite。设置为0，禁用自动触发
100M执行 下一次200M执行 下一次400M执行 下一次就是800M执行
若要设置crontab定时任务，这个配置要设0
auto-aof-rewrite-min-size 64mb
这个配置必须要存在
表示只有文件大于基准值，才会进行重写。这个值是AOF执行重写命令的最小值，避免开始启动redis后，文件太小频繁的进行创建
AOF重写为什么能够压缩文件：
- 在重写的过程中，过期的数据不会写入文件
- 重写的过程中，无效的命令（数据被重复设置）不再写入文件，删除的数据也不会写入
- 多条命令合成一个。sadd test1 v2 sadd test v3 sadd test1 v1 v2 v3
重写之后，AOF的文件当中命令减少了，空间也减少了，恢复也增加了。（重写不是必须的）
RDB和AOF之间的优缺点：
RDB的优点：文件体积小，网络传输速度很快，适合全量复制。恢复速度也比AOF要快
缺点：做不到实时的持久化，数据如此重要，不能够容忍丢失的。另外RDB需要满足特定的格式，兼容性很差。
老版本的RDB不支持新版本。(redis版本一定要一致）5.0.7
AOF的优点：秒级持久化。兼容性好。因为是文本格式保存的命令，命令是通用的
缺点：文件大，恢复速度慢。AOF持久化需要频繁的向磁盘写入数据，磁盘的IO压力也是很大的。对redis主进程的性能也会有一定的影响。
总结：
redis持久化也算是高可用的一种，通过备份文件来恢复数据，冷备份
两种方式：
rdb
save是线上禁用的
bgsave
aof（实时持续化）
写入的操作的命令，除了查（get、select）。set、del这种写入命令会记录。实际记录，不需要停机，恢复方式类似于MySQL的binlog
重写：推荐但是不是必须的。重写也是主进程创建一个子进程，在过程中产生的数据以及同步策略都会同步到AOF文件中
gbsave 配置文件 900
重复数据是否会被记录