managed-schema(schema.xml)/solrconfig.xml详解

solr主要有两个配置solrconfig.xml和schema.xml

一、 schema.xml

schema.xml相当于数据表配置文件，它定义了加入索引的数据的数据类型。主要包括types和fields以及其他一些缺省设置。
注:schema.xml里有一个uniqueKey,的配置，这里将id字段作为索引文档的唯一标识符，非常重要。<uniqueKey>id</uniqueKey>
1. FieldType（类型）
首先需要在types结点内定义一个FieldType子结点，包括name,class,positionIncrementGap等等一些参数，name就是这个FieldType的名称，class指向org.apache.solr.schema包里面对应的class名称，用来定义这个类型的行为。在FieldType定义的时候最重要的就是定义这个类型的数据在建立索引和进行查询的时候要使用的分析器analyzer,包括分词和过滤。例如：

<fieldType name="text" class="solr.TextField" positionIncrementGap="100">
<analyzer type="index">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"
enablePositionIncrements="true"/>
<filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
</analyzer>
……
</fieldType>

1.1常规域
● StrField: 这是一个不分词的字符串域，它支持 docValues 域，但当为其添加了docValues 域，则要求只能是单值域且该域必须存在或者该域有默认值
● BoolField ： boolean 域，对应 true/false
● TrieIntField, TrieFloatField, TrieLongField, TrieDoubleField 这几个都是默认的数字域， precisionStep 属性一般用于数字范围查询， precisionStep 值越小，则索引时该域的域值分出的 token 个数越多，会增大硬盘上索引的体积，但它会加快数字范围检索的响应速度， positionIncrementGap 属性表示如果当前域是多值域时，多个值之间的间距，单值域，设置此项无意义。
● TrieDateField ：显然这是一个日期域类型，不过遗憾的是它支持 1995-12-31T23:59:59Z 这种格式的日期，比较坑爹，为此我自定义了一个 TrieCNDateField 域类型，用于支持国人比较喜欢的 yyyy-MM-dd HH:mm:ss 格式的日期。源码请参见我的上一篇博客。
● BinaryField ：经过 base64 编码的字符串域类型，即你需要把 binary 数据进行base64 编码才能被 solr 进行索引。
● RandomSortField ：随机排序域类型，当你需要实现伪随机排序时，请使用此域类型。
● TextField ：是用的最多的一种域类型，它需要进行分词，所以它一般需要配置分词器。至于具体它如何配置 IK 分词器：一般索引使用最小粒度分词，搜索使用最大分词，

 <fieldType class="solr.TextField" name="text_ik">
            <analyzer type="index">  
              <tokenizer class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="false"/>  
            </analyzer>  
            <analyzer type="query">  
              <tokenizer class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="true"/>  
            </analyzer>
        </fieldType>

1.2对应属性
(1)、field type是对field类型的详细描述：
● name：类型的名称，对应field中的type
● class：类型对应的java对象， solr默认提供大概20多种类型
● positionIncrementGap：当field设置multValued为true时，用来分隔多个值之间的间隙大小
● autoGeneratePhraseQueries：有点类似找近义词或者自动纠错的设置，例如可以将 wi fi自动转为 wifi或wi-fi，如果不设置这个属性则需要在查询时强制加上引号，例如 ‘wi fi’
(2)、fieldType 元素还有一些额外的属性也需要注意下，比如sortMissingFirst,sortMissingLast 等：
● sortMissingLast 表示如果域值为 null, 在根据当前域进行排序时，把包含 null 值的document 排在最后一位
● sortMissingFirst ：与 sortMissingLast 对应的，不言自明了，你应该懂的
● docValues ：表示是否为 docValues 域，一般排序， group,facet 时会用到docValues 域。

