Redis（九）------哨兵模式、缓存穿透和雪崩

15、哨兵模式

参考博客：Redis哨兵（Sentinel）模式 - 简书 (jianshu.com)

15.1 概述

Redis2.8起正式提供了Sentinel（哨兵模式）
主从切换技术的方法是：当主机服务器宕机后，需要手动把一台服务器切换为主服务器，是需要人为干预的，费时费力，还会造成一段时间内服务不可用。不推荐这种方式，所以大多时候考虑使用哨兵模式
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行
原理：哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

在这里插入图片描述

哨兵有两个作用：
- 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
- 当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，可以使用多个哨兵进行监控
各个哨兵之间还会进行监控，这样就形成了多哨兵模式

在这里插入图片描述

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover（故障转移）过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，哨兵之间就会进行一次投票，投票结果由一个哨兵发起，进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线

15.2 测试

目前服务器的状态是一主二从
配置哨兵配置文件：sentinel.conf

# sentinel monitor 被监控的服务器 host（主服务器IP） port（主服务器端口号） 1
# 数字1代表，主机宕机，slave投票看让谁接替成为主机，票数最多的，会成为主机
sentinel monitor myredis 127.0.0.1 6379 1

启动哨兵模式：redis-sentinel xxx（文件夹名）/sentinel.conf

[root@iz2ze0l46im3eg03queta2z bin]# redis-sentinel myredisconfig/sentinel.conf 
26866:X 04 Nov 2020 16:47:08.573 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
26866:X 04 Nov 2020 16:47:08.573 # Redis version=6.0.9, bits=64, commit=00000000, modified=0, pid=26866, just started
26866:X 04 Nov 2020 16:47:08.573 # Configuration loaded
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.0.9 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 26866
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

26866:X 04 Nov 2020 16:47:08.574 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
26866:X 04 Nov 2020 16:47:08.576 # Sentinel ID is 276060e845a7365dbef0fe397a9c4907dab24e90
26866:X 04 Nov 2020 16:47:08.576 # +monitor master myredis 127.0.0.1 6379 quorum 1
26866:X 04 Nov 2020 16:47:08.577 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
26866:X 04 Nov 2020 16:47:08.579 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379

此时，哨兵成功监视主机6379，当断开主机后，会在从机中利用投票算法选出一个新主机

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r6VSMt8p-1648209734594)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20220325143606754.png)]$

15.3 哨兵模式的优缺点

优点：
- 哨兵集群，基于主从复制模式，所有主从复制的优点，它都有
- 主从可以切换，故障可以转移，系统的可用性更好
- 哨兵模式是主从模式的升级，从手动到自动，系统更加健壮
缺点：
- Redis不容易在线扩容，集群数量一旦达到上限，在线扩容就十分麻烦
- 实现哨兵模式的配置其实是很麻烦的，里面有很多配置项

15.4 哨兵模式全部配置

哨兵模式配置文件：sentinel.conf

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
# 这个数字越小，完成failover所需的时间就越长，
# 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
# 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
# 2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
# 3.当想要取消一个正在进行的failover所需要的时间。  
# 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
# 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
# 通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
# 这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
# 一个是事件的类型，
# 一个是事件的描述。
# 如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
# 通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

16、缓存穿透和雪崩

16.1 服务的高可用问题

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。同时，他也带来了一些问题。其中，最要害的问题，是数据的一致性问题（事务在运行时不能保证原子性），从严格意义上讲，这个问题无解。
如果对数据的一致性要求很高，就不能使用缓存
其他典型问题：缓存穿透、缓存雪崩和缓存击穿。目前，也都有比较流行的解决方案

在这里插入图片描述

16.2 缓存穿透

查不到数据导致的

16.2.1 概述

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中于是向持久层数据库查询。发现也没有，本次查询失败
当用户很多的时候，缓存都没有命中（秒杀），于是都去请求了持久层数据库，这会给持久层数据库造成很大的压力，这种时候就相当于出现了缓存穿透。数据库也查不到就没有缓存，就会一直进行数据库访问

16.2.2 解决方案

布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以Hash的形式存储，以便快速确定是否存在这个值，在控制层先进行拦截校验，校验不通过直接打回，减轻了存储系统的压力

在这里插入图片描述

缓存空对象

当存储层不命中后，及时返回的空对象也将其缓存起来，同时设置一个过期时间，之后在访问这个数据将会从缓存中获取，保护了后端数据源。也就是一次请求若在缓存和数据库中都没找到，就在缓存中放一个空对象用于处理后续这个请求

在这里插入图片描述

这种方法会存在两个问题：
- 如果空置能够被缓存起来，就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多空值的键
- 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据有一段时间窗口的不一致，这对于需要保存一致性的业务会有影响

16.3 缓存击穿（量太大，缓存过期）

查询量太大，缓存过期导致的

16.3.1 概述

相较于缓存穿透，缓存击穿的目的性更强，一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增，会穿破缓存。这就是缓存击穿，只是针对其中某个key的缓存不可用而导致击穿，但是其他的key依然可以使用缓存响应

16.3.2 解决方案

设置热点数据永不过期：这样就不会出现热点数据过期的情况，但是当Redis内存空间满的时候也会清理部分数据，而且此种方案会占用空间，一旦热点数据多了起来，就会占用部分空间
加互斥锁（分布式锁）：在访问key之前，采用SETNX（set if ont exist）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。保证同时刻只有一个线程访问。这样对锁的要求就十分高

16.4 缓存雪崩

16.4.1 概述

缓存雪崩是指缓存层出现了错误，不能正常工作了。于是所有的请求都会达到存储层，存储层的调用量都会暴增，造成存储层也会挂掉的情况，如此大量的key设置了相同的过期时间，倒是缓存存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩

在这里插入图片描述

16.4.2 解决方案

redis高可用：既然redis有可能宕机，就多增设几台redis，这样，一台宕机之后，其他的还可以继续工作，其实就是搭建的集群
限流降级：在缓存失效后，通过加锁或者队列来控制读取数据库写缓存的线程数量。例如：对某个key只允许一个线程查询数据和写缓存，其他线程等待
数据预热：数据预热的含义就是在正式部署前，先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前，手动触发加载缓存的不同key，设置不同的过期时间，让缓存失效的时间点尽量均匀

Redis（九）------哨兵模式、缓存穿透和雪崩

Redis（九）------哨兵模式、缓存穿透和雪崩

15、哨兵模式

15.1 概述

15.2 测试

15.3 哨兵模式的优缺点

15.4 哨兵模式全部配置

16、缓存穿透和雪崩

16.1 服务的高可用问题

16.2 缓存穿透

16.2.1 概述

16.2.2 解决方案

布隆过滤器

缓存空对象

16.3 缓存击穿（量太大，缓存过期）

16.3.1 概述

16.3.2 解决方案

16.4 缓存雪崩

16.4.1 概述

16.4.2 解决方案

猜你喜欢