关于redis集群:Redis集群介绍及测试思路

作者：京东批发 李磊

Redis 集群介绍

Redis 集群个别有四种形式，别离为：主从复制、哨兵模式、Cluster 以及各大厂的集群计划。在 3.0 版本之前只反对单实例模式，3.0 之后反对了集群形式。在 3.0 之前各大厂为了解决单实例 Redis 的存储瓶颈问题各自推出了本人的集群计划，其核心思想就是数据分片，次要有客户端分片、代理分片、服务端分片。这里咱们只介绍前三种形式：主从、哨兵、Cluster。

1、主从复制

Redis 单节点的数据是存储在一台服务器上的，如果服务器呈现故障，会导致数据不可用，而且读写都是在同一台服务器上，申请量大时会呈现 I / O 瓶颈。为了防止单点故障和读写不拆散，Redis 提供了复制性能来实现 Master 中的数据向 Slave 数据库的同步。Master 能够有多个 Slave 节点，Slave 节点也能够有 Slave 节点，从节点是级联构造，如下图所示：

主从复制工作原理

个别状况下为了让数据读写拆散，Master 节点用来执行写操作，Slave 节点提供读操作，Master 执行写操作时将变动的数据同步到 Slave，其工作原理如下图所示：

Redis 主从复制基本原理有三种：全量复制、基于长连贯的命令流传、增量复制。

首先介绍一下全量复制，当主从服务器刚建设连贯的时候，会依照三个阶段实现数据的第一次同步。假如当初有实例 1（192.168.1.1）和实例 2（192.168.1.2），当咱们在实例 2 上执行“replicaof 192.168.1.1 6379”命令后，实例 2 就变成了实例 1 的从库，并开始从实例 1 上复制数据，有如下三个阶段：

第一个阶段，是主从库之间建设连贯、协商同步的过程，为全量复制做筹备。具体来说，从库给主库发送 psync 命令，示意要进行数据同步，主库依据这个命令的参数来启动复制。psync 命令蕴含了主库的 runID 和复制进度 offset 两个参数。

•runID：是每个 Redis 实例启动时主动生成的一个随机 ID，用来惟一标记这个实例。当从库和主库第一次复制时，因为不晓得主库的 runID，所以将 runID 设置为“？”。

•offset：设置为 -1，示意第一次复制。

主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库，从库收到响应后会记录下这两个参数。FULLRESYNC 响应示意第一次复制采纳的全量复制，也就是说，主库会把以后所有的数据都复制给从库。

第二个阶段，主库将所有数据同步给从库，从库收到数据后，首先清空现有数据，而后在本地实现数据加载。这个过程依赖于内存快照生成的 RDB 文件。具体来说，主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。

第三个阶段，主库会把第二阶段执行过程中新接管到的写命令，再发送给从库。具体来说，当主库实现 RDB 文件发送后，就会把此时 replication buffer 中的批改和新增操作发给从库，从库再从新执行这些操作。这样一来，主从库就实现同步了。

以上是全量复制的根本流程，一旦主从库实现了全量复制，它们之间就会始终保护一个网络连接，主库会通过这个连贯将后续陆续收到的命令操作再同步给从库，这个过程也称为 基于长连贯的命令流传，能够防止频繁建设连贯的开销。

长连贯是基于网络的，那么它就存在网络断开的危险，在 Redis2.8 之前，如果主从库在命令流传时呈现了网络闪断，那么从库会和主库从新进行一次全量复制，开销十分大。在 Redis2.8 开始，网络闪断之后，主从库会采纳 增量复制 的形式持续同步，就只会把主从网络断连期间主库收到的命令同步给从库。

增量复制外围在于 repl\_backlog\_buffer 这个缓冲区。当主从库断连后，主库会把断连期间收到的写操作命令写入 replication buffer，同时也会写入 repl\_backlog\_buffer 这个缓冲区。repl\_backlog\_buffer 是一个环形缓冲区，主库记录本人写到的地位，从库也记录本人读到的地位。主从连贯复原之后，从库首先给主库发送 psync 命令，并把本人以后的 slave\_repl\_offset 发给主库，主库会判断本人的 master\_repl\_offset 和 slave\_repl\_offset 之间的差距，一般来说 master\_repl\_offset 会大于 slave\_repl\_offset。此时，主库只用把 master\_repl\_offset 和 slave\_repl\_offset 之间的命令操作同步给从库就行。

