1 Configuring solrconfig.xml
solrconfig.xml文件中包含了Solr需要的大部分参数，当你配置Solr时，你会经常性地使用solrconfig.xml。你可能会配置下述的一些重要特征，包括：
- request handlers（请求控制器）;
- listeners（监听器，监听与具体的查询请求相关的时间；
- 监听器可以用来触发执行特定代码，比如使用共同的查询使缓存升温），请求调度管理Http通信;
- Admin网络管理接口;
- 与复制、备份相关的参数（这些参数的具体信息在Legacy Scaling and Distribution中）。
solrconfig.xml文件可以在solr/conf/目录下找到。作为示例的文件包括了良好的注释信息，也包括了适用于大多数情况的配置信息。
这一章节包含了下列主题：
- DataDir and DirectoryFactory in SolrConfig
- Lib Directives in SolrConfig
- Managed Schema Definition in SolrConfig
- IndexConfig in SolrConfig
- UpdateHandlers in SolrConfig
- Query Settings in SolrConfig
- RequestDispatcher in SolrConfig
- RequestHandlers and SearchComponents in SolrConfig
Substituting Properties in Solr Config Files
Solr支持在配置文件中替换属性变量的值，即它允许在solrconfig.xml中定制各种运行时配置。这里的语法是：${propertyname[:option default value]}。它允许定义默认的值并在Solr载入时使用（原文用的是overridden）。如果一个属性的默认值没有设定，那么这个属性必须在运行时设定，否则配置文件将会在被分析的时候产生错误。
这里提供了多种方法在配置文件中设置属性。
JVM System Properties
任何JVM系统属性，通常在启动时使用-D标志指定，可以在Solr中作为任意XML配置文件的变量使用。
例如，在作为示例的solrconfig.xml中，你可以看到被定义为锁类型的值的使用。
<lockType>${solr.lock.type:native}</lockType>
这表示锁类型被默认为“native”，但是当启动Solr的示例应用时，你可以通过启动JVM来覆写这个值：
java -Dsolr.lock.type=simple -jar start.jar
solrcore.properties
如果配置设定的Solr core的路径下包含一个名为solrcore.properties的文件，那么这个文件可以包含任意由用户定义的、符合Java标准属性格式的属性名和属性值。这些属性（和值）可以作为配置Solr core的XML文件的变量使用。
例如，可以在Solr实例的配置文件路径solr/collection1/conf下创建下面的solrcore.properties文件，用来设置lockType的使用：
#conf/solrcore.properties
lock.type=simple
注意！solrcore.properties文件的路径和名称可以在属性文件（？）core.properties中被重写。
User defined properties from core.properties
如果使用新的solr.xml的发现模式（？），即每个Solr core拥有一个core.properties文件，那么任何用户都可以在文件中定义特定的属性，并且这些属性在分析Solr core的XML配置文件被替换。
例如，考虑下面的core.properties文件：
#core.properties
name=collection2
my.custom.prop=edismax
其中，my.custom.prop属性可以作为变量使用：
<requestHandler name="/select">
<lst name="defaults">
<str name="defType">${my.custom.prop}</str>
</lst>
</requestHandler>
User defined properties from the Legacy solr.xml Format
类似于上面的core.properties选项，用户定义的属性应该在传统格式的solr.xml中指定。请参考“User Defined Properties in solr.xml”部分中关于传统的solr.xml配置文档以获得更多细节。
Implicit Core Properties
一些在Solr core中“隐式”的属性有多个替代值，独立于它们何时或也何种方法初始化。举个例子：不考虑一个特定的Solr core的名字是否显式地配置在core.properties中或者有示例的目录名推断获得，隐式的属性solr.core.name可以在core的配置文件中作为一个变量出现……
<requestHandler name="/select">
<lst name="defaults">
<str name="collection_name">${solr.core.name}</str>
</lst>
</requestHandler>
所有隐式的属性使用“solr.core.”作为名字的前缀，并且会反射到相同的core.properties属性的运行时的值（？）
solr.core.name
solr.core.config
solr.core.schema
solr.core.dataDir
solr.core.transient
solr.core.loadOnStartup
More Information
- Solr Wiki拥有关于solrconfig.xml的完成的页面，在http://wiki.apache.org/solr/SolrConfigXml.
- 6 Sins of solrconfig.xml modifications from solr.pl
1.1 DataDir and DirectoryFactory in SolrConfig
Solr默认存储它的索引文件在Solr home的/data路径下。如果你想要设定一个不同的路径存储索引文件，那么请使用solrconfig.xml中的参数。你可以设定另一个文件路径。你可以使用完整的路径或者相对于当前servlet容器的工作路径的路径。例如：
<dataDir>/var/data/solr/</dataDir>
如果你使用了Solr索引文件的备份（在Legacy Scaling and Distribution部分有说明），那么路径应当同配置备份时使用的索引路径相符合。
Specifying the DirectoryFactory For Your Index
默认的solr.StandardDirectoryFactory是基于文件系统的，并且试图选择对当前JVM和平台最好的实现。你可以通过设定 solr.MMapDirectoryFactory，solr.NIOFSDirectoryFactory或者 solr.SimpleFSDirectoryFactory强行设置一个特定的实现。
<directoryFactory name="DirectoryFactory"
class="${solr.directoryFactory:solr.StandardDirectoryFactory}"/>
solr.RAMDirectoryFactory是基于内存的，非持久的，并且和备份无关。通过使用DirectoryFactory在RAM中存储索引文件：
<directoryFactory class="org.apache.solr.core.RAMDirectoryFactory"/>
1.2 Lib Directives in SolrConfig
Solr允许通过在solrconfig.xml中定义指令载入插件。
这些插件按照它们出现在solrconfig.xml中的顺序被载入。如果存在依赖，那么将最低层次的依赖jar放在最前面。
正则表达式可以用于支持载入jar包过程的控制（这依赖于其他在同一路径下的jar包）。所有路径值都是相对于Solr instanceDir的相对路径。
<lib dir="../../../contrib/extraction/lib" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-cell-\d.*\.jar" />
<lib dir="../../../contrib/clustering/lib/" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-clustering-\d.*\.jar" />
<lib dir="../../../contrib/langid/lib/" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-langid-\d.*\.jar" />
<lib dir="../../../contrib/velocity/lib" regex=".*\.jar" />
<lib dir="../../../dist/" regex="solr-velocity-\d.*\.jar" />
1.3 Managed Schema Definition in SolrConfig
Schema API使得通过REST接口修改schema成为可能（也支持以只读形式访问所有schema元素）。
允许程序访问一个配置文件，并同时允许手动编辑配置文件，这种规则产生了一些挑战：系统生成和手动编辑可能产生重叠，系统生成的编辑可能会删除注释或者其他帮助理解域、域类型的关键性的自定义内容。你可能希望通过源码控制标记（配置）文件的版本，或者同时限制手动编辑。
Solrconfig.xml允许Solr schema被定义为“被管理的索引模式”：只能通过Schema API修改schema。下面是例子：
<!--
<schemaFactory class="ManagedIndexSchemaFactory">
<bool name="mutable">true</bool>
<str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>
-->
<schemaFactory class="ClassicIndexSchemaFactory"/>
在上面的例子中， solrconfig.xml实际上被配置为使用ClassicIndexSchemaFactory处理schema.xml文件，即允许手动修改。这个设置不允许使用Schema API修改schema。
你可以在注释部分给出的示例中看到配置managed schema的方法。为了使通过Schema API修改schema成为可能，需要配置使用ManagedIndexSchemaFactory。参数mutable必须被设置为true。 managedSchemaResourceName属性的值默认为“managed-schema”，这个值也可以被设定为任何与 “schema.xml”不同的值。
每当Solr重新启动的时候，已经存在的schema.xml文件被重命名为schema.xml.bak，同时文件内容会被写入一个名为mana的文件。如果你打开结果文件查看，你会在文件的开头看到下面一行内容：
<!-- Solr managed schema - automatically generated - DO NOT EDIT -->
注意，在example/example-schemaless/下的Schemaless模式的例子使用了ManagedIndexSchemaFactory以允许基于文档更新域的值的schema域的自动添加。
1.4 IndexConfig in SolrConfig
Solrconfig.xml的部分从底层定义了Lucene index writers的行为。
在默认情况下，在作为示例的Solr的solrconfig.xml文件中，这些设置项被注释掉了，这意味这Solr使用了默认的值。在大多数情况下，使用默认值就可以了。
<indexConfig>
...
</indexConfig>
注意！在Solr 4之前的版本，上述的这些设置项目的很大部分被包括在mainIndex 和indexD
efaults 中。在Solr 4中，这些部分被废弃并移除。现在，所有设定项都集中在了。
1.4.1 Sizing Index Segments
ramBufferSizeMB
每当积累的更新文档超过了这个值规定的内存空间（用兆字节megabytes定义），这些更新就被写入硬盘。这个动作可能生成新的段或者引发段的合并。使用这个值通常要优于使用maxBufferedDocs。如果在solrconfig.xml中同时设置了maxBufferedDocs和 ramBufferSizeMB，那么一次写入硬盘的动作会发生在达到这两个限制中的任何一个的时候。默认的设置是100Mb（在Solr 4.1中是32Mb）。
<ramBufferSizeMB>100</ramBufferSizeMB>
maxBufferedDocs
用于设定在写入硬盘并加入当前索引段前内存缓冲中的更新文档的数目。如果一个段满了，那么会生成一个新的段，或者进行合并。默认的Solr配置中没有定义这个值。
<maxBufferedDocs>1000</maxBufferedDocs>
maxIndexingThreads
定义了用于索引文件的并发线程的最大数目。当达到了这个阙值，新加入的线程会等待其他线程结束。默认值是8。这个参数是在Solr 4.1版本加入的。
<maxIndexingThreads>8</maxIndexingThreads>
UseCompoundFile
设定为true会将一个段的多个文件合并为唯一的文件，默认为false。在那些每个进程允许打开的文件数目被限制的系统中，设置这个值为true可能避免达到限制（如果操作系统是Linux/Unix，那么使用ulimit命令可以更改打开文件数上限。其他操作系统则有类似的方法）。在一些情况下，一些内部因素会设置一个段为“compound=false”，即使这个设定值被显式地置为true，所以一个段的文件的合并并不总是会发生。
更新一个已经合并的索引会由于一些不同的原因导致小的性能损失，这决定于运行时的系统环境。例如，文件系统的缓冲通常和打开文件描述符是相关的，而打开文件描述符可能限制了每个索引能使用的缓存大小。
这个设定同时也会影响在索引备份操作时有多少数据需要转移。这个设定的默认值为false。
<useCompoundFile>false</useCompoundFile>
1.4.2 Merging Index Segments
mergeFactor
mergeFactor控制了一个Lucene索引在被合并为一个段（segment）前能够存在的段的数量。当索引被更新，它被添加于当前被打开的段中。当段被填满（参见上文中提到的maxBufferedDocs和ramBufferSizeMB参数），一个新的段就会产生，而接下来的更新则会在这里完成。
如果创建一个新段会导致最底层的段的数量超过mergeFactor的值，那么所有这些段就会被合并成一个单独的更大的段。所以如果 mergeFactor的值为10，那么合并后生成的唯一的段的大小就大致上等于合并前每个段的十倍。当mergeFactor设置被用于那些较大的段，之后这些段会合并成一个更大的段。这个动作可以被无限制地持续下去。
选择最佳的mergeFactor通常是索引速度和搜索速度的折中。当索引包含更少的段的时候通常可以加速搜索，因为需要加锁的地方更少。这通常也意味着在硬盘上更少的物理文件。但是，保持段的数量保持在低的水平，索引合并过程就会发生更多次，这一动作会加大系统的负担并且减慢更新索引的速度。
相反的，保持更多的段可以加速索引过程，因为合并操作发生的次数较少，在进行更新时更少的触发合并。但是搜索时的代价会变得可观，搜索速度也会下降，因为搜索一个词（term）需要查看索引中的更多的段。更快的索引更新速度意味着更短的提交周转时间，也意味着更长的搜索时间。
在示例的solrconfig.xml中默认的值是10，这是一个合理的开始（即可以在这个基础上调优）。
<mergeFactor>10</mergeFactor>
mergePolicy
定义了合并过程如何完成。在Solr中的默认值是TieredMergePolicy。这个默认的策略是合并那些差不多大小的段，受制于每次合并时允许的段的数量。其他可用的策略包括LogMergePolicy，LogByteSizeMergePolicy和LogDocMergePolicy。对于这些策略的更多信息，参考MergePolicy javadocs。（Lucene的这部分源码还真没看……）
<mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
<int name="maxMergeAtOnce">10</int>
<int name="segmentsPerTier">10</int>
</mergePolicy>
注意！当使用TieredMergePolicy 时，设置项maxMergeDocs 是不需要的。因为这是Solr的默认设置，所以它被有效地移除了。如果使用别的策略，则这个设置可能依旧是有效的。
mergeScheduler
合并调度程序（merge scheduler）控制了合并的实现。默认值是ConcurrentMergeScheduler，使用单独的线程在后台执行合并。作为替换的选择，SerialMergeScheduler不使用单独的线程进行合并操作。
<mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/>
mergedSegmentWarmer
当使用Solr的近实时搜索功能（Near Real Time Searching），可以配置一个合并段的加热器（merged segment warmer）在提交合并前加热在新合并段上的读取器（Reader）。这对于NRT搜索并不是必须的，但可以减少在一次合并结束后打开一个新的NRT读取器时搜索的潜伏时间。
<mergedSegmentWarmer class="org.apache.lucene.index.SimpleMergedSegmentWarmer"/>
1.4.3 Index Locks
lockType
LockFactory的选择决定了它的实现。
lockType=single使用了SingleInstanceLockFactory，目标是一个只读的索引或者其他的进程不可能修改索引的情况。
lockType=native使用NativeFSLockFactory去设置一个操作系统原生的文件锁。不要在多个Solr web应用程序跑在同一个JVM中并试图分享唯一一个索引的情况下使用。
lockType=simple使用SimpleFSLockFactory去设置一个空文件作为锁（大概是这个意思）。
在Solr 3.6和之后的版本中，默认使用native。在其他版本则默认使用simple。
关于LockFactory的细微差别的更多信息，参考http://wiki.apache.org/lucene-java/AvailableLockFactories.
<lockType>native</lockType>
unlockOnStartup
如果设置为true，那么当系统启动时，任何已经存在的写锁或者提交锁会解锁。这个设置破坏了使多个进程安全地访问Lucene索引文件的锁机制。默认值是false，当改变这个值的时候要小心。当lockType使用none或者single的时候这个参数不被使用。
<unlockOnStartup>false</unlockOnStartup>
writeLockTimeout
一个IndexWriter等待一个写锁的最长时间。默认值是1000，单位是毫秒。
<writeLockTimeout>1000</writeLockTimeout>
1.4.4 Other Indexing Settings
还有一些其他的参数对于配置你的实现可能很重要。这些设置影响什么时候并且如何更新索引。
设置
描述
termIndexInterval
控制词汇（term）载入内存的时间（often？）。默认值是128。
reopenReaders
设置使得IndexReader可以re-opened，取代先关闭再打开的过程，这个过程通常是较为抵消的。默认值是true。
deletionPolicy
控制在调用回滚时多少提交（commit）会被储存下来。默认是 SolrDeletionPolicy，这个参数使用下级参数，包括：保存的提交的最大数目（maxCommitsToKeep），保存的优化的最大数目（maxOptimizedCommitsToKeep），以及任何提交的最大寿命（maxCommitAge），支持DateMathParser语法。
infoStream
指定了用于在索引过程中写详细调试信息（Solr 日志信息）的潜在的Lucene类。
<termIndexInterval>128</termIndexInterval>
<reopenReaders>true</reopenReaders>
<deletionPolicy class="solr.SolrDeletionPolicy">
<str name="maxCommitsToKeep">1</str>
<str name="maxOptimizedCommitsToKeep">0</str>
<str name="maxCommitAge">1DAY</str>
</deletionPolicy>
<infoStream>false</infoStream>
注意：maxFieldLength参数自Solr 4开始被移除。如果严格的域的长度对你来说是重要的，你可以使用LimitTokenCountFactory获得类似的行为，它可以用于那些你希望做出限制的域。例如下面的例子将会限制域的大小为10000个字符。
<filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/>
1.5 UpdateHandlers in SolrConfig
在这部分的设置位于solrconfig.xml中<updateHandler>中，并且可能影响索引更新的效率。这些设置影响了更新如何在内部实现。<updateHandler>配置并不会影响高级别的RequestHandlers的配置，RequestHandlers用于处理用户的更新请求。
<updateHandler class="solr.DirectUpdateHandler2">
...
</updateHandler>
1.5.1 Commits
当数据传送到Solr之后并不能立刻被搜索，直到它被提交到索引。原因在于，在一些情况下，提交操作可能会很慢，并且它们应该与其他可能的提交分离以避免数据的重写。所以，最好提供对数据提交的控制机制。下面的一些选择可以有效控制定时提交。
commit and softCommit
在Solr 4中，提交操作仅由一个用户更新请求中的布尔标志位实现。命令中设置commit=true会使数据载入Solr后立即执行提交操作。
你也可以设置标志位softCommit=true去执行一个“软”提交，这意味这Solr会快速地提交你的变更，但并不保证文档会稳定地存储（为索引文件）。这是一个NRT存储的实现，用于加速文档可见的速度（即减少从导入Solr到能被搜索到的时间），因为你不需要等待后台的合并和存储过程（如果使用SolrCloud则为Zookeeper）的结束。一次全提交意味着，如果一个服务器崩溃了，Solr会精确地知道你的数据储存在什么地方，一个软提交意味着数据被存储了，但是地址信息还没有被存储。折中是，软提交为你提供了更快的可见性，因为它不需要等待后台的合并结束。
如果需要更多的关于NRT操作的信息，请参考NRT Searching章节。
autoCommit
这些设定控制了提交的更新以怎样的频率加入到索引中。可以使用commitWithin作为autoCommit的替代，它可以在发起一次对Solr的更新请求（如将文档即加入Solr）或在一个更新RequestHandle中定义。
设置
描述
maxDocs
在上次提交之后更新的文档的数量
maxTime
最老的未提交的更新的年龄（以毫秒为单位）
openSearcher
当进行提交时是否打开一个新的Searcher。如果这个值设置为false，也就是默认情况，那么提交会将当前索引的变化写入当前的索引文件（这样翻译应该可以），但是不会打开一个新的Searcher使这些更新可见。
maxDocs 和maxTime中任何一个被触发，Solr会自动执行提交操作。如果自动提交标签不存在，那么仅当显式提交时会更新索引。决定是否使用自动提交取决于你的应用。
确定最佳的自动更新设置需要平衡效率和准确性，使更新更频繁的设置可以提高搜索的准确性，因为新的内容可以被更快地搜索到，但这么做同时会降低效率，因为频繁的更新。更低的更新频率可以提升效率但是它也会使用更长的时间使更新结果反映在查询请求中。
<autoCommit>
<maxDocs>10000</maxDocs>
<maxTime>1000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
你可以通过同样的方法设置“软”自动更新，除非用来代替设置好的自动更新。
<autoSoftCommit>
<maxTime>1000</maxTime>
</autoSoftCommit>
commitWithin
commitWithin设置允许在一个定义的时间段后强制执行文档的提交。这个参数往往在NRT Searching中使用，也因此默认值是使用软提交。无论如何，它不会在主从环境中复制新的文档去从服务器。如果在你的实现中这是必要的，那么你可以通过添加一个参数强制执行“硬”提交，就像下面的例子所展示的：
<commitWithin>
<softCommit>false</softCommit>
</commitWithin>
通过这个配置，当你调用commitWithin作为你的更新信息的一部分，每次它都会自动执行硬提交。
maxPendingDeletes
这个值设置了Solr在进行文档删除操作时在缓冲中包含的删除的数量。它可以影响在索引过程中使用的内存的大小。
<maxPendingDeletes>100000</maxPendingDeletes>
1.5.2 Event Listeners
在UpdateHandler部分，还可以配置和更新相关的事件的监听器。这些监听器可以在提交、优化或仅仅是优化事件触发。
这个监听器由RunExecutableListener调用，RunExecutableListener运行一个可在外部执行的指令集合（程序？）。可用的命令如下：
设置
描述
event
如果设置为postCommit，RunExecutableListener将会在每次提交或者优化之后运行。如果设置为postOptimize，RunExecutableListener将只会在每次优化之后运行。
exe
需要运行的可执行程序。这个值应该包括文件的路径，这个路径是相对于Solr home的。
dir
这个路径被用于工作路径。默认为“.”。
wait
强制调用的线程等待直到可执行程序返回一个回应。默认值是true。
args
任何需要传给程序的参数。默认值是none。
env
任何需要设置的环境变量。默认值是none。
下面是一个来自solrconfig.xml的例子，它显示了一个基于脚本的备份的例子，例子在http://wiki.apache.org/solr/Coll。
<listener event="postCommit" class="solr.RunExecutableListener">
<str name="exe">solr/bin/snapshooter</str>
<str name="dir">.</str>
<bool name="wait">true</bool>
<arr name="args"> <str>arg1</str> <str>arg2</str> </arr>
<arr name="env"> <str>MYVAR=val1</str> </arr>
</listener>
1.5.3 Transaction Log
正如在RealTime Get部分定义的，一个事务（业务）日志对于这一特性是必要的。它在solrconfig.xml中的updateHandler中配置。 Realtime Get目前依赖于更新日志（这一）特性，这一特性是默认的。它依赖于更新日志，这可以在solrconfig.xml中配置，正如下面的例子：
<updateLog>
<str name="dir">${solr.ulog.dir:}</str>
</updateLog>
1.6 Query Settings in SolrConfig
在这个部分的设置影响了Solr处理和回应查询请求的方式。这些设置都在solrconfig.xml文件中<query>元素的子元素中被配置。
<query>
...
</query>
1.6.1 Caches
Solr的缓存与一个特定的索引搜索器实例相关，是一个在搜索器生命周期中不会变化的索引的特定视角（以某种形式将原始数据组织起来）。在一个索引搜索器被使用的期间，任何在它的缓存中的对象（文中用items，这里姑且翻译成对象）都是有效的并且是可重用的。Solr中的缓存操作不同于很多其他应用程序中的缓存操作，具体区别在于被缓存的Solr对象不会在一定的时间段后过期（expire），相对的，它们在索引搜索器的生命周期中一直保持可用（而这个生命周期的时间是不定的）。
当一个新的搜索器被打开，当前存在的搜索器继续处理请求，而新的搜索器则自动加热它的缓存。这个新的搜索器使用当前搜索器的缓存（中的数据？）预填充它自己的缓存。当新的搜索器准备好了，它像当前的搜索器一样被注册，并开始处理所有新的搜索请求。当老的搜索器将它的所有请求处理完毕后，它会关闭。
在Solr中，有三种缓存实现，包括：solr.search.LRUCache，solr.search.FastLRUCache和 solr.search.LFUCache。
缩写LRU代表了最近最少使用（Least Recently Used）。当一个LRU缓存被填充，带有最早的最后访问时间戳的实体会被移除（evicted），来为新的实体腾出空间。这个操作的影响（net effect）是那些频繁地被访问的实体倾向于停留在缓存中，同时那些不被频繁访问的实体则倾向于离开缓存并在需要的时候重新从索引中取出。
在Solr 1.4就已经存在的FastLRUCache，被设计为无锁的，所以它适合那些在一个请求中命中多次的缓存。
LRUCache和FastLRUCache都是用了自动加热计数器（？），用以获得当加热操作发生时当前缓存大小的整数或百分数值的计算值。
LFUCache是指最不经常使用（Least Frequently Used）缓存。它的工作方式和LRU缓存很相似，区别在于当缓存填满时，被移出缓存的实体是那些使用的最少的实体。
在Solr Admin界面中的统计页面会展示所有活动缓存的性能信息。这些信息可以帮助你微调各种缓存的大小以适应特定的应用。当一个搜索器终止的时候，一个它的缓存使用的摘要信息也同样会写入日志中。
每种缓存包括一些定义的设置，包括它的初始化大小（initialSize），最大大小）（size）和在加热过程中可用的对象（autowarmCount）。LRU 和FastLRU缓存实现可以使用百分数代替autowarmCount的绝对数值。
对每种缓存更详细的描述可以参考下面的内容。
filterCache
这个缓存用于对匹配一个查询的所有文档的为排列集合进行过滤（DocSets），它由SolrIndexSearcher使用。数值属性控制了在缓存中实体的数量。
Solr使用filterCache去缓存那些使用了“fq”搜索参数的查询的结果。后续的具有同样查询参数的查询使用缓存中已有的查询，命中并快速地返回结果。查看搜索部分可以获得对“fq”参数的更详细的讨论。
当设置参数facet.method 的值为fc的情况下，Solr在faceting过程中也使用这种缓存。同样的，关于faceting的更多讨论，参考搜索部分。
<filterCache class="solr.LRUCache"
size="512"
initialSize="512"
autowarmCount="128"/>
queryResultCache
这个缓存储存了之前搜索的结果：基于一个查询语句的，特定排列（规则）和文档范围的查询请求的排序了的文档Id列表（DocList）。
<queryResultCache class="solr.LRUCache"
size="512"
initialSize="512"
autowarmCount="128"/>
documentCache
这个缓存保存了Lucene文档对象（Document Object）（每个文档中需要储存的域）。自从Lucene内部的文档ID变成临时的以后，这个缓存不需要被加热。documentCache的大小应当总比max_concurrent_queries的max_results倍大（也就是大于 max_concurrent_queries×max_results），以保证Solr不需要在一个请求的过程中重新取得一个文档。在文档中你的存储域越多，那么缓存使用的内存也就越多。
<documentCache class="solr.LRUCache"
size="512"
initialSize="512"
autowarmCount="0"/>
User Defined Caches
你也可以使用你自己的应用代码定义命名的缓存。你可以通过调用SolrIndexSearcher的方法getCache(),cacheLookup()和cacheInsert()，用名字定位并使用你的缓存对象。
<cache name="myUserCache" class="solr.LRUCache"
size="4096"
initialSize="1024"
autowarmCount="1024"
regenerator="org.mycompany.mypackage.MyRegenerator" />
如果你想要自动加热你的缓存，（就需要）包括一个使用类名全称的，由solr.search.CacheRegenerator实现的再生成器属性。
1.6.2 Query Sizing and Warming
maxBooleanClauses
这个配置项设置了在布尔查询中允许的最大子句数量。这个配置项会影响范围或者会扩展为包含很多布尔term的查询的前缀查询。如果这个限制被超过，那么会抛出一个异常。
<maxBooleanClauses>1024</maxBooleanClauses>
这个选项更改了全局的属性，会影响所有的Solr Core。如果多个solrconfig.xml文件中这一属性的值不相符，那么这个值会根据最后被初始化的那个Solr core的设置而设置。
enableLazyFieldLoading
如果这个参数被设置为true，那么那些没有被直接请求的域会按照需要懒惰地（lazily）载入。如果大多数同样的查询请求仅需要一个域的小的子集，那么这个设定将加速效率，特别是当非频繁访问的域很大的时候。
<enableLazyFieldLoading>true</enableLazyFieldLoading>
useFilterForSortedQuery
这个参数使Solr使用一个过滤器去满足一个搜索请求。如果请求的排列不包括“评分”，那么filterCache会检查一个符合查询的过滤器。对于大多数时候，这个参数仅在同样的搜索请求使用不同的排序方法并且它们都没有使用“评分”的情况下使用。
<useFilterForSortedQuery>true</useFilterForSortedQuery>
queryResultWindowSize
如果使用了queryResultCache，Solr将会缓存请求的文档ID的集合的超集。比如当一个搜索服务响应一个特定的查询请求编号从10到19的文档，并且queryWindowSize的值为50，那么编号从0到49的文档会被缓存。
<queryResultWindowSize>20</queryResultWindowSize>
queryResultMaxDocsCached
这个参数设置了对于在queryResultCache的任意实体所缓存的最大文档数。
<queryResultMaxDocsCached>200</queryResultMaxDocsCached>
useColdSearcher
这个设定项控制了，搜索请求是否需要在当前没有一个注册的搜索器的情况下等待一个新的搜索器加热（设置为false），或者直接处理（设置为true）。如果设置为false，那么请求会阻塞直到搜索器加热了它的缓存。
<useColdSearcher>false</useColdSearcher>
maxWarmingSearchers
这个参数设置了任意给定时间在后台被加热的搜索器的最大数量。超过这一数值会产生一个错误。对于只读的从服务器，将这个值设置为2是合理的。对于主服务器，应给比这个值稍高。
<maxWarmingSearchers>2</maxWarmingSearchers>
1.6.3 Query-Related Listeners
正如在缓存部分描述的，新的索引搜索器会被缓存。为监听器使用触发器完成查询相关的任务是可以实现的。查询相关监听器最普遍的用处是定义一些查询，用以在索引搜索器开始时更加有效地加热这些搜索器。这种方法的好处之一是预填充域缓存以达到更快速度的排序。
对于这种类型的监听器来说，好的查询的选择是个关键。最好选择你最常见的and/or查询，并且不仅包含使用的关键词，还应该包含任何查询参数，比如排序和过滤请求。
有两种事件可以触发一个监听器。firstSearcher事件发生在当准备一个新的搜索器时，没有已经注册的搜索器可以用来处理请求或者作为自动加热的数据源。
监听器重视通过类solr.QuerySenderListener实例化，并且跟随一个命名列表的队列。下面是在solrconfig.xml中的例子。
<listener event="newSearcher" class="solr.QuerySenderListener">
<arr name="queries">
<!--
<lst><str name="q">solr</str><str name="sort">price asc</str></lst>
<lst><str name="q">rocks</str><str name="sort">weight asc</str></lst>
-->
</arr>
</listener>
<listener event="firstSearcher">
<arr name="queries">
<lst><str name="q">static firstSearcher warming in solrconfig.xml</str></lst>
</arr>
</listener>
注意！上面代码的例子是solrconfig.xml 中默认的，最佳实践的关键在于，在将你的应用程序放入生产环境之前修改这些默认定义。对于一个“新搜索器”，这个例子在没有将 “firstSearcher”事件注释掉的同时注释掉了几条简单的查询。用查询字符串“static firstSearcher warming in solrconfig.xml”自动加热你的索引搜索器是没有意义的，除非它和你的搜索应用有关。
1.7 RequestDispatcher in SolrConfig
Solrconfig.xml文件中的requestDispatcher元素控制了Solr的servlet的 RequestDispatcher实现对HTTP请求的相应方式。如果它支持远程流（remote streaming）、上传文件的最大尺寸以及它如何相应请求中的HTTP缓存头，那么这部分的内容包括了定义它是否应该处理/select url（为了和Solr 1.1兼容）的参数。
1.7.1 handleSelect Element
注意！HandleSelect用于对传统（以前的版本）的向后兼容性。那些新的Solr应用不需要改变任何默认配置。
第一个可以设置的对象是<requestDispatcher>元素自己的handleSelect属性。这个属性可以被设置成两个值中的一个，true或者false。它决定了Solr如何相应诸如/select?qt=XXX这样的请求。默认值是false。当取false时，如果 requestHandler没有显式地注册名为/select的handler的时候，系统会忽略那些以/select开头的请求。
在最近版本的solr中，默认定义了一个名字是/select的requestHandler，所以取false可以很好的工作。参考RequestHandlers and SearchComponents in SolrConfig部分以获得更多的信息。
<requestDispatcher handleSelect="true" >
...
</requestDispatcher>
1.7.2 requestParsers Element
<requestParsers>的下级元素包括了和解析请求有关的属性值。这是一个空的XML元素，没有任何内容，只有属性。
属性enableRemoteStreaming决定了是否允许内容的远程流。如果设置成false，那么流就被禁止。设置其为true（也就是默认情况）使你可以通过stream.file或者stream.url将特定位置的内容转变为流。
如果你允许远程流，那么请确定你有权限这么做。否则，其他人潜在地可能通过访问任意的URL而访问你的内容。将Solr置于一个防火墙之后来保护它避免不信任的用户访问是个好主意。
属性multipartUploadLimitInKB设置了通过多部分（multi-part）的HTTP POST请求提交的文档大小的上限，单位是Kb。这个值指定为1024的倍数来确定Bytes的大小。
属性formdataUploadLimitInKB设置了一个用Kb表示的限制，用以限制HTTP POST请求中提交的表单数据的大小，这个大小可以用来传递请求的参数但并不适合（写入）URL中。
属性addHttpRequestToContext用来声明原始的HttpServletRequest对象应该被包括在使用 httpRequest的SolrQueryRequest的上下文集合（context map）中。这个HttpServletRequest不会用于任何Solr的组成部分，但在开发自定义的插件是会很有用。
<requestParsers enableRemoteStreaming="true"
multipartUploadLimitInKB="2048000"
formdataUploadLimitInKB="2048"
addHttpRequestToContext="false" />
1.7.3 httpCaching Element
<httpCaching>元素控制了HTTP缓存控制头（HTTP cache control headers）。不要将这些设置和Solr内部的缓存配置混淆。这个元素控制了W3C HTTP规格定义的HTTP响应的缓存过程。这个元素允许三个属性和一个下级元素。<httpCaching>元素的属性决定了是否允许对一个GET请求进行304响应，如果可以，它应该是什么响应类别（sort）。当一个HTTP用户程序生成一个GET请求，如果资源从上一次被取得后还没有被修改，那么它可以可选择地指定一个可接受的304响应。
参数
描述
never304
如果将这个值设置为true，那么即使请求的资源还没有被修改，一个GET请求也永远不会得到一个304响应。如果这个属性被设置为true，那么接下来的两个属性会被忽略。将这个属性设置为true对于开发来说是方便的，因为当通过支持缓存头的web浏览器或者其他用户修补Solr的响应时，304响应可能会使人混淆。
lastModFrom
这个属性可以设置为openTime（默认值）或者dirLastMod。openTime 指示了最后更改时间，相对于客户发送的If-Modified-Since头，它应该在搜索器开始的时候计算。如果当索引在硬盘上更新时你需要精确同步，那么使用dirLastMod。
etagSeed
这个属性的值被作为ETag头的值。改变这个值可以有助于强制用户重新取得内容，即使索引没有被改变。例如，当你修改了配置的时候。
<httpCaching never304="false"
lastModFrom="openTime"
etagSeed="Solr">
<cacheControl>max-age=30,public</cacheControl>
</httpCaching>
cacheControl Element
作为对这些属性的补充，<httpCaching>接受一个子元素：<cacheControl>。这个元素的内容会被作为HTTP响应的Cache-Control头的值。这个值用来改变发出请求的用户的默认的缓存行为。Cache-Control头的可能取值被定义在 HTTP 1.1规范的14.9节。
设置max-age域控制了一个用户在再次请求服务器之前重用之前被缓存的响应的时间长短。这个时间间隔的设置应该取决于你更新索引的频率以及你的应用是否接受那些过期的数据。设置must-revalidate告诉用户在重用它缓存的拷贝前去和服务器验证这个拷贝是否是良好的。当第二次取得内容的行为并不需要的时候，这个操作会确认最及时的结果已经被使用，代价是这个请求会要求服务器进行检查操作。
1.8 RequestHandlers and SearchComponents in SolrConfig
在<query>部分结束后，可以对request handlers和search components进行配置。这两个部分在solrconfig.xml中经常被写作“requestHandler”和 “searchComponent”。一个request handler处理了发往Solr的请求。这些请求可能是查询请求，也可能是索引更新请求。你可能会需要若干个控制Solr如何处理你创建的各种请求的配置。
1.8.1 Request Handlers
每一个request handler都用一个名字和一个类定义。request handler的名字是对Solr的请求的引用。例如，一个对Solr的默认地址http://localhost:8983/solr/collection1的请求会打开Solr Admin界面。无论如何，在这个请求的末尾添加“/select”，你就可以建立一个查询：
http://localhost:8983/solr/collection1/select?q=solr
这个查询会被名字是“/select”的request handler处理。这里我们仅使用了“q”参数，这个参数包括了我们的查询词（term），一个简单的关键字“solr”。如果request handler定义了更多的参数，这些参数会用于任何我们交给这个request handler的查询，除非在查询中客户端（或用户）自己覆盖它们。
如果你定义了另一个request handler，你可以用对应的名字发送你的请求——比如，“/update”是一个用于处理更新索引操作的request handler，更新操作包括了发送新的文档到索引。
1.8.1.1 SearchHandlers
在Solr中默认定义的最主要的request handler是“SearchHandler”，它处理搜索查询。这个request handler已经被定义，并且在一个默认的列表中，这个handler的一系列默认的值被定义。例如，在默认的solrconfig.xml中，第一个 request handler的定义是这样的：
<requestHandler name="/select" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
<int name="rows">10</int>
<str name="df">text</str>
</lst>
</requestHandler>
这个例子定义了几行的参数。这些参数定义了需要返回多少结果（定义值为10），通过参数df定义了搜索的域默认为“text”域。 echoParams参数定义了查询中定义的参数在调试信息返回时也应该返回。另外还要注意在列表中这些默认值定义方法的变化：当参数是 String，integer或其他类型时，定义类型是不同的。
所有这些在搜索部分描述的参数可以在任何SearchHandlers中定义为默认值。（这些参数的细节信息请参考搜索部分。）
除了这些默认值，还有一些选择可用于SearchHandler，包括了下面的这些内容：
- appends：这个设置允许在用户查询中添加参数的定义。这些参数可能是过滤查询，或者其他可以被加入每一个查询的查询规则。在Solr中没有机制允许客户端覆盖这些添加，所以你应当完全确定你总是需要在查询中加入这些参数。
<lst name="appends">
<str name="fq">inStock:true</str>
</lst>
在这个例子中，过滤查询“inStock:true”会添加到每一个查询上。
<lst name="invariants">
<str name="facet.field">cat</str>
<str name="facet.field">manu_exact</str>
<str name="facet.query">price:[* TO 500]</str>
<str name="facet.query">price:[500 TO *]</str>
</lst>
在这个例子中，facet域被定义，这个定义会限制Solr返回的facets。如果客户端请求facets，那么他们只会看到和这个配置的相同的facets。
在request handler最后部分，是组件（component）的定义，它定义了可以被用于一个request
Handler的搜索组件的列表。它们仅在request handler中注册。对搜索组件的更进一步的讨论在搜索组件部分。搜索组件元素只能被用于SearchHandler。
在solrconfig.xml文件中还包括了许多其他的SearchHandlers的例子，这些例子可以根据需要使用或更改。
1.8.1.2 UpdateRequestHandlers
UpdateRequestHandlers是用于处理索引更新的一些request handlers。这个指导部分的内容覆盖了这些handler，它们的细节则在Uploading Data with Index Handlers给出。
1.8.1.3 ShardHandlers
通过配置一个request handler在集群的shard上进行分布式的搜索是可行的。关于分布式搜索和如何配置shardHandler的更多的信息在Distributed Search with Index Sharding章节。
1.8.1.4 Other Request Handlers
在solrconfig.xml中还定义了其他一些request handlers，可以通过下面的指导找到包含这些内容的章节：
- RealTime Get
- Index Replication
- Ping
1.8.2 Search Components
搜索组件（search components）定义了在SearchHandler中用于处理用户查询的逻辑。
1.8.2.1 Default Components
这里有一些没有任何额外配置的，用于所有SearchHandlers的默认search components。
组件名
类名
更多信息
query
solr.QueryComponent
更多信息在Query Syntax and Parsing章节
facet
solr.FacetComponent
更多信息在Faceting章节
mlt
solr.MoreLikeThisComponent
更多信息在MoreLikeThis章节
highlight
solr.HighlightComponent
更多信息在Highlighting章节
stats
solr.StatsComponent
更多信息在Component章节
debug
solr.DebugComponent
更多信息在Common Query Parameters章节
如果你使用上述默认名称之一注册了一个新的搜索组件，那么这个新定义的组件会取代默认的。
1.8.2.2 First-Components and Last-Components
可以定义一些在其他命名的组件之前（使用first-components）或之后（使用last-components）使用的组件。（比如）需要在常规的搜索组件被使用之前通过自定义的组件预处理数据的时候，这种方法会很有用。
在将组件注册到request handler时使用。
<arr name="first-components">
<str>mycomponent</str>
</arr>
<arr name="components">
<str>query</str>
<str>facet</str>
<str>mlt</str>
<str>highlight</str>
<str>spellcheck</str>
<str>stats</str>
<str>debug</str>
</arr>
1.8.2.3 Other Useful Components
在其他章节中还描述了许多有用的组件，下面的引导包括了这些组件和它们支持的特性：
- SpellCheckComponent，在Spell Checking中。
- TermVectorComponent，在Term Vector Component中。
- QueryElevationComponent，在Query Elevation Component中。
- TermsComponent，在Terms Component中。
1.8.3 Related Topics
- SolrRequestHandler from the Solr Wiki.
- SearchHandler from the Solr Wiki.
- SearchComponent from the Solr Wiki.
