ElasticSearch 设计的理念就是分布式搜索引擎，底层其实还是基于 lucene 的。核心思想就是在多台机器上启动多个 es 进程实例，组成了一个 es 集群。ES隐藏了复杂的分布式机制，下面我对ES的分布式原理进行剖析。
当ElasticSearch的节点启动后，它会利用多播(multicast)寻找集群中的其它节点，并与之建立连接。在集群中，一个节点被选举成主节点(master node)。这个节点负责管理集群的状态，当群集的拓扑结构改变时把索引分片分派到相应的节点上。
数据分片、节点扩展与容错
图1. 空集群
图2. 主分片
图3. 主从分片
在图1中，ES集群只有一个master节点，该节点是一个空的没有任何分片数据。图2中只有一个master节点，索引被拆成3个shard，由于只有一个节点，因此所有shard都只能分布在node1节点上（primary和replica不能同时存在于同一个节点上），若该索引设置的是3个primary shard，3个replica，那个这3个replica将都不是active，因为没有节点存放replica。图3有2个节点，3个primary shard在node1上，3个replica在node2上。replica shard负责容错，以及承担读请求负载。
master节点
图4. 节点扩展
若此时ES集群增加一个新的节点node3，shards会自动在节点中进行负载均衡。从图4中可以看出，当新增node3时，p0（primary shard 0）和R2（replica 2）将自动分布到node3上。
扩容之后，每个节点的shard数量更少，就意味着每个shard可以占用节点上更多的资源，IO、CPU、Memory，整个系统系统会更好。如果超出系统的扩容瓶颈，比如图4中6个shard，但是扩容到了9个基点，这时每个shard分布在一个节点上，仍然有3个节点处于空闲状态，此时我们可以增加replica shard数量（primary shard在索引创建时制定，创建后就不可修改），将replicas增加到6个，这样每台机器上都会有一个shard，并且是独享每台机器的资源。
图5. 从分片扩展
图7. 容错（故障恢复）
在图7中，node1发生故障后
- 首先进行master选举，自动选举另一个node成为新的master，承担起master的责任来；
- 新master将丢失掉的primary shard的某个replica shard提升为primary shard，此时cluster status状态会变为yellow，因为primary shard全部变为active了，但是少了一个replica shard，所以不是所有的replica shard都是active的；
- 重启故障的node，新的master会将缺失的副本都copy一份到该node上去，而且该node会使用之前已有的shard数据，只是同步一下宕机后发生的修改，cluster status变为green，因为primary shard和replica shard都齐全了
分片数量合理设置
1. 跟业务的实际使用场景有关，千万级别以下默认五个分片就足够。亿级需要压测，直至业务方认为查询延迟已经无法接受，此时认为分片数量已经不够。
2. 一个经验值就是每个分片不要超过30G，分片大小已经达到性能瓶颈，就需要考虑拆分索引。
作者：买个橘子
链接：
https://juejin.im/post/6895548216176033805
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。