2、哨兵模式

sentinel，中文名哨兵。Redis 的 sentinel 零碎用于治理多个 Redis 实例，该零碎次要执行以下四个工作：

1. 监控（Monitoring）：Sentinel 会一直的查看主服务器和从服务器是否失常运作。

2. 主动故障转移（Automatic failover）：当主节点不能失常工作时，哨兵会开始主动故障转移操作，它会将生效主节点的其中一个从节点降级为新的主节点，并让其余从节点改为复制新的主节点。

3. 告诉（Notification）：哨兵能够将故障转移的后果发送给客户端。

4. 配置提供者（Configuration provider）：客户端在初始化时，通过连贯哨兵来取得以后 Redis 服务的主节点地址。

其中，监控和主动故障转移性能，使得哨兵能够及时发现主节点故障并实现转移；而配置提供者和告诉性能，则须要在与客户端的交互中能力体现。

哨兵用于实现 Redis 集群的高可用性，自身也是分布式的，作为一个哨兵集群去运行。Sentinel 的过程之间应用谰言协定（gossip protocols)来接管对于主服务器是否下线的信息，并应用投票协定（agreement protocols）来决定是否执行主动故障迁徙，以及抉择哪个从服务器作为新的主服务器。上面别离介绍一下监控和主动故障转移的基本原理：

Sentinel 集群监控原理

1. 每个 Sentinel 以每秒一次的频率向它所知的主从服务器以及其它 Sentinel 实例发送一个 PING 命令。

2. 如果一个实例间隔最初一次无效回复 PING 命令的工夫超过指定的值，那么这个实例会被 Sentinel 标记为主观下线。

3. 正在监督这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器确实进入了主观下线状态。

4. 有足够数量的 Sentinel 在指定的工夫范畴内批准这一判断，那么这个主服务器被标记为主观下线。

5. 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主从服务器发送 INFO 命令。当一个主服务器被 Sentinel 标记为主观下线时，Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

6.Sentinel 和其它 Sentinel 协商主节点的状态，如果主节点处于 ODOWN（主观下线）状态，则投票主动选出新的主节点，将残余的从节点指向新的主节点进行数据复制。

7. 当没有足够数量的 Sentinel 批准主服务器 下线时，主服务器的主观下线状态就会被移除。主服务器从新向 Sentinel 的 PING 命令返回无效回复时，主服务器主观下线状态就会被移除。

哨兵是如何对 Slave 进行监控的呢？当然是通过 Master 来实现的，哨兵向 Master 发送 INFO 命令，Master 收到命令后便将 Slave 列表通知哨兵。而后哨兵依据 Slave 列表信息与每一个 Slave 建设连贯，并且依据这个连贯继续监控 Slave。

Sentinel 集群故障主动转移

故障转移简略来说有以下三个流程：

1.Sentinel 零碎筛选呈现故障的主服务器属下的其中一个从服务器，并将选中的从服务器降级为新的主服务器。

2.Sentinel 零碎向呈现故障的主服务器属下的所有从服务器发送新的复制命令，让他们成为新的主服务器的从服务器，当所有从服务器都开始复制新的主服务器时，故障转移操作执行结束。

3.Sentinel 零碎还会持续监听已下线的故障服务器，如果它从新上线时，会将它设置为新的主服务器的从服务器。

示意图

如上图所示，Server1 为 Master 节点，Server2、Server3、Server4 为主服务器 Server1 的从节点，而 Sentinel 零碎正在监督所有 4 个服务器

故障转移

如上图所示，主服务 server1 挂掉了，处于下线状态，那么 server2、server3、server4 对主服务器的复制操作将被终止，Server2 被 Sentinel 系统升级为新的 Master，而后将 Server2 和 Server3 转为新 Master 的从服务器，实现故障转移。同时持续监听已下线的 Server1。

如上图所示当 Server1 复原后，Sentinel 零碎将它设置为新的主服务器 Server2 的从服务器，集群复原原有状态。

3、Cluster 集群

