ElasticStack数据流
ElasticSearch
建立索引和类型
- 在Elasticsearch集群中，节点是对等的，节点间会通过自己的一些规则选取集群的Master，Master节点会负责集群状态信息的改变，并同步给其他节点。
- 建立索引和类型的请求先发送到Master节点，Master建立完索引后，将集群状态同步至Slave节点。
- 只有建立索引和类型需要经过Master节点，数据的写入有一个简单的Routing规则，可以Route到集群中的任意节点，所以数据写入压力是分散在整个集群的。
分片内文档写入流程
-
In-memory Buffer
在主分片节点上，文档会先被写入到内存（In-memory Buffer）中，此时数据还不能被搜索到。
-
Refresh
经过一段时间（refresh_interval）或者内存缓冲满了，Elasticsearch会将内存中的文档Refresh到文件系统缓存（Filesystem Cache）中，并清除内存中的对应文档。
-
Filesystem Cache
文档在文件系统缓存中被解析为Lucene的底层文件Segment中，同时建立倒排索引。这个时候文档是可以被搜索到的，因此减少了后续写入磁盘的大量时间，体现了Elasticsearch搜索的实时性（下图中的绿色和灰色图标分别代表已写入磁盘和未写入磁盘的文档）。
-
Segment
Lucene把每次生成的倒排索引，叫做一个段(Segment)，它无法被修改，只能被合并和删除。另外使用一个Commit文件，记录索引内所有的Segment。由于每次打开一个Segment就会消耗一个文件句柄，随着Segment越来越多，将导致查询性能越来越差。这时，ElasticSearch后台会有一个单独线程专门合并Segment，将零碎的小的Segment合并成一个大的Segment。
-
Flush
将Segment写入磁盘中，更新Commit文件并删除文档对应的Translog文件。
-
Translog
Elasticsearch在把数据写入到Index Buffer的同时，其实还另外记录了一个Translog日志。它是以顺序写文件的形式写入到磁盘中的，速度较快。如果发生异常，Elasticsearch会从Commit位置开始，恢复整个Translog文件中的记录，保证数据一致性。
多个分片的文档写入
确定文档存储位置
计算方式：
shard = hash(routing) % number_of_primary_shards
每个文档都有一个routing参数，默认情况下就使用其 _id 值。将其 _id 值计算哈希后，对索引的主分片数取余，就得到了文档实际应该存储到的分片。因此索引的主分片数不可以随意修改，一旦主分片数改变，所有文档的存储位置计算结果都会发生改变，索引数据就完全不可读了。
同步副本
.jpg)
- 客户端请求发送给Node 1节点，注意图中Node 1是Master节点，实际完全可以不是；
- Node 1用文档的 _id 取余计算得到应该将数据存储到shard 0上。通过Cluster State信息发现shard 0的主分片已经分配到了Node 3上。Node 1转发请求数据给Node 3；
- Node 3完成请求数据的索引过程，存入主分片 0。然后并行转发数据给分配有shard 0的副本分片的Node 1和Node 2。当收到任一节点汇报副本分片数据写入成功，Node 3即返回给初始的接收节点 Node 1，宣布数据写入成功。Node 1返回成功响应给客户端；
- 当集群中某个节点宕机，该节点上所有分片中的数据全部丢失（既有主分片，又有副分片）。丢失的副分片对数据的完整性没有影响，丢失的主分片在其他节点上的副分片会被选举成主分片；所以整个索引的数据完整性没有被破坏。
注：图中P代表主分片（Primary Shard），R代表副本（Replica Shard）。
根据_id查询文档
GET /[index]/_doc/[_id]
- Elasticsearch集群中的任意节点都可以作为协调（Coordinating）节点接受请求，每个节点都知道集群中任一文档位置；
- 协调节点对文档的_id进行路由，从而判断该数据在哪个Shard，然后将请求转发给对应的节点，此时会使用随机轮询算法，在Primary Shard和Replica Shard中随机选择一个，从而对请求负载均衡；
- 处理请求的节点返回文档给协调节点；
- 协调节点返回文档给客户端。
根据字段值检索数据
GET /[index]/_search?q=[field]: [value]
- Elasticsearch集群中的任意节点都可以作为协调（Coordinating）节点接受请求，每个节点都知道集群中任一文档位置；
- 协调节点进行分词等操作后，向所有的shard节点发送检索请求；
- ElasticSearch已建立字段的倒排索引，即可通过字段值检索到所在文档的_id。随后Shard将满足条件的数据（_id、排序字段等）信息返回给协调节点;
- 协调节点将数据重新进行排序，获取到真正需要返回的文档的_id。协调节点再次向对应的Shard发起请求（此时已经有_id 了，可以直接定位到对应的Shard）;
- Shard将_id对应的文档的完整内容返回给协调节点；
- 协调节点获取到全部检索结果，返回给客户端。
上述流程和根据_id查询文档相比，只是多了一个从倒排索引中根据字段值寻找文档_id的过程，其中的4~6步完全相同。
ElasticSearch架构原理
原文：https://www.cnblogs.com/koktlzz/p/14303609.html
