下面简单描述一下Elasticsearch横向扩容过程与容错机制1、横向扩容过程对于ES默认创建的索引有10个shard,其中有5个是primary shard5个是replica shard。在ES内部会自动做一些事情1primary shard replica shard会自动负载均衡。均匀的分布在各个节点2保持每个节点node拥有更少的shardIO/CPU/Memory资源给每个shard分配更多使得每个shard性能更好3Elasticsearch的扩容极限由于有10个shard5个primary shard,5个replica shard所以最多可以扩容到6台机器此时每个shard可以占用单台服务器的所有资源性能最好。4如果超出扩容的极限可以动态的修改replica数量比如将replica修改为2那么就有15个分片5个primary shard10个replica shard此时就可以扩容到15台机器比之前拥有更高的读吞吐量。5如果只有5台机器15个分片5个primary shard,10个replica shard每个shard占用的资源会更少但是容错性会比10个分片的要好此时最多可以容纳2台机器宕机而10个分片只能容纳1台机器宕机。这些知识点告诉我们一方面扩容应该怎么去扩怎么去提升系统整体的吞吐量另一方面还要考虑到系统的容错性怎样提高系统的容错性让尽可能多的服务器宕机不会造成数据的丢失。2、容错机制详解场景描述:假设master node1节点宕机的一瞬间P0P1,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都齐全了。