基于lucene的分布式搜索引擎——elasticsearch 分布式架构原理

es分布式架构原理

elasticsearch设计的理念就是分布式搜索引擎，底层实现还是基于Lucene的，核心思想是在多态机器上启动多个es进程实例，组成一个es集群。一下是es的几个概念：

1. 接近实时
   es是一个接近实时的搜索平台，这就意味着，从索引一个文档直到文档能够被搜索到有一个轻微的延迟
2. 集群（cluster）
   一个集群有多个节点（服务器）组成，通过所有的节点一起保存你的全部数据并且通过联合索引和搜索功能的节点的集合，每一个集群有一个唯一的名称标识
3. 节点（node）
   一个节点就是一个单一的服务器，是你的集群的一部分，存储数据，并且参与集群和搜索功能，一个节点可以通过配置特定的名称来加入特定的集群，在一个集群中，你想启动多少个节点就可以启动多少个节点。
4. 索引（index）
   一个索引就是还有某些共有特性的文档的集合，一个索引被一个名称唯一标识，并且这个名称被用于索引通过文档去执行搜索，更新和删除操作。
5. 类型（type）
   type 在6.0.0已经不赞成使用
6. 文档（document）
   一个文档是一个基本的搜索单元

es中存储数据的基本单位是索引，比如说你现在要在es中存储一些订单数据，你就应该在es中创建一个索引，order_idx，所有的订单数据就都写到这个索引里面去，一个索引差不多就是相当于是mysql里的一张表。index -> type -> mapping -> document -> field。

 

index：mysql里的一张表

 

type：没法跟mysql里去对比，一个index里可以有多个type，每个type的字段都是差不多的，但是有一些略微的差别。

 

好比说，有一个index，是订单index，里面专门是放订单数据的。就好比说你在mysql中建表，有些订单是实物商品的订单，就好比说一件衣服，一双鞋子；有些订单是虚拟商品的订单，就好比说游戏点卡，话费充值。就两种订单大部分字段是一样的，但是少部分字段可能有略微的一些差别。

 

所以就会在订单index里，建两个type，一个是实物商品订单type，一个是虚拟商品订单type，这两个type大部分字段是一样的，少部分字段是不一样的。

 

很多情况下，一个index里可能就一个type，但是确实如果说是一个index里有多个type的情况，你可以认为index是一个类别的表，具体的每个type代表了具体的一个mysql中的表

 

每个type有一个mapping，如果你认为一个type是一个具体的一个表，index代表了多个type的同属于的一个类型，mapping就是这个type的表结构定义，你在mysql中创建一个表，肯定是要定义表结构的，里面有哪些字段，每个字段是什么类型。。。

 

mapping就代表了这个type的表结构的定义，定义了这个type中每个字段名称，字段是什么类型的，然后还有这个字段的各种配置

 

实际上你往index里的一个type里面写的一条数据，叫做一条document，一条document就代表了mysql中某个表里的一行给，每个document有多个field，每个field就代表了这个document中的一个字段的值

总结：
es中，存储数据的基本单位就是索引，比如说es中存储了一些订单系统的销售数据，就因该在es中创建一个索引，order—index，所有的销售数据就会都写到这个索引里面去，一个索引就像数据库。而type就相当于每一张表，
一个index里面可以有多个type，而mapping就相当于表的结构定义，定义了什么字段类型等，你往index的一个type里添加一行数据就叫做一个document，每一个document有多个filed，每一个filed就代表这个document的一个字段的值。

1. 分片（shards）

在一个搜索里存储的数据，潜在的情况下可能会超过单个节点的硬件的存储限制，为了解决这个问题，elasticsearch便提供了分片的功能，它可以将索引划分为多个分片，当你创建一个索引的时候，你就可以简单的定义你想要的分片的数量，每一个分片本身是一个全功能的完全独立的索引，可以部署到集群中的任何一个节点。分片的两个总要原因：
（1）它允许你水平切分你的内容卷
（2）它允许通过分片来分布和并执行操作来应对日益增长的执行量

1. 复制（replica）
   在一个网络情况下，故障可能会随时发生，有一个故障恢复机制是必须的，为了达到这个目的，ES允许你制作一个或多个拷贝放入一个叫做复制分片或短暂的复制品中。复制对于以下两个主要原因很重要
   （1）高可用。它提供了高可用的以来防止分片或者节点宕机，为此，一个非常重要的注意点就是绝对不要讲一个分片的拷贝放在跟这个分片相同的机器上。
   （2）高并发。它允许你的分片可以提供超出自身吞吐量的搜索服务，搜索行为可以在分片所有的拷贝中并行执行。
   总之，一个完整的流程就是，ES客户端将一份数据写入primary shard,它会将分成成对的shard分片，并将数据进行复制，ES客户端取数据的时候就会在replica或primary 的shard中去读。ES集群有多个节点，会自动选举一个节点为master节点，这个master节点其实就是干一些管理类的操作，比如维护元数据，负责切换primary shard 和replica shard的身份之类的，要是master节点宕机了，那么就会重新选举下一个节点为master为节点。如果时非master宕机了，那么就会有master节点，让那个宕机的节点上的primary shard的身份转移到replica shard上，如果修复了宕机的那台机器，重启之后，master节点就会控制将缺失的replica shard 分配过去，同步后续的修改工作，让集群恢复正常。

