随着日志量的增加，es在不停的调整，结构层面的冷热数据分离、master和client节点的分离并引入部落节点，es集群层面的index优化、flush优化、merge优化、内存熔断优化，系统层面的GC、文

随着日志量的增加，es在不停的调整，结构层面的冷热数据分离、master和client节点的分离并引入部落节点，es集群层面的index优化、flush优化、merge优化、内存熔断优化，系统层面的GC、文件描述符、进程数、关闭交换分区调整等等，其实es优化是一个法无定法的事儿，并不是死板的调固定参数，而是要不停的去试各种参数值在自己的业务场景下哪个表现最好，但是总结起来，首先了解了es的数据写入和读取过程，才知道如何下手，我们做的所有调优都是为了更快的索引速度、更快更大数据量的搜索性能、更稳定的服务，下面从上下行的角度做个介绍。

上行数据写入过程如下：

画这张图还是费了一些精力的，试图将生产环境里真实的写入过程进行完全的抽象并展现出来，es里面有很多的概念，这个网上有很多介绍，不展开说。从这张图看，首先数据的写入不依赖master节点，其实读取也是一样的，每一个节点都可以作为协调节点处理请求，并将数据路由到数据该有的节点，每个节点都可以查询到集群和文档的详细信息，那master的作用是什么呢？es集群master节点的作用是维护元信息和管理集群状态，master节点只是维护元信息并不是所有元信息的存放点，它负责了删除和创建索引等系列操作，但数据的写入和数据的查询都不需要经过master节点的。

数据写入的整个过程如下：数据写入请求——>协调节点接收后数据路由处理——>存入对应数据节点的index buffer并记录translog日志——>经过refresh刷新为segment存入文件缓存并变为可搜索——>数据永久刷新到磁盘并清空translog日志。到此一次数据就写完了，同时后台根据merge策略进行段的合并操作，在一个索引中，segment越少，搜索效率越高，一个shard最小可以merge合并成一个segment，segment就是倒序索引。

下行数据写入搜索过程如下：

从整体原理上看，下行数据的搜索没有数据写入那么复杂，es集群也是类似于map reduce的方式进行查询的，分层聚合计算，中间会有打分制等算法，最后在client节点做结果汇聚返回给客户端。全过程大致如下，当客户端节点收到search请求后，计算出牵涉到的shard并将请求分发出去，收到请求的节点进行第一步的汇聚，然后将汇聚结果返回到client节点，client节点再次处理后，将结果发给客户端。

最终总结：知道了es的写入和查询原理后，就可以在相应的各环节做配置调整，每个环节点都是一个可以做的优化点，道法自然而术变万千。

“运维网咖社”原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://www.net-add.com

社长"矢量比特"，曾就职中软、新浪，现任职小米，致力于DevOps运维体系的探索和运维技术的研究实践.