Redis 的哨兵模式根本曾经能够实现高可用，读写拆散，然而在这种模式下每台 Redis 服务器都存储雷同的数据，很节约内存。所以在 redis3.0 上退出了 Cluster 集群模式，实现了 Redis 的 分布式存储，也就是说每台 Redis 节点上存储不同的内容。Redis 集群是由多个主从节点群组成的分布式服务集群，具备复制、高可用和分片个性。这种集群模式没有核心节点，可程度扩大，次要是针对海量数据、高并发、高可用的场景。

Cluster 集群模式次要有以下三个个性：

1. 分片存储：Redis3.0 退出了 Redis 的集群模式，实现了数据的分布式存储，对数据进行分片，将不同的数据存储在不同的 master 节点下面，从而解决了海量数据的存储问题。

2. 指令转换：Redis 集群采纳去中心化的思维，没有核心节点的说法，对于客户端来说，整个集群能够看成一个整体，能够连贯任意一个节点进行操作，就像操作繁多 Redis 实例一样，不须要任何代理中间件，当客户端操作的 key 没有调配到该 node 上时，Redis 会返回转向指令，指向正确的 Redis 节点。

3. 主从和哨兵：Redis 也内置了高可用机制，反对 N 个 master 节点，每个 master 节点都能够挂载多个 slave 节点，当 master 节点挂掉时，集群会晋升它的某个 slave 节点作为新的 master 节点。

如上图所示，Redis 集群能够看成多个主从架构组合起来的，每一个主从架构能够看成一个节点。

Redis 集群数据分片原理

集群的整个数据库被分为 16384 个槽（slot），数据库中的每个键都属于这 16384 个槽的其中一个，集群中的每个节点能够解决 0 个或最多 16384 个槽。

Key 与哈希槽映射过程能够分为两大步骤：

1. 依据键值对的 key，应用 CRC16 算法，计算出一个 16 bit 的值。

2. 将 16 bit 的值对 16384 执行取模，失去 0 ～ 16383 的数示意 key 对应的哈希槽。

另外，Cluster 还容许用户强制某个 key 挂在特定槽位上，通过在 key 字符串外面嵌入 tag 标记，这就能够强制 key 所挂在的槽位等于 tag 所在的槽位。

Cluster 集群申请路由形式

客户端直连 Redis 服务，进行读写操作时，若 Key 对应的 Slot 在以后直连的节点上，则可间接读写，但也有可能并不在以后直连的节点上，则通过“重定向”能力转发到正确的节点，如下图所示


和一般的查问路由相比，Redis Cluster 借助客户端实现的申请路由是一种混合模式的查问路由，它并非从一个 Redis 节点到另外一个 Redis，而是借助客户端转发到正确的节点。理论利用中，能够在客户端缓存 Slot 与 Redis 节点的映射关系，当接管到 MOVED 响应时批改缓存中的映射关系。如此，基于保留的映射关系，申请时会间接发送到正确的节点上，从而缩小一次交互，晋升效率。

那么客户端具体是怎么确定拜访的数据到底散布在哪个实例上呢？

Redis 实例会将本人的哈希槽信息通过 Gossip 协定发送给集群中其余的实例，实现了哈希槽调配信息的扩散。这样，集群中的每个实例都有所有哈希槽与实例之间的映射关系信息。在切片数据的时候是将 key 通过 CRC16 计算出一个值再对 16384 取模失去对应的 Slot，这个计算工作能够在客户端上执行发送申请的时候执行。然而，定位到槽当前还须要进一步定位到该 Slot 所在 Redis 实例。当客户端连贯任何一个实例，实例就将哈希槽与实例的映射关系响应给客户端，客户端就会将哈希槽与实例映射信息缓存在本地。当客户端申请时，会计算出键所对应的哈希槽，在通过本地缓存的哈希槽实例映射信息定位到数据所在实例上，再将申请发送给对应的实例。

这个时候大家可能会有个疑难：哈希槽与实例之间的映射关系因为新增实例或者负载平衡重新分配导致扭转了咋办？

集群中的实例通过 Gossip 协定相互传递音讯获取最新的哈希槽调配信息，然而，客户端无奈感知。Redis Cluster 提供了重定向机制：客户端将申请发送到实例上，这个实例没有相应的数据，该 Redis 实例会通知客户端将申请发送到其余的实例上。

Redis 如何告知客户端重定向拜访新实例呢？分为两种状况：MOVED 谬误、ASK 谬误。

