elasticsearch的分布式架构原理

对于全文检索，lucene是目前最流行的搜索库。以前我们都需要学习使用lucene,基于lucene做相关的开发，学习倒排索引的原理，而现在，我们可以直接使用现成的搜索框架了，因为现在很多这种搜索框架底层都是直接基于lucene的分布式搜索引擎，例如elasticsearch就是其中最典型的代表，我们亲切的简称其为es。

 

现在分布式搜索基本已经成为大部分互联网行业的java体系的标配，其中尤为流行的就是es，记得我2014年的时候还在用用solr，估计那个时候大部分小伙伴也是一样。但是最近几年基本都开始转向es了。

elasticsearch设计的理念就是分布式搜索引擎，底层其实还是基于lucene的。

elasticsearch通过在多台机器上启动多个进程实例，然后通相同的集群名称自动加入同一个集群组成了一个es集群。

 

es基础存储结构

es中存储数据的基本单位是索引index，比如我们可以创建订单索引order_index，然后创建一个type，所有的订单数据就都写到这个索引下的type里面去了，如果硬要和mysql进行类比的话，es中一个索引可以类比为mysql中的一个库，类型可以类比为mysql里的一张表，因此理论上一个索引index可以对应多个type。不过随着es版本的更新迭代，一般都是建议一个索引index只对应一个type。es中结构由大到小顺序大致为index -> type -> mapping -> document -> field。

 

比如：一个订单index里面一般就是一个订单type，只存放一种类型。

 

每个type都有一个mapping结构，mapping就是这个type的结构定义，这个结构定义就相当于你在mysql中创建一个表，要定义表结构和字段，以及类型。

 

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

 

然后你向index中的type写的一条数据，就相当于一个document对象，一个document对象就代表了mysql中某个表里的一行记录，每个document有多个field，每个field就代表了这个document中的一个字段的值

 

es的分布式架构

借图说话

 

 

根据es的分布式架构，es的每个索引都会被拆分成多个shard分片，每个shard分片只存储部分数据。

 

然后每个shard分片都是有副本的，其中主分片即primary shard负责写入数据， primary shard写入数据之后，会将数据同步到其他几个副本分片replica shard上去。通过这种副本机制达到es的高可用。

 

es集群中是有多个节点的，它们会自动选举一个节点做为master节点，master节点相当于一个协调管理者，用于维护索引元数据，切换primary shard和replica shard身份之类的。

 

如果master节点宕机了，其余节点会重新选举一个节点为master节点。

 

如果是非master节点宕机了，那么会由master节点，让那个宕机节点上的primary shard的身份转移到其他机器上的replica shard。然后如果该宕机节点修复重启了之后，master节点会将缺失的replica shard分配过去，同步主从分片数据，让集群恢复正常。

 

这就是elasticsearch作为一个分布式搜索引擎最基本的一个架构设计，后续会持续探讨es搜索和写入的内部原理和流程，以及实际项目中我们怎么使用elasticsearch实现全文检索，聚合统计相关功能。