什么是Elasticsearch？

Elasticsearch 是一个实时的分布式存储、搜索、分析的引擎。介绍那儿有几个关键字：

实时
分布式
搜索
分析

于是我们就得知道Elasticsearch是怎么做到实时的，Elasticsearch的架构是怎么样的（分布式）。存储、搜索和分析（得知道Elasticsearch是怎么存储、搜索和分析的）

为什么要用Elasticsearch

在学习一项技术之前，必须先要了解为什么要使用这项技术。所以，为什么要使用Elasticsearch呢？我们在日常开发中，数据库也能做到（实时、存储、搜索、分析）。相对于数据库，Elasticsearch的强大之处就是可以模糊查询。有的同学可能就会说：我数据库怎么就不能模糊查询了？？我反手就给你写一个SQL：

select * from user where name like '%Java%'

的确，这样做的确可以。但是要明白的是：name like %Java%这类的查询是不走索引的，不走索引意味着：只要你的数据库的量很大（1亿条），你的查询肯定会是秒级别的.

而且，即便给你从数据库根据模糊匹配查出相应的记录了，那往往会返回大量的数据给你，往往你需要的数据量并没有这么多，可能50条记录就足够了。

而Elasticsearch是专门做搜索的，就是为了解决上面所讲的问题而生的，换句话说：

Elasticsearch对模糊搜索非常擅长（搜索速度很快）
从Elasticsearch搜索到的数据可以根据评分过滤掉大部分的，只要返回评分高的给用户就好了（原生就支持排序）
没有那么准确的关键字也能搜出相关的结果（能匹配有相关性的记录）

下面我们就来学学为什么Elasticsearch可以做到上面的几点。

Elasticsearch的数据结构

众所周知，你要在查询的时候花得更少的时间，你就需要知道他的底层数据结构是怎么样的；举个例子：

树型的查找时间复杂度一般是O(logn)
链表的查找时间复杂度一般是O(n)
哈希表的查找时间复杂度一般是O(1)
....不同的数据结构所花的时间往往不一样，你想要查找的时候要快，就需要有底层的数据结构支持

从上面说Elasticsearch的模糊查询速度很快，那Elasticsearch的底层数据结构是什么呢？我们来看看。

Elasticsearch的索引是倒排索引。

我们输入一段文字，Elasticsearch会根据分词器对我们的那段文字进行分词（也就是图上所看到的Ada/Allen/Sara..)，这些分词汇总起来我们叫做Term Dictionary，而我们需要通过分词找到对应的记录，这些文档ID保存在PostingList

在Term Dictionary中的词由于是非常非常多的，所以我们会为其进行排序，等要查找的时候就可以通过二分来查，不需要遍历整个Term Dictionary

由于Term Dictionary的词实在太多了，不可能把Term Dictionary所有的词都放在内存中，于是Elasticsearch还抽了一层叫做Term Index，这层只存储 部分词的前缀，Term Index会存在内存中（检索会特别快）

Elasticsearch的术语和架构

在讲解Elasticsearch的架构之前，首先我们得了解一下Elasticsearch的一些常见术语。

Index：Elasticsearch的Index相当于数据库的Table
Type：这个在新的Elasticsearch版本已经废除（在以前的Elasticsearch版本，一个Index下支持多个Type--有点类似于消息队列一个topic下多个group的概念）
Document：Document相当于数据库的一行记录
Field：相当于数据库的Column的概念
Mapping：相当于数据库的Schema的概念
DSL：相当于数据库的SQL（给我们读取Elasticsearch数据的API）

相信大家看完上面的对比图，对Elasticsearch的一些术语就不难理解了。那Elasticsearch的架构是怎么样的呢？下面我们来看看：

一个Elasticsearch集群会有多个Elasticsearch节点，所谓节点实际上就是运行着Elasticsearch进程的机器。

在众多的节点中，其中会有一个Master Node，它主要负责维护索引元数据、负责切换主分片和副本分片身份等工作（后面会讲到分片的概念），如果主节点挂了，会选举出一个新的主节点。

从上面我们也已经得知，Elasticsearch最外层的是Index（相当于数据库表的概念）；一个Index的数据我们可以分发到不同的Node上进行存储，这个操作就叫做分片。

比如现在我集群里边有4个节点，我现在有一个Index，想将这个Index在4个节点上存储，那我们可以设置为4个分片。这4个分片的数据合起来就是Index的数据

为什么要分片？原因也很简单：

如果一个Index的数据量太大，只有一个分片，那只会在一个节点上存储，随着数据量的增长，一个节点未必能把一个Index存储下来。
多个分片，在写入或查询的时候就可以并行操作（从各个节点中读写数据，提高吞吐量）

现在问题来了，如果某个节点挂了，那部分数据就丢了吗？显然Elasticsearch也会想到这个问题，所以分片会有主分片和副本分片之分（为了实现高可用）

数据写入的时候是写到主分片，副本分片会复制主分片的数据，读取的时候主分片和副本分片都可以读。

Index需要分为多少个分片和副本分片都是可以通过配置设置的

如果某个节点挂了，前面所提高的Master Node就会把对应的副本分片提拔为主分片，这样即便节点挂了，数据就不会丢。

到这里我们可以简单总结一下Elasticsearch的架构了：

Elasticsearch 写入的流程

上面我们已经知道当我们向Elasticsearch写入数据的时候，是写到主分片上的，我们可以了解更多的细节。

