Redis----常见重点知识2（主从复制哨兵机制缓存穿透和雪崩）

Posted 2021-10-22 小样5411

目录

• • 一、主从复制
  • • 1.1 介绍
    • 1.2 配置
  • 二、哨兵机制
  • • 2.1 哨兵概念介绍
    • 2.2 配置哨兵
  • 三、缓存穿透与缓存雪崩
  • • 2.1 缓存穿透
    • 2.2 缓存雪崩

一、主从复制

1.1 介绍

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（主服务器master），后者成为从节点（从服务器slave）。数据复制是单向的，只能由主节点复制到从节点，主节点负责写操作，从节点负责读操作。

主从复制的作用如下：
1、数据备份：主从复制实现了数据的热备份
2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，过程就是主节点意外宕机，哨兵机制会将一台slave服务器升级为master服务器，使得工作能继续进行。
3、负载均衡：从主从复制的基础上，配合读写分离，可以由主节点提供写，从节点提供读，读写分离，这样就能分担压力，不用读写都在一个服务器上，多个服务器一起承担压力

注意：主从复制是哨兵机制和集群实施的基础（集群至少三个Redis服务器，即一主多从）

一般一台Redis服务器最大使用内存不应该超过20G，如果超过就需要分担这个压力，下图即一主三从，一般读操作占80%，所以从机一般多些

图来自狂神视频：https://www.bilibili.com/video/BV1S54y1R7SB?p=31

1.2 配置

主从结构，主是不用配的，因为默认自己是主，只要配从，我们可以启动一个redis，输入info replication可以查到主从复制信息，如下图，说明该redis服务是master，然后目前还没有slave

我们用MobaXterm再开三个服务，新的三个服务没有配置之前都是主节点，必须配置主从复制才会有主从关系

复制三份配置文件

第一个redis01.conf，需要编辑vi redis01.conf，改三个地方：端口，日志文件，rdb文件，使得三个不重名
1）改端口，第一个就是6379默认不用改,，即port 6379不改
2）搜索logfile，本来是logfile “”，现在不能日志文件每个都一样，所以需要取个名字logfile “6379.log”

3）dump.rdb也要改，不能每个都是dump.rdb，不然都重名

后面redis02.conf端口和文件都和上面一样改，不过redis02.conf改成6380即可，redis02.conf都改成6381，之后分别启动三个服务
注意：此处启动服务需要在不同主机上启动，不能在同一个主机同时启动三个服务

目前这三个认为自己都是主节点，也就是master服务器，现在就要认老大了！！！主机可以是三台中任何一台，姑且认为6379是主机，80和81是从机，然后我们就通过命令配置来实现，很简单，slaveof host port，slaveof就是从节点认老大，认了6379这个老大，因为我们是在同一个电脑打开三个所以写localhost的127.0.0.1本地，实际上公司中有多个服务器，就直接写服务器ip地址+端口即可，认完了老大，查看信息，角色就从master变为slave，并且master是谁也清清楚楚

6381这个主机也做同样操作，认6379作为主机

好了，一主二从就配好了，是不是很简单，就是slaveof host port一条命令即可，我们再看看6379的信息，它显示自己角色master，并且有两个从机

我们用命令slaveof设置主从机，这是暂时的，断开重启（shutdown）就没了，从机断开就不能获取到主机数据，要连上才能重新获取，如果想永久设置，需要改配置文件redis.conf，只要改下面两项，主机ip和port，若主机有密码再配个密码masterauth，打开注释

可以看到只有主机才能写（set），从机只能读（get），主机set的值，从机都能读到


复制原理如下

全量复制就是新连接成功将所有数据都同步

补充：slaveof no one可以手动在从机输入该命令将从机变成主机，不过现在都有哨兵机制，主机宕机会自动将从机升级为主机，不用你手动去配置，这是没有出哨兵机制以前的做法

二、哨兵机制

2.1 哨兵概念介绍

哨兵（sentinel）模式就是当主节点（master）故障宕机后，会自动选一个从节点升级为主节点，使得服务能继续进行，Redis提供了哨兵的命令，哨兵是一个独立的进程，哨兵通过发送命令，等待Redis服务器响应，从而监控多个Redis服务器

