1. 数据聚合

聚合（ (opens new window)aggregations (opens new window)） (opens new window)可以让我们极其方便的实现对数据的统计、分析、运算

聚合常见的有三类：

• 桶（Bucket） 聚合：用来对文档做分组
  • TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
  • Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
• 度量（Metric） 聚合：用以计算一些值，比如：最大值、最小值、平均值等
  • Avg：求平均值
  • Max：求最大值
  • Min：求最小值
  • Stats：同时求max、min、avg、sum等
• 管道（pipeline） 聚合：其它聚合的结果为基础做聚合

💡注意：

• 默认情况下，Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序
• 默认情况下，Bucket聚合是对索引库的所有文档做聚合，只要添加query条件即可限定要聚合的文档范围
• Metric聚合是在桶Bucket内进行运算

2. 自动补全

当用户在搜索框输入字符时，我们应该提示出与该字符有关的搜索项;因为需要根据拼音字母来推断，因此要用到拼音分词功能

2.1 拼音分词器

要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。地址：https://github.com/medcl/elasticsearch-analysis-pinyin

2.2 自定义分词器

默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。

elasticsearch中分词器（analyzer）的组成包含三部分：

• character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符
• tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik_smart
• tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等

为了避免搜索到同音字,拼音分词器适合在创建倒排索引时使用，但搜索时不要使用拼音分词器

2.3 自动补全查询

elasticsearch提供了Completion Suggester (opens new window)查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回。

为了提高补全查询的效率，对于文档中字段的类型有一些约束：

• 参与补全查询的字段必须是completion类型。
• 字段的内容一般是用来补全的多个词条形成的数组。

3. 数据同步

elasticsearch中的数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步

3.1 数据同步方案

① 同步调用

• 优点：实现简单，粗暴
• 缺点：业务耦合度高

② 异步通知

• 优点：低耦合，实现难度一般
• 缺点：依赖mq的可靠性

③ 监听binlog

• 优点：完全解除服务间耦合
• 缺点：开启binlog增加数据库负担、实现复杂度高

4. 集群

4.1 基础概念

单机的elasticsearch做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。

• 海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点
• 单点故障问题：将分片数据在不同节点备份（replica ）

ES集群相关概念:

• 集群（cluster）：一组拥有共同的 cluster name 的 节点。
• 节点（node) ：集群中的一个 Elasticearch 实例
• 分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中 解决问题：数据量太大，单点存储量有限的问题。
• 主分片（Primary shard）：相对于副本分片的定义。
• 副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

4.2 集群脑裂问题

4.2.1 集群职责划分

🏷️ elasticsearch中集群节点有不同的职责划分：

默认情况下，集群中的任何一个节点都同时具备上述四种角色。 但是真实的集群一定要将集群职责分离：

• master节点：对CPU要求高，但是内存要求低
• data节点：对CPU和内存要求都高
• coordinating节点：对网络带宽、CPU要求高

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署。而且避免业务之间的互相干扰。

一个典型的es集群职责划分如图：

4.2.2 脑裂问题

脑裂是因为集群中的节点失联导致的。

• 例如一个集群中，主节点与其它节点失联：

• 此时，node2和node3认为node1宕机，就会重新选主：

• 当node3当选后，集群继续对外提供服务，node2和node3自成集群，node1自成集群，两个集群数据不同步，出现数据差异。

• 当网络恢复后，因为集群中有两个master节点，集群状态的不一致，出现脑裂的情况

解决方案： 要求选票超过 ( eligible节点数量 + 1 ）/ 2 才能当选为主，因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum_master_nodes，在es7.0以后，已经成为默认配置，因此一般不会发生脑裂问题

例如：3个节点形成的集群，选票必须超过 （3 + 1） / 2 ，也就是2票。node3得到node2和node3的选票，当选为主。node1只有自己1票，没有当选。集群中依然只有1个主节点，没有出现脑裂。

4.3 集群分布式存储

当新增文档时，应该保存到不同分片，保证数据均衡，那么coordinating node如何确定数据该存储到哪个分片呢？

🏷️ elasticsearch会通过hash算法来计算文档应该存储到哪个分片：

• _routing默认是文档的id
• 算法与分片数量有关，因此索引库一旦创建，分片数量不能修改！

新增文档的流程如下：

4.4 集群分布式查询

elasticsearch的查询分成两个阶段：

• scatter phase：分散阶段，coordinating node会把请求分发到每一个分片
• gather phase：聚集阶段，coordinating node汇总data node的搜索结果，并处理为最终结果集返回给用户

4.5 集群故障转移

集群的master节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。

• 例如一个集群结构如图：
• 突然，node1发生了故障：
• 宕机后的第一件事，需要重新选主，例如选中了node2：
• node2成为主节点后，会检测集群监控状态，发现：shard-1、shard-0没有副本节点。因此需要将node1上的数据迁移到node2、node3：