主要内容：

本文主要介绍集群的工作模式、故障恢复、缓存击穿、缓存穿透、缓存雪崩等内容。

集群模式：

平时用一个服务器不是用着也挺好的吗？干嘛花钱来整整个集群呢？

所谓集群就是有很多服务器一起来提供服务，在目前高并发盛行的时代，一个服务器顶不住啊，一旦宕机，只能等到修复好才可以提供服务，用户体验极差。因此集群应运而生。

集群优势：

• 可以扩容，服务器多了，自然可存储的东西就多了

• 分摊压力

• 可以并发写

• 无中心配置相对简单

集群缺点：

• 多建操作不被支持

• 多键的 redis 事务不被支持，lua 脚本不被支持

集群的常见模式：

• 第一种比较常见的模式就是代理主机。来个图更好理解：

代理模式

以电商业务为例来说明：从图中就可以看到，每一个服务器主机都有一个从机，用户信息、订单信息、商品信息分别存储在不同的服务器中，这样就需要 8 个服务器来提供服务。使用一个代理主机来对客户端的请求进行处理，然后代理主机再分别请求不同的服务器来处理业务。从图中可以看出，这是一种中心化的服务模式，如果代理主机和从机都宕机的话，那么我们是无法再进行任何的请求的。

• 无中心化集群：

另外一种服务模式就是无中心化的模式，在这个集群中，没有哪个是主机，每一个都可以是主机。先看图：

无中心化集群

从图中可以看出，每一个服务器都有一个对应的从机，但是只需要 6 台服务器既可以满足要求。每一台服务器都可以作为服务入口，如果要查询的是订单，但是是从用户服务器进行请求的，那么用户服务器会把请求发给订单服务器，谁的活谁来干，不是我的我会转发给对应的人。目前这种无中心化的配置模式也是最流行的。

故障恢复：

如果一台主机挂掉，那么对应的从机会变为主机来提供服务，如果挂掉的主机修复好之后，那么原来的主机会变为从机来提供服务。

那如果主从机都挂了怎么办，这个时候是根据配置信息来确定的：

cluster-require-full-coverage 如果为 yes，整个集群都会挂掉，如果为 no，该插槽数据全部不能使用，也无法存储，其他的正常工作。

缓存穿透：

前情提要：一般服务器部署时会使用 Redis 来作为缓存数据库来提供服务。

现象：

• 应用服务器压力变大

• redis 命中率降低，查不到数据。换句话说就是 redis 中找不到请求的数据

• redis 中查不到数据，就会去数据库中查询

原因：

• redis 查不到数据

• 出现很多非正常 url 访问，比如数据库中就没有相关词条，然后客户端一直请求查询这个词条

看了以上内容，现在来谈谈我对缓存穿透的理解，穿透，就是 redis 查不到内容，就透过 redis 去访问数据库去了，这就是缓存穿透。

解决方案：

• 对空值进行缓存：如果一个查询返回的数据为空（不管数据是否存在）仍然把这个空结果 null 缓存起来，设置空结果的过期时间会很短，最长不超过 5 分钟。

• 通过 bitmaps 类型来定义一个可以访问的白名单

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

• 实时监控

缓存击穿：

现象：

• 数据库访问压力瞬时增大

• redis 里面并没有出现大量 key 失效的情况

• redis 还是正常运行的

原因：

redis 某个 key 过期了，但是某一时间段大量访问使用这个 key。比如某个明星离婚，其对应的 key 正好失效，但是这个时候一股脑上百万的访问量。

看了以上内容，现在来谈谈我对缓存击穿的理解：redis 是正常工作的，但是突然有一个极大的访问量在查询某个 key,不幸的的是，这个时候 redis 中对应的 key 因为失效而无法作为护盾来保护 redis 面对如此大的攻击。这个访问量就像一支箭一样穿过 redis，直达数据库。这就叫击穿

解决方案：

• 预先设置热门数据

• 实时调整

• 使用锁

缓存雪崩：

现象：

数据库压力变大，服务器崩溃

原因：

在很少时间段内，查询大量 key 的集中过期情况。大量 key 过期，就去查询数据库了

缓存雪崩这个好理解，一个时间段，大量访问去访问数据库中的大量不同的 key。不堪重负，崩溃了。

解决方案：

• 构建多级的缓存架构

• 使用锁或队列

• 设置过期标志，更新缓存

• 将缓存失效时间分散开