Redis高可用

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

在redis中实现高可用技术：

持久化，主从复制，哨兵模式， cluster集群。

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

redis持久化的两种方式：

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

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

RDB的触发机制

手动触发

：save bgsave都可以生成RDB文件。

save创建RDB文件时，整个redis进程会被阻塞，期间redis将无法进行读写操作，直到RDB文件创建完成为止。

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

• bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。

自动触发

在自动触发RDB持久化时，Redis 也会选择bgsave而不是save来进行持久化。

自动触发最常见的情况是在配置文件中通过 save m n 指定当m秒内发生n次变化时，会触发bgsave。

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
 ​
 ----242行--是否开启RDB文件压缩
 rdbcompression yes
 ​
 ----254行--指定RDB文件名
 dbfilename dump.rdb
 ​
 ----264行--指定RDB文件和AOF文件所在目录
 dir /var/lib/redis/6379  
 

sava 120 1000 bgsave
save 60 10000 bgsave

数据变动越多，执行的时间要越短。数据变动不大，时间间隔要长一点。

rdbcompression no
开启RDB的文件压缩功能，在高并发场景建议关闭。

其他自动触发机制

除了配置文件中的save m n之外
主从复制，从节点执行全量复制操作，直接执行bgsave,把rdb文件传送给从节点
关闭主进程，shutdown之后，会自动执行rdb的持久化。

启动时加载：

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。 服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。
Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。
redis-check-rdb修复RDB的持久化文件。

AOF持久化：

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

aof-load-truncated yes
用于判断AOF文件，如果被截断时的行为.
yes：发现被截断（写入过程中出现异常，导致文件未能完全写入。），redis会尽可能的恢复文件中的数据，redis会继续运行
no:发现AOF文件被截断，redis将拒绝启动。
数据完整性的要求高，no
注重数据服务器的可用性 yes

rdb是redis的默认持久化文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级。

 AOF的开启配置

Redis服务器默认开启RDB，关闭AOF的， 要开启AOF，需要在/etc/redis/6379.conf配置文件中配置。

vim /etc/redis/6379.conf
 ----700行---修改，开启AOF
 appendonly yes
 ----704行---指定AOF文件名称
 appendfilename "appendonly.aof"
 ----796行---是否忽略最后一条可能存在问题的指令
 aof-load-truncated yes   
 #Redis恢复时，发现AOF文件的末尾被截断了，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能发生redis机器运行崩溃，AOF文件的末尾被截断了，这种情况下，yes会继续执行并恢复尽量多的数据，而no会直接恢复失败报错退出。
 ​
 ​
 /etc/init.d/redis_6379 restart    #重启redis
 ls /var/lib/redis/6379/      #查看是否生成了aof文件

AOF的重写功能：

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

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

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

AOF同步文件策略的三种方式：

1.appendfsync always:写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，这次写入都执行同步，硬盘的性能有瓶颈。硬盘的寿命也会大大降低。

2.appendfsync no:写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证。

3.appendfsync everysec：命令写入，调用write操作，write操作结束后，线程会返回。FSYNC同步文件操作由专门的线程，每秒调用一次。这是一个折中的策略，是性能和安全性的平衡，是redis的默认配置。也是推荐配置。

重写的触发条件

1、手动触发

redis-cli bgrewriteaof

直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。

2、自动触发。

通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

vim /etc/redis/6379.conf
 ----771行----
  771 auto-aof-rewrite-percentage 100
  772 auto-aof-rewrite-min-size 64mb
 ​
 -----------------------以下是注释--------------------------------
 ● auto-aof-rewrite-percentage 100  
 #文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
 #即当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作。
 #注意：例如上次文件达到100M进行重写，那么这次需要达到200M时才进行重写。文件需要越来越大，所以一般不使用自动重写。如果使用自动重写，需要定期手动重写干预一次，让文件要求恢复到100M。
 ​
 ● auto-aof-rewrite-min-size 64mb      #当文件大于64M时才会进行重写
 #当前aof文件大于多少字节后才触发。
 #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

AOF重写为什么能够压缩文件：

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

2、无效的命令不再写入文件，数据被重复设值set test=1 set test 2,删除的数据也不会写入set test 1 del test

3、多条命令合并成一个。sadd test1 v1 sadd test1 v2 sdd test1 v3 sadd test1 v1 v2 v3
重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也增加了。（重写不是必须的。）

RDB和AOF之间的优缺点：

