[转载] sensei分布式实时搜寻系统源码解析(一) senseiServer的启动及若干概念
[转载] sensei分布式实时搜索系统源码解析(一) senseiServer的启动及若干概念
看来自己很懒，发现前同事的sensei 研究了
转载：http://johnnychenjun.blog.163.com/blog/static/137493406201161163651879/
一、源码结构
首先，先从github将 sensei源码 取下。从整体代码结构上来看主要分为如下几类：
![[转载] sensei分布式实时搜寻系统源码解析(一) senseiServer的启动及若干概念](/default/index/img?u=aHR0cDovL3d3dy5teWV4Y2VwdGlvbnMubmV0L2ltZy8yMDEyLzA2LzI0LzIzMDk0OTEwNjIuanBn "[转载] sensei分布式实时搜寻系统源码解析(一) senseiServer的启动及若干概念")
1. 提供多种index的提供数据的方式，主要在dataprovider下的几个包，及gateway下的几个包。
2. 提供client端调用的查询服务client及servlet，servlet下为提供包装搜索查询的servlet服务。
3. nodes下包含了在一个服务器上启动node入口类，senseibroker，以及一些本地配置类。
4. svc下的包顾名思义是sensei提供核心服务的类，如SenseiService。
5. req包下的为protobuf相关的消息转化的部分。
6. cluster 下提供了一些面向索引集群的负载均衡的实现。
二、 SenseiServer
基本了解代码结构后，可以从官方getting started 里面的内容来深入了解Sensei的运作原理： bin/sensei-client.sh client-conf 启动的是SenseiServer。
作为Server Node的入口类，main函数创建SenseiServerBuilder，该builder才真正建立一个jettyserver和senseiServer。
jettyServer其实是建立了一个web服务器，提供服务由SenseiHttpInvokerServiceServlet，DefaultSenseiJSONServlet来提供senseiservlet，初始化的时候从WebAppContext将相应的上下文设置上去，主要是跟sensei相关的配置文件被注入。
需要注意的是，上述Servlet在生成的时候延时加载的，刚开始看了半天没明白相关配置是如何加载进去的，最后在jettyServer.start()时WebAppContext里的相关配置才加载如servlet。
SenseiHttpInvokerServiceServlet 的功能实际由 ClusteredSenseiServiceImpl 提供，这个才是真正提供sensei查询服务的service。
这个ClusteredSenseiServiceImpl中的成员变量SenseiBroker 是做分布式query的broker，承担了loadbalance的调用和mergeresult的任务。
而SenseiServer中的成员_networkServer 才是提供本地node节点查询服务的NettyNetworkServer，这个NettyNetworkServer 注册了Message handler，来处理来自broker的请求。NettyNetworkServer是由norbert框架提供的，注册服务需要提供，inputmessage，outputmessage格式，及处理message的handler。本质是一个由CoreSenseiServiceImpl提供服务的SenseiCoreServiceMessageHandler。NettyNetworkServer其实是提供了通过protobuf来通讯，而CoreSenseiServiceImpl做target的服务。
至此，可能大家刚入sensei的也和我一样会产生一些概念上的疑惑，jettyServer/SenseiServer/_networkServer/clusterclient/等等，多种server和client会让人有点晕。其实理解起来主要是谁调用谁的问题，在sensei里面，存在着多种client/server的调用，如作为索引服务Server的node同样会是zookeeper的client，而jettyServer是一个http的Server来提供外部client的调用，同时该node作为senseibroker来调用另一个node的NettyNetworkServer的某shard的数据，则此时该node又变为其他Server的client。
NettyNetworkServer NettyNetworkClient分别代表着通过norbert进行调用的Server和client。
回到SenseiServer这个入口类，其中包含几个成员变量：
_networkServer 这个作为一个senseinode 提供网络服务的server
_serverNode 当前的servernode相关信息
_clusterClient 作为zookeeper的一个client来与zookeeper进行交互，如获取最新的节点变更
_innerSvc 提供sensei的核心服务的类
_externalSvc 一些扩展服务的类。
本来按照个人之前的解决搜索分布式的方案，自己实现的话，将可能采用更加熟悉的http方式的调用，但看到linkedin的这种方案，
之所以选用NettyNetworkServer 应该是linkedin考虑到提供高并发，低延时服务时的性能问题，选用了NIO的netty+protobuf来处理broker至一个node的服务请求。
下一章将详细介绍 Sensei的整个search的过程。