本文主要是介绍redis之高可用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
（一）redis之高可用
1、在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%
2、redis的高可用的含义更加广泛，正常服务是指标之一，数据容量的扩展、数据的安全性
3、在redis中实现高可用的技术
（1）持久化
（2）主从复制
（3）哨兵模式
（4）cluster集群
（二）持久化（RDB/AOF）（重点）
1、持久化：最简单的高可用方法，主要作用是数据备份，也就是把redis缓存在内存中的数据保存到本地的硬盘当中（冷备份—停止服务备份）
2、redis持久化的两种方式
（1）RDB持久化：redis在内存中的数据定时保存到磁盘（自动执行、手动执行）（生产中很少使用）
（2）AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysql的binlog
（三）RDB持久化
1、RDB：指在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），用二进制压缩存储，保存的文件名后缀.rdb，redis启动时可以直接读取快照文件，实现数据恢复
2、RDB的触发机制
（1）手动机制：save、bgsave都可以生成RDB文件
①save创建RDB文件时，整个redis进程会被阻塞，期间redis将无法进行读写操作，直到RDB文件创建完整为止（生产中禁止用save生成RDB文件）
②bgsave：就是主从复制的机制。特点：主进程会通过fork机制创建一个子进程，子进程创建的过程中，主进程会阻塞，子进程创建完毕，主进程解除阻塞，由子进程创建RDB文件，创建完成之后，通知主进程更新通知信息（重点）
③bgsave的工作流程
关闭服务（冷备份）：
恢复：
（2）自动机制（/ect/redis/6379.conf）
除了配置文件的save m n之外，还有：
①主从复制，从节点执行全量复制操作，直接执行bgsave，把RDB文件传送给从节点
②关闭主进程，shutdown之后，会自动指定RDB的持久化
③启动时加载，RDB文件被损坏，日志中会打印错误，redis会拒绝启动
④redis-check-rdb工具修复RDB的持久化文件
| save 900 1：表示当时间到900秒时，redis的数据至少发生一次变化，就执行bgsave save 300 10：表示当时间到300秒时，redis的数据至少发生十次变化，就执行bgsave save 60 10000：表示当时间到60秒时，redis的数据至少发生一万次变化，就执行bgsave
时间间隔不能太短，执行不能太频繁（数据变动的越多，执行的时间越短，数据变动不大，时间间隔要长一点） 生产中一般设置：save 120 1000、save 60 10000 | |
| rdbcompression yes
| 开启RDB文件的压缩功能，在高并发场景建议关闭 （生产中默认是no） |
（四）AOF持久化（生产中普遍使用）
1、AOF持久化是将redis的每一次读、写、删除命名记录到一个单独的.aof结尾的文件，查询操作由主进程记录，当redis重启时，再次执行AOF文件中的命令来恢复数据
2、AOF的实时性更好，也是主流的持久化方案
3、RDB是redis的默认持久化文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高级优先级
|
| |
 | aof-load-truncated yes：用于判断AOF文件是否被截断，发现被截断（写入过程中出现异常，导致文件未能完全写入）（重点） |
| AOF文件被截断时： 设置为yes，redis会尽可能的恢复文件中的数据，redis会继续运行 设置为no，发现AOF文件被截断，redis会拒绝启动 | |
| 数据完整祥的要求高：设置No | |
| 注重数据服务器的可用性：设置yes | |
4、AOF的工作流程（自动机制：编辑vim appendonly.aof）
（五）AOF的重写功能（重点）
1、重写的原因：随着时间增长，AOF文件中的数据也会不断增加，AOF的文件也会越来越大，过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复的时间过长
2、文件重写：是指定期的重写AOF文件，减小AOF文件的体积，AOF重写是把redis进程内的数据转化为写命令，同步到新的AOF文件中（不会额外的生成一个新的文件，只是在原内容中进行压缩），不会对原有的AOF文件进行任何读写的操作
3、文件重写虽然是AOF持久化强烈推荐的，但不是必须的，没有重写，并不影响redis启动时读取数据，在实际中，会关闭自动的文件重写，通过定时任务来完成
4、重写机制的工作路程（重点）
5、AOF同步文件策略的三种方式
 |
| （1）appendfsync always：写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，这次写入都执行同步，硬盘的性能有瓶颈，硬盘的寿命会大大降低（不推荐） （2）appendfsync everysec：命名写入，调用write操作，write操作结束后，write线程会返回，fsync同步文件操作由专门的线程每秒同步一次（这是一个折中的策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置） （3）appendfsync no：写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证 |
6、重写的触发条件
（1）手动触发：redis-cli bgrewriteaof
（2）自动触发（配置配置文件）：
 |
| auto-aof-rewrite-percentage 100： 表示文件的大小超过基准的百分比，默认值就是100，文件的大小超过两倍时，执行bgrewriteaof，设置为0，表示禁用自动触发（100M—200M—400M） *若要创建定时任务，可以设置为0，或者注释掉 |
| auto-aof-rewrite-min-size 64mb（必须要有）： 表示只有文件大于基准值，才会进行重写，这个值是AOF执行重写的最小值，可以避免开始启动redis后，文件太小，然后频繁的进行重写 |
7、AOF重写为什么能压缩文件
（1）重写的过程中，如果有过期的数据不会写入文件
（2）无效的命令不再写入文件，数据被重复设置（set test 1，set test 2），删除的数据也不会写入
（3）把多条命令合并成一个
例：sadd test1 1 sadd test1 2 sadd test1 3——sadd test1 1 2 3
（4）重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了（重写不是必须的，根据需求——重点）
（六）RDB和AOF之间的优缺点
1、DRB
（1）RDB的优点：RDB文件体积小，网络传输速度很快，适合全量复制，恢复速度也比AOF要快
（2）RDB的缺点：做不到实时的持久化，数据如此重要，不能容忍丢失的；RDB需要满足特定的格式，兼容性很差，老版本的RDB不支持新版本（redis的版本要一致，redis的版本：5.0.7）
2、AOF
（1）AOF的优点：秒级持久化，兼容性好（文本格式保存的命名，命令通用）
（2）AOF的缺点：文件大，恢复速度慢，AOF持久化需要频繁的向磁盘写入数据，磁盘的I/O压力很大，对redis 主进程的性能也会有一定影响
（七）持久化总结
1、redis的持久化也算是高可用的一种，通过备份文件来恢复数据（冷备份）
2、RDB：save（线上禁用），bgsave
3、AOF：
（1）实时持久化，写入的是操作命令，除了查（set和del会记录，select和get不记录）。实时记录，恢复方式类似于mysql的binlog
（2）重写（推荐但是不是必须的）：也是主进程创建一个子进程，在过程中产生的数据以及同步策略都会写入到AOF文件当中
这篇关于redis之高可用的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