MOVED 谬误（负载平衡，数据曾经迁徙到其余实例上）：当客户端将一个键值对操作申请发送给某个实例，而这个键所在的槽并非由本人负责的时候，该实例会返回一个 MOVED 谬误指引转向正在负责该槽的节点。

(error) MOVED 16330 172.17.18.2:6379

该响应示意客户端申请的键值对所在的哈希槽 16330 迁徙到了 172.17.18.2 这个实例上，端口是 6379。这样客户端就与 172.17.18.2:6379 建设连贯，并发送 GET 申请。同时，客户端还会更新本地缓存，将该 slot 与 Redis 实例对应关系更新正确。

ASK 谬误：如果某个 slot 的数据比拟多，局部迁徙到新实例，还有一部分没有迁徙咋办？

如果申请的 key 在以后节点找到就间接执行命令，否则就须要 ASK 谬误响应了，槽局部迁徙未实现的状况下，如果须要拜访的 key 所在 Slot 正在从从 实例 1 迁徙到 实例 2，实例 1 会返回客户端一条 ASK 报错信息：客户端申请的 key 所在的哈希槽正在迁徙到实例 2 上，你先给实例 2 发送一个 ASKING 命令，接着发送操作命令。

(error) ASK 16330 172.17.18.2:6379

比方客户端申请定位到 key 的槽 16330 在实例 172.17.18.1 上，节点 1 如果找失去就间接执行命令，否则响应 ASK 错误信息，并指引客户端转向正在迁徙的指标节点 172.17.18.2：6379

留神：ASK 谬误指令并不会更新客户端缓存的哈希槽调配信息。所以客户端再次申请 Slot 16330 的数据，还是会先给 172.17.18.1 实例发送申请，只不过节点会响应 ASK 命令让客户端给新实例发送一次申请。MOVED 指令则更新客户端本地缓存，让后续指令都发往新实例。

Cluster 集群选举算法

1. 集群的配置纪元 +1，是一个自曾计数器，初始值 0，每次执行故障转移都会 +1。

2. 检测到主节点下线的从节点向集群播送一条
CLUSTERMSG\_TYPE\_FAILOVER\_AUTH\_REQUEST 音讯，要求所有收到这条音讯、并且具备投票权的主节点向这个从节点投票。

3. 这个主节点尚未投票给其余从节点，那么主节点将向要求投票的从节点返回一条
CLUSTERMSG\_TYPE\_FAILOVER\_AUTH\_ACK 音讯，示意这个主节点反对从节点成为新的主节点。

4. 参加选举的从节点都会接管
CLUSTERMSG\_TYPE\_FAILOVER\_AUTH\_ACK 音讯，如果收集到的票 >= (N/2) + 1 反对，那么这个从节点就被选举为新主节点。

5. 如果在一个配置纪元外面没有从节点能收集到足够多的反对票，那么集群进入一个新的配置纪元，并再次进行选举，直到选出新的主节点为止。

流程如下图所示：

Cluster 集群故障转移

Redis 集群的故障转移次要有三个流程：故障检测、选主流程、故障转移，上面别离简略介绍一下。

•故障查看

一个节点认为某个节点失联了并不代表所有的节点都认为它失联了。只有当大多数负责解决 slot 的节点都认定了某个节点下线了，集群才认为该节点须要进行主从切换。Redis 集群节点采纳 Gossip 协定来播送本人的状态以及本人对整个集群认知的扭转。比方一个节点发现某个节点失联了 (PFail)，它会将这条信息向整个集群播送，其它节点也就能够收到这个节点的失联信息。

如果一个节点收到了某个节点失联的数量 (PFail Count) 曾经达到了集群的大多数，就能够标记该节点为确定下线状态 (Fail)，而后向整个集群播送，强制其它节点也接管该节点曾经下线的事实，并立刻对该失联节点进行主从切换。

•选主流程

参考上一节的“Cluster 集群选举算法”

•故障转移

当一个 Slave 发现自己的主节点进入已下线状态后，从节点将开始对下线的主节点进行故障转移。

1. 从下线的 Master 节点的 Slave 节点列表抉择一个节点成为新主节点。

2. 新主节点会撤销所有对已下线主节点的 slot 指派，并将这些 slots 指派给本人。