RDB
优点：文件体积小，网络传输速度很快，适合全量复制。恢复速度也比AOF要快。
缺点：做不到实时的持久化，数据如此重要，不能够容忍丢失的。另外RDB需要满足特定的格式，兼容性很差。老版本的RDB不支持新版本。 (redis的版本一定要一致) 5.0.7
AOF
优点：秒级持久化。兼容性好。文本格式保存的命令。
缺点：文件大，恢复速度慢。AOF持久化需要频繁的向磁盘写数据，磁盘的IO压力也很大。对redis主进程的性能也会有一定的影响。

redis的持久化也算是高可用的一种，通过备份文件来恢复数据，冷备份。
rdb：sava线上禁用。bgsave:
AOF：实时持久化 写入的操作的命令，除了查set del会记录 get select不计入。实时词录，恢复方式类似于MYSQL的bin-log重写：推荐但是不必须的。重写也是主进程创建一个子进程，在过程中产生的数据以及同步策略都是写入到AOF文件当中。

Redis性能管理

查看redis的内存使用情况 

（1） redis-cli
 127.0.0.1:6379> info memory
 （2） redis-cli info memory

• used_memory_rss：是Redis向操作系统申请的内存。
• used_memory：是Redis中的数据占用的内存。
• used_memory_peak：redis内存使用的峰值。

系统巡检：硬件巡检，数据库nginx redis docker k8s

内存碎片 

内存碎片率=Redis向操作系统申请的内存 / Redis中的数据占用的内存

used_memory_rss/used_memory
系统已经分配给了redis,但是redis未能够有效利用的内存。
allocator_frag_ratio:1.19
分配器碎片的比例，redis主进程调度时产生的内存，比例越小越好，值越高，内存的浪费越多。
allocator_rss_ratio:7.15
分配器占用物理内存的比例，告诉你主进程调度执行时占用了多少物理内存。rss_overhead_ratio:0.31
RSS是向系统申请的内存空间，redis占用物理空间额外的开销比例，比例越低越好，redis实际占用的物理内存和向系统申请的内存越接近，额外的开销越低。mem_fragmentation_ratio:3.33

mem_fragmentation_ratio：3.33 
内存碎片的比例，越低越好，内存的使用率越高。
自动清理碎片：
activedefrag yes 
手动清理：
redis-cli memory purge

内存碎片产生的原因

Redis内部有自已的内存管理器，为了提高内存使用的效率，来对内存的申请和释放进行管理。
Redis中的值删除的时候，并没有把内存直接释放、交还给操作系统，而是交给了Redis内部有内存管理器。
Redis中申请内存的时候，也是先看自己的内存管理器中是否有足够的内存可用。
Redis的这种机制，提高了内存的使用率，但是会使Redis中有部分自己没在用，却不释放的内存，导致了内存碎片的发生。

内存碎片率对redis的影响 

内存碎片率在1到1.5之间是正常的，这个值表示内存碎片率比较低，也说明Redis 没有发生内存交换。
内存碎片率超过1.5，说明Redis消耗了实际需要的物理内存的150%，其中50%是内存碎片率。
内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换（使用虚拟内存，会降低性能）。需要增加可用物理内存或减少Redis内存占用。

解决碎片率过大的方法 

如果你的Redis版本是4.0以下的，需要在redis-cli 工具上输入shutdown save命令，让Redis数据库执行保存操作并关闭Redis服务，再重启服务器。Redis服务器重启后，Redis 会将没用的内存归还给操作系统，碎片率会降下来。
Redis4.0版本开始，可以在不重启的情况下，线上整理内存碎片，将未使用的内存归还给操作系统。
 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

 内存使用率 

redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换。

避免内存交换发生的方法：

• 针对缓存数据大小选择安装Redis 实例
• 尽可能的使用Hash数据结构存储
• 设置key的过期时间

内回收key

内存清理策略，保证合理分配redis有限的内存资源。

当内存使用达到设置的最大阈值时，需选择一种key的回收策略，默认情况下回收策略是禁止删除（noenviction）。配置文件中修改 maxmemory-policy 属性值：

vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据
 （移除最近最少使用的key，针对设置了TTL的key）
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰
 （移除最近过期的key）
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰
 （在设置了TTL的key里随机移除）
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据
 （移除最少使用的key，针对所有的key）
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）

redis的优化策略

(1)设置Redis客户端连接的超时时间 

