tigercn 2019-07-01
下面简单描述一下Elasticsearch横向扩容过程与容错机制
对于ES默认创建的索引有10个shard,其中有5个是primary shard,5个是replica shard。
在ES内部会自动做一些事情:
(1)primary shard & replica shard会自动负载均衡。均匀的分布在各个节点
(2)保持每个节点node拥有更少的shard,IO/CPU/Memory资源给每个shard分配更多,使得每个shard性能更好
(3)Elasticsearch的扩容极限,由于有10个shard(5个primary shard,5个replica shard),所以最多可以扩容到6台机器,此时每个shard可以占用单台服务器的所有资源,性能最好。
(4)如果超出扩容的极限,可以动态的修改replica数量,比如将replica修改为2,那么就有15个分片(5个primary shard,10个replica shard),此时就可以扩容到15台机器,比之前拥有更高的读吞吐量。
(5)如果只有5台机器,15个分片(5个primary shard,10个replica shard),每个shard占用的资源会更少,但是容错性会比10个分片的要好,此时最多可以容纳2台机器宕机,而10个分片只能容纳1台机器宕机。
这些知识点告诉我们,一方面扩容应该怎么去扩,怎么去提升系统整体的吞吐量;另一方面还要考虑到系统的容错性,怎样提高系统的容错性,让尽可能多的服务器宕机,不会造成数据的丢失。
场景描述:
假设master node1节点宕机的一瞬间,P0,P1,P2,P3,P4这些primary shard就没了,也就是说此时就不是active status
下面是ES做的容错的一个过程:
第一步:master选举,自动选择另一台node作为新的master节点,承担起master的责任来
第二步:新的master node2将丢失掉primary shard的某个replica shard提升为primary shard。此时cluster status就会变为yellow,因为primary shard全部变成active了,但是少了一个replica shard,所以就不是所有的replica shard都是active的
第三步:重启故障的node,新的master会将缺失的副本都copy一份到该node上去。而且该node会使用之前已有的shard数据,只是同步一下宕机之后发生过的修改。cluster的状态变为green,因为primary shard和replica shard都齐全了。
另外一部分,则需要先做聚类、分类处理,将聚合出的分类结果存入ES集群的聚类索引中。数据处理层的聚合结果存入ES中的指定索引,同时将每个聚合主题相关的数据存入每个document下面的某个field下。