一.搜索处理器简介
所有的请求处理器都实现一个Java类，本例实现了solr.SearchHandler。在运行时，solr.SearchHandler被解析为内置的Solr类org.apache.solr.handler.component.SearchHandler。一般来说，只要在solrconfig.xml文件中看到一个前缀为solr.的类，一般都是Solr的核心Java包之一。在配置文件中利用solr.前缀简写Solr类的名称，运行时再解析至相应的内置Solr类，这种方式让配置文件看起来更加简介有序。
搜索处理器执行过程：
这种设计方式使得应用程序很容易根据实际情况调整Solr的查询处理过程。通常情况下，一个搜索处理器由以下组件组成，其中每个组件都定义在solrconfig.xml文件中。
1.请求参数修饰组件
a.默认值修饰【defaults】：为客户端未指定的值的参数添加默认值
b.常量修饰【invariants】：将客户端的参数值覆写为固定值
c.后缀修饰【appends】：在客户端请求的末尾添加额外参数
2.预处理组件【first-components】：一组优先执行的可选搜索组件，执行预处理任务
3.主搜索组件【components】：一组链式组合的搜索组件，至少包含查询组件
4.后处理组件【last-components】：一组可选的链式组合的搜索组件，执行后处理任务
一般而言，一个请求处理器并不需要定义上述所有组件，比如/select请求处理器仅仅定义了默认值修饰组件。这意味着所有的其他组件均是默认为solr.SearchHandler实现。
二.新建搜索器
Solr的所有查询语句都由一个叫搜索器的组件处理。在Solr中，任何时候都只能存在一个“处于活动状态”的搜索器。所有的搜索请求处理器中的查询组件都向这个处于活动状态的搜索器发起查询请求。
处于活跃状态的搜索器拥有底层Lucene索引快照的只读视图。这意味着，如果将一个新的文档添加到Solr中，它在当前搜索器的搜索结果中是不可见的。如果要搜索到，必须先关闭当前的搜索器，打开一个新的搜索器，这个新的搜索器添加了索引更新以后的只读视图。
在solr web界面查看活跃的搜索器：
每一个commit提交操作都会创建一个新的搜索器，以确保更新后的文档和索引可以被搜索器检索到。首先，旧的搜索器必须被销毁，但旧的搜索器上面可能存在大量查询请求，所以，Solr要等到所有正在进行的搜索都被旧搜索器处理完之后才会执行销毁操作。
同时，所有基于旧搜索器中索引视图的缓存对象都将会失效，新的缓存对象需要重新计算，所以基于索引提交开启一个新的搜索器是一个非常耗费资源的操作，在这个过程中可能造成搜索延迟。所幸，Solr有许多工具可以帮助解决这个问题。最重要的是，Solr支持预热理念，即在后台预热新搜索器，同时保证当前搜索器的活跃状态，直到新搜索器预热完毕。
三.预热新搜索器
Solr秉承一种理念，即允许应用在短时间内提供过期数据，但不允许应用的查询性能有大幅下降。这就是说，在新搜索器预热完成，并准备好处理查询请求前，Solr不会关闭当前活跃的搜索器。
一般而言，Solr有两种预热机制：一种是利用旧缓存自动预热新缓存，另一种是执行缓存预热查询。缓存预热查询就是向搜索器提交一段预先在solrconfig.xml文件中配置好的查询语句，目的是让新搜索器将需要缓存的查询结果载入到缓存中。
注意：一旦Solr中有commit等newSearcher事件发生，这些查询语句就会被执行。只有识别出能够提高查询性能的查询语句时，搜索器的预热才能真正地发挥作用。一般而言，预热查询语句应当包含应用程序中使用最频繁的查询请求参数【q、fq、sort等】。Solr并不一定要有预热查询语句，如果在提交操作之后查询性能出现明显下降，才有必要考虑使用预热查询语句。而且，预热查询语句不易过多，只包含最重要的查询语句即可。
四.第一个搜索器
在Solr初始化过程中或重新加载完一个内核之后，预热第一个搜索器。是否为第一个搜索器配置预热查询语句，这完全由开发者自己决定。大多数的Solr开发者使用完全相同的查询语句来预热新搜索器和第一个搜索器。
与搜索器相关的配置元素：
1.useColdSearcher
适用于一个搜索请求已经提交，而目前Solr中没有定义搜索器的情况。如果它的值为false，那么Solr将会一直处于阻塞状态，直到正在预热的搜索器完成所有预测查询，否则会立即使一个正在预热的搜索器进入活跃状态，而不管搜索器的预热程度如何。
2.maxWarningSearchers
当一个搜索器预热之前又接到提交请求，这意味着在当前搜索器预热完成之前，另一个搜索器的预热又开始了。如果预热时间过长，那么上述情况就会频繁发生。该参数就是控制后台并发预热的搜索器最大数目。一旦达到阈值，新的提交请求将会失败。这是一种很好的保障机制，因为后台并发预热的搜索器过多时会快速耗尽服务器的内存和CPU资源，该参数默认为2。如果发现服务器经常达到阈值，那就需要重新思考预热机制的设计逻辑，看看新搜索器的预热时间是否过长。