elasticsearch源码分析之search模块(client端)

elasticsearch源码分析之search模块(client端)

注意,我这里所说的都是通过rest api来做的搜索,所以对于接收到请求的节点,我姑且将之称之为client端,其主要的功能我们可以简单地概括为将的数据请求发送到node,然后在对返回的结果做处理并返回给调用方,话虽如此,但是过程并非那么简单。

请求初始化

1、api的注册,上一篇已经提到了,所以的api都是通过Guice框架注册进来的,在注册的时候会在controller上将不同的url绑定到不同的handler中:

controller.registerHandler(GET, "/_search", this);
controller.registerHandler(POST, "/_search", this);
controller.registerHandler(GET, "/{index}/_search", this);
controller.registerHandler(POST, "/{index}/_search", this);
controller.registerHandler(GET, "/{index}/{type}/_search", this);
controller.registerHandler(POST, "/{index}/{type}/_search", this);
controller.registerHandler(GET, "/_search/template", this);
controller.registerHandler(POST, "/_search/template", this);
controller.registerHandler(GET, "/{index}/_search/template", this);
controller.registerHandler(POST, "/{index}/_search/template", this);
controller.registerHandler(GET, "/{index}/{type}/_search/template", this);
controller.registerHandler(POST, "/{index}/{type}/_search/template", this);

上述的url都属于search的范畴,

2、当接收到请求后,client端会parseSearchRequest,对于请求进行解析,解析结果用一个SearchRequest来表示,我们来看看包含哪些内容:

其他的不多说,特别地,对于source的解析是核心所在,由parseSearchSource来完成,返回一个SearchSourceBuilder,其主要包含:

private QuerySourceBuilder querySourceBuilder;

private QueryBuilder postQueryBuilder;

private BytesReference filterBinary;

其实就相当于分解动作了,所以的search不外乎都是由这些要素组成,主要包括query、filter、aggs等等。

请求的执行

1、接下来,client会将send request:client.search(searchRequest, new RestStatusToXContentListener<SearchResponse>(channel));,其中channel用于处理回调,返回的类型为SearchResponse

2、对应action的构建:

public void search(final SearchRequest request, final ActionListener<SearchResponse> listener) {
    execute(SearchAction.INSTANCE, request, listener);
}

其中SearchAction.INSTANCE就是一个search action的实例。listener监听回调。

3、用proxy来发送请求到server,上面的proxy其实是一个TransportProxyClient的实例,在Transport模块中其实已经说过了,请求都是由proxy的发送的:

protected <Request extends ActionRequest, Response extends ActionResponse, RequestBuilder extends ActionRequestBuilder<Request, Response, RequestBuilder>> void doExecute(Action<Request, Response, RequestBuilder> action, Request request, ActionListener<Response> listener) {
    proxy.execute(action, request, listener);
}

底层还是调用的TransportService的sendRequest,而发送到的node由DiscoveryNode node = nodes.get((index) % nodes.size());来决定,可以理解为轮训选取一个node(其实这里看到的和我之前的理解是有些大不一样了,我一直以为client端是直接发送给不同的shard所在的node上,再把结果合并起来的,难道之前理解是错的???)。

获取到从node返回的结果之后。由listener通过channel返回给调用方。

总结

client端的工作大体就是这么些了,下一遍再来说说在server端的工作了,server端的会比较麻烦一点,查询还会分query、fetch上面的,下一篇再见咯。

转载请注明出处:http://www.opscoder.info/es_search_client.html

时间: 2024-10-05 16:26:55

elasticsearch源码分析之search模块(client端)的相关文章

Android4.4.2源码分析之WiFi模块(二)

接着上一篇继续对WiFi源码的分析 Android4.4.2源码分析之WiFi模块(一) onResume方法中 6>,首先是调用WiFiEnabler的resume方法对switch进行管理 接下来注册广播 getActivity().registerReceiver(mReceiver, mFilter); 广播监听的action如下 //wifi状态改变的action mFilter.addAction(WifiManager.WIFI_STATE_CHANGED_ACTION); //W

Android4.42-Setting源码分析之蓝牙模块Bluetooth(下)

接着上一篇Android4.42-Settings源码分析之蓝牙模块Bluetooth(上) 继续蓝牙模块源码的研究 THREE,蓝牙模块功能实现 switch的分析以及本机蓝牙重命名和可见性的分析见上一篇,接下来进行第三章第三部分的介绍:关于蓝牙远程设备列表的加载.如果没有看过,建议看看上一篇关第一章蓝牙的布局,有助于理解 3>,设备列表的加载 因为这部分代码很多,所以在介绍时先说一下思路,程序首先通过底层的BluetoothAdapter的getBondedDevices()方法获取到已配对