vim /etc/redis/6379.conf
 -----114行------
 114 timeout 0     
 #单位为秒（s），取值范围为0~100000。默认值为0，表示无限制，即Redis不会主动断开连接，即使这个客户端已经空闲了很长时间。
 #例如可设置为600，则客户端空闲10分钟后，Redis会主动断开连接。
 ​
 #注意：在实际运行中，为了提高性能，Redis不一定会精确地按照timeout的值规定的时间来断开符合条件的空闲连接，例如设置timeout为10s，但空闲连接可能在12s后，服务器中新增很多连接时才会被断开。

(2) 设置 redis客户端最大连接数

 vim /etc/redis/6379.conf
 -----540行------
 540 # maxclients 10000     #若不设置，默认是10000
redis-cli info clients       #查看redis当前连接数

(3) 设置redis自动碎片清理

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

(4) 设置redis最大内存阈值 

内存阈值如果不设置，则没有限制，直到把服务器的内存干满、之后会使用交换分区。

设置内存阈值后，不会使用swap交换分区。且如果设置了key回收策略，当内存使用达到设置的最大阈值时，系统会进行key回收。

vim /etc/redis/6379.conf
 -----567行------
 567 # maxmemory
 568 maxmemory 1gb           #例如设置最大内存阈值为1gb

(5) 设置key回收策略

当内存使用达到设置的最大阈值时，需选择一种key的回收策略，默认情况下回收策略是禁止删除（noenviction）。设置key回收策略后，则当redis内存使用达到设置的最大阈值时，系统会进行key回收，释放一部分内存。

vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #需要修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据（移除最近最少使用的key，针对设置了TTL的key）
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）

在工作当中的，一定要给redis占用内存设置阀值。

redis占用的内存的效率问题如何解决：

1、日常巡检当中，对redis的占用情况做监控
2、设置redis占用系统内存的阀值，避免占用系统全部内存
3、内存碎片清理，手动自动。
4、配置合适的key回收机制。

redis雪崩、穿透、击穿的原因和解决方案

(1) redis雪崩

定义：缓存雪崩是指大量的应用请求无法在 Redis 缓存中进行处理，紧接着，应用将大量请求发送到数据库层，导致数据库层的压力激增。 

一个简单的雪崩过程：

Redis 集群产生了大面积故障；

缓存失败，此时仍有大量请求去访问 Redis 缓存服务器；

在大量 Redis 请求失败后，这些请求将会去访问数据库；

由于应用的设计依赖于数据库和 Redis 服务，很快就会造成服务器集群的雪崩，最终导致整个系统的瘫痪。

产生的原因：

(1）缓存中有大量数据同时过期，导致大量请求无法得到处理。

(2）Redis 缓存实例发生故障宕机了

(3) 集群大规模故障

解决方案： 

【事前】高可用缓存：高可用缓存是防止出现整个缓存故障。即使个别节点，机器甚至机房都关闭，系统仍然可以提供服务，Redis 哨兵(Sentinel) 和 Redis 集群(Cluster) 都可以做到高可用；

【事中】缓存降级（临时支持）：当访问次数急剧增加导致服务出现问题时，我们如何确保服务仍然可用。在国内使用比较多的是 Hystrix，它通过熔断、降级、限流三个手段来降低雪崩发生后的损失。只要确保数据库正常，系统总可以响应请求。

【事后】Redis备份和快速预热：Redis数据备份和恢复、快速缓存预热。

(2）redis 击穿

 缓存击穿是指当前热点数据存储到期时，多个线程同时并发访问热点数据。因为缓存刚过期，所有并发请求都会到数据库中查询数据。

解决方法：

• 将热点数据设置为永不过期；

• 加互斥锁：互斥锁可以控制查询数据库的线程访问，但这种方案会导致系统的吞吐量下降，需要根据实际情况使用。

(3）缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起id为-1的数据或者特别大的不存在的数据。有可能是黑客利用漏洞攻击从而去压垮应用的数据库。 

验证拦截：接口层进行校验，如鉴定用户权限，对ID之类的字段做基础的校验，如id<=0的字段直接拦截；
缓存空数据：当数据库查询到的数据为空时，也将这条数据进行缓存，但缓存的有效性设置得要较短，以免影响正常数据的缓存；
使用布隆过滤器：布隆过滤器是一种比较独特数据结构，有一定的误差。当它指定一个数据存在时，它不一定存在，但是当它指定一个数据不存在时，那么它一定是不存在的。