哨兵机制有以下优点：
1、集群监控：监控Redis主服务器和从服务器是否能正常工作
2、消息通知：若某个Redis实例发生故障，哨兵会发消息通知管理员
3、故障转移：若主服务器挂掉，会自动转移到从服务器上，从服务器升级为主服务器，并通知客户端新的master地址

有优点也肯定有缺点：
Redis不好在线扩容，当集群内存达到上限，扩容很麻烦

如上，redis-sentinel就是哨兵，fallover就是故障转移，一个哨兵认为主服务器宕机不会马上故障转移，要多个哨兵都认为宕机才会，比如3个哨兵中有两个都认为主服务器宕机，也就是发送的命令没有响应。投票（一种投票算法）就是投给slave服务器，哪个slave被投票数最多，哪个就升级为主服务器，然后其他从服务器再将他们认的主服务器切换到新的主服务器，简而言之就是之前大哥die了，重新认老大。

2.2 配置哨兵

在新开的主机进行配置

写入上面内容，wq保存，1表示需要1个哨兵认为主机挂了，才发生故障转移，这里测试就设置成一个，实际情况不会设置1个，应该多个哨兵认为主机挂才真的挂。我们这个sentinel.conf哨兵配置文件只配一行，因为只是演示一下，所以配最简单的，如果是集群，很多哨兵，配置就会复杂些

然后我们手动模拟master宕机，关闭前先设置一个key

关闭后（宕机），哨兵会自动去投票选举，发生故障转移（选出某个slave升级为master）

最后就投票给了6381，我们看一下，如下，确实6381升级为了master服务器，它有一个slave0，是6380

如果宕机的以前主机被工程师修复，又启动了，会自动归并到新主机下面，也就是会归并到新的master->6381下，我们来试试

哨兵会自动将其转到新的主机下，打印了下面一句话

再看下6381主机，发现确实多了6379这个slave1，简而言之，就是物是人非，重新回来只能当小弟

如果有多个哨兵，就要配置多个sentinel.conf文件，相比上面的sentinel.conf文件，还要多配一个占用的port，配置sentinel01.conf、sentinel02.conf，然后用 redis-sentinel启动文件

port 26379
sentinel monitor master 127.0.0.1 6379 2

2就是两个哨兵都认为6379挂了，才会故障转移

三、缓存穿透与缓存雪崩

2.1 缓存穿透

缓存穿透就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。

举例：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。秒杀场景也可能出现，比如缓存中存好的商品数据丢失，然后大量客户请求直接查数据库，mysql直接压力过大崩溃

如何解决？
1、缓存无效key
如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，比如set key “”，将不存在的key设置为空，并且设置一个短期限（如1分钟），但这种方案并不能从根本上解决此问题，还是会多出许多无效数据，导致无效数据占用大量空间

2、布隆过滤器
布隆过滤器是一种神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。也就是可以通过布隆过滤器判断key是否合法，不合法就过滤掉。用户请求过来会先进入布隆过滤器过滤不合法请求，请求合法才会继续在缓存查数据。

布隆过滤器能过滤绝大部分请求，为什么是绝大部分，不是所有？
答：因为布隆过滤器底层用的是哈希值进行比较，而不同数据的hash值可能相同（散列到相同位置），所以很小概率出现不合法请求却经过了布隆过滤器，但是绝大部分不合法请求都被挡住了，也就基本不会被穿透

2.2 缓存雪崩

缓存雪崩：缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。举个例子，双十一抢购一波商品，这波商品集中放到了缓存中，并设置1小时过期，1小时过后，商品缓存失效，但是仍然有许多请求，这时请求就直接落在数据库，引发雪崩。

对比：雪崩和穿透都是大量请求直接落在了数据库上，但是原因不同，穿透是大量请求的 key 根本不存在于缓存，雪崩是缓存在同一时间大面积失效（如过期）

解决方法：
1、采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用，并且还会将不常用服务关闭，让出服务资源给热点服务，如支付。
2、限流，避免同时处理大量的请求（SpringCloud）。