3. 新的主节点向集群播送一条 PONG 音讯，这条 PONG 音讯能够让集群中的其余节点立刻晓得这个节点曾经由从节点变成了主节点，并且这个主节点曾经接管了本来由已下线节点负责解决的槽。

4. 新的主节点开始接管解决槽无关的命令申请，故障转移实现。

Cluster 集群扩容与缩容

扩容

Redis 集群次要有两种扩容形式：垂直扩容和程度扩容。

垂直扩容：减少内存形式来减少缓存实例的零碎容量，比方从 2G 减少到 4G。

程度扩容：通过减少节点的形式来减少整个缓存零碎的容量。

垂直扩容比拟不便，然而受制于机制内存的限度，一个机器不可能有限增大内存，所以到了肯定阶段必定要进行程度扩容。上面咱们次要讲一下程度扩容。

程度扩容又有两种形式：1、主节点数量不变；2、减少主节点数量

1、主节点数量不变：比方，以后有一台物理机 A，构建了一个蕴含 3 个 Redis 实例的集群；扩容时，咱们新增一台物理机 B，拉起一个 Redis 实例并退出物理机 A 的集群；B 上 Redis 实例对 A 上的一个主节点进行复制，而后进行主备倒换；如此，Redis 集群还是 3 个主节点，只不过变成了 A2-B1 的构造，将一部分申请压力分担到了新增的节点上，同时物理容量下限也会减少，次要步骤如下：

1. 将新增节点退出集群；

2. 将新增节点设置为某个主节点的从节点，进而对其进行复制；

3. 进行主备倒换，将新增的节点调整为主。

2、减少主节点数量：不减少主节点数量的形式扩容比较简单，然而，从负载平衡的角度来看，并不是很好的抉择。例如，如果主节点数量较少，那么单个节点所负责的 Slot 的数量必然较多，很容易呈现大量 Key 的读写集中于多数节点的景象，而减少主节点的数量，能够更无效的摊派拜访压力，充分利用资源。次要步骤如下：

1. 将新增节点退出集群；

2. 将集群中的局部 Slot 迁徙至新增的节点。

缩容

•如果下线的是 slave，那么告诉其余节点遗记下线的节点

•如果下线的是 master，那么将此 master 的 slot 迁徙到其余 master 之后，告诉其余节点遗记此 master 节点

•其余节点都遗记了下线的节点之后，此节点就能够失常进行服务了

Redis 集群测试思路及常见问题

集群搭建好之后，就能够对集群的各种性能和应用进行测试了。个别咱们会从两个方面来制订测试计划：1、集群功能测试；2、集群调优测试

1、集群功能测试

集群功能测试属于最根本的测试，是为了验证集群所提供的各种性能是否能失常应用，次要有以下方面的内容：

•主从节点的数据备份是否失常

•主从节点的切换性能是否失常

•监控及故障转移性能是否失常

•集群扩缩容性能是否失常

集群的功能测试相似于黑盒测试，内容比较简单，在这里咱们就不开展介绍了，上面次要介绍一下集群在应用过程中的调优测试。

2、集群调优测试

集群调优测试，是为了验证集群在提供服务时，如何最大限度防止因各种异样导致数据失落或者缓存性能生效，提前对配置进行调优或者提前预案，从而保障缓存架构设计是最优的。须要留神的点次要有：集群脑裂、缓存穿透、缓存击穿、缓存雪崩、缓存预热、缓存降级、缓存更新，上面别离介绍一下定义以及解决方案。

集群脑裂

定义

当 Redis 主从集群环境呈现两个主节点为客户端提供服务，这时客户端申请命令可能会产生数据失落的状况。脑裂产生的场景次要有两个：

1. 如果哨兵正在进行选举，故障转移的过程中原主节点复原和客户端的通信，那么证实原主节点没有真正的故障，这时客户端仍旧能够向原主节点失常通信，然而当故障转移完结后，就又产生了一个主节点，这就是脑裂产生的第一个场景，如下图所示：


2. 网络分区，主节点和客户端，哨兵和从库宰割为了两个网络，主库和客户端处在一个网络中，从库和哨兵在另外一个网络中，此时哨兵也会发动主从切换，呈现两个主节点的状况，如下图所示：


脑裂呈现后带来最重大的结果就是数据失落，为什么会呈现数据失落的问题呢？