在index的analyzer中使用 solr.WhitespaceTokenizerFactory这个分词包，就是空格分词，然后使用 solr.StopFilterFactory，solr.WordDelimiterFilterFactory，solr.LowerCaseFilterFactory，solr.EnglishPorterFilterFactory，solr.RemoveDuplicatesTokenFilterFactory 这几个过滤器。在向索引库中添加text类型的索引的时候，Solr会首先用空格进行分词，然后把分词结果依次使用指定的过滤器进行过滤，最后剩下的结果才会加入到索引库中以备查询。Solr的analysis包并没有带支持中文分词的包
2. Fields（字段）
接下来的工作就是在fields结点内定义具体的字段（类似数据库中的字段），就是filed，filed定义包括name,type（为之前定义过的各种FieldType）,indexed（是否被索引）,stored（是否被储存），multiValued（是否有多个值）等等。
例：

<fields>
<field name="id" type="integer" indexed="true" stored="true" required="true" />
<field name="name" type="text" indexed="true" stored="true" />
<field name="summary" type="text" indexed="true" stored="true" />
<field name="author" type="string" indexed="true" stored="true" />
<field name="date" type="date" indexed="false" stored="true" />
<field name="content" type="text" indexed="true" stored="false" />
<field name="keywords" type="keyword_text" indexed="true" stored="false" multiValued="true" />
<field name="all" type="text" indexed="true" stored="false" multiValued="true"/>
</fields>

2.1 字段的有效属性:
1. name：属性的名称，这里有个特殊的属性“version”是必须添加的。
2. type：字段的数据结构类型，所用到的类型需要在fieldType中设置。
3. default：默认值。
4. indexed：是否创建索引只有index=true 的字段才能做facet.field的字段，同时只有index=true该字段才能当做搜索的内容,当然store=true或者false没关系,将不需要被用于搜索的，而只是作为结果返回的field的indexed设置为false
5. stored：是否存储原始数据（如果不需要存储相应字段值，尽量设为false）,表示是否需要把域值存储到硬盘上，方便你后续查询时能再次提取出来原样显示给用户
6. docValues：表示此域是否需要添加一个 docValues 域，这对 facet 查询， group 分组，排序， function 查询有好处，尽管这个属性不是必须的，但他能加快索引数据加载，对 NRT 近实时搜索比较友好，且更节省内存，但它也有一些限制，比如当前docValues 域只支持strField,UUIDField,Trie*Field 等域，且要求域的域值是单值不能是多值域
8. multValued：是否有多个值，比如说一个用户的所有好友id。（对可能存在多值的字段尽量设置为true，避免建索引时抛出错误）
9. omitNorms：此属性若设置为 true ，即表示将忽略域值的长度标准化，忽略在索引过程中对当前域的权重设置，且会节省内存。只有全文本域或者你需要在索引创建过程中设置域的权重时才需要把这个值设false, 对于基本数据类型且不分词的域如intFeild,longField,Stre, 否则默认就是 false.
10. required：添加文档时，该字段必须存在，类似mysql的not null
11. termVectors: 设置为 true 即表示需要为该 field 存储项向量信息，当你需要MoreLikeThis 功能时，则需要将此属性值设为 true ，这样会带来一些性能提升。
12. termPositions: 是否存储 Term 的起始位置信息，这会增大索引的体积，但高亮功能需要依赖此项设置，否则无法高亮
13. termOffsets: 表示是否存储索引的位置偏移量，高亮功能需要此项配置，当你使用SpanQuery 时，此项配置会影响匹配的结果集
field的定义相当重要，有几个技巧需注意一下，对可能存在多值得字段尽量设置 multiValued属性为true，避免建索引是抛出错误；如果不需要存储相应字段值，尽量将stored属性设为false。
3. copyField（复制字段）
建议建立了一个拷贝字段，将所有的全文字段复制到一个字段中，以便进行统一的检索：

<field name="all" type="text" indexed="true" stored="false" multiValued="true"/>

并在拷贝字段结点处完成拷贝设置：

<copyField source="name" dest="all"/>
<copyField source="summary" dest="all"/>

