Solr基本配置（三）——Searcher

Posted 2023-04-23

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Solr基本配置（三）——Searcher相关的知识，希望对你有一定的参考价值。

参考技术A <query />
　　在标签<query/>里面可以进行一些优化搜索的配置。在Solr的查询过程中，运用到一个叫searcher的组件，在一个特定的时间只能有一个“active”的searcher。这个active searcher在Lucene索引中有一个只读的映射。当新的document加入到Solr的时候，当前的searcher在搜索结果中是看不到这个新加的document的。那么问题就来了：怎么样才能让新添加的文件出现在搜索结果中？一个解决这个问题的办法就是关闭当前的searcher并对新的索引文件打开一个新的searcher。
　　在admin界面中，查看collection1的Plugins/Status，点击core：
　　

第一行展示的就是当前的Searcher，当我们重新对文件建立索引，在example的exampledocs下运用：
　　Java -jar post.jar *.xml:
　　刷新界面：　

可以看到Searcher改变了。这是因为post.jar提交个commit指令。从上面的示例我们知道commit指令可以创建一个新的searcher，使得可以检索到最新的文件，当新searcher创建的时候要先销毁旧的searcher。这时候如果还有基于旧searcher的查询在进行中，Solr就要等待所有进行中的查询结束。然后，所有基于当前searcher的cached对象都要失效。因为之前建立起来的cache都失效了，所以建立一个新的searcher可能是很耗时的。假设一个用户在返回的结果中进行翻页操作，当用户从第二页翻到第三页的时候一个新的searcher打开了，此时用户就会一直等待第三页的加载，但是这时候之前加载的document都已经失效，所以就会让用户感觉到加载很慢。
　　对于上述问题，Solr提供了一系列的工具，Solr在建立一个searcher的时候有称为warming的概念，即让新的searcher在后台建立，并让当前的searcher继续工作直到后台的searcher完全warm。
　　
Warming a new searcher
　　Solr运用这个策略来使得在一段时间内还是返回旧的结果，而避免用户因为新建searcher而降低查询的性能。有两种warming的策略：autowarming new caches from the old caches（从旧的cache中创建新的cache）和execute cache-warming queries(重新执行一些queries来填充新的cache)。
　　Cache-warming queries是一种preconfigured query来构建新searcher的cache。

上面的配置定义了一系列的queries当newSearcher事件出现的时候就执行（如在commit之后）。

<useColdSearcher/>
　　如果为false，那么Solr就会阻塞直到warming searcher完成所有的warming queries。
　　<useColdSearcher>false</useColdSearcher>
　　如果为true，Solr会马上注册一个warming searcher。

<maxWarmingSearchers>
　　定义在后台可以同时warming的最大searcher数量。默认值为2.

Solr集群搭建详细教程

注：欢迎大家转载，非商业用途请在醒目位置注明本文链接和作者名dijia478，商业用途请联系本人[email protected]。

之前步骤：Solr集群搭建详细教程（一）

三、solr集群搭建

注意，在搭建solr集群前，建议最好有一个solr服务是已经搭建好的，可以简化大量重复的配置操作。

单机solr服务搭建过程参看我的这篇文章：

Solr服务在Linux上的搭建详细教程

这个单机solr服务在solr集群搭建第二步和第三步里需要，搭建好一个solr服务后，就可以进行集群搭建了。

第一步：创建四个tomcat实例。每个tomcat运行在不同的端口。8180、8280、8380、8480

上传解压步骤省略，这是我解压好的

技术分享图片

复制tomcat到之前搭建zookeeper集群第四步时，创建的/usr/local/solr-cloud目录里，复制4个

技术分享图片

去solr-cloud目录，发现已经复制好了4个tomcat目录

在tomcat目录下的conf里的server.xml，修改每个tomcat的端口号，这里只演示第一个目录的，另外三个都要改，端口要互不冲突

技术分享图片

