🚄【Redis 基础指南】推荐给大家的「主从模式」+「缓存穿透」的学习小贴士（提炼优化）

Redis 缓存穿透

redis 缓存穿透：前提-访问 redis 中不存在的 key 时，会查询数据库；当大量请求同时查询一个 redis 中不存在的 key 时，就会查询数据库，导致在那个时刻超出数据库的负载能力，严重的导致宕机，这个时候缓存其实就失效了。

图解：

Redis 缓存穿透解决方案

布隆过滤器

布隆过滤器（英语：Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

原理

当一个元素被加入集合时，通过 K 个散列函数将这个元素映射成一个位数组中的 K 个点，把它们置为 1。检索时，我们只要看看这些点是不是都是 1 就（大约）知道集合中有没有它了：如果这些点有任何一个 0，则被检元素一定不在；如果都是 1，则被检元素很可能在。这就是布隆过滤器的基本思想。

Redis 缓存雪崩与预防

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如 DB)带来很大压力，造成数据库后端故障，从而引起应用服务器雪崩。

预防方案

1. 避免缓存集中失效，不同的 key 设置不同的超时时间

2. 增加互斥锁，控制数据库请求，重建缓存。

3. 提高缓存的 HA，如：redis 集群。

multiple-Get 查询优化

底层使用的是 redis 的 mget 命令，可以根据一个 key 集合查询使用 mget 命令。redis 的 client 跟 redisserver 使用 socket 通信的，get 命令会查一个 key 就建立一个连接，查完关闭，而 mget 命令则会一个连接查一批。

pipeline 批量查询

Pipeline 允许客户端可以一次发送多条命令，而不等待上一条命令执行的结果。不仅减少了 RTT，同时也减少了 IO 调用次数（IO 调用涉及到用户态到内核态之间的切换）

Redis 的主从模式

概念图解

主从模式是 redis 常用的集群部署方式，通常都是一主二从。一主二从：

一主多从

主从的原理：在 redis 从节点上线后，会发送 ping 命令给主节点，这时候主节点会通过网络传输的方式将当前内存 RDB 文件发送到从节点所在的服务器上，从节点下载 RDB 文件，然后从自己硬盘上的 RDB 文件进行恢复数据，在恢复数据的过程中，如果主节点有数据写入，主节点会将写命令放在缓冲区，在从节点完成数据恢复后，主节点会将缓冲区中的数据发送给从节点，这样就保证了主从节点的数据一致性。由于主节点只负责写命令，而从节点负责读命令，所以永远只会读到从节点的数据。

配置操作

1. 查看下当前 redis 节点的 replication 信息 redis-cli 上输入info replication命令，下图可见当前 redis 节点的 role 是一个 master，同时连在上面的从节点有一个。主节点 repliaction 信息：

2. 

3. 下图是从节点的一些信息，可以看出来当前 redis 节点的 role 是一个 slave，同时 master 主节点的连接状态是 up。从节点 replication 信息：

4. 

上面是 redis 搭建好以后的信息，下面是搭建 redis 主从模式的步骤

2. 修改从节点 redis 的 redis.conf 文件搜索：replication，找到下图的位置。

3. 

4. 添加上图的两行，分别代表主节点的 ip/port 和 主节点的连接密码，配置完成后，当前从节点会自动像主节点进行注册连接。一般而言，slave 节点只允许读操作，不允许写操作，写操作只能从 master 节点，所以需要关闭 slave 节点的写操作权限（一般默认是关闭）。如下图：

配置完后重启 slave 节点 redis，就成功了！！

Redis 无磁盘化复制数据

一般而言，rerdis 主从模式，slave 节点同步 master 节点的数据是 master 节点通过网络把 RDB 文件传输到 slave 节点的硬盘上，然后 slave 节点再同步硬盘上的 RDB 文件。由于数据的复制通过硬盘的 IO 操作了，可能由于硬盘只是普通的机械硬盘，速度相对而言会慢，所以 redis 又提供一种无磁盘化的复制方法，将 RDB 文件通过发送到 slave 节点 socket 上，不经过磁盘的持久化。

原理 master 节点会创建一个子进程，在等待一定时间后（目的是等待 slave 节点连接上来）将 RDB 文件发送到 slave 节点的 socket 上。所以，redis 配置文件中有两个配置项，一个是打开无磁盘化复制数据的功能开关，一个是配置发送等待时间的，如下图：

等待时长：单位是 s

Redis 哨兵机制与实现

哨兵机制的作用

哨兵是一个独立的进程，用于监听 redis 集群中 redis 的存活状态，是 redis 高可用的解决方案。一个哨兵可以监控多个 master 节点以及下面的 slave 节点，当 master 节点宕机后，所有的哨兵会通过选举机制，先选举出一个哨兵 leader，有哨兵 leader 做故障转移，选举出一个新的 master 节点，保证集群的高可用性

哨兵机制的特性

• 选举机制：当一定数量（这个数量可配置）的哨兵认为 master 节点宕机后，哨兵集群就会选出一个哨兵 leader，leader 就会从剩余的 slave 节点中选举出一个新的 master

• 当老的 master 节点恢复后，它会变成 slave 节点

配置哨兵

配置哨兵的数量一般会是奇数个，这样选举机制就是属于少数服从多数的策略修改 redis 文件中的 sentinel.conf 文件

# 允许非哨兵进程所在本机访问哨兵protected-mode no# 哨兵进程占用的端口port 26379# 哨兵进程是否后台运行daemonize yes# 哨兵进程pid文件---存哨兵进程的进程id，默认就行，不用管它pidfile /var/run/redis-sentinel.pid# 哨兵日志文件地址logfile /usr/local/redis/log/sentinel.log# 哨兵进程工作空间dir /usr/local/redis-config/sentinel-working#哨兵监控的master节点信息 mymaster--master节点name（随便配）后面是ip+port，最后的数字代表当master宕机后，多少哨兵认为master宕机了，哨兵集群才统一认为master宕机sentinel monitor <mymaster> <127.0.0.1> <6379> <2># master节点name和密码sentinel auth-pass <mymaster> <password># 哨兵多久连不上master节点，认为节点宕机，默认30ssentinel down-after-milliseconds <mymaster> 30000# 选举出新master后，剩余slave节点同步master节点数据的并行度，1代表剩余slave节点一台一台同步数据sentinel parallel-syncs <mymaster> <1># 哨兵故障转移执行等待时间，默认3分钟，防止哨兵在故障转移时宕机，出现没有进行转移的问题sentinel failover-timeout <mymaster> <180000>

上面是实现哨兵需要配置一些配置项。配置完成后记得将 sentinel 的工作空间文件夹创建下，不然启动哨兵会报错。

启动哨兵命令：

redis-sentinel <配置文件全路径>tail -f <哨兵 log 全路径>---查看哨兵日志

测试：停掉 master 节点，查看哨兵日志

哨兵相关 FAQ

master 节点恢复成 slave 后，不同步新 master 的数据，master_link_status:down

• 原 master 节点 redis.conf 文件中未设置 masterauth，导致 master 成为 slave 节点后，连不上新 master 节点

• 一般 master 数据无法同步给 slave 的方案检查为如下：网络通信问题，要保证互相 ping 通，内网互通。关闭防火墙，对应的端口开发（虚拟机中建议永久关闭防火墙，云服务器的话需要保证内网互通）。统一所有的密码，master 节点和 slave 节点密码一样，不要漏了某个节点没有设置。

部署约定

• 哨兵节点至少是 3 个或者奇数个

• 哨兵分布式部署在不同的计算机节点

• 一组哨兵只监听一组主从