Redis缓存穿透
redis缓存穿透：前提-访问redis中不存在的key时，会查询数据库；当大量请求同时查询一个redis中不存在的key时，就会查询数据库，导致在那个时刻超出数据库的负载能力，严重的导致宕机，这个时候缓存其实就失效了。
图解：
Redis缓存穿透解决方案
布隆过滤器
布隆过滤器（英语：Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
原理
当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。
Redis缓存雪崩与预防
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力，造成数据库后端故障，从而引起应用服务器雪崩。
预防方案
- 避免缓存集中失效，不同的key设置不同的超时时间
- 增加互斥锁，控制数据库请求，重建缓存。
- 提高缓存的HA，如：redis集群。
Redis的主从模式
概念图解
主从模式是redis常用的集群部署方式，通常都是一主二从。 一主二从：
一主多从
主从的原理：在redis从节点上线后，会发送ping命令给主节点，这时候主节点会通过网络传输的方式将当前内存RDB文件发送到从节点所在的服务器上，从节点下载RDB文件，然后从自己硬盘上的RDB文件进行恢复数据，在恢复数据的过程中，如果主节点有数据写入，主节点会将写命令放在缓冲区，在从节点完成数据恢复后，主节点会将缓冲区中的数据发送给从节点，这样就保证了主从节点的数据一致性。 由于主节点只负责写命令，而从节点负责读命令，所以永远只会读到从节点的数据。
配置操作
- 查看下当前redis节点的replication信息 redis-cli上输入
info replication命令，下图可见当前redis节点的role是一个master，同时连在上面的从节点有一个。 主节点repliaction信息：
下图是从节点的一些信息，可以看出来当前redis节点的role是一个slave，同时master主节点的连接状态是up。 从节点replication信息：
上面是redis搭建好以后的信息，下面是搭建redis主从模式的步骤
- 修改从节点redis的redis.conf文件 搜索：replication，找到下图的位置。
添加上图的两行，分别代表主节点的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节点，认为节点宕机，默认30s sentinel 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
1.原master节点redis.conf文件中未设置masterauth，导致master成为slave节点后，连不上新master节点
一般master数据无法同步给slave的方案检查为如下： 网络通信问题，要保证互相ping通，内网互通。 关闭防火墙，对应的端口开发（虚拟机中建议永久关闭防火墙，云服务器的话需要保证内网互通）。 统一所有的密码，master节点和slave节点密码一样，不要漏了某个节点没有设置。
部署约定
- 哨兵节点至少是3个或者奇数个
- 哨兵分布式部署在不同的计算机节点
- 一组哨兵只监听一组主从