用/port命令搜索port字符串，按n搜索下一个，有三个地方要改，依次更改为

技术分享图片

其他三个tomcat目录里的server.xml配置的端口按照234的顺序全改了啊，具体过程这里我就不截图了。

一共要改四个文件，每个文件里改三个地方，这12个端口号要互不冲突

技术分享图片

第二步：把单机版的solr工程复制到集群中的tomcat中

在搭建好的单机solr服务里（这里是另一篇教程，上面说过了），复制solr工程到第一步的4个tomcat目录里，一共是复制4份

技术分享图片

第三步：为每个solr实例创建一个对应的solrhome。使用单机版的solrhome复制四份

一样在之前搭建的单机solr服务里，把solrhome复制4份出来到solr-cloud目录里

技术分享图片

现在solr-cloud目录里是有这些目录，检查一下有没有复制错地方的：

技术分享图片

第四步：配置solrCloud相关的配置。每个solrhome下都有一个solr.xml，把其中的ip及端口号配置好

之前搭建单机版solr服务的时候没有动过solrhome里的这个文件，现在搭建集群了，需要进行修改

技术分享图片

需要修改4个solr.xml，我这里还是只演示第一个，另外三个目录里的类比着改，一样的，就是1234的顺序

找到这个地方，第一个红框代表当前节点的ip地址，就是你部署这个solrhome01，tomcat01集群节点的服务器ip，实际工作中就是会部署4个服务器，一个服务器是一个节点，部署一个solr服务

第二个红框代表当前solr服务实例的端口号，就是所在的tomcat的端口号，就是第一步在tomcat01的server.xml里配置的8180

技术分享图片

我的配置完后是这样的

技术分享图片

其他三个照着改啊，由于我是在一台虚拟机搭建的四个实例，所以肯定四个实例的ip是一样的，但端口分别是8180，8280，8380，8480

技术分享图片

第五步：需要修改solr服务的web.xml文件。把solrhome关联起来

修改这个文件，和之前单机版的solr配置是一样的

要注意的是，tomcat01这里的solr服务，是上面第二步复制过来的对吧，是我之前用solr7搭建的单机solr服务，里面的配置和solr4不太一样，具体还是去文章最上面看我提供的单机solr服务搭建教程链接

技术分享图片

找到这个，这里是我之前搭建单机solr服务时，配置的solrhome路径

技术分享图片

现在改成集群的solrhome01目录，使他们关联起来

技术分享图片

其他三个tomcat里的web.xml都对应着一改，solrhome02，03，04

技术分享图片

第六步：让zookeeper统一管理配置文件。需要把/conf目录上传到zookeeper

现在我们每一个solr都有了自己的solrhome，现在我们要让每一个solr实例的配置文件都一样，这个配置文件需要集中管理，这个时候我们使用zookeeper来统一管理配置文件。所以要将配置文件上传到zookeeper中。那么上传哪些配置文件呢？

这里注意下managed-schema文件，网上有很多低版本solr，会提到一个collection1/conf下的schema.xml，但是并没有找到。好像是从5.0版本开始不使用schema.xml的，这俩其实内容都一样，搞不懂为啥要换个名字，而且内容格式是xml，但是文件名却没有.xml的后辍，这里直接上传整个conf目录就行。

技术分享图片

知道了要上传什么，那么怎么上传呢？打开最早solr解压出来的原始文件（如果删了那就重新上传解压吧）

技术分享图片

在这个目录下有个脚本文件，执行这个脚本就可以将配置文件上传到zookeeper了，有点难找，我是用find命令给搜出来的。不过我这里给出了pwd路径

技术分享图片

要注意，在执行脚本上传配置文件前，必须先去启动zookeeper集群

技术分享图片

然后回来执行脚本

这里脚本的执行命令有点长，主要是参数多，建议复制出来改好后再粘贴上去

