玩转 Elasticsearch Query DSL（一）：基础查询与复合查询

上文我们深入理解了 Elasticsearch 的架构与实现原理，通过倒排索引实现了搜索，你是否考虑过关键词的搜索中，其中关键词是如何从文档中拆分的呢？这实际上是通过分词器实现的，然而，在处理中文文本时，Elasticsearch 内置的标准分词器往往表现不佳，它会将句子逐字分割，无法理解词汇的边界，导致搜索准确率低下。

例如，句子 "我是中国人" 会被拆分为 "我"，"是"，"中"，"国"，"人" 这五个独立的字。当用户搜索 "中国" 时，可能无法精准匹配到这条文档。

IK 分词器 正是为了解决这一问题而生的。它是 Elasticsearch 的一款开源中文分词插件，提供了智能、细粒度的中文分词能力，并支持丰富的自定义词典，从而极大地提升了中文搜索的准确性和用户体验。接下来本文将手把手带你完成从 Elasticsearch 环境搭建到 IK 分词器集成的全过程。

## Elasticsearch 环境搭建

我们首先在本地搭建一个 Elasticsearch 服务，通过使用 Docker 快速部署，Docker 方式能实现环境隔离，部署简单快捷，特别适合开发和测试环境。

### 拉取并运行 Elasticsearch 容器

创建es的网络环境

```
sh

docker network create es-net
```

拉取镜像

```
sh

docker pull elasticsearch:7.16.3
```

如何选择版本

根据实际使用情况，Elasticsearch最常用的版本是7.x系列中的7.10+版本。如果有 AI 需求的，可直接选择 8.X 版本。

从各家云服务厂商的支持上可以看出：

腾讯云支持的版本:

