1，ES的索引和分片
（1）索引（index）：
概念：相当于数据库，用于定义文档类型的存储，在同一个索引中，同一个字段只能定义一个数据类型。每个索引都可以有一个或者多个主索引片，同时每个索引还可以有零个或者多个副本索引片。
创建索引：curl -XPUT http://localhost:9200/index （localhost可以换为自己的主机IP，index是想要创建的索引的名字）
（2）分片（shard）：
概念：ElasticSearch集群通过把数据分发到多个存储Lucene索引的物理机上，达到能够存储超出单机容量的信息这一目的。这个分发的过程称为索引分片(Sharding)。在ElasticSearch集群中，索引分片(Sharding)是自动完成的，而且所有分片索引(Shard)是作为一个整体呈现给用户的。整体呈现可以这样理解：当你查询的索引分布在多个分片上时， Elasticsearch会把查询发送给每个相关的分片，并将结果合并在一起，而应用程序并不知道分片的存在
默认值：分片默认为5个主分片，1个分片副本，一旦创建好索引，定义的主分片数量就不能更爱
通过集群状态API获取当前的分片和副本的设置：
curl -XGET 'http://localhost:9200/_cluster/index?human&pretty'
创建索引，定义分片数量：
PUT /my_index
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
查看每个分片的情况：
GET /_cluster/health?level=indices
2，ES分片的一致性
概念：简单说就是主分片写完，同步到副本分片上，等所有的分片写完才分会成功
理解：
高可用方面：
ElastcSearch拥有许多高可用的特性，例如Replica，例如Data Node挂掉后的数据迁移，例如Master Node挂掉后的自动重选，但这不代表万无一失了。常见的坑是，某个Node表现糟糕但是偏偏又没挂（挂了反而更好），此时整个Cluster的性能就会被一个坑爹Node拖累，这往往就是雪崩的开始。因此，从高可用方面来考虑，应当部署多个ES Cluster（部分作为灾备）。
性能方面：
单个Cluster的搜索能力是有瓶颈的。Cluster越大，Node越多，自然Shard就越多。而Shard不是越多越好，Shard增多会导致通讯成本的增加、查询收束时Re-ranking环节的负担增加。如果有100台机器，那么比起一个100 Node、300 Shards的巨型Cluster，使用十个10 Node 30 Shards的小型Cluster可能表现会更好。
如何确保多个ES Cluster的更新操作的一致性：
加入一层可以被多人重复消费的消息队列（例如Kafka），作为所有ES Cluster插入/更新的中间层。
优点：
1）主更新程序只有一个，提高可控性和发现问题的能力；
2）使用消息队列来统一发布内容，降低了对数据源的压力；
3）图中消费者这个角色，Elastic Stack官方提供了一个轻量级高可用解决方案，就是Beat