Android4.4.2源码分析之WiFi模块(一)

由对Androidsetting的源码分析之WiFi模块的界面fragment为WiFisettings.java,关于setting模块的源码分析可以参考 Android系统源码剖析(一)---Settings 已经写了几篇关于Android源码的,源码代码量太大,所以如果想分析某个模块可能不知如何下手,说一下思路 1,分析源码英文阅读能力要够,想要分析某个模块一般找模块对应的英文,就是模块 2,找到之后首先查看清单配置文件Androidmani.fest,找到程序主界面activity 3,

[nginx] nginx源码分析--健康检查模块锁分析

健康检查模块 见前文:[nginx] nginx源码分析--健康检查模块 其中有一张框架图, 接下来的内容,将会利用到这个图中的内容. [classic_tong @ https:////www.cnblogs.com/hugetong/p/12274125.html ]  描述 我们知道nginx是多进程的,每个进程都保存了相同的配置.但是实际上, 并不需要每一个进程对每一个后端服务器进行. 于是健康检查模块在这里需要一个进程间同步机制,用来协商哪一个进程对 哪一个后端服务器进行检查. 接下来

Docker源码分析(二):Docker Client创建与命令执行

1. 前言 如今,Docker作为业界领先的轻量级虚拟化容器管理引擎,给全球开发者提供了一种新颖.便捷的软件集成测试与部署之道.在团队开发软件时,Docker可以提供可复用的运行环境.灵活的资源配置.便捷的集成测试方法以及一键式的部署方式.可以说,Docker的优势在简化持续集成.运维部署方面体现得淋漓尽致,它完全让开发者从持续集成.运维部署方面中解放出来,把精力真正地倾注在开发上. 然而,把Docker的功能发挥到极致,并非一件易事.在深刻理解Docker架构的情况下,熟练掌握Docker C

jQuery 源码分析(十一) 队列模块 Queue详解

队列是常用的数据结构之一,只允许在表的前端(队头)进行删除操作(出队),在表的后端(队尾)进行插入操作(入队).特点是先进先出,最先插入的元素最先被删除. 在jQuery内部,队列模块为动画模块提供基础功能,负责存储动画函数.自动出队并执行动画函数,同时还要确保动画函数的顺序执行. jQuery的静态方法含有如下API: $.queue(elem,type,data) ;返回或修改匹配元素关联的队列,返回最新的队列,参数如下:   elem ;DOM元素或JavaScript对象 type  ;

WebRTC源码分析:音频模块结构分析

一.概要介绍WebRTC的音频处理流程,见下图: webRTC将音频会话抽象为一个通道Channel,譬如A与B进行音频通话,则A需要建立一个Channel与B进行音频数据传输.上图中有三个Channel,每个Channel包含编解码和RTP/RTCP发送功能. 以一个Channel而言,应用程序中将包含三个活动线程,录音线程,音频接收线程和播放线程. 1)录音线程:负责麦克风音频的采集,见图中红色路径,采集到音频后,缓存到一定长度,进行音频处理,主要包括EC,AGC和NS等.然后送到Chann

[Abp 源码分析]四、模块配置

0.简要介绍 在 Abp 框架当中通过各种 Configuration 来实现模块的配置,Abp 本身提供的很多基础设施功能的一些在运行时的行为是通过很多不同的 Configuration 来开放给用户进行一些自定义配置的. 比如说缓存模块,我要配置缓存的过期时间,Abp 默认是 1 个小时,但是我也可以自己来定义,直接赋值或者从配置项来读取都是由具体使用者来控制的,所以 Abp 通过各种 Configuration 类来控制一些运行时参数. 这些 Abp 本身基础设施的配置类都是存放在 \Ab

jquery源码分析(七)——事件模块 event(二)

上一章节探讨了事件的一些概念,接下来看下jQuery的事件模块. jQuery对事件的绑定分别有几个API:.bind()/.live()/.delegate()/.on()/click(), 不管是用什么方式绑定,归根到底还是用addEventListener/attachEvent(IE)处理的,正如jQuery的选择器一样不管如何匹配最终还是使用浏览器提供的几个接口处理. 那么现在就有个疑问,事件为什么还要区分那么多不同的处理方案? 这里就要涉及到之前提到的 DOM 事件处理模型了,捕获与