共计 3370 个字符，预计需要花费 9 分钟才能阅读完成。
Redis 缓存穿透
redis 缓存穿透：前提 - 拜访 redis 中不存在的 key 时，会查询数据库；当大量申请同时查问一个 redis 中不存在的 key 时，就会查询数据库，导致在那个时刻超出数据库的负载能力，重大的导致宕机，这个时候缓存其实就生效了。
图解：
Redis 缓存穿透解决方案
布隆过滤器
布隆过滤器（英语：Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器能够用于检索一个元素是否在一个汇合中。它的长处是空间效率和查问工夫都远远超过个别的算法，毛病是有肯定的误识别率和删除艰难。
原理
当一个元素被退出汇合时，通过 K 个散列函数将这个元素映射成一个位数组中的 K 个点，把它们置为 1。检索时，咱们只有看看这些点是不是都是 1 就（大概）晓得汇合中有没有它了：如果这些点有任何一个 0，则被检元素肯定不在；如果都是 1，则被检元素很可能在。这就是布隆过滤器的根本思维。
Redis 缓存雪崩与预防
当缓存服务器重启或者大量缓存集中在某一个时间段生效，这样在生效的时候，也会给后端系统 (比方 DB) 带来很大压力，造成数据库后端故障，从而引起应用服务器雪崩。
预防计划
- 防止缓存集中生效，不同的 key 设置不同的超时工夫
- 减少互斥锁，管制数据库申请，重建缓存。
- 进步缓存的 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 文件进行复原数据，在复原数据的过程中，如果主节点有数据写入，主节点会将写命令放在缓冲区，在从节点实现数据恢复后，主节点会将缓冲区中的数据发送给从节点，这样就保障了主从节点的数据一致性。因为主节点只负责写命令，而从节点负责读命令，所以永远只会读到从节点的数据。
配置操作
-
查看下以后 redis 节点的 replication 信息 redis-cli 上输出
info replication命令，下图可见以后 redis 节点的 role 是一个 master，同时连在下面的从节点有一个。主节点 repliaction 信息：2. 下图是从节点的一些信息，能够看进去以后 redis 节点的 role 是一个 slave，同时 master 主节点的连贯状态是 up。从节点 replication 信息：
下面是 redis 搭建好当前的信息，上面是搭建 redis 主从模式的步骤
2. 批改从节点 redis 的 redis.conf 文件搜寻：replication，找到下图的地位。
3. 增加上图的两行，别离代表主节点的 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 个或者奇数个
- 哨兵分布式部署在不同的计算机节点
-
一组哨兵只监听一组主从
本文由博客一文多发平台 OpenWrite 公布！