从功能上说,可以分为两部分,分布式功能和数据功能.分布式功能主要是节点集群及集群附属功能如restful借口.集群性能检测功能等,数据功能主要是索引和搜索.代码上这些功能并不是完全独立,而是由相互交叉部分.当然分布式功能是为数据功能服务,数据功能肯定也难以完全独立于分布式功能. 它的源码有以下几个特点: 模块化:每个功能都以模块化的方式实现,最后以一个借口向外暴露,最终通过guice(google轻量级DI框架)进行管理.整个系统有30多个模块(version1.5). 接口解耦:es代码中使用

前期博客是 Elasticsearch之源码编译 (1)elasticsearch在建立索引时,根据id或(id,类型)进行hash,得到hash值之后再与该索引的分片数量取模,取模的值即为存入的分片编号.源码:org.elasticsearch.cluster.routing.OperationRouting类中的generateShardId方法 (2)可以指定把数据存储到某一个分片中,通过routing参数 curl -XPOST '192.168.80.10:9200/zhouls/em

_field_stats 实现的功能:https://www.elastic.co/guide/en/elasticsearch/reference/5.6/search-field-stats.html 获取索引下字段的统计信息,如下表,同时还可以针对这些统计值进行过滤: Field statistics The field stats api is supported on string based, number based and date based fields and can re

ElasticSearch Index操作源码分析 本文记录ElasticSearch创建索引执行源码流程.从执行流程角度看一下创建索引会涉及到哪些服务(比如AllocationService.MasterService),由于本人对分布式系统理解不是很深,所以很多一些细节原理也是不懂. 创建索引请求.这里仅仅是创建索引,没有写入文档. curl -X PUT "localhost:9200/twitter" ElasticSearch服务器端收到Client的创建索引请求后,是从or

原文地址:https://mp.weixin.qq.com/s?__biz=MzU2Njg5Nzk0NQ==&mid=2247483694&idx=1&sn=bd03afe5ab798b4732c1a3457d60c53b 本篇介绍一下如何从源码构建Elasticsearch,构建Elasticsearch源码是学习和研究Elasticsearch源码的基础,有助于更好的了解Elasticsearch. 环境准备 环境/软件 版本 备注 OS Ubuntu 14.04 LTS Gr

ElasticSearch 启动时加载 Analyzer 源码分析 本文介绍 ElasticSearch启动时如何创建.加载Analyzer,主要的参考资料是Lucene中关于Analyzer官方文档介绍.ElasticSearch6.3.2源码中相关类:AnalysisModule.AnalysisPlugin.AnalyzerProvider.各种Tokenizer类和它们对应的TokenizerFactory.另外还参考了一个具体的基于ElasticSearch采用HanLP进行中文分词的

Elasticsearch源码分析—线程池(十一) 转自:https://www.felayman.com/articles/2017/11/10/1510291570687.html 线程池 每个节点都有一些线程池来优化线程内存的消耗,按节点来配置管理.有些线程池还拥有与之关联的队列配置,用来允许挂住一些未处理的请求,而不是丢弃它. Elasticsearch对线程池的处理的源码在org.elasticsearch.node.Node中,核心代码为: final ThreadPool thre

elasticsearch源码分析之search模块(server端) 继续接着上一篇的来说啊,当client端将search的请求发送到某一个node之后,剩下的事情就是server端来处理了,具体包括哪些步骤呢? 过程 一.首先我们来看看接收地方其实就是在org.elasticsearch.action.search.TransportSearchAction中,收到请求之后会判断请求的index的shard是否只有一个,如果是一个的话,那么会强制将请求的type设置为QUERY_AND_F

elasticsearch源码分析之search模块(client端) 注意,我这里所说的都是通过rest api来做的搜索,所以对于接收到请求的节点,我姑且将之称之为client端,其主要的功能我们可以简单地概括为将的数据请求发送到node,然后在对返回的结果做处理并返回给调用方,话虽如此,但是过程并非那么简单. 请求初始化 1.api的注册,上一篇已经提到了,所以的api都是通过Guice框架注册进来的,在注册的时候会在controller上将不同的url绑定到不同的handler中: co

Solr4.8.0源码分析(13)之LuceneCore的索引修复 题记:今天在公司研究elasticsearch,突然看到一篇博客说elasticsearch具有索引修复功能,顿感好奇,于是点进去看了下,发现原来是Lucene Core自带的功能.说实话之前学习Lucene文件格式的时候就想做一个索引文件解析和检测的工具,也动手写了一部分,最后没想到发现了一个已有的工具,正好对照着学习下. 索引的修复主要是用到CheckIndex.java这个类,可以直接查看类的Main函数来了解下. 1.

