Elasticsearch 集群

  当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 clustername 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上

运行的节点才会自动组成集群。

  如果启动了第二个节点，集群将会拥有两个节点 : 所有主分片和副本分片都已被分配 。

  通过 elasticsearch-head 插件查看集群情况

  集群健康值:green( 3 of 6 )：表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。

：3 个主分片正常。

  怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配 。

通过 elasticsearch-head 插件查看集群情况。

集群健康值:green( 3 of 6 )：表示所有 6 个分片（包括 3 个主分片和 3 个副本分片）都在正常运行。

Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有 2 个分片， 而不是之前的 3 个。 这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片 的性能将会得到提升。

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。 我们这个拥有 6 个分 片（3 个主分片和 3 个副本分片）的索引可以最大扩容到 6 个节点，每个节点上存在一个分片，并且每个 分片拥有所在节点的全部资源。

但是如果我们想要扩容超过 6 个节点怎么办呢？

主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。） 但是，读 *** 作——搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2。

users 索引现在拥有 9 个分片： 3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍。

通过 elasticsearch-head 插件查看集群情况：

当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。 你需要增加更多的硬件资源来提升吞吐量。

但是更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去 2 个节点的情况下不丢失任何数据。

我们关闭第一个节点，这时集群的状态为:关闭了一个节点后的集群。

我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 2 。在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。

幸运的是，在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片， 此时集群的状态将会为yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

为什么我们集群状态是 yellow 而不是 green 呢？

虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应 2 份副本分片，而此时只存在一份副本分片。 所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 Node 2 ，我们的程序 依然 可以保持在不丢任何数据的情况下运行，因为Node 3 为每一个分片都保留着一份副本。

如果想回复原来的样子，要确保Node-1的配置文件有如下配置：

集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。 如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是 Master 节点切换了。

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量:因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

所有的文档API ( get index delete 、 bulk , update以及 mget ）都接受一个叫做routing 的路由参数，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档—一例如所有属于同一个用户的文档——都被存储到同一个分片中。

我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。在下面的例子中，如果将所有的请求发送到Node 1001，我们将其称为协调节点coordinating node。

当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。

Net的ElasticSearch 有两个版本，ElasticsearchNet(低级) 和 NEST(高级)，推荐使用 NEST，低级版本的更灵活，水太深 把握不住。有个需要注意，使用的版本号必须要ElasticSearch服务端版本号一致。

一、 连接池

11 SingleNodeConnectionPool 单节点连接池

适合只有一个节点的情况。当没有在ConnectionSettings 构造函数中显式指定连接池类型的时候，默认此连接池。这种连接池不会标记节点是否存活

12 StaticConnectionPool 静态连接池

适合多个节点，它维护一个静态的节点hosts清单，使用前通过ping节点来确认节点是否存活。如果一个节点处理请求失败，该节点会被标记为死节点，这个节点会被“关禁闭”，“关禁闭”出来后，会再次处理请求，如果还是失败，“关禁闭”的时间会更长。

13 SniffingConnectionPool 嗅探连接池

它继承至静态连接池，有静态连接池的Ping特性。区别在于是动态的，用户提供hosts种子，而客户端则会嗅探这些hosts并发现集群的其他节点。

启动过程

当ElasticSearch节点启动时，使用广播技术来发现同一集群中的其他节点（配置文件中的集群名称）并于它们连接。集群中会有一个节点被选为管理节点（master node），负责集群的状态管理以及在集群拓扑变化时做出反应，分发索引分片至集群的相应节点。

es写数据

1）客户端选择一个node发送请求，这个node就是coordinating node（协调节点）

2）协调节点对document进行路由，将请求转发给对应的node

3）node上的primary shard处理请求，然后将数据同步到replica shard

①先写入内存，并将 *** 作写入translog（数据不能被搜索，translog会在每隔5秒或者每次写入完成后写入磁盘）

②es每隔1秒（配置）进行一个刷新（refresh），写入内存到新数据被写入文件缓存中，并构成一个segement（数据能被搜索，未写入磁盘，可能丢失）

③每隔30分钟或者translog大小达到阈值，触发commit，执行fsync *** 作，当前translog被删除

（merge：每次refresh都会生成一个segment，segment过多会消耗资源，搜索变慢。A和B两个segment，小segmentC，A，B被读到内存中和Cmerge，生产大segement D，触发commit）

4）返回响应结果给客户端

es删除数据

磁盘上每个segment都有一个del文件关联，当发送删除请求时，在del中标记为删除，文档仍能够被搜索到，但会从结果中过滤掉。merge时del文件中标记但数据不会被包括在新的segment中

es读数据

1）客户端发送请求到协调节点

2）协调节点将请求转发到对应的shard（通过对doc key进行哈希（ Murmur哈希算法 ），判断出doc在哪个shard上，然后对该shard查询）

3）每个shard将搜索结果（doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等 *** 作

4）协调节点根据doc id去各节点拉取document，返回给客户端

es更新数据

创建新文档时，es会为该文档分配一个版本号。对文档但每次更新都会产生一个新的版本号。当执行更新时，旧版本在del文件中标记删除，并且新版本在新segment中写入索引

并发控制

基于乐观锁和版本号

master选举

①如果集群中存在master，认可该master，加入集群

②如果集群中不存在master，从具有master资格的节点中选id最小的节点作为master

实时性（FileSystem Cache）

一个Index由若干segment组成，搜索时按segment搜索，索引一条segment后，每个段会通过fsync *** 作持久化到磁盘，而fsync *** 作比较耗时。

es中新增的document会被收集到indexing buffer区后被重写成一个segment，然后直接写入FileSystem Cache中，只要sengment文件被写入cache后，这个sengment就可以打开和查询，从而确保在短时间内就可以搜到。

以上就是关于Elasticsearch 集群全部的内容，包括:Elasticsearch 集群、ES近实时搜索原理、ES系列6-ElasticSearch集群进阶等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！