es的分布式原理？es是如何实现分布式的？

Elasticsearch设计的理念是分布式搜索引擎，底层其实是基于lucene。核心思想是在多台机器上启动多个es进程实例，组成一个es集群。

es中存储数据的基本单位是索引，比如说你现在要在es中存储一些订单数据，你就应该在es创建一个索引order_idx,所有的订单数据都会写入这个索引里面去，一个索引差不多相当于mysql中的一个数据库。为了方面记忆，可以跟传统的数据库对比来看，但记住不是一样的概念。

很多情况下，一个index里可能就只有一个type，但是确实如果说一个index里有多个type的情况，你可以认为index就像一个数据库，一个数据库有多个type表，每个表有多个document行，每行也会有多个field字段的值，而mapping对应这个type的表结构定义，但在es7.x已经被移除。

你创建一个索引，这个索引可以拆分成多个shard，每个shard存储部分数据。拆分多个shard是有好处的。一是支持横向扩展。比如你的数据量是3T，3个shard，每个shard就1T的数据，若现在数据量增加到4T，怎么扩展呢？简单，重新建一个有4个shard的索引，将数据导进去；而是提供性能，数据分布在多个shard，即多台服务器上，所有的操作，都会在多台机器上并行分布式执行。提高了吞吐量和性能。

接着就是多个shard的数据实际是有多个备份，就是说每个shard都会有个primary shard，负责写入数据，但是有多个replica shard。primary shard写入数据之后，会将数据同步到其他几个replica shard上去。

通过这个replica的方案，每个shard的数据都有多个备份，如果某台服务器挂了，没关系，还有别的数据副本在其他集群上，由此实现了高可用。

es集群多个节点，会自动选举一个节点为master节点，这个master节点其实就是干一些管理的工作，比如维护索引元数据，负责切换primary shard和replica shard身份等，如果master节点挂了，那么会重新选举一个节点为master节点。

如果非master节点挂了，那么master节点会让宕机的primary shard的身份转移到其他机器上replica shard。接着你要是修复了那个宕机节点机器，重启之后，master节点会控制将缺失的replica shard分配过去，同步后续修改的数据等操作， 让集群正常工作。

简单来说，非master节点宕机之后，节点上primary shard就没有了。那么master会让primary shard对应的replica shard(其他机器)切换成primary shard 。当宕机服务器修复之后，修复后的的节点不在是primary shard，而是replica shard。

上述其实就是elsaticsearch作为分布式搜索引擎的最基本的架构设计。