背景 在基于elk的日志系统中,filebeat几乎是其中必不可少的一个组件,例外是使用性能较差的logstash file input插件或自己造个功能类似的轮子:). 在使用和了解filebeat的过程中,笔者对其一些功能上的实现产生了疑问,诸如: 为什么libbeat能如此容易的进行扩展,衍生出多个应用广泛的beat运输程序? 为什么它的性能比logstash好? (https://logz.io/blog/filebeat-vs-logstash/) 是如何实现‘保证至少发送一次’这个f

文章目录 1. 开箱即用,内藏玄机 2. 总结 3. 源代码 Spring Boot提供了很多”开箱即用“的依赖模块,那么,Spring Boot 如何巧妙的做到开箱即用,自动配置的呢? 开箱即用,内藏玄机 Spring Boot提供了很多”开箱即用“的依赖模块,都是以spring-boot-starter-xx作为命名的.例如,之前提到的 spring-boot-starter-redis.spring-boot-starter-data-mongodb.spring-boot-starter

ElasticSearch-hadoop saveToEs源码分析: 类的调用路径关系为: EsSpark -> EsRDDWriter -> RestService -> RestRepository -> RestClient 他们的作用: EsSpark,读取ES和存储ES的入口 EsRDDWriter,调用RestService创建PartitionWriter,对ES进行数据写入 RestService,负责创建 RestRepository,PartitionWrite

开篇 在ElasticSearch 系列十四中提到的问题即 ElasticStack系列之十四 & ElasticSearch5.x bulk update 中重复 id 性能骤降,继续这个问题再继续查看更加多的源代码,看看底层在执行 index.create 和 update 操作到底有什么不同,有什么可以使得我们使用性能更加好的. 准备 使用 Intellij IDEA 来阅读 ElasticSearch 源码,操作相对来说比较简单.具体操作步骤如下: 1. 下载 ElasticSearch

ElasticSearch6.3.2源码分析之节点连接实现 这篇文章主要分析ES节点之间如何维持连接的.在开始之前,先扯一下ES源码阅读的一些心得:在使用ES过程中碰到某个问题,想要深入了解一下,可源码又太多了,不知道从哪里入手,怎么办?ES启动的入口类是Elasticsearch.java,顺着这个启动流程,到Node类的构造方法:org.elasticsearch.node.Node#Node(org.elasticsearch.env.Environment, java.util.Coll

前文回顾 CommitLog篇 --[RocketMQ源码分析]深入消息存储(1) ConsumeQueue篇 --[RocketMQ源码分析]深入消息存储(2) 前面两篇已经说过了消息如何存储到CommitLog,以及ConsumeQueue的构建流程,到了第三篇,我们有一个不得不跨过的坎儿,MappedFile -- 内存文件映射. MappedFile的存在是RocketMQ选择将消息直接存储到磁盘的关键因素,在第一篇CommitLog存储流程开篇中,我就写过一个思路. 即用到内存又用到本

ABP是一套非常优秀的web应用程序架构,适合用来搭建集中式架构的web应用程序. 整个Abp的Infrastructure是以Abp这个package为核心模块(core)+15个模块(module).其中13个依赖于Abp这个核心包.另外两个包(FluentMigration,Web.Resources)相对独立 Abp.AutoMapper: 实现对象之间的自动映射. Abp.EntityFramework:通过EntityFramework实现数据访问层. Abp.FluentMigra

1. 引言     在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Java这么久,也写过一些小项目,也使用过TreeMap无数次,但到现在才明白它的实现原理).因此本着"不要重复造轮子"的思想,就用这篇博客来记录分析TreeMap源码的过程,也顺便瞅一瞅HashMap. 2. 继承结构 (1) 继承结构 下面是HashMap与TreeMap的继承结构: pu

nginx作为一个高性能的HTTP服务器,网络的处理是其核心,了解网络的初始化有助于加深对nginx网络处理的了解,本文主要通过nginx的源代码来分析其网络初始化. 从配置文件中读取初始化信息 与网络有关的配置命令主要有两个:listen和sever_name.首先先了解这两个命令的用法. listen listen命令设置nginx监听地址,nginx从这里接受请求.对于IP协议,这个地址就是address和port:对于UNIX域套接字协议,这个地址就是path. 一条listen指令只能

leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcessor -> ProposalRequestProcessor ->CommitProcessor -> Leader.ToBeAppliedRequestProcessor ->FinalRequestProcessor 具体情况可以参看代码: @Override protected v

上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析各自一下消息处理过程: 前文可以看到在 1.在单机情况下NettyServerCnxnFactory中启动ZookeeperServer来处理消息: public synchronized void startup() { if (sessionTracker == null) { createSe