redis高可用---持久化

redis高可用

在集群当中有一个非常重要的指标，提供正常服务的时间的百分比(365天) 99.9%，redis高可用含义更广泛，支持服务是指标之一，数据容量扩展，数局的安全性。（容量、安全性）

redis中实现高可用的技术：

1、持久化-----就简单的高可用方法，主要作用是数据备份，也就是把redis缓存在内存中的数据保存在本地硬盘中。（冷备份）
2、主从复制
3、哨兵模式
4、cluster集群

持久化

主要作用是数据备份，最简单的高可用方法，也就是把redis缓存在内存中的数据保存在本地硬盘中。（冷备份）

持久化的两种方式：

1、RDB持久化：redis在内存中的数据定时保存到磁盘。（自动执行、手动执行）
2、AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysql的binlog
优先级 RDB的.rdb文件（默认）< AOF的.aof文件

RDB持久化

RDB持久化：指在指定时间间隔内，将内存中当前进程中的数据生产快照保存到硬盘(快照持久化)，用二进制压缩存储。保存的文件名后缀.rdb。redis启动时，可以直接读取快照文件，实现数据恢复。

RDB的触发机制
手动机制：save bgsave都可以生成RDB文件。

手动机制

save工作流程：创建rdb文件时，整个redis进程会被阻塞模式，期间redis将无法进行读写操作，直到rdb文件创建完成为止。生产中不能用save。

bgsave：是主从复制的机制

bgsave工作流程：主进程会通过fork机制创建一个子进程，子进程重建过程中，主进程会阻塞，子进程创建完毕，主进程解除阻塞。子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息。

vim /etc/redis/6379.conf

--219行--以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
 
--254行--指定RDB文件名
dbfilename dump.rdb
 
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
 
--242行--是否开启RDB文件压缩
rdbcompression yes

自动机制

除了save m n 以外，还有一些其他情况会触发bgsave：
● 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点。
● 执行shutdown命令时，自动执行rdb持久化。

AOF的重写功能

1、 随着时间增长AOF文件中的数据也会不断怎加。AOF的文件也会越来越大，过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长。

文件重写是指定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写的命令，同步到新的AOF文件中(不会额外生成一个新的文件，只是在原有内容中进行压缩)，不会对原有的文件进行任何读、写的操作。

文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写，并不影响redis启动时读取数据。在实际中，会关闭自动的文件重写。通过定时任务来完成。

AOF持久化：

·AOF持久化是将redis的每一次读写删除命令记录到一个单独的文件。保存的文件名后缀.aof。查主询操作由进程记录。当redis重启时，，再次执行AQF文件中的命令来恢复数据。
·AOF的实时性更好，也是主流的持久化方案

vim /etc/redis/6379.conf

--700行--修改，开启AOF
appendonly yes
 
--704行--指定AOF文件名称
appendfilename "appendonly.aof"
 
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
#用于判断AOF文件，如果被截断时的行为
#截断：写入过程中出现异常，导致文件未能完全写入
#yes：发现被截断，redis会在启动时尽可能恢复文件中的数据。redis会继续运行
#no：发现AOF文件被截断，redis将拒绝启动
 
如果对数据的完整性高，建议使用no
如果追求数据服务器的可用性，可以使用yes
可用性在并发场景上很重要，推荐使用yes

AOF如何实现备份恢复

vim /etc/redis/6379.conf
cd /var/lib/redis/6379
#检查文件是否生成
 
实现数据恢复
进入redis
set test1 1
set test2 2
set test3 3
vim /var/lib/redis/6379/appendonly.aof
#配置文件会记录所有redis的操作
flushall
/etc/init.d/redis_6379 stop
#停止redis服务
vim /var/lib/redis/6379/appendonly.aof
#根据为位置点删除flushall这个操作
/etc/init.d/redis_6379 restart
#重启服务
进入redis查看文件恢复
实验已经完成！

AOF缓存区的同步文件策略存在三种同步方式，它们分别是：

vim /etc/redis/6379.conf
--729--
●appendfsync always： 命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。
这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，
严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
 
●appendfsync no： 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，
通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
 
●appendfsync everysec： 命令写入aof_buf后调用系统write操作，write完成后线程返回；
fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，
因此是Redis的默认配置，也是我们推荐的配置。

重写的触发条件

1、手动触发
重写命令 redis-cli bgrewriteaof

2、自动触发
 

vim /etc/redis/6379.conf​
771行
auto-aof-rewrite-percentage 100
#文件的大小超过基准的百分比。默认值就是100。文件的大小超过2倍时，会执行bgrewriteaof。
如果设置为0就是禁用自动触发。
 
auto-aof-rewrite-min-size 64mb
#文件大于基准值，才会进行重写。这个是AOF文件执行重写的最小值，避免开始启动redis后，文件太小，然后频繁的进行重写。​
必须要有auto-aof-rewrite-min-size 64mb。
否则会频繁重写。如果配置定时任务需要先注释掉auto-aof-rewrite-percentage 100否则会自动生效。

AOF重写为什么可以压缩文件？

1、 在重写的过程中，如果有过期的数据不会写入文件

2、 重写的过程中无效的命令不再写入文件，数据被重复设置，例如：set test=1 set test=2。删除的数据也不会写入，例如：set test 1 del test

3、 多条命令合并成一个。例如：sadd test1 v1 sadd test1 v2 sadd test1 v3 合并为 sadd test1 v1 v2 v3

重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了。(重写不是必须的)
 

RDB和AOF的优缺点

RDB的优点：文件体积小，网络传输的速度很快，适合全量复制。恢复速度比AOF快。
RDB的缺点：做不到实时的持久化，数据如此重要，不能够容忍数据丢失。RDB需要满足特定的格式，兼容性很差。
老版本的RDB不支持新版本。redis版本要一致

AOF的优点：秒级持久化，兼容性好（文本格式保存命令通用）。
AOF的缺点：文件大，恢复速度慢。AOF持久化，需要频繁的向磁盘写入数据，磁盘的io压力大，对redis的主进程新能也有一定的影响

启动时加载发现rdb文件被损坏，日志中会打印错误，redis会拒绝启动。redis-check-rdb 修复RDB的持久化文件。