es集群工作原理

一、es集群简介

当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据（同步）

二、集群节点

1、集群中一个节点会被选举为主节点(master)
2、主节点不参与文档级别的变更或搜索
3、任何节点都可以成为主节点。
4、用户，我们能够与集群中的任何节点通信，包括主节点。
5、每一个节点都知道文档存在于哪个节点上，它们可以转发请求到相应的节点上。
6、我们访问的节点负责收集各节点返回的数据，最后一起返回给客户端。这一切都由Elasticsearch处理。

三、集群健康

在Elasticsearch集群中可以监控统计很多信息，但是只有一个是最重要的：集群健康(cluster health)。集群健康有三种状态：green、yellow或red。

GET /_cluster/health

在一个没有索引的空集群中运行如上查询，将返回这些信息：

{
   "cluster_name":          "elasticsearch",
   "status":                "green", 
   "timed_out":             false,
   "number_of_nodes":       1,
   "number_of_data_nodes":  1,
   "active_primary_shards": 0,
   "active_shards":         0,
   "relocating_shards":     0,
   "initializing_shards":   0,
   "unassigned_shards":     0
}

status字段提供一个综合的指标来表示集群的的服务状况。三种颜色各自的含义：
green 所有主要分片和复制分片都可用
yellow 所有主要分片可用，但不是所有复制分片都可用
red 不是所有的主要分片都可用

四、集群分片

索引就是mysql的db数据库！！！只是用来指向分片的！！！
索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.

分片(shard)是一个最小级别工作单元(worker unit),它只是保存了索引中所有数据的一部分，是一个Lucene实例，并且它本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，我们的应用程序直接与索引通信。
分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。
当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。

1、主分片

索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。
理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期望的响应时间。

2、副分片

复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

创建分片：

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

增加副分片：

PUT /blogs/_settings
{
   "number_of_replicas" : 2
}

主分片设置后不能进行修改，只能修改副本分片

集群的健康状态yellow表示所有的主分片(primary shards)启动并且正常运行了——集群已经可以正常处理任何请求——但是复制分片(replica shards)还没有全部可用。事实上所有的三个复制分片现在都是unassigned状态——它们还未被分配给节点。
在同一个节点上保存相同的数据副本是没有必要的，如果这个节点故障了，那所有副本也会丢失。但如果保存在其他节点，即使这个节点挂了，还可以从其他节点找回副本。

五、故障转移

在单一节点上运行意味着有单点故障的风险——没有数据备份。幸运的是，要防止单点故障，我们唯一需要做的就是启动另一个节点。

第二个节点已经加入集群，三个复制分片(replica shards)也已经被分配了——分别对应三个主分片，这意味着在丢失任意一个节点的情况下依旧可以保证数据的完整性。
文档的索引将首先被存储在主分片中，然后并发复制到对应的复制节点上。这可以确保我们的数据在主节点和复制节点上都可以被检索。

六、集群操作原理

1、路由

当你索引一个文档，它被存储在单独一个主分片上。Elasticsearch是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片1还是分片2上的呢？
进程不能是随机的，因为我们将来要检索文档。
算法决定：

shard = hash(routing) % number_of_primary_shards

routing值是一个任意字符串，它默认是_id但也可以自定义。

为什么主分片的数量只能在创建索引时定义且不能修改？
如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。

所有的文档API（get、index、delete、bulk、update、mget）都接收一个routing参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档——例如属于同一个人的文档——被保存在同一分片上。

2、操作数据节点工作流程（把图看明白）

每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点，所以也可以将请求转发到需要的节点。

新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。

node1的P1主分片，对应node2的R1和node3的R1两个复制分片
node3的P0主分片，对应node1的R0和node2的R0两个复制分片

1. 客户端给Node 1发送新建、索引或删除请求。
2. 节点使用文档的_id确定文档属于分片0。它转发请求到Node 3，分片0位于这个节点上。
3. Node 3在主分片上执行请求，如果成功，它转发请求到相应的位于Node 1和Node 2的复制节点上。当所有的复制节点报告成功，Node 3报告成功到请求的节点，请求的节点再报告给客户端。

replication
复制默认的值是sync。主分片得到复制分片的成功响应后才返回。
如果你设置replication为async，主分片被执行后就会返回给客户端。它依旧会转发请求给复制节点，但你将不知道复制节点成功与否。
上面的这个选项不建议使用。默认的sync复制允许Elasticsearch强制反馈传输。
async复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。

3、检索流程（把图看明白）

文档能够从主分片或任意一个复制分片被检索。

node1的P1主分片，对应node2的R1和node3的R1两个复制分片
node3的P0主分片，对应node1的R0和node2的R0两个复制分片

1. 客户端给Node 1发送get请求。
2. 节点使用文档的_id确定文档属于分片0。分片0对应的复制分片在三个节点上都有。此时，它转发请求到Node 2。
3. Node 2返回文档(document)给Node 1然后返回给客户端。
   对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。
   可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。