ITPub博客

elasticsearch集群的搭建教程很多。网上一搜都是，但是，搭建不难。更重要的是明白集群原理，性能以及运维知识点。所以，本文将从这些点着重介绍。

前两天突然被业务部的同事问了一句：“我现在要做搜索结果全量导，该用哪个接口，性能要好的？”之前虽然是知道这三种方法都是可以做分页的深度查询，但是由于具体的代码实现细节没看过，因此心里一下子就没有了底气，只好回答说先看看。fromsizefromsize是最家喻户晓的，也是最暴力的，需要查询from+

这两周主要看了下Elasticsearch（其实是Lucene）的segments的merge流程。事情起因是，线上的ES有些大索引，其中的segments个数几十个，每个大小100M+，小segments若干，而遇到问题就是这些大的segments不再做merge了，除非强制进行forceMerg

上周听了院长讲了一课ES之后，绕梁三日，并对里面关于节点failover的逻辑非常好奇，乃至自己这两天捣鼓一下，没事做设定一个很简单的场景，想看ES是怎么走的。看了不少文章翻了不少代码，有收获顾记录之。本篇打算讨论下面这个很简单的问题：索引primaryshard失效示意图客户端首先发送文档A到No

最近项目上的需要，要在某些场景下拦截ES的Request 和Response，进而把ES的整个plugin 的机制原理分析了一遍。但是并不等于说会写plugin就可以为所欲为，实操下来还是发现不少问题，这篇文章主要还是围绕一个目的：如何通过写plugin来想办法拦截ES的Request 和Response 的思路来写。

elk + filebeat 具体配置内容

本篇只关注一个细节，就是在一个端到端的场景，一个Request是如何构造并传输，从Client到Node的Action接收端又如何被parse，接着传输到各个的shards去处理；反之一个Response生成后如何一直传输回到Node端最后回到TransportClient或者RESTClient。

这两周做的事情比较杂，所以看代码的点也稍微有点分散，不过我尽量用手头的例子来把这些东西串起来。做的事情还是上两周那件事：我想拦截ES的Request和Response，统计我自己想要的指标并保存，那么需要完成以下3件事情：怎么拦截除了Request和Response外如何获取container里的其

在我看来，ClusterState就是整个ES进程的所有状态的逻辑封装，里面包含了各式各样的功能的Settings和Configs，每个nodes最终都需要维护一个一致的ClusterState属性。在5.0 以后，为了节省网络带宽，ES允许相邻的两个版本可以只发送 diff 数据，而不需要每次都发送整个全量的clusterState。

bully算法是一个分布式系统中动态选择master节点的算法，进程号最大的非失效的节点将被选为master。

这几天刚实操了一把shard 的relocation， 在cerebro 上看着图标移来晃去觉得很爽，但之前并没深究，也没读过这部分的代码。前几晚夜间上线需要重启所有的ES机器，大家也对ES的relocation 讨论了一番，这次就顺便读读这部分的代码。

Redis实现基于Zookeeper来实现分布式锁总结不过目前互联网项目越来越多的项目采用集群部署，也就是分

分布式的搜索引擎和数据分析引擎 全文检索，结构化检索，数据分析 对海量数据进行近实时的处理

ES5.6 Bulk源码解析

楼主在上篇文章中，提出了将词和字分开，用不同的分词器分别构建索引，来解决match_phrase在中文中的短语或者句子匹配问题。详细的内容请看上一篇文章：为什么要自己写分词器？楼主想要一种分词器，分词器完全按照词典分词，只要是词典有的词语，分词器就一定要分出来。测试了两个分词器比如说IK，MMseg

这两天遇到了一个坑，就是ES的默认排序，对于我们有时候直接把ES当数据库来玩的时候，往往返回的结果的_score都是0, 而ES默认的排序，恰恰就是按 _score的desc。

本篇为elasticsearch源码分析系列文章的第二篇，由于技术不精，而叙述的不好或不对的地方还请大家指出^_^!!!源码主要模块distribution：elasticsearch的打包发行相关，将elasticsearch打成各种发行包（zip，deb，rpm，tar）的模块。具体用法如是，在

这些天在做ES调优，因为之前更多的是考虑ES的架构和可运维性，并没有过多关注query调优这块。今天一查Query Cache相关的内容，发现是少之又少。于是自己深入Dig了下，总算是有所了解。

2017-1-9更新：https://elasticsearch.cn/article/446whythishappened?携程的兄弟给出了答案，看来结论是一致的就是number在构造scorer时，实际上是构造一个巨大的bitset并在上面生成一个迭代器。而keyword在做链表时有跳表查询显然

大促在即，最近几个索引被盯上了，因为出现了类似99.9% 百分位延迟很大的问题，大家都知道，在电商大并发的系统里，任何的延迟抖动最后可能都会导致非常恐怖的崩塌效应，因此最近两周都在仔细地琢磨这个问题，想尽力去解决。