集群扩容
Elasticsearch 可以随时按需扩容。扩容的方式有水平扩容、垂直扩容。
- 水平扩容：添加更多的服务器，使集群的负载能力更强
- 垂直扩容：替换性能更强的机器，使集群的负载能力更强
显然垂直扩容需要大量资金，并且有瓶颈。水平扩容更合适用来提升集群的负载能力。
横向扩容则需要分布式技术来支持，对于大多数的数据库而言，通常需要对应用程序进行非常大的改动，才能利用上横向扩容的新增资源。而ElastiSearch天生就是 分布式的 ，它知道如何通过管理多节点来提高集群负载能力。
集群通信
- Elasticsearch 中的集群，无非就是一个或多个
cluster.name相同的节点，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。 - Elasticsearch 的集群也有master节点，但是它只负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。
- 用户的请求可以发送到集群的任意节点中，每个节点都知道任意文档所处的位置，通过文档进行routing，能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从这些节点收集回数据，并将最终结果返回给客户端。
集群状态
可以通过GET /_cluster/healthAPI查看集群的状态：
{
"cluster_name" : "docker-cluster",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 4,
"active_shards" : 6,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
这里主要关注status的值：
- green:所有的主分片和副本分片都正常运行。
- yellow:所有的主分片都正常运行，但不是所有的副本分片都正常运行。
- red:有主分片没能正常运行。
shard 详解
- 从客户端看来，数据插入、查询等操作都是基于 index 而言，index实际上是由一个或多个 shard 组成，而我们在查询的时候并没有关注数据应该去哪个 shard 查询，这是因为ES屏蔽掉了细节，这也是ES深受广大程序员青睐的原因之一，简单、易用。
- 而这一个个 shard 其实就是一个个Lucene实例。而我们在做数据插入时，存储document数据的具体容器也是 shard。ES会将shards尽可能的均匀分配到集群中的每个节点上。并且在集群节点的动态增减后也同样有效。
- shard 又分为 primary shard 和 replace shard，前面所说的基本是 primary shard 的功能，也就是说某一个document 数据其实是放在某一个 primary shard 中的，而一个 primary shard 是有存储上限（Integer.MAX_VALUE - 128）的，由此可以知道primary shard 数量能够大致决定 index 的数据存储上限。
- replace shard 的功能除了对其 primary shard 做数据备份以外，还能为搜索API提供服务。
- primary shard 只能在新建 index 时设置，且不允许对已经存在的 index 做修改。
- replace shard 可以随时修改。
- replace shard 不能和其备份的 primary shard 处于同一个节点，所以如果设置了 replace shard 数量，则集群中至少需要俩个节点，否则replace shard 会分配失败，ES存在数据丢失的风险。