名词解释: 分片:分片就是对数据切分成了多个部分,Elasticsearch默认会把一个索引分成五个分片, 数据保存在分片内,分片又被分配到集群内的各个节点里 副本:副本就是对原分片的复制,和原分片的内容是一样的,Elasticsearch默认会生成一份副本,所以相当于是五个原分片和五个分片副本,相当于一份数据存了两份,并分了十个分片 主节点:即Master节点。主节点的主要职责是和集群操作相关的内容,如创建或删除索引,跟踪哪些节点是群集的一部分,并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu,内存,io资源,为了确保一个集群的稳定,分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点,路由搜索和从客户端新增数据到数据节点,但最好不要使用这些专用的主节点。一个重要的原则是,尽可能做尽量少的工作。 数据节点:即Data节点。数据节点主要是存储索引数据的节点,主要对文档进行增删改查操作,聚合操作等。数据节点对CPU、内存、IO要求较高,在优化的时候需要监控数据节点的状态,当资源不够的时候,需要在集群中添加新的节点。 负载均衡节点:也称作Client节点,也称作客户端节点。当一个节点既不配置为主节点,也不配置为数据节点时,该节点只能处理路由请求,处理搜索,分发索引操作等,从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的,他协调主节点和数据节点,客户端节点加入集群可以得到集群的状态,根据集群的状态可以直接路由请求。 预处理节点:也称作Ingest节点,在索引数据之前可以先对数据做预处理操作,所有节点其实默认都是支持Ingest操作的,也可以专门将某个节点配置为Ingest节点。ES的节点类型 1。Master:主节点,每个集群都有且只有一个 尽量避免Master节点又是数据节点:node。datatrue 主节点的主要职责是负责集群层面的相关操作,管理集群变更,如创建或删除索引,跟踪哪些节点是群集的一部分,并决定哪些分片分配给相关的节点。 2。Voting:投票节点 node。votingonlytrue(仅投票节点,即使配置了data。mastertrue,也不会参选,但是仍然可以作为数据节点)。 3。Coordinating:协调节点 每一个节点都隐式的是一个协调节点,如果同时设置了data。masterfalse和data。datafalse,那么此节点将成为仅协调节点。 4。Mastereligiblenode(候选节点) 可以通过选举成为Master的节点 5。Datanode(数据节点) 主要负责数据存储和查询服务 配置:node。mastertruenode。datatrue 这是ES节点默认配置,既作为候选节点又作为数据节点,这样的节点一旦被选举为Master,压力是比较大的,通常来说Master节点应该只承担较为轻量级的任务,比如创建删除索引,分片均衡等。node。mastertruenode。datafalse 只作为候选节点,不作为数据节点,可参选Master节点,当选后成为真正的Master节点。node。masterfalsenode。datafalse 既不当候选节点,也不作为数据节点,那就是仅协调节点,负责负载均衡node。masterfalsenode。datatrue 不作为候选节点,但是作为数据节点,这样的节点主要负责数据存储和查询服务。 协调节点是如何工作的,他是怎么找到对应的节点的? 每个节点都保存了集群的状态,只有Master节点才能修改集群的状态信息 集群状态(ClusterStarte),维护了一个集群中,必要的信息 所有的节点信息 所有的索引和其相关的Mapping与Setting信息 分片的路由信息 协调节点作为es节点中的一个节点,默认情况下es集群中所有的节点都能当协调节点,主要作用于请求转发,请求响应处理等轻量级操作。 这意味着如果它们接收到用户请求,它们就可以处理用户请求集群健康状态GETclusterhealth status字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下: green所有的主分片和副本分片都正常运行。 yellow所有的主分片都正常运行,但不是所有的副本分片都正常运行。 red有主分片没能正常运行 路由一个文档到一个分片中 当索引一个文档的时候,文档会被存储到一个主分片中。Elasticsearch如何知道一个文档应该存放到哪个分片中呢?当我们创建文档时,它如何决定这个文档应当被存储在分片1还是分片2中呢? 首先这肯定不会是随机的,否则将来要获取文档的时候我们就不知道从何处寻找了。实际上,这个过程是根据下面这个公式决定的:shardhash(routing)numberofprimaryshards routing是一个可变值,默认是文档的id,也可以设置成一个自定义的值。routing通过hash函数生成一个数字,然后这个数字再除以numberofprimaryshards(主分片的数量)后得到余数。这个分布在0到numberofprimaryshards1之间的余数,就是我们所寻求的文档所在分片的位置。主分片和副本分片如何交互 我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置,所以可以直接将请求转发到需要的节点上。在下面的例子中,将所有的请求发送到Node1,我们将其称为协调节点(coordinatingnode)。新建、索引和删除文档 以下是在主副分片和任何副本分片上面成功新建,索引和删除文档所需要的步骤顺序:客户端向Node1发送新建、索引或者删除请求。节点使用文档的id确定文档属于分片0。请求会被转发到Node3,因为分片0的主分片目前被分配在Node3上。Node3在主分片上面执行请求。如果成功了,它将请求并行转发到Node1和Node2的副本分片上。一旦所有的副本分片都报告成功,Node3将向协调节点报告成功,协调节点向客户端报告成功 consistency一直性:参数的值可以设为one(只要主分片状态ok就允许执行写操作),all(必须要主分片和所有副本分片的状态没问题才允许执行写操作),或quorum。默认值为quorum,即大多数的分片副本状态没问题就允许执行写操作。int((primarynumberofreplicas)2)1es怎么实现master选举 master选举当然是由mastereligible节点发起没有master节点;脑裂产生2个master节点 深入理解Elasticsearch7。x新的集群协调层: https:easyice。cnarchives332 Elasticsearch的选举机制 https:www。jianshu。compbba684897544 elasticsearch选主流程 https:www。easyice。cnarchives164 elasticsearch的master选举机制 https:www。cnblogs。comjelly12345p15319549。html https:blog。csdn。netailiandeziweiarticledetails87856210 ES写入数据的过程客户端选择一个node发送请求过去,这个node就是coordinatingnode(协调节点)coordinatingnode,对document进行路由,将请求转发给对应的node实际上的node上的primaryshard处理请求,然后将数据同步到replicanodecoordinatingnode,如果发现primarynode和所有的replicanode都搞定之后,就会返回请求到客户端 shardnumhash(routing)numprimaryshards 其中routing是一个可变值,默认是文档的id的值,也可以设置成一个自定义的值。routing通过hash函数生成一个数字,然后这个数字再除以numofprimaryshards(主分片的数量)后得到余数。这个分布在0到numberofprimaryshards1之间的余数,就是我们所寻求的文档所在分片的位置。这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量:因为如果数量变化了,那么所有之前路由的值都会无效,文档也再也找不到了。写入数据底层原理 数据先写入到buffer里面,在buffer里面的数据时搜索不到的,同时将数据写入到translog日志文件之中;如果buffer快满了,或是一段时间之后(定时),就会将buffer数据refresh到一个新的OScache之中,然后每隔1秒,就会将OScache的数据写入到segmentfile之中,但是如果每一秒钟没有新的数据到buffer之中,就会创建一个新的空的segmentfile,只要buffer中的数据被refresh到OScache之中,就代表这个数据可以被搜索到了。当然可以通过restfulapi和Javaapi,手动的执行一次refresh操作,就是手动的将buffer中的数据刷入到OScache之中,让数据立马搜索到,只要数据被输入到OScache之中,buffer的内容就会被清空了。同时进行的是,数据到shard之后,就会将数据写入到translog之中,每隔5秒将translog之中的数据持久化到磁盘之中重复以上的操作,每次一条数据写入buffer,同时会写入一条日志到translog日志文件之中去,这个translog文件会不断的变大,当达到一定的程度之后,就会触发commit操作。将一个commitpoint写入到磁盘文件,里面标识着这个commitpoint对应的所有segmentfile强行将OScache之中的数据都fsync到磁盘文件中去。 解释:translog的作用:在执行commit之前,所有的而数据都是停留在buffer或OScache之中,无论buffer或OScache都是内存,一旦这台机器死了,内存的数据就会丢失,所以需要将数据对应的操作写入一个专门的日志问价之中,一旦机器出现宕机,再次重启的时候,es会主动的读取translog之中的日志文件的数据,恢复到内存buffer和OScache之中。 将现有的translog文件进行清空,然后在重新启动一个translog,此时commit就算是成功了,默认的是每隔30分钟进行一次commit,但是如果translog的文件过大,也会触发commit,整个commit过程就叫做一个flush操作,我们也可以通过ESAPI,手动执行flush操作,手动将OScache的数据fsync到磁盘上面去,记录一个commitpoint,清空translog文件 补充:其实translog的数据也是先写入到OScache之中的,默认每隔5秒之中将数据刷新到硬盘中去,也就是说,可能有5秒的数据仅仅停留在buffer或者translog文件的OScache中,如果此时机器挂了,会丢失5秒的数据,但是这样的性能比较好,我们也可以将每次的操作都必须是直接fsync到磁盘,但是性能会比较差。 如果时删除操作,commit的时候会产生一个。del文件,里面讲某个doc标记为delete状态,那么搜索的时候,会根据。del文件的状态,就知道那个文件被删除了。 如果时更新操作,就是讲原来的doc标识为delete状态,然后重新写入一条数据即可。 buffer每次更新一次,就会产生一个segmentfile文件,所以在默认情况之下,就会产生很多的segmentfile文件,将会定期执行merge操作 每次merge的时候,就会将多个segmentfile文件进行合并为一个,同时将标记为delete的文件进行删除,然后将新的segmentfile文件写入到磁盘,这里会写一个commitpoint,标识所有的新的segmentfile,然后打开新的segmentfile供搜索使用。删除和更新 段是不可改变的,所以既不能从把文档从旧的段中移除,也不能修改旧的段来进行反映文档的更新。取而代之的是,每个提交点会包含一个。del文件,文件中会列出这些被删除文档的段信息。 当一个文档被删除时,它实际上只是在。del文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到,但它会在最终结果被返回前从结果集中移除。 文档更新也是类似的操作方式:当一个文档被更新时,旧版本文档被标记删除,文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到,但被删除的那个旧版本文档在结果集返回前就已经被移除。段合并 由于自动刷新流程每秒会创建一个新的段,这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是,每个搜索请求都必须轮流检查每个段;所以段越多,搜索也就越慢。 Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段,然后这些大的段再被合并到更大的段。 段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档(或被更新文档的旧版本)不会被拷贝到新的大段中。 合并大的段需要消耗大量的IO和CPU资源,如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制,所以搜索仍然有足够的资源很好地执行Elasticsearchhead图形化界面的安装 https:blog。csdn。netqq21299835articledetails106534644http。cors。enabled:truehttp。cors。alloworigin:统一的集群名cluster。name:myes当前节点名node。name:node1对外暴露端口使外网访问network。host:127。0。0。1对外暴露端口http。port:9201集群间通讯端口号transport。tcp。port:9301集群的ip集合discovery。zen。ping。unicast。hosts:〔127。0。0。1:9301,127。0。0。1:9302,127。0。0。1:9303〕http。cors。enabled:truehttp。cors。alloworigin:统一的集群名cluster。name:myes当前节点名node。name:node2对外暴露端口使外网访问network。host:127。0。0。1对外暴露端口http。port:9202集群间通讯端口号transport。tcp。port:9302集群的ip集合discovery。zen。ping。unicast。hosts:〔127。0。0。1:9301,127。0。0。1:9302,127。0。0。1:9303〕http。cors。enabled:truehttp。cors。alloworigin:统一的集群名cluster。name:myes当前节点名node。name:node3对外暴露端口使外网访问network。host:127。0。0。1对外暴露端口http。port:9203集群间通讯端口号transport。tcp。port:9303集群的ip集合discovery。zen。ping。unicast。hosts:〔127。0。0。1:9301,127。0。0。1:9302,127。0。0。1:9303〕