ITPub博客

本篇只关注一个细节，就是在一个端到端的场景，一个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% 百分位延迟很大的问题，大家都知道，在电商大并发的系统里，任何的延迟抖动最后可能都会导致非常恐怖的崩塌效应，因此最近两周都在仔细地琢磨这个问题，想尽力去解决。

elasticsearch是什么不再赘述。本文希望通过对ES源代码进行一些简单的分析，目的在于打通整个结构，了解整个运行方式，以及如果我需要对源代码进行简单的调整和修改我需要从哪里入手，抛砖引玉。本文选择了elasticsearch2.3.5的版本来进行分析调试，适用于2.x的版本。

Elasticsearch 的发现模块应该算是保证Elasticsearch启动并正常工作最基本的模块了，可以这么理解，如果启动一个实例后，它连最基本的加入一个“组织”都失败的话那么它将无法提供服务。

双十一来临，大家应该要对所有索引都做做健康检查了，由于最近压力上不去，所以盯上了Query Cache，由于之前Query Cache没有怎么注意，一直用的是默认配置，所以导致我发现cache的效率一直没上去。如下图，初步一看命中率50%+， Memory size 也没伤到预订大小，这里先不逐个字段解释，下面就以问答的形式来介绍一下这个query cache。

High cardinality下对持续写入的Elasticsearch索引进行聚合查询的性能优化

Amazon Redshift 集群管理指南

目前我们已经将两台 Web 服务器放在两个不同的可用区，并在 Web 服务器前放置一个应用负载均衡器 ALB，接着我们把后端的数据库架设起来，如图 1 所示，今天要介绍的是 Amazon 的关系数据库 Amazon Relational Database Service 简称 Amazon RDS 。