知其然，知其所以然！本文我们从底层进行理解Elasticsearch是如何写入和查询索引的，通过本文的理解，对我们在实际业务使用ES有很大的帮助。

Elasticsearch写入与查询过程

首先，我们来了解下Elasticsearch写数据以及查询数据的过程！

Elasticsearch写数据过程

客户端选择一个节点Node发送请求过去，该节点Node称为Coordinating Node（协调节点）；
协调节点对Document进行路由（注：通过hash算法计算：shard = hash(document_id) % (num_of_primary_shards)），将请求转发给对应的节点Node；
实际节点Node上的Primary Shard处理请求，然后将数据同步到Replica Node；
协调节点返回响应结果给客户端；

Elasticsearch读数据过程

客户端发送请求到任意一个节点Node，该节点成为协调节点；
协调节点对DocId进行哈希路由，将请求转发到对应的节点Node，此时会使用随机轮询算法Round-Robin，在Primary Shard以及其所有Replica中随机选择一个，让读请求负载均衡；
接收请求的节点Node返回Document给协调节点，协调节点将结果返回给客户端；

【注】：这里介绍的过程是通过DocId来查询的，会根据DocId进行hash，判断出DocId在哪个分片上，进而到该分片区查询。

Elasticsearch搜索数据过程

客户端发送请求到协调节点；
协调节点将搜索请求转发到所有的Shard对应的Primary Shard或者Replica Shard；
Query Phase处理，每个Shard将自己的搜索结果（其实就是一些DocId）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作；
Fetch Phase处理，由协调节点根据DocId到各个节点上拉取实际的Document数据，最终返回给客户端；

Tips：写请求是写入Primary Shard，然后同步给所有的Replica Shard；读请求可以从Primary Shard或者Replica Shard读取，采用的是随机轮询算法。

Elasticsearch写入与查询原理

先写入内存buffer，在buffer中的时候数据是搜索不到的，同时将数据写入translog日志文件；如果buffer快满了，或者到一定时间，就会将内存buffer中的数据refresh到一个新的segment文件中，但是此时数据不是直接进入segment file磁盘文件，而是先进入os cache（这个过程就是refresh）

每隔1秒钟，Elasticsearch将buffer中的数据写入一个新的segment file，每秒钟会产生一个新的磁盘文件segment file，这个segment file中就存储最近1秒内buffer中写入的数据。但是如果buffer中此时没有数据，那当然就不会执行refresh操作，如果buffer中有数据，默认1秒钟执行一次refresh操作，刷入一个新的segment file中。

操作系统中，磁盘文件都有一个os cache（系统缓存），就是说数据在写入磁盘文件之前，会先进入os cache，先进入操作系统级别的一个内存缓存中。只要buffer中的数据被refresh操作刷入os cache中，这个数据就可以被搜索到。

重复上面的步骤，新的数据不断进入buffer和translog，不断将buffer数据写入一个又一个新的 segment file中去，每次refresh完buffer清空，translog保留。随着这个过程推进，translog会变得越来越大。当translog达到一定长度的时候，就会触发commit操作。

commit操作发生第一步，就是将buffer中现有数据refresh到os cache中去，清空buffer。然后，将一个commit point写入磁盘文件，里面标识着这个commit point对应的所有segment file ，同时强行将os cache中目前所有的数据都fsync到磁盘文件中去。最后清空现有translog日志文件，重启一个translog，此时commit操作完成。

这个commit操作叫做flush 。默认30分钟自动执行一次flush ，但如果translog过大，也会触发 flush 。flush操作就对应着commit的全过程，我们可以通过ES API，手动执行flush操作，手动将 os cache中的数据fsync强刷到磁盘上去。

【总结】：数据写入Elasticsearch首先是写入内存buffer，然后每隔1秒钟，将数据refresh到os cache中，到了os cache数据就能被搜索到（所以说ES从写入到能被检索到，中间有1秒钟的延迟）。每隔5秒钟，将数据写入translog文件（这样保证机器宕机，最多只会5秒的数据丢失），translog大到一定程度，或者默认每隔30分钟，会触发commit操作，将缓冲区的数据都flush到segment file磁盘文件中。【数据写入segment file之后，同时就建好了倒排索引】。

为什么Elasticsearch是准实时的（NRT：near real-time）？

默认是每隔1秒refresh一次的，所以Elasticsearch是准实时的，因为写入的数据1秒之后才能被看到。可以通过ES的RESTful API或者 Java API，手动执行一次refresh操作，就是手动将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。只要数据被输入os cache中，buffer就会被清空了，因为不需要保留buffer了，数据在translog里面已经持久化到磁盘去一份了。

Translog日志的作用是什么？

执行commit操作之前，数据要么是停留在buffer中，要么是停留在os cache中，无论是buffer还是 os cache都是内存，一旦这台机器死了，内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件translog中，一旦此时机器宕机，再次重启的时候，Elasticsearch会自动读取translog日志文件中的数据，恢复到内存buffer和os cache 。