注：“拷贝字段”就是查询的时候不用再输入：userName:张三 and userProfile:张三的个人简介。直接可以输入”张三”就可以将“名字”含“张三”或者“简介”中含“张三”的又或者“名字”和“简介”都含有“张三”的查询出来。他将需要查询的内容放在了一个字段中，并且默认查询该字段设为该字段就行了。
4. dynamicField（动态字段）
除此之外，还可以定义动态字段，所谓动态字段就是不用指定具体的名称，只要定义字段名称的规则，例如定义一个 dynamicField，name 为*_i，定义它的type为text，那么在使用这个字段的时候，任何以_i结尾的字段都被认为是符合这个定义的，例如：name_i，gender_i，school_i等。
schema.xml配置文件大体上就是这样。
二 solrConfig.xml
solrconfig.xml配置文件主要定义了SOLR的一些处理规则，包括索引数据的存放位置，更新，删除，查询的一些规则配置。
可以在tomcat的安装路径下找到这个文件C:\Program Files\Apache Software Foundation\Tomcat 8.0\solr\collection1\conf
1.datadir节点

${solr.data.dir:d:/Server/Solr/data}//定义了索引数据和日志文件的存放

位置。solr 创建的索引会存放在 data\index 目录下，默认 dataDir 是相对于当前 core 目录 ( 如果 solr_home 下存在 core 的话 ) ，如果 solr_home 下不存在 core 的话，那 dataDir 默认就是相对于 solr_home 啦，不过一般 dataDir 都在 core.properties 下配置。
2.luceneMatchVersion

<luceneMatchVersion>4.8</luceneMatchVersion>    //表示solr底层使用的是lucene4.8

1. lib

