Elasticsearch 杂项

1.elasticsearch 如何实现Master 选举

elasticsearch 选主是zenDiscovery模块负责，主要通过ping(节点之间的RPC来发现彼此)和Unicast(单播模块包含一个主机列表来控制那些节点需要ping通)；对所有可以成为master的节点（node.master:true）根据nodeId字典排序，每次选举都把自己所知道的节点排一次序，然后选出第一个（第0位）节点，暂认为它是master 节点。如果对某个节点投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选自己，那这个节点就是master。否则重新选举一直到满足上述条件。

2.es写数据过程

• 客户端选择一个node 发送过去，这个node就是coordinating node(协调节点)。
• coordinating node 对document 进行路由，将请求转发给对应的node(primary shard)。路由算法 hashcode(document_id) % shards
• 实际的node 上的parimary shard 处理请求，然后将数据同步到replica node。
• coordinating node 如果发现primary shard 处理请求，然后将数据同步到replica node
• coordinating node 如果发现primary node 和所有replica node 都搞定之后，就返回响应结果给客户端。

3.es 读取数据过程

可以通过doc id 来查询，会根据doc id 进行hash ,判断出来当时doc id 分配到那个shard 上面去，从那个shard查询

• 客户端发送一个请求到任意一个node,成为coordinate node。
• coordinate node 对doc id 进行hash 路由，将请求转发到对应的node, 此时会使用round-robin 轮询算法在primary shard 以及其所有replica 中随机选择一个，让读请求负载均衡。
• 接收请求的node 返回document 给coordinate node。
• 给coordinate node 返回document 给客户端。

4.es 写数据的底层原理

1). document 先写入到内存buffer 中，同时写translog 日志

2). refresh 操作之所以是近实时搜索：写入和打开一个新段（一个追加的倒排索引）的轻量过程叫refresh。每隔一秒把buffer 中的数据创建一个新的segement。这里新段会被先写入文件系统缓存（代价相对比较低），稍后再被刷入到磁盘（代价高）。不过只要文件在缓存中，就可以像其他文件一样可以被打开和读取了。内存buffer 被清空。此时新segment中的文件就可以被搜索了，这就意味着document 可以写入到被搜索需要一秒钟，如果要更改这个属性，可以执行以下操作

put /index_test
{
	"settings":
	{
		"refresh_interval":"30s"	
	}
}

3). flush 操作导致持久化变更：执行一个提交并且截断translog 的行为在Elasticsearch 被称作一次flush。 刷新（refresh）完成后，缓存被清空但是translog 日志不会。translog 日志也会越来越多，当translog 日志大于一个阈值时候或30分钟，会发出flush 操作。

• 所有内存缓存区的文档都会被写入一个新的segement。
• 缓存区被清空
• 一个提交点被写入磁盘
• 文件系统通过fsync 到磁盘
• 老的translog 被删除

分片每30分钟自动（flush）,或着translog 太大的时候也会被刷新。也可以用flush命令手动执行。

translog 每5秒会被写入磁盘（所以如果这5s,数据在cache 而且log 没持久化会丢失）。在一次增删改操作后translog 只有在replica 和 primary shard 都成功才会成功，如果需提高操作速度，可以设置成异步的

PUT /index_test
{
 "settings": {
  "index.translog.durability": "async" ,
  "index.translog.sync_interval":"5s"
 }
}

所以总结是有三个批次操作，一秒一次refresh 保证近实时，5秒做已给translog 持久化保证数据未持久化前留底，30分钟做一次持久化。

4.es搜索数据过程

客户端发送到一个coordinate node。

协调节点将搜索请求转发到所有的shard对应的primary shard 或replica shard,都可以

query phase:每个shard 将自己的搜索结果（doc id）返回给协调节点，由协调节点进行数据合并，排序，分页等操作，产出最终结果。

fetch phase: 接着由协调节点根据doc id 去哥哥节点拉取实际的document 数据，最终返回给客户端。

5.translog 和commit point 的数据恢复

在磁盘上会有一个上次持久话的commit point,translog 上有一个commit point ,根据这俩个commit point ,会把translog 中的变更记录进行回访，重新执行之前的操作。

6.删除和更新原理

一个document被删除，它实际只是在.del 文件中被标记删除。一个标记删除的文档然可以被查询匹配到，但它最终结果被返回前从结果中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

segment合并的时候那些被删除的document 会被清除。被删除的文档（或被更新文档的旧版本）不会拷贝到新的大segement。

7.segment合并

由于buffer 数据会被刷新到segment中，所以segment会很多，为了防止这种情况，es 会把一些小segment合并。并执行物理删除小segement。

手动执行段合并命令

POST /index_test/_forcemerge?max_num_segements=1