高可用
ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，所以这种情况只是理想状况。
ES不允许Primary和它的Replica放在同一个节点中（为了容错），并且同一个节点不接受完全相同的两个Replica，也就是说，因为同一个节点存放两个相同的副本既不能提升吞吐量，也不能提升查询速度，徒耗磁盘空间。
每台节点的shard数量越少，每个shard分配的CPU、内存和IO资源越多，单个shard的性能越好，当一台机器一个Shard时，单个Shard性能最好。
(4)相同资源分配相同的前提下，单个shard的体积越大，查询性能越低，速度越慢
稳定的Master节点对于群集健康非常重要！理论上讲，应该尽可能的减轻Master节点的压力，分片数量越多，Master节点维护管理shard的任务越重，并且节点可能就要承担更多的数据转发任务，可增加“仅协调”节点来缓解Master节点和Data节点的压力，但是在集群中添加过多的仅协调节点会增加整个集群的负担，因为选择的主节点必须等待每个节点的集群状态更新确认。
如果相同资源分配相同的前提下，shard数量越少，单个shard的体积越大，查询性能越低，速度越慢，这个取舍应根据实际集群状况和结合应用场景等因素综合考虑
数据节点和Master节点一定要分开，集群规模越大，这样做的意义也就越大
数据节点处理与数据相关的操作，例如CRUD，搜索和聚合。这些操作是I / O，内存和CPU密集型的，所以他们需要更高配置的服务器以及更高的带宽，并且集群的性能冗余非常重要
于仅投票节不参与Master竞选，所以和真正的Master节点相比，它需要的内存和CPU较少。但是，所有候选节点以及仅投票节点都可能是数据节点，所以他们都需要快速稳定低延迟的网络
高可用性（HA）群集至少需要三个主节点，其中至少两个不是仅投票节点。即使其中一个节点发生故障，这样的群集也将能够选举一个主节点。生产环境最好设置3台仅Master候选节点（node.master = true node.data = true）
为确保群集仍然可用，集群不能同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，群集仍可以正常工作。这意味着，如果存在三个或四个主节点合格的节点，则群集可以容忍其中一个节点不可用。如果有两个或更少的主机资格节点，则它们必须都保持可用
容灾
第一步：Master选举
脑裂：可能会产生多个Master节点
解决：discovery.zen.minimum_master_nodes=N/2+1
第二步：Replica容错
第三步：尝试重启故障机
第四步：数据同步
