Redis(九)------哨兵模式、缓存穿透和雪崩
15、哨兵模式
15.1 概述
- Redis2.8起正式提供了
Sentinel(哨兵模式)
- 主从切换技术的方法是:当主机服务器宕机后,需要手动把一台服务器切换为主服务器,是需要人为干预的,费时费力,还会造成一段时间内服务不可用。不推荐这种方式,所以大多时候考虑使用
哨兵模式
- 哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行
- 原理:哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例
- 哨兵有两个作用:
- 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器
- 当哨兵检测到master宕机,会自动将slave切换成master,然后通过
发布订阅模式
通知其他的从服务器,修改配置文件,让他们切换主机
- 然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,可以使用多个哨兵进行监控
- 各个哨兵之间还会进行监控,这样就形成了多哨兵模式
- 假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行
failover(故障转移)
过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象称为主观下线
。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,哨兵之间就会进行一次投票,投票结果由一个哨兵发起,进行failover(故障转移)
操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线
15.2 测试
- 目前服务器的状态是一主二从
- 配置哨兵配置文件:
sentinel.conf
sentinel monitor myredis 127.0.0.1 6379 1
- 启动哨兵模式:
redis-sentinel xxx(文件夹名)/sentinel.conf
[root@iz2ze0l46im3eg03queta2z bin]
26866:X 04 Nov 2020 16:47:08.573
26866:X 04 Nov 2020 16:47:08.573
26866:X 04 Nov 2020 16:47:08.573
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ 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
26866:X 04 Nov 2020 16:47:08.576
26866:X 04 Nov 2020 16:47:08.576
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,当断开主机后,会在从机中利用投票算法选出一个新主机
15.3 哨兵模式的优缺点
- 优点:
- 哨兵集群,基于主从复制模式,所有主从复制的优点,它都有
- 主从可以切换,故障可以转移,系统的可用性更好
- 哨兵模式是主从模式的升级,从手动到自动,系统更加健壮
- 缺点:
- Redis不容易在线扩容,集群数量一旦达到上限,在线扩容就十分麻烦
- 实现哨兵模式的配置其实是很麻烦的,里面有很多配置项
15.4 哨兵模式全部配置
port 26379
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel notification-script mymaster /var/redis/notify.sh
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,设置不同的过期时间,让缓存失效的时间点尽量均匀