客户端写入一条数据，到Elasticsearch集群里边就是由节点来处理这次请求：

集群上的每个节点都是coordinating node（协调节点），协调节点表明这个节点可以做路由。比如节点1接收到了请求，但发现这个请求的数据应该是由节点2处理（因为主分片在节点2上），所以会把请求转发到节点2上。

coodinate（协调）节点通过hash算法可以计算出是在哪个主分片上，然后路由到对应的节点
shard = hash(document_id) % (num_of_primary_shards)

路由到对应的节点以及对应的主分片时，会做以下的事：

首先我们从分布式集群的角度分析下写入，采用系统默认的参数来说明

假设集群有三个节点，都存储数据，indexA 有5个分片，2个复制集。
数据如下分布：
Node1: shard1
Node2: shard2,shard3,shard1-R1(shard1的复制集)
Node3: shard4,shard5,shard-R2(shard1的复制集)

首先客户端根据配置的连接节点，通过轮询方式连接到一个coordinate节点。

coordinate节点不是很master/client/data节点一个维度的描述，它就是指处理客户端请求的节点。这个描述和cassandra的coordinate节点是一个概念。集群中所有的节点都可以是coordinate节点。

coodinate节点通过hash算法计算出数据在shard1上shard = hash(document_id) % (num_of_primary_shards)，然后根据节点上维护的shard信息，将请求发送到node1上。
node1 对索引数据进行校验，然后写入到shard中。具体细节见下一节写入到shard
主节点数据写入成功后，将数据并行发送到副本集节点Node2,Node3。
Node2,Node3写入数据成功后，发送ack信号给shard1主节点Node1。
ode1发送ack给coordinate node
coordinate node发送ack给客户端。

整个过程coordinate node部分类似cassandra,主shard节点和副本集受master-slave模式影响，必须有master决定写入成功与否，和mysql类似的。

写入shard
上面第三步骤，shard内写入还需要详细分析下

数据写入到内存buffer
同时写入到数据到translog buffer
每隔1s数据从buffer中refresh到FileSystemCache中，生成segment文件，一旦生成segment文件，就能通过索引查询到了
refresh完，memory buffer就清空了。
每隔5s中，translog 从buffer flush到磁盘中
定期/定量从FileSystemCache中,结合translog内容flush index到磁盘中。做增量flush的。

各种数据库的单节点写入过程大同小异，一般都是写内存，记录操作日志（防止节点宕机，内存中的数据丢失）然后flush到磁盘，有个线程不断的merge 数据块。不过是写入的数据格式不同。

1、Buffer（缓冲区）是系统两端处理速度平衡（从长时间尺度上看）时使用的。它的引入是为了减小短期内突发I/O的影响，起到流量整形的作用。比如生产者——消费者问题，他们产生和消耗资源的速度大体接近，加一个buffer可以抵消掉资源刚产生/消耗时的突然变化。

2、Cache（缓存）则是系统两端处理速度不匹配时的一种折衷策略。因为CPU和memory之间的速度差异越来越大，所以人们充分利用数据的局部性（locality）特征，通过使用存储系统分级（memory hierarchy）的策略来减小这种差异带来的影响。

所以写入到buffer中的数据，还是原始数据，还没有索引，搜索不到的。只有到Cache中还可以。

常见面试题

ES与Lucence的区别：

分布式搜索引擎：ES可以自动将海量数据分散到多台服务器上去存储和检索 Lucene：单机应用，最多只能处理单台服务器可以处理的数据量

区别：Lucence实现起来比较复杂，对比而言，ES是基于lucence的，对lucence进行了简化，提供了简单易用的restful api接口，支持分布式。

ES的分布式架构原理能说一下吗？
Es设计理念就是分布式搜索引擎，底层还是Lucence,核心思想就是在多台机器上启动多个es实例，组成一个es集群。es中存储数据的基本单位是索引，这个索引可以拆分成多个shard,每个shard存储部分数据，每个shard都有一个primary shard,负责写入数据，相应的每个primary shard可能有几个replica shard（只负责读），primary shard 写入数据后，会将数据同步到replica shard上去。es集群有多个节点，会自动选举一个节点为master节点。同时将宕机所对应的存活于其他节点的replica shard 提升为 primary shard。

ES写入数据的工作原理是什么？

写入数据时首先将数据随机发送到一个节点上，这个节点成为cooridinate shard，这个协调节点会进行hash路由，将数据发送到对应的节点上的primary shard，同时primary 将数据同步给replica shard上。写完成功后，协调节点返回客户端成功。

ES在大数据（几亿）下如何提高查询效率：

首先ES优化不是能够通过调参数能够解决的我们自己的生产环境实践经验，所以说我们当时的策略，是仅仅在es中就存少量的数据，就是你要用来搜索的那些索引，内存留给filesystem cache的，就100G，那么你就控制在100gb以内，相当于是，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在1秒以内

缓存预热：

哪怕是你就按照上述的方案去做了，es集群中每个机器写入的数据量还是超过了filesystem cache一倍，比如说你写入一台机器60g数据，结果filesystem cache就30g，还是有30g数据留在了磁盘上。对于那些你觉得比较热的，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问一下，让数据进入filesystem cache里面去。这样期待下次别人访问的时候，一定性能会好一些。

冷热分离：

你最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在filesystem os cache里，别让冷数据给冲刷掉。

参考文章：
https://juejin.cn/post/6844904051994263559#heading-1 https://www.cnblogs.com/stoneFang/p/11254521.html