doc/后端/redis/5.redis哨兵模式.md

Redis集群高可用环境

---

Redis主从复制

基本概念：

单个Redis如果因为某种原因宕机的话，可能会导致Redis服务不可用，可以使用主从复制实现一主多从，主节点负责写的操作，从节点负责读的操作，主节点会定期将数据同步到从节点中，保证数据一致性的问题。

主从复制数据同步的过程--首次全量，后面增量

1. Redis从节点向主节点建立socket长连接

2. Redis采用全量或者增量的形式将数据同步给从节点

从Redis2.8版本以后 过程采用增量和全量同步

全量复制：一般用于在初次的复制场景（从节点与主节点一次建立），发送二进制rdb文件

增量复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步，使用aof日志文件进行同步

主从复制存在那些缺陷

传统的一主多从效率偏低，建议使用树状模型

如果主节点存在了问题，整个Redis环境是不可以实现写的操作，需要人工更改配置变为主操作

如何解决该问题：使用哨兵机制可以帮助解决Redis集群主从选举策略。

哨兵机制原理--哨兵之监听master，不监听slave

1. 哨兵机制每隔10s（可以配置）时间只需要配置监听我们的主节点就可以获取当前整个Redis集群的环境列表，采用info 命令形式。因为这个info可以知道你的从节点信息，递归调用直到没有从节点为止
2. 哨兵不建议是单机的，最好每个Redis节点都需要配置哨兵监听。
3. 哨兵集群原理是如何：多个哨兵都执行同一个主的master节点，订阅到相同都通道，有新的哨兵加入都会向通道中发送自己服务的信息，该通道的订阅者可以发现新哨兵的加入，随后相互建立长连接。
4. Master的故障发现：单个哨兵会向主的master节点发送ping的命令，如果master节点没有及时的响应，哨兵会认为该master节点为“主观不可用状态”会发送给其他都哨兵确认该Master节点是否不可用，当前确认的哨兵节点数（别人确定他，自己不能投给自己）>=quorum(可配置)，会实现重新选举。

只能解决选举问题，不能解决主从复制问题

redis哨兵会修改配置文件，底层原理

挂掉的节点，他不会修改redis.conf配置文件。但是也会修改哨兵的配置文件

Redis安全控制

缓存穿透--没有key

产生的背景：

缓存穿透是指使用不存在的key进行大量的高并发查询，导致缓存无法命中，每次请求都要都要穿透到后端数据库查询，使得数据库的压力非常大，甚至导致数据库服务压死；

解决方案：

1. 接口层实现api限流、用户授权、id检查等；
2. 从缓存和数据库都取不到数据的话，一样将数据库空值放入缓存中，设置30s有效期避免使用同一个id对数据库攻击压力大；
3. 布隆过滤器

缓存击穿--单个key

产生背景：

在高并发的情况下，当一个缓存key过期时，因为访问该key请求较大，多个请求同时发现缓存过期，因此对多个请求同时数据库查询、同时向Redis写入缓存数据，这样会导致数据库的压力非常大；

解决方案：

1. 使用分布式锁

保证在分布式情况下，使用分布式锁保证对于每个key同时只允许只有一个线程查询到后端服务，其他没有获取到锁的权限，只需要等待即可；这种高并发压力直接转移到分布式锁上，对分布式锁的压力非常大。

1. 使用本地锁

使用本地锁与分布式锁机制一样，只不过分布式锁适应于服务集群、本地锁仅限于单个服务使用。

1. 软过过期

设置热点数据永不过期或者异步延长过期时间；

1. 布隆过滤器

缓存雪崩--多个key

缓存雪崩指缓存服务器重启或者大量的缓存集中在某个时间段失效，突然给数据库产生了巨大的压力，甚至击垮数据库的情况。

解决思路：对不用的数据使用不同的失效时间，加上随机数