```
<lib dir="../../../contrib/extraction/lib"regex=".*\.jar"/>

    //表示solr引用包的位置,当dir对应的目录不存在时候，会忽略此属性。这里的 dir 表示一个 jar 包目录路径，该目录路径是相对于你当前 core 根目录的； regex 表示一个正则表达式，用来过滤文件名的，符合正则表达式的 jar 文件将会被加载

4.directoryFactory
索引存储方案，共有以下存储方案
1、solr.StandardDirectoryFactory,这是一个基于文件系统存储目录的工厂，它会试图选择最好的实现基于你当前的操作系统和Java虚拟机版本。
2、solr.SimpleFSDirectoryFactory,适用于小型应用程序，不支持大数据和多线程。
3、solr.NIOFSDirectoryFactory,适用于多线程环境，但是不适用在windows平台（很慢），是因为JVM还存在bug。
4、solr.MMapDirectoryFactory,这个是solr3.1到4.0版本在linux64位系统下默认的实现。它是通过使用虚拟内存和内核特性调用mmap去访问存储在磁盘中的索引文件。它允许lucene或solr直接访问I/O缓存。如果不需要近实时搜索功能，使用此工厂是个不错的方案。
5、solr.NRTCachingDirectoryFactory,此工厂设计目的是存储部分索引在内存中，从而加快了近实时搜索的速度。
6、solr.RAMDirectoryFactory,这是一个内存存储方案，不能持久化存储，在系统重启或服务器crash时数据会丢失。且不支持索引复制

<directoryFactory class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}" name="DirectoryFactory">  
<str name="solr.hdfs.home">${solr.hdfs.home:}</str>  
<str name="solr.hdfs.confdir">${solr.hdfs.confdir:}</str>  
<str name="solr.hdfs.blockcache.enabled">${solr.hdfs.blockcache.enabled:true}</str>  
<str name="solr.hdfs.blockcache.global">${solr.hdfs.blockcache.global:true}</str>  
</directoryFactory>  

1. codecFactory
   编解码工厂允许使用自定义的编解码器。例如：如果想启动per-field DocValues格式, 可以在solrconfig.xml里面设置SchemaCodecFactory：
   docValuesFormat=”Lucene42”: 这是默认设置，所有数据会被加载到堆内存中。
   docValuesFormat=”Disk”: 这是另外一个实现，将部分数据存储在磁盘上。
   docValuesFormat=”SimpleText”: 文本格式，非常慢，用于学习。

<codecFactory class="solr.SchemaCodecFactory"/>
<schemaFactory class="ClassicIndexSchemaFactory"/>

6.indexconfig节点
用于设置索引的低级别的属性

<filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/><!--限制token最大长度,它对所有域生效，可以将它注释掉，不限制域中的词元个数。即使没有强制限制,你还要受Java内存分配的限制，如果超过内存分配限制，就会抛出错误-->
<writeLockTimeout>1000</writeLockTimeout><!--writeLockTimeout 表示 IndexWriter 实例在获取写锁的时候最大等待超时时间，超过指定的超时时间仍未获取到写锁，则 IndexWriter 写索引操作将会抛出异常-->
<maxIndexingThreads>8</maxIndexingThreads><!--生成索引时使用的最大线程数-->
<useCompoundFile>false</useCompoundFile><!--是否开启复合文件模式，启用了复合文件模式即意味着创建的索引文件数量会减少，这样占用的文件描述符也会减少，但这会带来性能的损耗，在 Lucene 中，它默认是开启，而在 Solr 中，自从 3.6 版本开始，默认就是禁用的-->
<ramBufferSizeMB>100</ramBufferSizeMB><!--缓存大小文档数大小,达到大小后将执行更新动作，表示创建索引时内存缓存大小，单位是 MB, 默认最大是 100M-->
<maxBufferedDocs>1000</maxBufferedDocs><!--设置索引刷新到磁盘前，缓存在内存中文档的数量。Solr 默认情况下没有设置该值。与上一个两个同时定义时命中较低的那个。-->
<mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
         <int name="maxMergeAtOnce">10</int>
          <int name="segmentsPerTier">10</int>
      </mergePolicy>   <!--合并策略。配置 Lucene 索引段合并策略的，里面有两个参数：
maxMergeAtOne: 一次最多合并段个数；segmentPerTier:  每个层级的段个数，同时也是内存 buffer 递减的等比数列的公比，solr6.4.2中默认设置为10-->
<mergeFactor>10</mergeFactor><!--合并因子,每次合并多少个segments。决定低水平的 Lucene 段被合并的频率。较小的值（最小为 2）使用的内存较少但导致的索引时间也更慢。较大的值可使索引时间变快但会牺牲较多的内存。IndexWriter 的 mergeFactory 允许你来控制索引在写入磁盘之前内存中能缓存的 document 数量，以及合并多个段文件的频率。默认这个值为 10. 当往内存中存储了 10 个 document, 此时 Lucene 还没有把单个段文件写入磁盘， mergeFactor 值等于 10 也意味着当硬盘上的段文件数量达到 .lucene 将会把这 10 个段文件合并到一个段文件中。例如：如果你把 mergeFactor 设置为 10 ，当你往索引中添加了 10 个 document, 一个段文件将会在硬盘上被创建，当第 10 个段文件被添加时，这 10 个段文件就会被合并到 1 个段文件，此时这个段文件中有 100 个 document, 当 10 个这样的包含了 100 个 document 的段文件被添加时，他们又会被合并到一个新的段文件中，而此时这个段文件包含 1000 个 document, 以此类推。所以，在任何时候，在索引中不存在超过 9 个段文件。每个被合并的段文件包含的 document 个数都是 10 ，但这样有点小问题，我们还必须设置一个maxMergeDocs变量，当合并段文件的时候，lucene必须确保没有哪个段文件超过maxMergeDocs变量规定的最大document数量。设置maxMergeDocs的目的是为了防止单个段文件中包含的document数量过大，假定你把 maxMergeDocs 设置为 1000 ，当你创建第 10 个包含 1000 个 document 段文件的时候，这时并不会触发段文件合并(如果没有设置maxMergeDocs为100的话，按理来说，这10个包含了1000个document的段文件将会被合并到一个包含了 10000 个 document 的段文件当中，但 maxMergeDocs 限制了单个段文件中最多包含 1000 个 document, 所以此时并不会触发段合并操作 ) 。影响段合并还有一些其他参数，比如：
mergeFactor ：当大小几乎相当的段的数量达到此值的时候，开始合并。
minMergeSize ：所有大小小于此值的段，都被认为是大小几乎相当，一同参与合并。
maxMergeSize ：当一个段的大小大于此值的时候，就不再参与合并。
maxMergeDocs ：当一个段包含的文档数大于此值的时候，就不再参与合并。
段合并分两个步骤：
1.首先筛选出哪些段需要合并，这一步由MergePolicy合并策略类来决定
2. 然后就是真正的段合并过程了，这一步是交给 MergeScheduler 来完成的， MergeScheduler 类主要做两件事：
A.对存储域，项向量，标准化因子即norms等信息进行合并
B.对倒排索引-->

<mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/><!--合并调度器-->
<lockType>${solr.lock.type:native}</lockType><!--锁工厂。single：适用于只读的索引库，即索引库是定死的，不会再更改；native：使用本地操作系统的文件锁方式，不能用于多个solr服务共用同一个索引库。Solr3.6 及后期版本使用的默认锁机制；simple：使用简单的文件锁机制；Defaults ：从 solr3.6 版本开始，这个默认值是 native, 否则，默认值就是 simple, 意思就是说，你如果配置为 Defaults ，到底使用哪种锁实现，取决于你当前使用的 Solr版本。-->
<unlockOnStartup>false</unlockOnStartup> <!--是否启动时先解锁。某些情况下，索引可能会由于不正确的关机或其他错误而一直处于锁定，这就妨碍了添加和更新。将其设置为 true 可以禁用启动锁定，进而允许进行添加和更新。如果这个设置为 true, 那么在 solr 启动后， IndexWriter 和 commit 提交操作拥有的锁将会被释放，这会打破 Lucene 的锁机制，请谨慎使用。如果你的 lockType 设置为single, 那么这个配置 true or false 都不会产生任何影响。-->
<termIndexInterval>128</termIndexInterval><!--将经常使用的内容加入内存，默认128，大部分时候够用了-->
<reopenReaders>true</reopenReaders><!--重新打开,替代先关闭-再打开。-->
<deletionPolicy class="solr.SolrDeletionPolicy"><!--用来配置索引删除策略的，默认使用的是 Solr 的 SolrDeletionPolicy 实现。如果你需要自定义删除策略，那么你需要实现 Lucene 的 org.apache.lucene.index.IndexDeletionPolicy 接口-->
<str name="maxCommitsToKeep">1</str><!--最多持有提交点的数量-->
<str name="maxOptimizedCommitsToKeep">0</str><!--最多持有优化提交点的数量-->
<str name="maxCommitAge">30MINUTES</str> OR <str name="maxCommitAge">1DAY</str><br><!--一旦达到指定的时间删除所有的提交点-->
<infoStream   file="INFOSTREAM.txt">false</infoStream><!--相当于把创建索引时的日志输出-->  

updateHandler节点
定义更新处理器，

<updateLog>  
 <str name="dir">${solr.ulog.dir:}</str>  
</updateLog>  

设置索引库更新日志，默认路径为solr home下面的data/tlog。随着索引库的频繁更新，tlog文件会越来越大，所以建议提交索引时采用硬提交方式，即批量提交。

<autoCommit>  
<maxTime>15000</maxTime>  
<maxDocs>10000</maxDocs>  
<openSearcher>false</openSearcher>  
</autoCommit>  

autoCommit自动硬提交方式:
maxTime：设置多长时间提交一次,
maxDocs：设置达到多少文档提交一次
openSearcher：文档提交后是否开启新的searcher，如果false，文档只是提交到index索引库，搜索结果中搜不到此次提交的文档；如果true，既提交到index索引库，也能在搜索结果中搜到此次提交的内容。
autoSoftCommit软提交：把内存文件fsync到磁盘，但不创建index descriptor。也就是说原索引和现在的索引还互不感知，所以如果jvm崩溃，那这部分索引就没了。可以重新打开searcher，使得新的索引可以被查找到。

<updateHandler class="solr.DirectUpdateHandler2">  
<!-- 允许事务日志  -->   
<updateLog>  
<str name="dir">${solr.ulog.dir:}</str>  
</updateLog>  
<!--  在满足一定条件时自动提交。maxDocs/maxTime/openSearcher  -->  
<autoCommit>   
<maxTime>15000</maxTime>   
<openSearcher>false</openSearcher>   
</autoCommit>  
    <!-- 软提交VS硬提交 -->  
<!--  
<autoSoftCommit>   
<maxTime>1000</maxTime>   
</autoSoftCommit>  
-->  
<!--   
更新相关事件监听器  
postCommit - fired after every commit or optimize command  
postOptimize - fired after every optimize command  
-->  
<!-- The RunExecutableListener executes an external command from a  
hook such as postCommit or postOptimize.  
exe - the name of the executable to run  
dir - dir to use as the current working directory. (default=".")  
wait - the calling thread waits until the executable returns.   
(default="true")  
args - the arguments to pass to the program.  (default is none)  
env - environment variables to set.  (default is none)  
-->  
<!--  
<listener event="postCommit" class="solr.RunExecutableListener">  
<str name="exe">solr/bin/snapshooter</str> //exe--可执行的文件类型 
<str name="dir">.</str>  //dir--可以用该目录做为当前的工作目录。默认为 "."
<bool name="wait">true</bool>  //wait--调用线程要等到可执行的返回值
<arr name="args"> <str>arg1</str> <str>arg2</str> </arr>  //args--传递给程序的参数 默认nothing
<arr name="env"> <str>MYVAR=val1</str> </arr>  //env--环境变量的设置 默认nothing
</listener>  
-->  
</updateHandler>  

8.Query查询节点

<maxBooleanClauses>1024</maxBooleanClauses>

设置boolean 查询中，最大条件数。在范围搜索或者前缀搜索时，会产生大量的 boolean 条件，
如果条件数达到这个数值时，将抛出异常，限制这个条件数，可以防止条件过多查询等待时间过长。
缓存方法

<filterCache class="solr.FastLRUCache" size="512" initialSize="512" autowarmCount="0"/>  
<queryResultCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/>  
<documentCache class="solr.LRUCache" size="512" initialSize="512" autowarmCount="0"/>  
<queryResultMaxDocsCached>200</queryResultMaxDocsCached>  //查询结果文档的最大缓存数
<maxWarmingSearchers>2</maxWarmingSearchers>  //该参数用于设置最大的 searcher 数量，这些 searcher 实现预热好的，随时可以调用。如果超过这个数量，将会报错。在一个只读的索引库中，2个预热的 searcher 是相对合理的，如果是读写的索引库中，根据内存和cpu的大小可以给一个相对大一点的值。
<enableLazyFieldLoading>true</enableLazyFieldLoading>   //某些字段延时加载，以提高性能，例如内容较多的压缩文件
<queryResultWindowSize>50</queryResultWindowSize>       //Result Window Size 优化queryResultCache结果cache

1）size：cache中可保存的最大的项数，默认是1024
2）initialSize：cache初始化时的大小，默认是1024。
3）autowarmCount：当切换SolrIndexSearcher时，可以对新生成的SolrIndexSearcher做autowarm（预热）处理。autowarmCount表示从旧的SolrIndexSearcher中取多少项来在新的SolrIndexSearcher中被重新生成，如何重新生成由CacheRegenerator实现。在当前的1.4版本的Solr中，这个autowarmCount只能取预热的项数，将来的4.0版本可以指定为已有cache项数的百分比，以便能更好的平衡autowarm的开销及效果。如果不指定该参数，则表示不做autowarm处理。
实现上，LRUCache直接使用LinkedHashMap来缓存数据，由initialSize来限定cache的大小，淘汰策略也是使用LinkedHashMap的内置的LRU方式，读写操作都是对map的全局锁，所以并发性效果方面稍差。

9.Request Dispatcher请求转发器

<!-- Request Dispatcher主要是介绍当有请求访问SolrCore时SolrDispatchFilter如何处理。handleSelect是一个以前版本中遗留下来的属性,会影响请求的对应行为（比如/select?qt=XXX）。当handleSelect="true"时导致SolrDispatchFilter将请求转发给qt指定的处理器（前提是/select已经注册）。当handleSelect="false"时会直接访问/select,若/select未注册则为404。-->  
<requestDispatcher handleSelect="false" >  
<!-- 
Request Parsing：请求解析，这些设置说明Solr Requests如何被解析,以及对ContentStreams有什么限制。
enableRemoteStreaming - 是否允许使用stream.file和stream.url参数来指定远程streams。multipartUploadLimitInKB - 指定多文件上传时Solr允许的最大的size,设置了通过多部分（multi-part）的HTTP        POST请求提交的文档大小的上限，单位是Kb。这个值指定为1024的倍数来确定Bytes的大小。
formdataUploadLimitInKB - 表单通过POST请求发送的最大size,设置了一个用Kb表示的限制，用以限制HTTP POST请求中提交的表单数据的大小，这个大小可以用来传递请求的参数但并不适合（写入）URL中
addHttpRequestToContext - 用来声明原始的HttpServletRequest对象应该被包括在使用httpRequest的SolrQueryRequest的上下文集合（context map）中。 这个HttpServletRequest不会用于任何Solr的组成部分，但在开发自定义的插件是会很有用
-->   
<requestParsers enableRemoteStreaming="true"  
multipartUploadLimitInKB="2048000"  
formdataUploadLimitInKB="2048"/>  
<!-- 
<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="true" />  
<!--  
<httpCaching never304="true" >  
<cacheControl>max-age=30, public</cacheControl>   
</httpCaching>  
-->  
<!--  
<httpCaching lastModifiedFrom="openTime"  etagSeed="Solr">  
<cacheControl>max-age=30, public</cacheControl>   
</httpCaching>  
-->  
</requestDispatcher>  

10.requestHandler请求处理器

<!-- Request Handlers:提供了类似webservice的功能，可以通过http请求solr搜索,输入的请求会通过请求中的路径被转发到特定的处理器。-->  
<!-- SearchHandler：基本的请求处理器是SearchHandler,它提供一系列SearchComponents。通过multiple shards支持分布式。-->  
<requestHandler name="/select" class="solr.SearchHandler">  
<!-- 下面这些参数定义了需要返回多少结果（定义值为10），通过参数df定义了搜索的域默认为“text”域。echoParams参数定义了查询中的在调试信息返回的客户端请求中的参数。另外还要注意在列表中这些默认值定义方法的 变化：当参数是String，integer或其他类型时，定义类型是不同的。所有这些在搜索部分描述的参数可以在任何SearchHandlers中定义为默认值 -->  
<lst name="defaults">  
<str name="echoParams">explicit</str>  
<int name="rows">10</int>  
<str name="df">text</str>  
</lst>  
<!--  appends：这个设置允许在用户查询中添加参数的定义。这些参数可能是过滤查询，或者其他可以被加入每一个查询的查询规则。在Solr中没有机制允许客户端覆盖这些添加，所以你应当确定你总是需要在查询中加入这些参数。在这个例子中，过滤查询“inStock:true”会添加到每一个查询上。 -->  
<lst name="appends">  
<str name="fq">inStock:true</str>  
</lst>  
<!-- 用法同上,尽量不要使用。-->  
<!-- Invariants：这个设置允许定义不会被客户端覆盖的参数。在invariants部分定义的值总是会被使用，而不考虑用户或客户端默认的或添加的值。facet域被定义，这个定义会限制Solr返回的facets。如果客户端请求facets，那么他们只会看到和这个配置的相同的facets。  -->  
<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>       
<!-- 
在request handler最后部分，是组件（component）的定义，它定义了可以被用于一个request Handler的搜索组件的列表。它们仅在request handler中注册。对搜索组件的更进一步的讨论在搜索组件部分。搜索组件元素只能被用于SearchHandler。
Handler Resolution：客户端可以通过带有“gt”这个参数的“/select/ url”请求，也可以通过在solrconfig.xml配置的方式来决定要访问的SolrRequestHandler。
Solr是通过下面的步骤去选择一个handler并处理请求的.....
寻找name属性跟请求中的qt参数匹配的handler
寻找在配置文件中“default=true”的handler
寻找在配置文件中name属性为“standad”的handler
使用StandardRequestHandler的默认实例
如果配置文件solrconfig.xml 包含有name属性为"/select", "/update", 或"/admin"，那么你的程序将不会沿用标准的请求处理过程，而将会是你自己自定义的逻辑。
扩展自己的Handler：实现一个SolrRequestHandler 最简单的方法是去扩展 RequestHandlerBase 类。
-->  
<!--  
<arr name="components">  
<str>nameOfCustomComponent1</str>  
<str>nameOfCustomComponent2</str>  
</arr>  
-->  
</requestHandler>