./zkcli.sh -zkhost 192.168.25.128:2181,192.168.25.128:2182,192.168.25.128:2183 -cmd upconfig -confdir /usr/local/solr-cloud/solrhome01/configsets/sample_techproducts_configs/conf -confname myconf

技术分享图片

我解释下各个参数的含义：

红色框代表zookeeper集群的ip和端口号列表（搭建zookeeper集群的时候配置过的）

绿色框代表要执行的是上传配置文件操作

黄色框代表的是要上传的配置文件目录（低版本不太一样，具体以那两个主要的配置文件所在目录为准，不知到在哪就find命令搜吧）

紫色框代表的是你给上传的配置起的名字，可以改

现在上传完了，那么我们怎么确定是否上传成功呢？去zookeeper集群的一个目录找到bin里zookeeper的客户端脚本

技术分享图片

运行后，里面会出现一大堆内容，如果你不指定参数，他会默认访问localhost:2181

技术分享图片

在最下面执行这个命令，查看在根目录下有什么，发现一个configs

技术分享图片

再看它里面有什么？哈！

技术分享图片

这就是我们刚才上传的配置了，名字一样的，代表上传成功了

然后用quit命令退出

技术分享图片

如果你需要修改配置的话，只用在刚才那个conf目录里改好，改好后再上传一次就行了，就会覆盖原来的配置文件

第七步：修改tomcat/bin目录下的catalina.sh 文件，关联solr和zookeeper

现在上传好配置文件了，可是solr和zookeeper还没有建立任何关系，他们也不知道对方在哪里，这个时候需要修改4个tomcat的配置文件，这里只演示tomcat01，其他三个完全相同照着改

技术分享图片

打开catalina.sh文件，加一个JAVA_OPTS这个参数，初始化这个值完了会传给solr，注意不是在这个截图这里修改啊

技术分享图片

用/JAVA_OPTS搜索红色框框里的这句话（因为低版本加的位置长的不太一样，但这句话的例子是不变的），在这句话下面的位置加（注意位置啊，不要弄错了）：

技术分享图片

加上JAVA_OPTS的值（zookeeper集群的ip列表）：

JAVA_OPTS="-DzkHost=192.168.25.128:2181,192.168.25.128:2182,192.168.25.128:2183"

技术分享图片

然后把其他三个tomcat也一改，改的位置和内容是一样的，不用变

技术分享图片

这样每个solr实例就通过这个参数和zookeeper集群建立了联系，solr会将自己的状态发送给zookeeper，比如ip地址啊，端口号啊，zookeeper就可以连接到solr了，建立了通信关系

第八步：启动每个tomcat实例。要包装zookeeper集群是启动状态

现在需要启动每个tomcat，当然了，这个和启动zookeeper集群一样，要一个一个进去启动，太麻烦了，还是写个批处理脚本来运行

技术分享图片

/usr/local/solr-cloud/tomcat01/bin/startup.sh
/usr/local/solr-cloud/tomcat02/bin/startup.sh
/usr/local/solr-cloud/tomcat03/bin/startup.sh
/usr/local/solr-cloud/tomcat04/bin/startup.sh

技术分享图片

保存，退出

技术分享图片

发现没有运行权限，添加权限

技术分享图片

然后运行脚本，等等啊，tomcat集群启动比较慢

技术分享图片

如果你想看启动起来没，可以复制一个会话窗口（我用的xshell5），去看看tomcat的日志信息（相当于看控制台打印信息）

技术分享图片

用这个命令查看，我这就查看一个，应该已经启动好了

技术分享图片

这里说个小知识点，tomcat8开始，默认启动的是NIO模式，7默认启动的是BIO模式，还可以通过配置设置APR模式启动，至于APR，NIO和BIO的区别，是和tomcat并发性能有关的，高并发的系统应该将tomcat的模式设置成APR模式，会大幅度的提高服务器的处理和响应性能。感兴趣的可以自己百度下。当然这个不用在意，跟本文集群搭建没啥关系，就是想到了说一下。