分布式搜索引擎-Elasticsearch

Lucene是什么？

Lucene 是一个基于 Java 的全文信息检索工具包，目前主流的搜索系统Elasticsearch和solr都是基于lucene的索引和搜索能力进行。

Lucene 实现全文检索的流程？


1. 创建索引的过程：确定要搜索的内容—>构建文档对象—>分析文档（分词）—>创建索引
2. 搜索过程：用户通过搜索界面—>创建查询—>执行搜索，从索引库搜索—>渲染搜索结果

什么是全文检索？

数据总体分为两类：结构化数据和非结构化数据。

• 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。
• 非结构化数据：指不定长或无固定格式的数据。非结构化数据又一种叫法叫全文数据。

对结构化数据的搜索：如对数据库的搜索，用SQL语句。再如对元数据的搜索，如利用windows搜索对文件名，类型，修改时间进行搜索等。

对非结构化数据的搜索：如利用windows的搜索也可以搜索文件内容，Linux下的grep命令，再如用Google和百度可以搜索大量内容数据。

*全文检索：即先建立索引，再对索引进行搜索。索引是从非结构化数据中提取出之后重新组织的信息。

倒排索引和常规索引？

常规索引：

文档——>关键词 但是这样检索关键词的时候很费力，要一个文档一个文档的遍历一遍。

倒排索引：倒排索引是关键词到文档的映射

关键词——>文档 这样，只要有关键词，立马就能找到她在那个文档里出现过，然后就可以查出整个文档。

Elasticsearch基本概念

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的。

• Elasticsearch 中的索引、类型和文档，类似于 MySQL 中的数据库、表和行。

elasticsearch的核心概念

1. Near Realtime（NRT）：近实时，两个意思，从写入数据到数据可以被搜索到有一个小延迟（大概1秒）；基于es执行搜索和分析可以达到秒级；
2. Cluster：集群：包含多个节点，每个节点属于哪个集群是通过一个配置（集群名称，默认是elasticsearch）来决定的，对于中小型应用来说，刚开始一个集群就一个节点很正常。
3. Node：节点：集群中的一个节点，节点也有一个名称（默认是随机分配的）。
4. Index：索引：包含一堆有相似结构的文档数据，比如可以有一个客户索引，商品分类索引，订单索引，索引有一个名称。一个index包含很多document，一个index就代表了一类类似的或者相同的document。
5. Type：类型：每个索引里都可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field。
6. Document&field：文档：es中的小数据单元，一个document可以是一条客户数据，一条商品分类数据，一条订单数据，通常用JSON数据结构表示，每个index下的type中，都可以去存储多个document。一个document里面有多个field，每个field就是一个数据字段。
7. shard：分区：单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。
8. replica：副本：任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。

es的分布式架构原理能说一下么（es是如何实现分布式的啊）？

写的情况：

1. 把索引可以拆分成多个shard（分区），每个shard存储部分数据。
2. 这个shard的数据实际是有多个备份，就是说每个shard都有一个primary shard（主分区），负责写入数据，但是还有几个replica shard（副本）。primary shard（主分区）写入数据之后，会将数据同步到其他几个replica shard（副本）上去。
3. 通过这个replica的方案，每个shard的数据都有多个备份，如果某个机器宕机了，还有别的数据副本在别的机器上。这样实现高可用。
4. 如果master节点宕机了，那么会重新选举一个节点为master节点。
5. 如果某台primary shard（主分区）宕机，那么会由master节点，让那个宕机节点上的primary shard（主分区）的身份转移到其他机器上的replica shard（副本）。
6. 当你修复了那台宕机的机器，重启之后，master节点会控制将缺失的replica shard分配过去，同步后续修改的数据之类的，让集群恢复正常。

读的情况：可以从replica（副本）/primary（主分区） shard去读

es写入数据的工作原理是什么啊？es查询数据的工作原理是什么啊？

写入数据：

• 写入数据的时候随便挑选一个节点，被选中的节点叫做协调节点，协调节点会对要写入的数据做一下Hash，然后把数据路由到某一个节点上的primary shard（主分区）上面去，路由过去了以后，就把数据同步到自己的replica shard（副本）上面，当主，副同步数据完成后，协调节点就会响应回客户端写成功了。

• 1）先写入buffer，在buffer里的时候数据是搜索不到的；同时将数据写入translog日志文件
  
• 2）如果buffer快满了，或者到一定时间，就会将buffer数据写入（refresh）到一个新的segment file中，但是此时数据不是直接进入segment file的磁盘文件的，而是先进入os cache的。这个过程就是更新（refresh）。但是如果buffer里面此时没有数据，那当然不会执行refresh操作
  
• 3）只要数据进入os cache，此时就可以让这个segmentfile的数据对外提供搜索了
  
• 4）每次一条数据写入buffer，同时会写入一条日志到translog日志文件中去，所以这个translog日志文件是不断变大的，当translog日志文件大到一定程度的时候，就会执行commit操作。
  
• 5）commit操作发生步，就是将buffer中现有数据refresh到os cache中去，清空buffer
  
• 6）将一个commit point写入磁盘文件，里面标识着这个commit point对应的所有segment file
  
• 7）强行将os cache中目前所有的数据都同步（fsync）到磁盘文件中去
  
• 8）将现有的translog清空，然后再次重启启用一个translog，此时commit操作完成。默认每隔30分钟会自动执行一次commit，但是如果translog过大，也会触发commit。整个commit的过程，叫做flush操作。我们可以手动执行flush操作，就是将所有os cache数据刷到磁盘文件中去。
  
• 9）translog其实也是先写入os cache的，默认每隔5秒刷一次到磁盘中去，所以默认情况下，可能有5秒的数据会仅仅停留在buffer或者translog文件的os cache中，如果此时机器挂了，会丢失5秒钟的数据。但是这样性能比较好，多丢5秒的数据。也可以将translog设置成每次写操作必须是直接fsync到磁盘，但是性能会差很多。
  
• 10）如果是删除操作，commit的时候会生成一个.del文件，里面将某个doc标识为deleted状态，那么搜索的时候根据.del文件就知道这个doc被删除了
  
• 11）如果是更新操作，就是将原来的doc标识为deleted状态，然后新写入一条数据
  
• 12）buffer每次refresh一次，就会产生一个segment file，所以默认情况下是1秒钟一个segment file，segment file会越来越多，此时会定期执行merge
  
• 13）当segment file多到一定程度的时候，es就会自动触发合并（merge）操作，将多个segment file给合并（merge）成一个segment file。
  

es读取数据的过程

• 查询，GET某一条数据，写入了某个document，这个document会自动给你分配一个全局的id，doc id，同时也是根据doc id进行hash路由到对应的primary shard上面去。也可以手动指定doc id，比如用订单id，用户id。
  
• 1）客户端发送请求到任意一个node，成为coordinate node
  

2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡

3）接收请求的node返回document给coordinate node

4）coordinate node返回document给客户端

查询的时候根据某一id查询doc，这时候就是找一个协调节点，协调节点根据id路由找到shard然后返回数据

es搜索数据过程

发送一个搜索请求，协调节点会把请求发送所有shard，然后所有的shard会去自己里面查，找到可能会匹配到的doc，返回到协调节点，协调节点在去doc里面去匹配，找到符合你需要的那些document，在给你返回回来。