次要起因是新主库确定后会向所有的实例发送 slave of 命令，让所有实例从新进行全量同步，而全量同步首先就会将实例上的数据先清空，所以在主从同步期间在原主库执行的命令将会被清空（下面场景二是同样的情理，在网络分区复原后原主节点将被降级为从节点，并且执行全量同步导致数据失落），所以这就是数据失落的具体起因，如下图所示：

解决方案

应答脑裂的解决办法应该是去限度原主库接管申请，Redis 提供了两个配置项：

1.min-replicas-to-write：主库能进行数据同步的起码从库数量，否则主节点回绝写入。

2.min-replicas-max-lag：主从库间进行数据复制时，从库给主库发送 ACK 音讯的最大提早（单位 s），否则主节点回绝写入。

这两个配置项必须同时满足，不然主节点回绝写入。

即便原主假故障，假故障期间也无奈响应哨兵心跳，也不能和从库进行同步，天然就无奈和从库进行 ACK 确认。这俩配置项组合要求就无奈失去满足，原主库就会被限度接管客户端申请，客户端也就不能在原主库中写新数据。等新主上线，就只有新主能接管和解决客户端申请，此时，新写的数据会被间接写到新主。而原主会被哨兵降为从库，即便它的数据被清空，也不会有新数据的失落。示例如下：

假如：

min-replicas-to-write=1

min-replicas-max-lag 设为 12s

哨兵的 down-after-milliseconds 设为 10s

主库因某起因卡住 15s，导致哨兵判断主库主观下线，开始进行主从切换。同时，因原主库卡住 15s，没有一个从库能和原主库在 12s 内进行数据复制，原主库也无奈接管客户端申请。主从切换实现后，也只有新主库能接管申请，不会产生脑裂，也就不会产生数据失落。

然而，在理论利用中，真的能完全避免数据的失落吗？咱们看上面的例子：

假如：

min-replicas-to-write 置 1

min-replicas-max-lag 设置为 15s

哨兵的 down-after-milliseconds 设置为 10s 哨兵主从切换须要 5s，主库因为某些起因卡住 12s，此时，还会产生脑裂吗？主从切换实现后，数据会失落吗？

主库卡住 12s，达到哨兵设定的切换阈值，所以哨兵会触发主从切换。但哨兵切换工夫 5s，即哨兵还未切换实现，主库就会从阻塞状态中复原回来，且没有触发 min-slaves-max-lag 阈值，所以主库在哨兵切换剩下的 3s 内，仍旧能够接管客户端的写操作，如果这些写操作还未同步到从库，哨兵就把从库晋升为主库了，那么此时也会呈现脑裂的状况，之后旧主库降级为从库，从新同步新主库的数据，新主库也会产生数据失落。

所以，即便 Redis 配置了 min-replicas-to-write 和 min-replicas-max-lag，当脑裂产生时，还是无奈严格保证数据不失落，只是尽量减少数据的失落。咱们须要依据被测系统的性能、网络状况、流量状况来调优这两个参数的配置，当出现异常的时候尽可能最小的缩减数据失落的工夫。

缓存穿透

定义

当查问 Redis 中没有的数据时，该查问会下沉到数据库层，同时数据库层也没有该数据，当这种状况大量呈现或被歹意攻打时，接口的拜访全副透过 Redis 拜访数据库，而数据库中也没有这些数据，咱们称这种景象为 ” 缓存穿透 ”。缓存穿透会穿透 Redis 的爱护，晋升底层数据库的负载压力，同时这类穿透查问没有数据返回也造成了网络和计算资源的节约。

解决方案

1. 在接口拜访层对用户做校验，如接口传参、登陆状态、n 秒内拜访接口的次数；

2. 利用布隆过滤器，将数据库层有的数据 key 存储在位数组中，以判断拜访的 key 在底层数据库中是否存在；核心思想是布隆过滤器，在 redis 里也有 bitmap 位图的相似实现，布隆过滤器不能实现动静删除，有工夫能够钻研下布谷鸟过滤器，是布隆过滤器加强版本。布隆过滤器有误判率，尽管不能完全避免数据穿透的景象，但曾经能够将 99.99% 的穿透查问给屏蔽在 Redis 层了，极大的升高了底层数据库的压力，缩小了资源节约。

基于布隆过滤器，咱们能够先将数据库中数据的 key 存储在布隆过滤器的位数组中，每次客户端查问数据时先拜访 Redis：