es写入数据的过程

1. 客户端选择一个node发送请求过去，这个node就是coordinating node (协调节点)
2. coordinating node，对document进行路由，将请求转发给对应的node
3. 实际上的node上的primary shard处理请求，然后将数据同步到replica node
4. coordinating node，如果发现primary node和所有的replica node都搞定之后，就会返回请求到客户端

es读数据过程

查询，GET某一条的数据，写入某个document，这个document会自动给你分配一个全局的唯一ID，同时跟住这个ID进行hash路由到对应的primary shard上面去，当然也可以手动的设置ID

1. 客户端发送任何一个请求到任意一个node，成为coordinate node
2. coordinate node 对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮训算法，在primary shard 以及所有的replica中随机选择一个，让读请求负载均衡，
3. 接受请求的node，返回document给coordinate note
4. coordinate node返回给客户端

es搜索数据过程

1. 客户端发送一个请求给coordinate node
2. 协调节点将搜索的请求转发给所有的shard对应的primary shard 或replica shard
3. query phase：每一个shard 将自己搜索的结果（其实也就是一些唯一标识），返回给协调节点，有协调节点进行数据的合并，排序，分页等操作，产出最后的结果
4. fetch phase ，接着由协调节点，根据唯一标识去各个节点进行拉去数据，最总返回给客户端

写入数据的底层原理

1. 数据先写入到buffer里面，在buffer里面的数据时搜索不到的，同时将数据写入到translog日志文件之中
2. 如果buffer快满了，或是一段时间之后，就会将buffer数据refresh到一个新的OS cache之中，然后每隔1秒，就会将OS cache的数据写入到segment file之中，但是如果每一秒钟没有新的数据到buffer之中，就会创建一个新的空的segment file，只要buffer中的数据被refresh到OS cache之中，就代表这个数据可以被搜索到了。当然可以通过restful api 和Java api，手动的执行一次refresh操作，就是手动的将buffer中的数据刷入到OS cache之中，让数据立马搜索到，只要数据被输入到OS cache之中，buffer的内容就会被清空了。同时进行的是，数据到shard之后，就会将数据写入到translog之中，每隔5秒将translog之中的数据持久化到磁盘之中
3. 重复以上的操作，每次一条数据写入buffer，同时会写入一条日志到translog日志文件之中去，这个translog文件会不断的变大，当达到一定的程度之后，就会触发commit操作。
4. 将一个commit point写入到磁盘文件，里面标识着这个commit point 对应的所有segment file
5. 强行将OS cache 之中的数据都fsync到磁盘文件中去。
   解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中。
6. 将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API,手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件
   补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差。
7. 如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了。
8. 如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可。
9. buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作
10. 每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用。

总之，segment的四个核心概念，refresh，flush，translog、merge

搜索的底层原理

查询过程大体上分为查询和取回这两个阶段，广播查询请求到所有相关分片，并将它们的响应整合成全局排序后的结果集合，这个结果集合会返回给客户端。

1. 查询阶段

   1. 当一个节点接收到一个搜索请求，这这个节点就会变成协调节点，第一步就是将广播请求到搜索的每一个节点的分片拷贝，查询请求可以被某一个主分片或某一个副分片处理，协调节点将在之后的请求中轮训所有的分片拷贝来分摊负载。
   2. 每一个分片将会在本地构建一个优先级队列，如果客户端要求返回结果排序中从from 名开始的数量为size的结果集，每一个节点都会产生一个from+size大小的结果集，因此优先级队列的大小也就是from+size，分片仅仅是返回一个轻量级的结果给协调节点，包括结果级中的每一个文档的ID和进行排序所需要的信息。
   3. 协调节点将会将所有的结果进行汇总，并进行全局排序，最总得到排序结果。

2. 取值阶段

   1. 查询过程得到的排序结果，标记处哪些文档是符合要求的，此时仍然需要获取这些文档返回给客户端
   2. 协调节点会确定实际需要的返回的文档，并向含有该文档的分片发送get请求，分片获取的文档返回给协调节点，协调节点将结果返回给客户端。

倒排索引

倒排索引就建立分词与文档之间的映射关系，在倒排索引之中，数据时面向分词的而不是面向文档的。

在海量数据中怎样提高效率

1. filesystem cache
   ES的搜索引擎是严重的依赖底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的index segment file 索引数据文件
2. 数据预热
   对于那些你觉得比较热的数据，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问以下，让数据进入filesystem cache里面去，这样期待下次访问的时候，性能会更好一些。
3. 冷热分离

关于ES的性能优化，数据拆分，将大量的搜索不到的字段，拆分到别的存储中去，这个类似于MySQL的分库分表的垂直才分。

1. document的模型设计

不要在搜索的时候去执行各种复杂的操作，尽量在document模型设计的时候，写入的时候就完成了，另外对于一些复杂的操作，尽量要避免

1. 分页性能优化

翻页的时候，翻得越深，每个shard返回的数据越多，而且协调节点处理的时间越长，当然是用scroll，scroll会一次性的生成所有数据的一个快照，然后每次翻页都是通过移动游标完成的。 api 只是在一页一页的往后翻。