![image.png](https://blog.liushigong.cn/static/img/0ffab8ea2484d42263894d5d437959e2.image.webp)

阿里云提供7.10.x和7.16.x版本

![image.png](https://blog.liushigong.cn/static/img/7e46f70333600ca5c8a427acbae009fd.image.webp)

华为云支持7.6.x和7.10.x版本

各大云厂商主要推广7.x版本，稳定性更有保障

执行 docker run 命令

```
sh

docker run -d \
--name elasticsearch \
-e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
-e "discovery.type=single-node" \
-v /Users/zhangni/liushiGong/docker/elasticsearch/data:/usr/share/elasticsearch/data \
-v /Users/zhangni/liushiGong/docker/elasticsearch/plugins:/usr/share/elasticsearch/plugins \
--privileged \
--network es-net \
-p 9200:9200 \
-p 9300:9300 \
elasticsearch:7.16.3
```

参数说明：

* -d：后台运行容器。
* --name elasticsearch：为容器指定一个名称。
* -p 9200:9200 -p 9300:9300：将容器的 9200（HTTP API 端口）和 9300（集群通信端口）映射到宿主机。
* -e "discovery.type=single-node"：设置为单节点模式，简化部署。
* -e "ES\_JAVA\_OPTS=-Xms512m -Xmx512m"：设置 JVM 堆内存大小，请根据你的机器资源调整。

提示

在8.x版本默认开启安全功能，添加 `-e "xpack.security.enabled=false" \` 设置禁用，仅用于测试

验证安装

容器启动后，在浏览器中访问 <http://localhost:9200> ,如果返回一个包含 cluster\_name、version 等信息的 JSON 对象，说明 Elasticsearch 已成功启动。

![image.png](https://blog.liushigong.cn/static/img/02db43df6b464665269960b4c9a27413.image.webp)

## Kibana 的安装

Kibana 是一个开源的数据分析和可视化平台，专为与 Elasticsearch 协同工作而设计。Kibana 提供了一个直观的用户界面，让用户能够快速搜索、分析和可视化存储在 Elasticsearch 中的数据。

拉取镜像，版本与 elasticsearch 保持一致

```
sh

docker pull kibana:7.16.3
```

执行 docker run 命令

```
sh

docker run -d \
--name kibana \
-e ELASTICSEARCH_HOSTS=http://elasticsearch:9200 \
--network=es-net \
-p 5601:5601 \
kibana:7.16.3
```

验证安装

容器启动后，在浏览器中访问 <http://localhost:5601> , 访问到主界面即安装成功

![image.png](https://blog.liushigong.cn/static/img/dc06c5e4f524d2993a7a8f9ecfe409b1.image.webp)

## IK 分词器的安装与配置

成功启动 Elasticsearch 与 Kibana 后，接下来我们安装 IK 分词器插件。

核心前提

核心前提：**版本匹配**。

IK 分词器的版本必须与你的 Elasticsearch 版本严格对应。例如，如果你的 Elasticsearch 是 7.16.3，那么 IK 分词器也应选择 7.16.3 版本。

下载对应版本的 IK 分词器

你可以在 IK 分词器的 GitHub Releases <https://github.com/infinilabs/analysis-ik/releases> 页面找到所有版本。

此处使用 7.16.3 版本，复制下面地址，修改为 `bin/elasticsearch-plugin install https://get.infini.cloud/elasticsearch/analysis-ik/7.16.3`

![image.png](https://blog.liushigong.cn/static/img/5336c3107b69ad45883bc8e6a6dcb30d.image.webp)

对于 Docker 安装：

```
sh

docker exec -it elasticsearch bin/elasticsearch-plugin install https://get.infini.cloud/elasticsearch/analysis-ik/7.16.3
```

或者，你也可以将下载好的 ZIP 包复制到容器的插件的挂载目录，使用 elasticsearch-plugin 脚本安装：

```
bash

./bin/elasticsearch-plugin install ./elasticsearch-analysis-ik-7.16.3.zip
```

重启 Elasticsearch，安装完成后，必须重启 Elasticsearch 服务以使插件生效。

```
sh

docker restart elasticsearch
```

验证安装

检查 IK 分词器是否加载成功，可以查看插件列表：

```
bash

./bin/elasticsearch-plugin list
```

如果输出中包含 analysis-ik，则表示安装成功。

## IK 分词器的使用与测试

IK 分词器提供了两种主要的分词模式：

* `ik_smart`：智能切分，做最粗粒度的拆分，力求准确且无冗余。例如，"中华人民共和国国歌" 会被分为 "中华人民共和国" 和 "国歌"。
* `ik_max_word`：最细粒度切分，会穷尽所有可能的词语组合。例如，"中华人民共和国国歌" 会被拆分为 "中华人民共和国"、"中华人民"、"中华"、"华人"、"人民共和国"、"人民"、"共和国"、"共和"、"和"、"国歌" 等。

### 测试分词效果

点击 Kibana 主界面上的 Dev Tools

![image.png](https://blog.liushigong.cn/static/img/07b7b989598c9483faf22cce11eb34e1.image.webp)

接下来我们可以使用 Elasticsearch 的 \_analyze API 来测试和对比分词效果。

测试ES自带的默认分词器：

```
bash

POST _analyze
{
  "text": "学习java太棒了"
}
```

![image.png](https://blog.liushigong.cn/static/img/90db048da839c43d5819eb27bf7b1135.image.webp)

默认分词器可能会将每个汉字单独分开，效果不理想。

测试 IK 分词器：

```
bash

# 使用 ik_smart 模式
POST _analyze
{
  "analyzer": "ik_smart",
  "text": "学习java太棒了"
}
```

![image.png](https://blog.liushigong.cn/static/img/df0ba246d398125246764bcdaaf72bf5.image.webp)

```
sh

# 使用 ik_max_word 模式
POST _analyze
{
  "analyzer": "ik_max_word",
  "text": "学习java太棒了"
}
```

![image.png](https://blog.liushigong.cn/static/img/57423cf14425b6b8505a0db610c11e77.image.webp)

可以清晰地看到 ik\_smart 和 ik\_max\_word 在分词粒度上的区别。

### 在索引映射中指定 IK 分词器

要让索引的字段真正使用 IK 分词器，你需要在创建索引时，在映射 (Mapping) 中明确指定。

以下是一个创建商品索引的示例，其中 skuTitle 字段使用了 ik\_smart 分词器：

```
bash

PUT /gulimall_product
{
  "mappings": {
    "properties": {
      "skuTitle": {
        "type": "text",
        "analyzer": "ik_smart",    # 索引时使用 ik_smart 分词
        "search_analyzer": "ik_smart" # 搜索时也使用 ik_smart 分词
      },
      "brandName": {
        "type": "keyword"          # keyword 类型适用于精确匹配，如品牌名
      }
      // ... 其他字段定义
    }
  }
}
```

* analyzer：指定在建立倒排索引（索引化）时对文本进行分词的器。
* search\_analyzer：指定在搜索时，对查询关键词进行分词的器。通常两者设置为一致。

## 进阶：配置 IK 分词器自定义词库

语言在不断演变，新词、网络用语、专业术语层出不穷。IK 分词器允许你通过自定义词库来识别这些词典中没有的词语，这是其强大和灵活的关键。

### 配置本地词库

IK 分词器的配置文件位于 `plugins/ik/config/` 目录下，核心文件是 IKAnalyzer.cfg.xml。

```
xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
    <comment>IK Analyzer 扩展配置</comment>
    
    <entry key="ext_dict">custom/mydict.dic;custom/single_word.dic</entry>
    
    <entry key="ext_stopwords">custom/ext_stopword.dic</entry>
</properties>
```

* ext\_dict：指定扩展词典文件路径（相对于 config 目录），每行一个词。
* ext\_stopwords：指定扩展停用词词典（如 "的"，"了"等无实际搜索意义的词）。

创建 custom/mydict.dic 文件，并加入你的新词，例如：

```
text

乔碧罗
汪汪队
区块链
```

修改配置后，需要重启 Elasticsearch。

### 配置远程词库（热更新）

对于生产环境，每次更新词库都重启服务是不可接受的。IK 分词器支持通过 HTTP 请求从远程服务器拉取词库，实现热更新。

修改 IKAnalyzer.cfg.xml：

```
xml

<properties>
    <comment>IK Analyzer 扩展配置</comment>
    
    <entry key="remote_ext_dict">http://your-nginx-server.com/dict/mydict.dic</entry>
    
    <entry key="remote_ext_stopwords">http://your-nginx-server.com/dict/stop_words.dic</entry>
</properties>
```

IK 分词器会定期（默认每分钟）向该 URL 发送 HEAD 请求，如果文件的 Last-Modified 时间戳发生了变化，它会自动重新加载词典，无需重启 Elasticsearch。

你需要在 Nginx 或其它 Web 服务器上托管你的词典文件，并确保 Elasticsearch 服务器能够访问到。

Elasticsearch 环境搭建与 IK 分词器的集成

在实际生产业务中经常会遇到高性能、高并发的查询场景，也就是需要再极短的时间内快速响应用户的查询内容，提高用户的体验性，此时就需要用到搜索技术了，接下来我们将深入了解搜索引擎的核心。

## 为什么需要搜索引擎？

在如今的互联网应用中搜索无处不在，例如在电商网站的商品列表页中，通常会有按照商品名称进行模糊搜索的需求，要求延迟低，响应迅速。

对于这种场景，最简单的做法就是写一条SQL直接进行模糊匹配，例如：

```
sql

select * from sku where name like %手机%;
```

使用 SQL 模糊查询在小型项目中可以适用，但是如果数据量非常多，那么此方式的性能会急剧下降。

想象一下，你有一个包含数百万乃至数十亿条记录的数据库（比如商品信息、日志数据）。当你想进行 **快速、灵活** 的搜索时（例如：“查找名称中带有‘手机’且价格在2000-3000元之间的**小米**商品，并按销量排序”），传统的 `SQL LIKE` 语句将会变得异常缓慢甚至无法工作。

实际上在互联网的项目中，基本上都是在海量数据中进行搜索，且搜索的关键词多种多样，SQL 语句查询是远远达不到要求的。搜索并不是简单的查询，而是一套复杂且专业的技术方案，可以解决海量数据及多维度搜索的各种难题。

## 搜索引擎的底层的算法与架构是怎样的？

搜索引擎是根据一定策略、运用特定的计算机程序从互联网上手机信息，对信息进行组织和处理后，将与用户检索相关的信息展示给用户系统。搜索引擎主要分为以下几类：

* **全文检索引擎**：对网页的文字、图片、视频和链接等内容进行检索
* **垂直搜索引擎**：对网站内垂直领域内容进行搜集和真理，如电商网站中的商品信息搜索
* **元数据搜索引擎**：对数据的数据进行搜索和处理，例文章中的字数、文件的大小等，可以看作是对数据整合后再提供给用户的搜索引擎

我们来看下可以实现搜索引擎的算法，实现上都是基于索引来的，相当于我们一本书需要先有目录，才能准确定位的去查询内容，实现的方式主要有 **正排索引、倒排索引** 两种。

索引概念

被搜索的信息称为 **文档**，而搜索的词语称为 **关键词**，文档中包含内容会被拆分成一堆关键词，如果文档包含关键词，那此文档会被检索到，如果不包含关键词在检索时被过滤。

### 正排索引 or 倒排索引？

**正排索引**

在搜索层面上，从文档映射到关键词列表的索引叫正排索引，也就是说我们首先对文档添加一个唯一的编号ID，然后对文档进行分词，建立一个文档ID和文档词语对应的哈希表, 同时保存的还有词出现的次数,位置等信息,如下图:

![image.png](https://blog.liushigong.cn/static/img/042b8b7a8561a7c52a643b45dbae5e58.image.webp)

这就是一个哈希表，key就是文档的ID，value就是一个组合结构，里面包含词语，词语频次，出现位置

如果根据文档ID搜索内容效率是极快的，但是如果想要多维度条件查询，那么只能通过全文档扫描才能找出存在对应关键词的文档，效率极低，这个时候我们就需要用到倒排索引了。

**倒排索引**

按照多维度查询来说，如果我们搜索中包含特定关键词，用正排索引，显然不合适，因为涉及到大量的遍历。那思考一下，我们需要如何调整才能最优呢？是不是可以搜索什么，就去查什么呢？从正排索引进行推导，如果我们能直接搜索关键词，通过关键词查找文档，可以在O(1)时间复杂度找到包含这个关键词的列表，是不是更快捷呢？

其实上面思考的过程，就是倒排索引的实现原理。

![image.png](https://blog.liushigong.cn/static/img/f05c1dc2aff48faaeff22810378ab653.image.webp)

倒排索引的创建过程，整体来说比较简单，主要有以下几步：

* 首先对文档进行编号，且排序，编号顺序就是文档的顺序， 不然就需要对文档进行排序。
* 遍历排序后的文档，对每个文档进行分词，生成《词语，文档ID，位置》的一组组数据，只所以保存位置是为了高亮查询的关键词，有些多个词语查询，如果两个词语靠的更近，得分会更高些。
* 将《词语，文档ID，位置》插入到以词语作为key，《文档ID，位置》作为value的哈希表中。value中也可以多存点信息，比如此在这个文档中出现的次数，这对于我们搜索后排序很有用。最后形成如上图的倒排索引，注意下，上面的倒排索引的value是个链表，而且是排序的链表（id小的在前面）。

如果只是简单的一个词语进行查找，利用倒排索引轻易查出 `posting list` 获取到文档ID，在通过文档ID把一个个查询出来的文档提取出来就可以了。

但是实际中，我们查询的关键词经常是多个，如果查询即包含 `中国` 又包含 `真气` 词语的小说，我们会得到两个 `posting list` 如下：

![image.png](https://blog.liushigong.cn/static/img/5808b369c392724ca9a33d8f74977aa1.image.webp)

如上图，查询两个关键词，我们得到两个 `posting list` 然后进行归并，由于文档是有序的，所以归并的过程性能还不错，我们通过两个指针来指向 `posting list` 的开头，然后根据比较结果移动指针，如果相同，把 docID 取出来放在结果集合中，如果不相等，小的那个指针对后移动，继续进行比较，直到一个 `posting list` 结束。

这是查询同时包含两个词的情况，还有的情况需要查询包含多个词其中之一的，或者包含A词语，却不含有B词语的无非是两个集合的 **并集，交集，差集**。

虽然上面这种归并的方法，性能还不错，但是实际工程中，需要用多种手段来优化归并的性能，因为 `posting list` 很长，如果上述的归并算法是O(m+n),仍然难以性能要求，可以通过调表，哈希表，位图等多种手段优化归并性能。

提示

可以简单理解从文章到关键词叫正排,从关键词到文章叫倒排。以这些方式建的索引分别叫正排索引和倒排索引。

这里面文档可以是一篇文章,也可以是一个网页,还可以是一本小说，这里的文档是我们定义的任何要搜索的信息

## Elasticsearch 的前世今生

要实现一个功能完善、性能强大的全文搜索引擎并不简单。在早期出现的一些开源的搜索引擎中最受欢迎的就是 Lucene，使用 Lunene 来实现搜索功能，开发者无需关心底层实现，只需要关注业务本身即可。

但是，随着微服务分布式的崛起，面对高并发的访问，需要搜索引擎能够横向扩展，且每个节点都能以近实时的速度来同步数据，并把请求按多种不同算法分发给具体的服务节点。而 Lunene 是无法满足的，因为它只是一个库，并不具备分布式的能力，因此，开发者基于 Lucene 构建了一套功能强大的搜索引擎 - Elasticsearch

![image.png](https://blog.liushigong.cn/static/img/5f67b4f95df2094e6511f1576d93bef1.image.webp)

Elasticsearch 是一个开源的分布式搜索和分析引擎，使用 Lucene 作为核心实现了索引和搜索功能，采用 REST 风格，通过简单的 RESTful API 隐藏了 Lucene 的复杂性，从而让全文搜索变得简单。

让我们来拆解这个定义：

* **基于 Lucene**：Lucene 是一个顶级的 Java 全文检索库，功能强大但 API 复杂。ES 在 Lucene 之上提供了一个更简单易用的分布式封装。
* **开源**：免费使用，社区活跃。
* **分布式**：这是 ES 的灵魂。它能将海量数据分割成多个部分（分片），存储在不同的服务器（节点）上，从而实现**水平扩展**和高可用性。
* **RESTful**：所有操作，如插入、搜索、删除，都可以通过标准的 HTTP REST API 进行。这意味着你可以用 `curl`、Kibana 或者任何 HTTP 客户端（如 Java 中的 `RestTemplate`）与之交互。
* **搜索和分析引擎**：核心能力是**搜索**（找到你想要的数据）和**分析**（从数据中提取有意义的统计信息，如月度销售额趋势）。

## 核心概念剖析

### 为什么是“分布式”的？核心架构解析

分布式是 ES 解决海量数据问题的法宝。我们来理解几个核心分布式概念：

**集群 (Cluster)**

由一个或多个具有相同 `cluster.name` 的节点组成。它们共同工作，共享数据，并提供跨节点的联合索引和搜索能力。Elasticsearch 采用的是去中心化的架构，在 Elasticsearch 集群中有很多节点，其中一个是主节点，是通过选举产生的。

**节点 (Node)**

节点即 Elasticsearch 的服务器实例，主要有一下3种类型：

* client\_node：做请求分发
* master\_node：主节点，所有的新增、删除及数据分片都是由主节点来操作的，同时也提供搜索请求功能
* data\_node：只能进行搜索操作，data\_node 的数据都是从 master\_node 同步过来的。

![image.png](https://blog.liushigong.cn/static/img/87649228df4ec61f788e39e3e1629a27.image.webp)

**分片 (Shard)**

当一个索引数据量过大时，ES 会将其切分成多个部分，每个部分就是一个**分片**。每个分片本身就是一个功能完整的 Lucene 索引，可以分布在集群中的任何节点上。

有个分片就可以横向扩展，存储更多的数据，让搜索和分析等操作分布到多台服务器上去执行，从而提升吞吐量和性能。

**副本（Replica）**：

任何一个服务器随时可能出现故障和宕机，此时分片可能会丢失。因此可以为每个分片创建多个副本。副本可以在分片出现故障时提供备用服务，保障数据不会丢失。多个副本一起使用，可以提升搜索操作的吞吐量和性能

分片和副本的区分

**分片** 和 **副本** 是 ES 分布式架构的精髓所在。

分片 Shard 分为 主分片 `Primary Shard` 和 副本分片 `Replica Shard`

`Primary Shard` 一般简称为分片 Shard； `Replica Shard` 一般简称为副本 Replica

在分片/节点宕机时，副本分片可以接管工作，防止数据丢失和服务中断。

所有的**读**操作（搜索、查询）都可以由**主分片或副本分片**处理，因此增加副本数量可以扩展搜索性能。

**一个简单的三节点集群数据分布示意图：**

![image.png](https://blog.liushigong.cn/static/img/3f2172d6398f6798e6068e32a06638b0.image.webp)

**创建索引时的关键决策**：

当你创建一个索引时（例如 `products`），你需要指定：

* `number_of_shards`：主分片的数量。**一旦设置，不可修改**。
* `number_of_replicas`：每个主分片的副本数量。这个值后续可以动态调整。

当存储容量超过 Elasticsearch 所有节点的总容量时，一般在生产中的做法是：重新简历索引（比之前多一点分片），然后导入数据。但是这种做法的缺点是，重新建立索引需要消耗时间。所以通常的做法是进行预分配。通过预分配可以完全避免这个问题。

副本分片是可以动态扩展的。在读取量很大的场景下，适当的扩充副本分片可以增加吞吐量。

**如何预估分片容量**

预估分片容量涉及的因素较多，例如硬件的容量、文件的大小和复杂度、文档的索引分析方式、运行的查询类型、执行的聚合方式，以及采用的数据模型等等。

预估分片容量的步骤如下：

1. 基于“准备用于生产环境的硬件”创建一个拥有单个节点的集群
2. 创建一个和生产环境相同配置的索引，但是让它只有一个主分片，没有副本分片。
3. 在创建的索引中添加文档
4. 运行查询和聚合
5. 利用与真实环境相同的方式，将文档全部压缩到单个分片上直到宕机

一个定义了单个分片的容量，就很容易推送出整个索引需要的分片数。用 “需要索引的数据总数” + “上一部分预期的增长” 之和，除以 “单个分片的容量”，结果就是整个索引需要的分片数。

### 如何数据建模

**文档（Document）**

文档是 Elasticsearch 的最小存储单元，一个文档可以是一条商品数据，也可以是一个订单数据，通常以 JSON 结构来表示

**索引（Index）**

索引是存储数据的合集，索引包含一堆相似结构的文档数据。每个索引都有一个唯一的名称，一个集群中可以有多个索引。

Schema-less vs 强 Schema

ES 支持动态映射，你可以在不预定义 Mapping 的情况下直接插入 JSON 文档，它会自动推断类型。但在生产环境中，**强烈建议预定义 Mapping**，以避免自动推断带来的潜在问题。

为了帮助理解，我们将其与熟悉的关系型数据库（如 MySQL）进行类比：

| Elasticsearch | MySQL | 说明 |
| --- | --- | --- |
| **索引 (Index)** | **数据库 (Database)** | 一类数据的集合，是最高层级的逻辑容器。 |
| **文档 (Document)** | **行 (Row)** | 一条完整的数据记录，是 ES 中最基本的数据单元。 |
| **字段 (Field)** | **列 (Column)** | 文档中的一个属性。 |
| **映射 (Mapping)** | **表结构 (Schema)** | 定义了索引中每个字段的数据类型（如 text, keyword, integer）和属性。 |
| **DSL (Domain Specific Language)** | **SQL** | ES 使用基于 JSON 的 DSL 来进行查询和聚合操作。 |

关于“类型 (Type)”

在 7.x 之前的版本，Index 下面还有 Type 的概念（类似数据库中的表）。但从 7.x 开始，**Type 已被废弃**，一个 Index 默认只对应一个 `_doc` Type。这是为了消除关系型数据库类比带来的误导，因为同一个 Index 下不同 Type 的字段会相互影响。

## 总结

Elasticsearch 是一个分布式搜索和分析引擎，用于处理海量数据的快速检索。分布式是其灵魂，通过分片实现水平扩展，通过副本保证高可用和提升读性能。其数据建模的核心概念可以通过与关系型数据库的类比来帮助记忆，但要注意 Type 已被废弃。

Elasticsearch 入门：从零开始理解分布式搜索引擎

总结整理了一些常见的 Redis 缓存，前面全面学习了 Redis，结合此处常见的面试题就可以进行回答了，整理自己的话术语言，做出关键词的提示构思，自信的对面试官说出来你的理解。

## 为什么要用 Redis /为什么要用缓存

主要从“高性能”和“高并发”这两点来看待这个问题

### 高性能

假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在数缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

### 高并发

直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

## Redis为什么这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；

3、使用多路 I/O 复用模型，非阻塞 IO、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；6.0版本以后使用多线程提高网络性能。

4、Redis 构建了自己的通信协议，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

## Redis 如何实现分布式锁

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。

* 当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则 SETNX 不做任何动作
* SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
* 返回值：设置成功，返回 1 。设置失败，返回 0 。
* 使用SETNX完成同步锁的流程及事项如下：
* 使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功
* 为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间
* 释放锁，使用DEL命令将锁数据删除

## 什么是 RedLock

Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：

* 安全特性：互斥访问，即永远只有一个 client 能拿到锁
* 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
* 容错性：只要大部分 Redis 节点存活就可以正常提供服务

## 缓存雪崩

缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

### 缓存雪崩常见原因

* 缓存设置了集中的过期时间：大量缓存数据设置了相同或者相似的过期时间，导致它们在同一时间段内集体过期。
* 缓存预热不充分：系统启动时缓存数据加载不充分，导致大量请求直接访问数据库。缓存服务器宕机：redis集群中，多个节点同时宕机，导致大量缓存数据不可用
* 常见一些经典场景：促销活动结束（大量商品缓存同时失效）、或者定时任务触发（比如凌晨批量更新缓存，固定过期时间触发雪崩）

### 解决方案

1. 通过分散过期时间，缓存数据的过期时间设置随机（可通过均匀设置过期时间解决，即让过期时间相对离散一点。如采用一个较大固定值+一个较小的随机值，1小时+0到100秒酱紫），防止同一时间大量数据过期现象发生，是解决缓存雪崩最简单有效的解决方案。
2. 一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。
3. Redis 故障宕机也可能引起缓存雪奔。这就需要构造Redis高可用集群啦。比如redis主从、哨兵模式、集群模式（Redis cluster）。
4. 还有最后的防线，就是限流和降级~~

## 缓存穿透

先来看一个常见的缓存使用方式：

> 读请求来了，先查下缓存，缓存有值命中，就直接返回；缓存没命中，就去查数据库，然后把数据库的值更新到缓存，再返回。

![image.png](https://blog.liushigong.cn/static/img/18018b24cdd81c27db1508a5d0ed6d6b.image.webp)

### 什么是缓存穿透问题

缓存穿透指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力，造成数据库短时间内承受大量请求而崩掉。

> 通俗点说，读请求访问时，缓存和数据库都没有某个值，这样就会导致每次对这个值的查询请求都会穿透到数据库，这就是缓存穿透。

### 缓存穿透产生原因

* 业务逻辑设计不合理: 比如大多数用户都没开守护，但是你的每个请求都去查询缓存，查询某个userid有没有开守护
* 黑客非法请求攻击：比如黑客故意捏造大量非法请求，以读取不存在的业务数据。
* 数据生命周期管理问题：某些数据被删除后，缓存没有及时更新，导致后续查询穿透。

### 解决方案

1. 用户请求进行有效性检查：它的核心思想是对请求参数进行合法性校验，提前过滤掉明显无效的请求。（主要包括数据格式校验、数据范围校验、权限校验等等）;
2. 缓存空值：如果查询数据库为空，我们可以给缓存设置个空值，或者一个特殊标记的默认值，设置一个较短的过期时间，避免频繁访问数据库。例如从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。
3. 采用布隆过滤器，快速判断数据是否存在。将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力

布隆过滤器（推荐）

就是引入了k(k>1)k(k>1)个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程。

它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

Bloom-Filter算法的核心思想就是利用多个不同的Hash函数来解决“冲突”。Hash存在一个冲突（碰撞）的问题，用同一个Hash得到的两个URL的值有可能相同。为了减少冲突，我们可以多引入几个Hash，如果通过其中的一个Hash值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的Hash函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是Bloom-Filter的基本思想。

Bloom-Filter一般用于在大数据量的集合中判定某元素是否存在。

## 缓存击穿

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库；缓存击穿导致数据库短期压力剧增；缓存雪崩则可能导致数据库被压垮。

### 缓存击穿常见原因

* 高并发场景，比如秒杀活动呀，热点新闻等管理员手动误清除：
* 运维人员误删或主动清理某个热点Key（如商品价格调整），删除后突发流量访问。

### 解决方案

1. 设置热点数据“永不过期”，是指没有设置过期时间，但是热点数据快要过期时，异步线程去更新和设置过期时间。
2. 使用互斥锁方案（对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询）

## 缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

### 解决方案

1. 直接写个缓存刷新页面或者接口，上线时手工操作一下；
2. 数据量不大，可以在项目启动的时候自动进行加载；
3. 定时刷新缓存；

## 缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

缓存降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

1. 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
2. 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
3. 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
4. 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。
   。

## 如何保证缓存与数据库双写时的数据一致性？

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？

一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况

串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。

还有一种方式就是可能会暂时产生不一致的情况，但是发生的几率特别小，就是先更新数据库，然后再删除缓存。
问题场景描述解决先写缓存，再写数据库，缓存写成功，数据库写失败缓存写成功，但写数据库失败或者响应延迟，则下次读取（并发读）缓存时，就出现脏读这个写缓存的方式，本身就是错误的，需要改为先写数据库，把旧缓存置为失效；读取数据的时候，如果缓存不存在，则读取数据库再写缓存先写数据库，再写缓存，数据库写成功，缓存写失败写数据库成功，但写缓存失败，则下次读取（并发读）缓存时，则读不到数据缓存使用时，假如读缓存失败，先读数据库，再回写缓存的方式实现需要缓存异步刷新指数据库操作和写缓存不在一个操作步骤中，比如在分布式场景下，无法做到同时写缓存或需要异步刷新（补救措施）时候确定哪些数据适合此类场景，根据经验值确定合理的数据不一致时间，用户数据刷新的时间间隔

具体详细方案可查看 [性能优化 - 保证数据的双写一致性](https://blog.liushigong.cn/post/79)

## Redis常见性能问题和解决方案？

1. Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2. 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3. 为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4. 尽量避免在压力较大的主库上增加从库
5. Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
6. 为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。

## 一个字符串类型的值能存储最大容量是多少？

512M

## Redis如何做大量数据插入？

Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入工作。

## 假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。一般生产都会禁用 keys \*

## Redis 如何处理缓存中的大 kEY?

有时候会因为业务人员使用不当，在 Redis 实例中会形成很大的对象，比如一个很大的hash，一个很大的 zset 这都是经常出现的。这样的对象对 Redis 的集群数据迁移带来了很大的问题，因为在集群环境下，如果某个 key 太大，会数据导致迁移卡顿。另外在内存分配上，如果一个 key 太大，那么当它需要扩容时，会一次性申请更大的一块内存，这也会导致卡顿。如果这个大 key 被删除，内存会一次性回收，卡顿现象会再一次产生。

**在平时的业务开发中，要尽量避免大 key 的产生。**

如果你观察到 Redis 的内存大起大落，这极有可能是因为大 key 导致的，这时候你就需要定位出具体是那个 key，进一步定位出具体的业务来源，然后再改进相关业务代码设计。

## 那如何定位大 key 呢？

为了避免对线上 Redis 带来卡顿，这就要用到 scan 指令，对于扫描出来的每一个key，使用 type 指令获得 key 的类型，然后使用相应数据结构的 size 或者 len 方法来得到它的大小，对于每一种类型，保留大小的前 N 名作为扫描结果展示出来。

上面这样的过程需要编写脚本，比较繁琐，不过 Redis 官方已经在 redis-cli 指令中提供了这样的扫描功能，我们可以直接拿来即用。

```
sh

redis-cli -h 127.0.0.1 -p 7001 –-bigkeys
```

如果你担心这个指令会大幅抬升 Redis 的 ops 导致线上报警，还可以增加一个休眠参数。

```
sh

redis-cli -h 127.0.0.1 -p 7001 –-bigkeys -i 0.1
```

上面这个指令每隔 100 条 scan 指令就会休眠 0.1s，ops 就不会剧烈抬升，但是扫描的时间会变长。

## Redis 如何保证分布式下所有节点的数据一致性？

应用 CAP 理论，redis 是保证最终一致性，在不同的数据节点下采用不同的方式进行同步：增量同步、快照同步、增加从节点全量同步、无盘复制。

### 增量同步

Redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一遍向主节点反馈自己同步到哪里了 (偏移量)。

因为内存的 buffer 是有限的，所以 Redis 主库不能将所有的指令都记录在内存 buffer 中。Redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

![image.png](https://blog.liushigong.cn/static/img/e39f1a5676a7113fbe39d1de3395d2a3.image.webp)

如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，那么当网络状况恢复时，Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉了，从节点将无法直接通过指令流来进行同步，这个时候就需要用到更加复杂的同步机制 —— 快照同步。

### 快照同步

快照同步是一个非常耗费资源的操作，它首先需要在主库上进行一次 bgsave 将当前内存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点。从节点将快照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。

### 增加从节点，全量同步

当从节点刚刚加入到集群时，它必须先要进行一次快照同步，同步完成后再继续进行增量同步。

### 无盘复制

主节点在进行快照同步时，会进行很重的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。

所以从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是指主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一遍将序列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

Redis - 面试中常见的缓存问题与方案

主从同步是 Redis 分布式的基础，由此联想到分布式理论的基础 - CAP 原理，如何保证数据一致性，但凡分布式就离不开它。Redis 的高可用离开了主从同步将无从进行，其中 Redis Cluster 集群模式的节点数据同步，也是依赖于主从同步，本文将总结主从同步到底是如何做的，Redis Cluster 集群的架构实现原理。

## 主从同步

很多企业都没有使用到 Redis 的集群，但是至少都做了主从。有了主从，当 master 挂掉的时候，运维让从库过来接管，服务就可以继续，否则 master 需要经过数据恢复和重启的过程，这就可能会拖很长的时间，影响线上业务的持续服务。

单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。

### CAP 原理

在了解 Redis 的主从复制之前，让我们先来理解一下现代分布式系统的理论基石—— CAP 原理。

CAP 原理就好比分布式领域的牛顿定律，它是分布式存储的理论基石。自打 CAP 的论文发表之后，分布式存储中间件犹如雨后春笋般一个一个涌现出来。理解这个原理其实很简单，本节我们首先对这个原理进行一些简单的讲解。

* C - Consistent ，一致性
* A - Availability ，可用性
* P - Partition tolerance ，分区容忍性

分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫着「网络分区」。

在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。

![image.png](https://blog.liushigong.cn/static/img/6173fe3a6683c26dab0228edbefed64a.image.webp)

一句话概括 **CAP 原理就是——网络分区发生时，一致性和可用性两难全**。

### 最终一致

Redis 的主从数据是异步同步的，所以分布式的 Redis 系统并不满足「一致性」要求。当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供修改服务，所以 Redis 满足「可用性」。

Redis 保证「最终一致性」，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。

### 主从同步

Redis 同步支持主从同步和从从同步，从从同步功能是 Redis 后续版本增加的功能，为了减轻主库的同步负担。后面为了描述上的方便，统一理解为主从同步。

![image.png](https://blog.liushigong.cn/static/img/b00af88468ce3c98ecbfcd61fd9df6aa.image.webp)

### 增量同步

Redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一遍向主节点反馈自己同步到哪里了 (偏移量)。

因为内存的 buffer 是有限的，所以 Redis 主库不能将所有的指令都记录在内存 buffer 中。Redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

![image.png](https://blog.liushigong.cn/static/img/e39f1a5676a7113fbe39d1de3395d2a3.image.webp)

如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，那么当网络状况恢复时，Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉了，从节点将无法直接通过指令流来进行同步，这个时候就需要用到更加复杂的同步机制 —— 快照同步。

### 快照同步

快照同步是一个非常耗费资源的操作，它首先需要在主库上进行一次 bgsave 将当前内存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点。从节点将快照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。

### 增加从节点 - 全量同步

当从节点刚刚加入到集群时，它必须先要进行一次快照同步，同步完成后再继续进行增量同步。

### 无盘复制

主节点在进行快照同步时，会进行很重的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。

所以从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是指主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一遍将序列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

### Wait 指令

Redis 的复制是异步进行的，wait 指令可以让异步复制变身同步复制，确保系统的强一致性 (不严格)。wait 指令是 Redis3.0 版本以后才出现的。

```
sh

> set key value
OK
> wait 1 0
(integer) 1
```

wait 提供两个参数，第一个参数是从库的数量 N，第二个参数是时间 t，以毫秒为单位。它表示等待 wait 指令之前的所有写操作同步到 N 个从库 (也就是确保 N 个从库的同步没有滞后)，最多等待时间 t。如果时间 t=0，表示无限等待直到 N 个从库同步完成达成一致。

假设此时出现了网络分区，wait 指令第二个参数时间 t=0，主从同步无法继续进行，wait 指令会永远阻塞，Redis 服务器将丧失可用性。

## Sentinel 哨兵模式

sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

* 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
* 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
* 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
* 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

### 哨兵的核心知识

哨兵至少需要 3 个实例，来保证自己的健壮性。

哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。

对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

## Redis Cluster

RedisCluster 是 Redis 的亲儿子，它是 Redis 作者自己提供的 Redis 集群化方案，它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。这三个节点相互连接组成一个对等的集群，它们之间通过一种特殊的二进制协议相互交互集群信息。

![image.png](https://blog.liushigong.cn/static/img/24b129fe32846aa66e68ce111178f13f.image.webp)

Redis Cluster 将所有数据划分为 16384 的 slots，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中，不需要另外的分布式存储来存储节点槽位信息。

当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息。这样当客户端要查找某个 key 时，可以直接定位到目标节点。

客户端为了可以直接定位某个具体的 key 所在的节点，它就需要缓存槽位相关信息，这样才可以准确快速地定位到相应的节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。另外，RedisCluster 的每个节点会将集群的配置信息持久化到配置文件中，所以必须确保配置文件是可写的，而且尽量不要依靠人工修改配置文件。

当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。

### 槽位定位算法

Cluster 默认会对 key 值使用 crc32 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。

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

### 容错

Redis Cluster 可以为每个主节点设置若干个从节点，单主节点故障时，集群会自动将其中某个从节点提升为主节点。如果某个主节点没有从节点，那么当它发生故障时，集群将完全处于不可用状态。不过 Redis 也提供了一个参数 cluster-require-full-coverage 可以允许部分节点故障，其它节点还可以继续提供对外访问。

### 节点间的内部通信机制

因为 Redis Cluster 是去中心化的，一个节点认为某个节点失联了并不代表所有的节点都认为它失联了。所以集群还得经过一次协商的过程，只有当大多数节点都认定了某个节点失联了，集群才认为该节点需要进行主从切换来容错。

Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。比如一个节点发现某个节点失联了 (PFail)，它会将这条信息向整个集群广播，其它节点也就可以收到这点失联信息。如果一个节点收到了某个节点失联的数量 (PFail Count) 已经达到了集群的大多数，就可以标记该节点为确定下线状态 (Fail)，然后向整个集群广播，强迫其它节点也接收该节点已经下线的事实，并立即对该失联节点进行主从切换。

### 方案说明

1.通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
2.每份数据分片会存储在多个互为主从的多节点上
3.数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
4.同一分片多个节点间的数据不保持一致性
5.读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
6.扩容时时需要需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。

16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

### 优点

* 无中心架构，支持动态扩容，对业务透明
* 具备Sentinel的监控和自动Failover(故障转移)能力
* 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
* 高性能，客户端直连redis服务，免去了proxy代理的损耗

### 缺点

* 运维也很复杂，数据迁移需要人工干预
* 只能使用0号数据库
* 不支持批量操作(pipeline管道操作)
* 分布式逻辑和存储模块耦合等

### 生产环境中的 redis 是怎么部署的？

redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。

机器是什么配置？

32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

5 台机器对外提供读写，一共有 50g 内存。

因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。

你往内存里写的是什么数据？每条数据的大小是多少？

商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。

其实大型的公司，会有基础架构的 team 负责缓存集群的运维。