ElasticSearch 设计的理念就是分布式搜索引擎,底层其实还是基于 lucene 的。核心思想就是在多台机器上启动多个 es 进程实例,组成了一个 es 集群。ES隐藏了复杂的分布式机制,下面我对ES的分布式原理进行剖析。
当ElasticSearch的节点启动后,它会利用多播(multicast)寻找集群中的其它节点,并与之建立连接。在集群中,一个节点被选举成主节点(master node)。这个节点负责管理集群的状态,当群集的拓扑结构改变时把索引分片分派到相应的节点上。
![d93df0f3ba11d7e9943359904b02c8df.png](https://i-blog.csdnimg.cn/blog_migrate/feb4939e0d85c9d45f2629f472527191.jpeg)
数据分片、节点扩展与容错
![62a23f0f349507bc0d6eab7b534ab319.png](https://i-blog.csdnimg.cn/blog_migrate/d191a6859f4092b580385b3240bc4e01.jpeg)
图1. 空集群
![38e8a821f8cf0d3dde8b623acf05867b.png](https://i-blog.csdnimg.cn/blog_migrate/f233af063b872a32e19f755ec4e0a90e.jpeg)
图2. 主分片
![7ae4c6902eb930a9bc1cb11780629273.png](https://i-blog.csdnimg.cn/blog_migrate/affbd3732d68e39ded89b59ed0d58229.jpeg)
图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节点
![d8407799e8f75a3fb5aa31740296897e.png](https://i-blog.csdnimg.cn/blog_migrate/407802e530d827c6b803d934a72fe807.jpeg)
图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,并且是独享每台机器的资源。
![f05f0c331563077a218ab5b1209c6cdc.png](https://i-blog.csdnimg.cn/blog_migrate/97f8c1d3ebb674d893ab5296872c2f0c.jpeg)
图5. 从分片扩展
![fa2001a075cc6cd2b1f9e0a18372fe70.png](https://i-blog.csdnimg.cn/blog_migrate/3d36d3028852506443ab8a8629b81f36.jpeg)
图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
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。