•如果 Redis 内不存在该数据，则通过布隆过滤器判断数据是否在底层数据库内；

•如果布隆过滤器通知咱们该 key 在底层库内不存在，则间接返回 null 给客户端即可，防止了查问底层数据库的动作；

•如果布隆过滤器通知咱们该 key 极有可能在底层数据库内存在，那么将查问下推到底层数据库即可；

缓存击穿

定义

缓存击穿和缓存穿透从名词上可能很难辨别开来，它们的区别是：穿透示意底层数据库没有数据且缓存内也没有数据，击穿示意底层数据库有数据而缓存内没有数据。当热点数据 key 从缓存内生效时，大量拜访同时申请这个数据，就会将查问下沉到数据库层，此时数据库层的负载压力会骤增，咱们称这种景象为 ” 缓存击穿 ”。

解决方案

•缩短热点 key 的过期工夫或者设置永不过期，如排行榜，首页等肯定会有高并发的接口；

•利用互斥锁保障同一时刻只有一个客户端能够查问底层数据库的这个数据，一旦查到数据就缓存至 Redis 内，防止其余大量申请同时穿过 Redis 拜访底层数据库；

缓存雪崩

定义

缓存雪崩是缓存击穿的 ” 大面积 ” 版，缓存击穿是数据库缓存到 Redis 内的热点数据生效导致大量并发查问穿过 redis 间接击打到底层数据库，而缓存雪崩是指 Redis 中大量的 key 简直同时过期，而后大量并发查问穿过 redis 击打到底层数据库上，此时数据库层的负载压力会骤增，咱们称这种景象为 ” 缓存雪崩 ”。

事实上缓存雪崩相比于缓存击穿更容易产生，对于大多数公司来讲，同时超大并发量拜访同一个过期 key 的场景确实太少见了，而大量 key 同时过期，大量用户拜访这些 key 的几率相比缓存击穿来说显著更大。

解决方案

1. 在可承受的工夫范畴内随机设置 key 的过期工夫，扩散 key 的过期工夫，以避免大量的 key 在同一时刻过期；

2. 对于肯定要在固定工夫让 key 生效的场景(例如每日 12 点准时更新所有最新排名)，能够在固定的生效工夫时在接口服务端设置随机延时，将申请的工夫打散，让一部分查问先将数据缓存起来；

3. 缩短热点 key 的过期工夫或者设置永不过期，这一点和缓存击穿中的计划一样；

缓存预热

如字面意思，当零碎上线时，缓存内还没有数据，如果间接提供给用户应用，每个申请都会穿过缓存去拜访底层数据库，如果并发大的话，很有可能在上线当天就会宕机，因而咱们须要在上线前先将数据库内的热点数据缓存至 Redis 内再提供进来应用，这种操作就成为 ” 缓存预热 ”。

缓存预热的实现形式有很多，比拟通用的形式是写个批工作，在启动我的项目时或定时去触发将底层数据库内的热点数据加载到缓存内。

缓存降级

•缓存降级是指当访问量剧增、服务呈现问题（如响应工夫慢或不响应）或非核心服务影响到外围流程的性能时，即便是有损局部其余服务，依然须要保障主服务可用。能够将其余主要服务的数据进行缓存降级，从而晋升主服务的稳定性。

•降级的目标是保障外围服务可用，即便是有损的。如某年双十一的时候淘宝购物车无奈批改地址只能应用默认地址，这个服务就是被降级了，这里阿里保障了订单能够失常提交和付款，但批改地址的服务能够在服务器压力升高，并发量绝对缩小的时候再复原。

•降级能够依据实时的监控数据进行主动降级也能够配置开关人工降级。是否须要降级，哪些服务须要降级，在什么状况下再降级，取决于大家对于零碎性能的取舍。

缓存更新

缓存服务（Redis）和数据服务（底层数据库）是互相独立且异构的零碎，在更新缓存或更新数据的时候无奈做到原子性的同时更新两边的数据，因而在并发读写或第二步操作异样时会遇到各种数据不统一的问题。如何解决并发场景下更新操作的双写统一是缓存零碎的一个重要知识点。

参考文档：《Redis 设计与实现》- 黄健宏著
https://www.cnblogs.com/yizhiamumu/p/16704556.htmlhttps://clo…