Solr之配置文件Solrconfig.xml和solr.xml说明

1 Solrconfig.xml

在Solr中solrconfig.xml文件是影响Solr本身参数最多的配置文件。
在solrconfig.xml中，需要配置下述的一些重要的功能，如：

1.1 DataDir和DirectoryFactory

1.1.1 使用dataDir参数指定索引数据的位置

默认情况下，Solr将其索引数据存储在一个名为/data的目录下中，该目录位于核心的实例目录下（instanceDir）。如果想要指定不同的目录来存储索引数据，则可以在core.properties文件中为核心配置dataDir，或使用solrconfig.xml文件中的参数。可以使用绝对路径或相对于SolrCore的instanceDir的路径名指定另一个目录。例如：

/solr/data/${solr.core.name}

所述${solr.core.name}取代将导致当前核心的名称被取代，这导致每个核心的数据被保持在一个单独的子目录中。

如果使用复制来复制Solr索引（如传统扩展和分发中所述），那么该目录应该对应于复制配置中使用的索引目录。

如果定义了环境变量 SOLR_DATA_HOME，或者为DirectoryFactory配置了solr.data.home，或者solr.xml包含一个元素，则数据目录的位置将是//data

1.1.2 为索引指定DirectoryFactory

默认solr.StandardDirectoryFactory是基于文件系统的，并且试图为当前的JVM和平台选择最好的实现。可以通过指定solr.MMapDirectoryFactory、solr.NIOFSDirectoryFactory或solr.SimpleFSDirectoryFactory来强制执行特定的实现或配置选项。

  true

这solr.RAMDirectoryFactory是基于内存的，不是持久性的，并且不适用于复制。使用此DirectoryFactory将你的索引存储在RAM中。

如果正在使用Hadoop并希望将索引存储在HDFS中，那么应该使用solr.HdfsDirectoryFactory，而不是上述任何一种实现

1.2 SolrConfig中的Lib指令

Solr允许通过在solrconfig.xml中定义指令来加载插件。

插件是按照它们在solrconfig.xml出现的顺序加载的。如果存在依赖关系，请首先列出最低级别的依赖关系jar。

可以使用正则表达式来提供对同一目录中其他jar的依赖关系的控制加载jar。所有目录都解析为相对于Solr instanceDir

1.3 SolrConfig中的架构工厂定义（Schema Factory Definition）

Solr的架构API使远程客户端可以通过REST接口访问架构信息并进行架构修改。
其他特性，如Solr的Schemaless Mode，也可以在运行时通过编程方式进行架构修改。

使用托管架构需要能够使用架构API来修改您的架构。然而，使用托管架构本身并不意味着您也在无架构模式(或“架构猜测”模式)中使用Solr

无架构模式需要启用托管架构（如果尚未建立模式），但是完全模式猜测需要额外配置，如“无模式模式”部分中所述。

尽管架构API的“读取”特性对于所有架构类型都是支持的，但是支持以编程方式进行架构修改依赖于正在使用的

1.3.1 Solr默认使用托管架构

当没有在solrconfig.xml文件中显式声明时，Solr隐式地使用ManagedIndexSchemaFactory，它是默认的mutable并将模式信息保存在一个managed-schema文件中。

 
  
    true
    managed-schema
  

如果你想明确配置 ManagedIndexSchemaFactory，下列选项可用：

• mutable - 控制是否可以对架构数据进行更改。这必须设置为true，以允许使用Schema API进行编辑。
• managedSchemaResourceName - 一个可选参数，默认为managed-schema，并为架构文件定义一个新的名称，该名称可以是除schema.xml以外的任何其他名称。

使用上面所示的默认配置，可以使用Schema API根据需要尽可能多地修改架构，如果希望将架构“锁定”到位并防止将来发生更改，则稍后将mutable值更改为false。

1.3.2 经典schema.xml

使用托管架构的替代方法是显式配置一个ClassicIndexSchemaFactory。ClassicIndexSchemaFactory 需要使用schema.xml配置文件，并且不允许在运行时对架构进行任何编程式更改。该schema.xml文件必须手动编辑，仅在加载集合时才加载。

1.3.3 从schema.xml切换到托管架构

如果你有一个现有的Solr集合使用了ClassicIndexSchemaFactory，并且你希望转换为使用托管模式，则可以简单地修改solrconfig.xml以指定使用ManagedIndexSchemaFactory

一旦Solr重新启动，它检测到schema.xml文件存在，但managedSchemaResourceName文件（即：managed-schema）不存在，现有的schema.xml文件将被重命名为schema.xml.bak，内容被重新写入托管的架构文件。如果你查看生成的文件，你会在页面顶部看到这个：

你现在可以随意使用Schema API，只需要进行更改，然后删除schema.xml.bak

1.3.4 从托管架构切换到手动编辑的schema.xml

如果你启动了Solr并启用了托管架构，并且想要切换到手动编辑schema.xml文件，则应执行以下步骤：

1. 重命名managed-schema文件为：schema.xml。
2. 修改solrconfig.xml以替换schemaFactory类。删除任何ManagedIndexSchemaFactory定义，如果存在。添加一个ClassicIndexSchemaFactory，如上所示的定义。
3. 重新加载核心。

如果你正在使用SolrCloud，则可能需要通过ZooKeeper修改文件。该bin/solr脚本提供了一种简单的方法来从ZooKeeper下载文件并在编辑之后将其上传

要完全控制schema.xml文件，你可能还需要禁用架构猜测，这可以在编制索引期间将未知字段添加到架构中

1.4 SolrConfig中的IndexConfig

solrconfig.xml的部分定义了Lucene索引编写器的低级行为。
默认情况下，这些设置在Solr包含的示例solrconfig.xml中注释掉，这意味着使用默认值。在大多数情况下，默认值是好的。

  ...

1.4.1 编写新的段

• ramBufferSizeMB
  一旦累积的文档更新超过了这么多的内存空间（以兆字节为单位），那么待完成的更新就会被刷新。这也可以创建新的段或触发合并。通常使用这个设置对于maxBufferedDocs是可取的。如果同时在solrconfig.xml中设置了maxBufferedDocs与ramBufferSizeMB的话，当到达任何一个限制时，就会出现一个刷新。默认值是100Mb。
  100
• maxBufferedDocs
  将文档更新的数量设置为内存中的缓冲区，然后再刷新为新段。这也可能触发合并。默认的 Solr 配置集由 RAM 使用量 (ramBufferSizeMB) 刷新。
  1000
• useCompoundFile
  控制新写入的（还没有合并的）索引段是否应该使用复合文件段格式。默认值是false
false

1.4.2 合并索引段

• mergePolicyFactory
  定义合并分段的完成方式。
  Solr中的默认值是使用 TieredMergePolicy，它将合并大小相同的段，并受到每层允许的段数限制。
  其他可用的政策是LogByteSizeMergePolicy、LogDocMergePolicy和UninvertDocValuesMergePolicy

  10
  10

1.4.3 控制段大小：合并因素

用户对配置TieredMergePolicy（或LogByteSizeMergePolicy）所做的最常见的调整是“合并因素”，以一次更改应合并的段数。

对于TieredMergePolicy，这是通过设置和选项来控制的，而LogByteSizeMergePolicy只有一个选项（全部默认值为10）

如果创建新的段会导致最低层段的数量超过mergeFactor值，那么所有这些段被合并在一起形成一个大的段。因此，如果合并因子为10，则每次合并都会创建一个单独的段，该段大约是其十个成分中的每一个的十倍。当有10个这些较大的段时，他们又被合并成一个更大的单个段。这个过程可以无限期地继续下去。

当使用TieredMergePolicy时，过程是相同的，但不是一个单一的mergeFactor值，该segmentsPerTier设置被用作阈值来决定是否应该发生合并，并且该maxMergeAtOnce设置确定合并中应该包括多少段。

选择最佳的合并因素通常是索引速度与搜索速度的权衡。在索引中有更少的段通常会加速搜索，因为查找的位置更少。它也可以导致磁盘上的物理文件更少。但是为了保持低段的数量，合并会更频繁地发生，这会给系统增加负载并且减慢对索引的更新。

相反，保留更多的段可以加快索引，因为合并发生的次数少，使得更新不太可能触发合并。但是搜索的计算成本更高，并且可能会变慢，因为搜索条件必须在更多的索引段中查找。更快的索引更新也意味着更短的提交周转时间，这意味着更及时的搜索结果。

1.4.4 定制合并策略

如果内置合并策略的配置选项不完全适合你的用例，则可以对它们进行自定义：通过创建您在配置中指定的自定义合并策略工厂，或者配置使用wrapped.prefix配置选项用于控制将如何配置其包装的工厂：

  timestamp desc
  inner
  org.apache.solr.index.TieredMergePolicyFactory
  10
  10

上面的例子显示了 Solr 的 SortingMergePolicyFactory 被配置为通过 timestamp desc对合并段中的文档进行排序，并将 TieredMergePolicyFactory 配置为使用 maxMergeAtOnce=10 和 segmentsPerTier=10 的值，通过SortingMergePolicyFactory的wrapped.prefix选项定义的inner前缀

• mergeScheduler
  合并调度程序控制如何执行合并。默认ConcurrentMergeScheduler使用单独的线程在后台执行合并。替代方法是SerialMergeScheduler，不执行与单独线程的合并。
  
• mergedSegmentWarmer
  使用Solr进行近实时搜索合并段时，可以配置为在合并提交之前在新合并的段上预热读取器。这对于近乎实时的搜索并不是必需的，但是在合并完成之后将减少在打开新的近实时阅读器时的搜索延迟。
  

1.4.5 复合文件段

每个Lucene段通常由十几个文件组成。可以将Lucene配置为将一个段的所有文件打包成单个复合文件，其文件扩展名为.cfs；它是复合文件段的缩写。
由于各种原因，CFS 段可能会受到轻微的性能影响，具体取决于运行时环境。例如，文件系统缓冲区通常与打开的文件描述符关联，这可能会限制每个索引可用的总缓存空间。

在每个进程允许的打开文件数量有限的系统上，CFS可能会避免达到该限制。打开的文件限制也可以通过Linux / Unix ulimit命令对您的操作系统进行调整，或者其他操作系统的类似操作。

注意：CFS: 新段与合并段：要配置新写入的段是否应使用 CFS

许多合并策略实现都支持 noCFSRatio 和 maxCFSSegmentSizeMB 设置, 并使用默认值防止复合文件被用于大段, 但对于小段, 也要用复合文件。

1.4.6 索引锁

LockFactory选项指定要使用的锁定实现。
这组有效的锁定类型选项取决于你配置的DirectoryFactory。以下列出的值受StandardDirectoryFactory（默认）支持：

• native（默认）使用NativeFSLockFactory指定本机操作系统文件锁定。如果第二个Solr进程试图访问该目录，它将会失败。当多个Solr Web应用程序试图共享单个索引时，请勿使用它们。
• simple 使用 SimpleFSLockFactory指定一个纯文件进行锁定。
• single 使用SingleInstanceLockFactory。用于只读索引目录的特殊情况，或者当不可能有多个进程尝试修改索引（甚至是连续的）时。这种类型将防止同一个 JVM 内的多个内核试图访问相同的索引。但是，如果不同JVM中的多个Solr实例修改索引，则此类型不会防止索引损坏。
  hdfs使用HdfsLockFactory支持将索引和事务日志文件读写到HDFS文件系统。native

writeLockTimeout
在IndexWriter上等待写入锁定的最长时间。缺省值是1000，以毫秒表示。
1000

1.4.7 其他索引设置

还有一些其他参数可能对您的实现配置很重要。这些设置会影响对索引进行更新的方式或时间。

• reopenReaders
  控制是否重新打开IndexReader，而不是关闭然后打开，这通常效率较低。默认值是true。
• deletionPolicy
  控制在回滚情况下如何保留提交。默认值是SolrDeletionPolicy，其中有最大提交数量（maxCommitsToKeep）的子参数，要保留的最优化提交数（maxOptimizedCommitsToKeep），以及任何提交保留（maxCommitAge）的最大保留期限，它支持DateMathParser语法。
• infoStream
InfoStream设置指示底层Lucene类从索引过程中编写详细的调试信息作为Solr日志消息。

true

  1
  0
  1DAY

false

1.5 SolrConfig中的InitParams

solrconfig的 部分允许你定义处理程序配置之外的请求处理程序参数。
有几个用例可能是需要的：

• 一些处理程序在代码中隐式定义
• 在处理程序中使用了一些属性。这有助于你只保留这些属性的单个定义，并将其应用于多个处理程序。

例如，如果你希望多个搜索处理程序返回相同的字段列表，则可以创建一个部分，而无需在每个请求处理程序定义中定义相同的一组参数。如果你有一个单一的请求处理程序，该处理程序应该返回不同的字段，那么可以像往常一样在个别部分定义重写参数。
一个部分的属性和配置镜像了请求处理程序的属性和配置。它可以包含用于默认、附加和不变的部分，与任何请求处理程序相同。

例如，这里是在_default示例中默认定义的部分：

  
    _text_
  

这会将默认搜索字段（df）设置为路径部分中指定的所有请求处理程序的“文本”。如果我们稍后想要更改/query请求处理程序以在默认情况下搜索不同的字段，则可以通过定义/query中的部分的参数来重写

1.6 UpdateHandlers

在solrconfig.xml中的元素中进行配置，可能会影响索引更新的性能。这些设置影响在内部进行更新的方式。配置不会影响处理客户端更新请求的RequestHandler的更高级配置。

  ...

1.6.1 提交（Commits）

发送到 Solr 的数据在被提交到索引之前是不可搜索的。这样做的原因是，在某些情况下，提交可能会很慢，并且应该与其他可能的提交请求隔离进行，以避免覆盖数据。所以，最好提供数据提交时的控制权。有几个选项可用来控制提交的时间。

• commit和softCommit
  在Solr中，commit是一个动作，要求Solr将这些改变“提交”到Lucene索引文件中。默认情况下，提交操作会导致所有Lucene索引文件“hard commit”到稳定的存储（磁盘）。当客户端包含具有更新请求的commit=true参数时，可以确保索引更新完成后，就会将更新中受添加和删除影响的所有索引段写入磁盘。
  如果指定了一个额外的标志：softCommit=true，那么Solr执行一个“soft commit”，这意味着Solr会快速地将你的更改提交到Lucene数据结构，但不能保证Lucene索引文件被写入到稳定的存储中。这是近实时存储的一个实现，这个功能可以提高文档的可见性，因为你不必等待后台合并和存储（如果使用SolrCloud，则到ZooKeeper ）完成，然后再转到其他位置。完全提交意味着，如果服务器崩溃，Solr将确切地知道您的数据存储在哪里；soft commit意味着数据被存储，但位置信息尚未被存储。折中的方法是，soft commit使你能够更快地查看，因为它不等待后台合并完成。
• 自动提交
  这些设置控制挂起的更新将自动推送到索引的频率。自动提交的另一种替代方法是使用commitWithin，它可以在向Solr发送更新请求（即推送文档时）或更新RequestHandler时定义。
  maxDocs : 自上次提交以来发生的更新次数。
  maxTime : 自最早未提交更新以来的毫秒数。
  openSearcher : 是否在执行提交时打开新的搜索器。如果是false，则提交将刷新最近的索引更改为稳定的存储，但不会导致新的搜索器被打开，使这些更改可见。默认是true。
  如果达到了 maxDocs 或 maxTime 限制，Solr 将自动执行提交操作。如果缺少自动提交标记，那么只有显式提交才会更新索引。是否使用自动提交取决于应用程序的需求。
  确定最佳自动提交设置是性能和准确性之间的权衡。导致频繁更新的设置将提高搜索的准确性，因为新内容可以更快地进行搜索，但由于频繁的更新，性能可能会受到影响。不太频繁的更新可能会提高性能，但在查询中显示更新需要更长的时间。

  10000
  30000
  false

也可以像指定soft提交一样指定'soft'自动提交，不同之处在于，不应将 autoSoftCommit 标记设置为 "自动提交"。

  60000

• commitWithin
  这些commitWithin设置允许强制文档提交在规定的时间段内发生。这在近实时搜索中最常使用，因此默认情况下是执行soft提交。但是，这并不会将新文档复制到主/从环境中的从属服务器上。如果这是对实现的要求，可以通过添加一个参数来强制执行，如下例所示：

  false

有了这个配置，当您将commitWithin作为更新消息的一部分进行调用时，每次都会自动执行一个硬性提交。

1.6.2 事件监听器

UpdateHandler部分也是可以配置与更新相关的事件侦听器的地方。这些可以在任何commit（event="postCommit"）之后触发，或者仅在优化命令（event="postOptimize"）之后触发。
用户可以编写自定义更新事件监听器类，但常见的用例是通过RunExecutableListener运行外部可执行文件：

• exe
  要运行的可执行文件的名称。它应该包括文件的路径，相对于Solr home。
• dir
  用作工作目录的目录。默认是当前目录（“.”）。
• wait
  强制调用线程等待，直到可执行文件返回响应。默认是true。
• args
  任何传递给程序的参数。默认值是none。
• env
  任何环境变量设置。默认值是none。

1.6.3 事务日志

如RealTime Get部分所述，该功能需要事务日志。它在 solrconfig. xml 的 updateHandler 部分中进行了配置。
实时获取当前依赖于默认情况下启用的更新日志功能。它依赖于在 solrconfig. xml 中配置的更新日志，其内容如下：

  ${solr.ulog.dir:}

三个额外的专家级配置设置会影响索引性能，以及复制副本在必须进入完全恢复之前可能落后于更新的程度

• numRecordsToKeep
  每个日志保留的更新记录数。默认是100。
• maxNumLogsToKeep
  日志的最大数量保持不变。默认是10。
• numVersionBuckets
  用于在检查重新更新时用于跟踪最大版本值的bucket的数量；增加此值可降低在高容量索引期间同步对版本存储区的访问的成本，这要求每个Solr核心具有堆空间
  (8 bytes (long) * numVersionBuckets)。默认是65536

一个例子，要被包括在solrconfig.xml的下，将使用上述高级设置：

  ${solr.ulog.dir:}
  500
  20
  65536

1.7 查询SolrConfig中的设置

这些设置都是在solrconfig. xml中的 元素的子元素中配置的。

  ...

1.7.1 高速缓存

Solr缓存与索引搜索器的特定实例关联，索引的特定视图在该搜索器的生命周期内不发生变化。只要索引搜索器正在被使用，其缓存中的任何项目都将是有效的并可供重用。Solr中的缓存与许多其他应用程序中的缓存不同，因为缓存的Solr对象在一段时间间隔后不会过期；相反，它们在索引检索器的整个生命周期内仍然有效。

当新的搜索器被打开时，当前的搜索器将继续服务请求，而新的搜索者则 auto-warms 其缓存。新的搜索器使用当前搜索的缓存预先填充自己的缓存。当新的搜索器准备好时，它被注册为当前的搜索器，并开始处理所有新的搜索请求。一旦完成了所有的请求，旧的搜索器将被关闭。

在Solr中，有三个缓存实现：solr.search.LRUCache，solr.search.FastLRUCache和solr.search.LFUCache

缩写词LRU代表最近最少使用。当LRU缓存填满时，具有最早的最后访问时间戳的条目被驱逐，以为新条目腾出空间。最终的结果是被频繁访问的条目倾向于停留在缓存中，而那些不经常访问的条目倾向于退出，并且如果需要的话将会从索引中重新获取。

Solr 1.4中引入的这个FastLRUCache函数被设计成无锁的，所以它非常适合于在请求中多次触发的缓存。

LRUCache和FastLRUCache都使用 auto-warm 计数来支持整数和百分比，当 warm 发生时，它会相对于缓存的当前大小进行评估。

该LFUCache指最不常用的缓存。这与LRU缓存的工作方式类似，不同之处在于当缓存填满时，已经被使用的条目被删除。

Solr Admin UI中的Statistics页面将显示有关所有活动缓存的性能的信息。这些信息可以帮助您针对特定应用程序适当调整各种缓存的大小。当搜索器终止时，其缓存使用情况的摘要也被写入日志。

每个缓存都有设置来定义它的初始大小（initialSize），最大大小（size）和项目的数量，以用于warm（autowarmCount）。LRU和FastLRU缓存实现可以采取一个百分比，而不是autowarmCount的绝对值。

FastLRUCache和LFUCache支持showItems属性。这是要在缓存的统计信息页面中显示的缓存项目的数量。这是为了调试。

• filterCache
SolrIndexSearcher使用此缓存用于对所有匹配查询的所有文档的无序集进行筛选。数字属性控制缓存中条目的数量。
  Solr使用filterCache最典型的方法是缓存每个fq搜索参数的结果，尽管还有一些其他的情况。随后的查询使用相同的参数过滤器查询导致缓存命中并快速返回结果。
  当配置参数facet.method设置为fc时，Solr也使用这个高速缓存进行faceting

• queryResultCache
  该缓存保存以前搜索的结果：基于查询、排序和所请求的文档范围的文档ID（DocList）的有序列表。
  queryResultCache具有使用了附加的（可选的）设置，以限制使用的最大RAM（maxRamMB）。这使你可以指定此缓存内容使用的最大堆大小（以兆字节为单位）。当缓存增长超过此大小时，最早访问的查询将被逐出，直到缓存的堆使用率降至指定的限制以下。

• documentCache
  这个缓存包含Lucene文档对象（每个文档的存储字段）。由于Lucene的内部文档ID是暂时的，所以这个缓存不是自动加热的。为了确保Solr在请求期间不需要重新获取文档，documentCache应该始终大于max_resultstimes乘以max_concurrent_queries。存储在文档中的字段越多，此缓存的内存使用率就越高。

• 用户定义的高速缓存
  也可以为你自己的应用程序代码定义指定的缓存来使用。你可以找到并通过名字调用使用缓存对象SolrIndexSearcher的方法getCache()，cacheLookup()和cacheInsert()

如果要auto-warming缓存，请包含一个regenerator属性的具有实现solr.search.CacheRegenerator类的完全限定名称。你也可以使用NoOpRegenerator，它只是简单地重新填充旧项目的缓存。使用regenerator参数来定义它，比如：regenerator =“solr.NoOpRegenerator”

1.7.2 查询大小和Warm

• maxBooleanClauses
  这设置了布尔查询中允许的最大子句数。这可能会影响扩展到具有大量布尔项的查询的范围或前缀查询。如果超出此限制，则会引发异常。
  1024
  此选项修改影响所有Solr核心的全局属性。如果多个solrconfig.xml文件在这个属性上不一致，则任何时候的值都将基于初始化的最后一个Solr核心。
• enableLazyFieldLoading
  如果此参数设置为true，则不直接请求的字段将根据需要延迟加载。这可以提高性能，如果最常见的查询只需要一小部分的字段，特别是在不经常访问的字段大小较大的情况下。
  true
• useFilterForSortedQuery
  此参数将Solr配置为使用筛选器来满足搜索。如果所请求的排序不包括“score”，filterCache则将检查与查询匹配的过滤器。对于大多数情况，这只有在经常用不同的排序选项请求相同的搜索并且没有使用“score”时才是有用的。
  true
• queryResultWindowSize
  与queryResultCache一起使用时，将缓存请求数量的文档ID的超集。例如，如果响应于特定查询的搜索请求文档10到19，并且queryWindowSize是50，则文档0到49将被高速缓存。
  20
• queryResultMaxDocsCached
  该参数将文档的最大数量设置为在queryResultCache中任何条目的缓存。
  200
• useColdSearcher
  此设置控制是否有当前没有注册的搜索器的搜索请求应等待新的搜索器warm（false）或立即执行（true）。当设置为“false”时，请求将被阻塞，直到搜索器已经warm其缓存为止。
  false
• maxWarmingSearchers
  此参数设置在任何给定时间可能在后台预热的搜索器的最大数量。超过这个限制会引发错误。对于只读，值为2是合理的。
  2

1.7.3 与查询相关的监听器

如缓存部分所述，新索引搜索器被缓存。可以使用监听器的触发器执行与查询有关的任务。最常见的用途是定义查询，以便在索引搜索器启动时进一步“warm”索引搜索器。这种方法的一个好处是，可以预先填充字段缓存以进行更快的排序。

良好的查询选择对于这种类型的监听器是关键的。最好选择最常见或最重的查询，不仅包括使用的关键字，还包括任何其他参数，如排序或过滤请求。

有两种类型的事件可以触发监听器。正在准备一个新的搜索时，会发生firstSearcher事件，但没有当前注册搜索来处理请求或获得从auto-warming的数据（例如，Solr上的启动）。每当有新的搜索器准备好时，就会触发一个newSearcher事件，并有一个当前的搜索器处理请求。

下面的（注释掉的）例子可以在Solr sample_techproducts_configs 配置集的solrconfig.xml的文件中找到，并且演示如何使用这个solr.QuerySenderListener类来warm一组显式查询：

  
  
  



  
    static firstSearcher warming in solrconfig.xml
  

1.8 RequestDispatcher

solrconfig.xml的requestDispatcher元素，控制了Solr HTTP RequestDispatcher实现对请求的响应方式。

1.8.1 handleSelect元素

注意：handleSelect 是为了传统的后向兼容性；那些新来的Solr不需要改变默认配置的方式

第一个可配置项是元素本身的handleSelect当选属性。该属性可以设置为“true”或“false”两个值之一。它管理Solr如何响应请求，如：/select?qt=XXX。如果requestHandler没有显式注册/select名称，默认值“false”将忽略请求/select。值“true”将查询请求路由到定义为qt值的解析器。
在Solr的最新版本中，/selectrequestHandler是默认定义的，因此值“false”将正常工作

  ...

1.8.2 requestParsers元素

该子元素控制与解析请求的相关值。这是一个空的XML元素，没有任何内容，只有属性。
属性enableRemoteStreaming控制是否允许远程传输内容。如果省略或设置为false（默认），则不允许流式传输。将其设置为true允许你指定要使用stream.file和stream.url参数进行流式传输的内容或位置。
如果启用远程流式传输，请确保你已启用身份验证。否则，有人可能通过访问任意的URL访问您的内容。将Solr放置在防火墙后面以防止从不可信的客户端访问Solr也是一个好主意。

属性multipartUploadLimitInKB以可以在多部分HTTP POST请求中提交的文档的大小为单位设置以千字节为单位的上限。指定的值乘以1024来确定以字节为单位的大小。-1意味着MAX_INT 的值，如果省略，它也是系统默认值。

属性formdataUploadLimitInKB在HTTP POST请求中提交的表单数据（application / x-www-form-urlencoded）的大小上设置了一个限制（千字节），可用于传递不适合URL的请求参数。-1意味着MAX_INT 的值，如果省略，也是系统默认值。

属性addHttpRequestToContext可以用来指示原始HttpServletRequest对象应该包含在SolrQueryRequest使用httpRequest键的上下文映射。HttpServletRequest不是任何Solr组件所使用的，但在开发自定义插件时可能会有用。

1.8.3 httpCaching元素

该元素控制HTTP缓存控制标头。不要将这些设置与Solr的内部缓存配置混淆。该元素控制由W3C HTTP规范定义的HTTP响应的缓存。
这个元素允许三个属性和一个子元素。元素的属性控制是否允许对GET请求的304响应，如果是，则应该是什么类型的响应。当一个HTTP客户端应用程序发出一个GET时，它可以选择性地指定一个304响应是可接受的，如果该资源从上次被提取以来没有被修改过。

• never304
  如果存在值true，则GET请求将永远不会响应304代码，即使请求的资源未被修改。当此属性设置为true时，接下来的两个属性将被忽略。将其设置为true对于开发是非常方便的，因为当通过Web浏览器或其他支持缓存头的客户端修改Solr响应时，304响应可能会造成混淆。
• lastModFrom
  该属性可以设置为openTime（默认）或dirLastMod。该值openTime表示与由客户端发送的If-Modified-Since报头相比，最后修改时间应该相对于搜索器开始的时间来计算。使用dirLastMod，如果您想要时间精确地对应于磁盘上最后更新的索引。
• etagSeed
  这个属性的值作为ETag头的值发送。即使索引没有改变，更改此值也可能有助于强制客户重新获取内容 - 例如，当您对配置进行了一些更改时。

  max-age=30, public

1.8.4 cacheControl元素

除了这些属性之外，接受一个子元素：。这个元素的内容将作为HTTP响应的Cache-Control头的值发送。此标头用于修改请求客户端的默认缓存行为。
设置max-age字段控制客户端在从服务器再次请求之前可以重新使用缓存响应的时间。此时间间隔应根据你更新索引的频率以及你的应用程序是否可接受使用已过时的内容来设置。
设置must-revalidate将告诉客户端在服务器上重新使用之前确认其缓存副本仍然正常。这将确保使用最及时的结果，同时避免在不需要的情况下再次获取内容，则请求服务器进行检查。

1.9 编解码器：Codec Factory

可以在solrconfig.xml中指定一个codecFactory来确定将索引写入磁盘时使用哪个Lucene Codec

如果未指定，则Lucene的默认编解码器将被隐式使用。

Lucene的默认编解码器有两种选择，如下所述：

• solr.SchemaCodecFactory
  该solr.SchemaCodecFactory支持以下2个主要特点：
  • 基于架构的每个字段类型配置docValuesFormat和postingsFormat- 请参阅“字段类型属性”部分以获取更多详细信息。
  • 一个compressionMode选项：BEST_SPEED （默认）针对搜索速度性能进行了优化；BEST_COMPRESSION 针对磁盘空间使用情况进行了优化
    如下示例：

  BEST_COMPRESSION

• solr.SimpleTextCodecFactory
Lucene的这个工厂SimpleTextCodecFactory生成一个纯文本可读的索引格式。
  这个编解码器不应该在生产中使用。SimpleTextCodec相对较慢，占用大量的磁盘空间
  示例：

转载于:https://www.w3cschool.cn/solr_doc/solr_doc-orsk2hja.html

2 Solr核心和solr.xml

在Solr中，术语core用于指单个索引和关联的事务日志和配置文件（包括solrconfig.xml和Schema文件等）。如果需要，你的Solr安装可以具有多个核心，这使你可以在同一台服务器中为不同结构的数据建立索引，并且更好地控制数据如何呈现给不同的受众。在 SolrCloud模式中，将更熟悉术语“collection”。在幕后，一个集合由一个或多个核心组成。

在独立模式下，solr.xml必须驻留在solr_home。在SolrCloud模式下，将从ZooKeeper加载solr.xml（如果它存在），回退到solr_home。

注意：在较旧版本的Solr中，核心必须在solr.xml中预定义为标签。为了让Solr了解它们。现在，Solr支持自动发现核心，它们不再需要显式定义。推荐的方法是使用api动态创建内核/集合。

2.1 solr.xml的格式

2.1.1 定义solr.xml

可以在$SOLR_HOME目录（通常是：server/solr）中以独立模式，或者在使用SolrCloud时在ZooKeeper中找到solr.xml。默认solr.xml文件如下所示：

  
    ${host:}
    ${jetty.port:8983}
    ${hostContext:solr}
    ${zkClientTimeout:15000}
    ${genericCoreNodeNames:true}
  

  
    ${socketTimeout:0}
    ${connTimeout:0}
  

发现 Solr 配置是SolrCloud 友好的。但是，元素的存在并不意味着Solr实例在SolrCloud模式下运行。除非在启动时指定了-DzkHost或-DzkRun

2.1.2 Solr.xml参数

• 元素
  没有属性可以在标签中指定，这是solr.xml的根元素。下表列出了solr.xml中每个XML元素的子节点。
  • adminHandler
    这个属性不需要设置
    如果使用，则应将此属性设置为继承自CoreAdminHandler的类的FQN（完全限定名称）。例如，com.myorg.MyAdminHandler将配置自定义管理处理程序（MyAdminHandler）来处理管理请求。
    如果这个属性没有设置，Solr使用默认的管理处理程序，org.apache.solr.handler.admin.CoreAdminHandler
  • collectionsHandler
    如上所述，用于自定义CollectionsHandler实现。
  • infoHandler
    如上所述，用于自定义InfoHandler实现。
  • coreLoadThreads
    指定将分配给并行加载内核的线程数。
  • coreRootDirectory
    核心发现树的根目录，默认为$SOLR_HOME（默认server/solr）。
  • managementPath
    目前不可操作。
  • sharedLib
    指定将在所有内核之间共享的公用库目录的路径。此目录中的任何JAR文件都将被添加到Solr插件的搜索路径中。这条路是相对$SOLR_HOME的。自定义处理程序可能被放置在这个目录中。
  • shareSchema
    此属性设置为true，可确保指向同一个Schema资源文件的多个核心将引用同一个IndexSchema对象。共享IndexSchema对象使加载核心更快。如果你使用此功能，请确保架构文件中没有使用特定于核心的属性。
  • transientCacheSize
    定义transient=true在最近使用最少的内核之前，可以加载多少个内核。
  • configSetBaseDir
    可以找到用于Solr核心的configSets的目录。默认为$SOLR_HOME/configsets
• 元素
  这个元素定义了几个与SolrCloud相关的参数。除非Solr实例以-DzkRun或-DzkHost开始，否则这部分被忽略。
  • distribUpdateConnTimeout
    用于设置集群内部更新的基础connTimeout。
  • distribUpdateSoTimeout
    用于设置集群内部更新的基础socketTimeout。
  • host
    Solr用于访问核心的主机名称。
  • hostContext
    url上下文路径。
  • hostPort
    Solr端口用于访问内核。
    在默认solr.xml文件中，设置为${jetty.port:8983}，将使用Jetty中定义的Solr端口，否则返回到8983。
  • leaderVoteWait
    当SolrCloud启动时，每个Solr节点将等待该分片的所有已知副本多长时间，然后才能假定任何未报告的节点已关闭。
  • leaderConflictResolveWait
    当试图为碎片选择一个引线时，该属性设置副本将等待查看冲突的状态信息以待解决的最大时间；在进行滚动重启时，特别是当托管监督员的节点重新启动时，可能会出现状态信息中的临时冲突。
    通常，180000（ms）的默认值足以解决冲突；如果你在SolrCloud中有数百或数千个小集合，则可能需要增加此值。
  • zkClientTimeout
    连接到ZooKeeper服务器的超时。它与SolrCloud一起使用。
  • zkHost
    在SolrCloud模式下，Solr应该用于集群状态信息的ZooKeeper主机的URL。
  • genericCoreNodeNames
    如果为TRUE，则节点名称不是基于节点的地址，而是基于标识核心的通用名称。当一台不同的机器接管服务的时候，核心的东西就会更容易理解。
  • zkCredentialsProvider ＆ zkACLProvider
    如果使用ZooKeeper访问控制，则这是可以指定的可选参数。
• 元素
  • class
    用于记录的类。相应的JAR文件必须可用于Solr，也许通过solrconfig.xml中的一个指令。
  • enabled
true / false - 是否启用日志记录。
• 元素
  • size
    缓冲的日志事件的数量。
  • threshold
    你的特定日志记录实现将记录到的日志记录级别。例如，当使用 log4j 时，可以指定DEBUG，WARN，INFO等。
• 元素
  如果你希望创建自定义分片处理程序，则可以在solr.xml定义自定义分片处理程序：
  由于这是自定义分片处理程序，因此子元素是特定于实现的。Solr提供的默认和唯一的分片处理程序是HttpShardHandlerFactory，在这种情况下，可以指定以下子元素：
  • socketTimeout
    群集内查询和管理请求的读取超时。默认值与节中指定的distribUpdateSoTimeout相同。
  • connTimeout
    群集内查询和管理请求的连接超时。默认为distribUpdateConnTimeout在该部分中指定的。
  • urlScheme
    要在分布式搜索中使用的URL方案。
  • maxConnectionsPerHost
    每个主机允许的最大连接数，默认为20。
  • maxConnections
    允许的最大连接总数。默认为10000。
  • corePoolSize
    线程池服务请求的初始核心大小。默认是0。
  • maximumPoolSize
    线程池服务请求的最大大小。默认是无限的。
  • maxThreadIdleTime
    空闲线程在被杀死之前在队列中持续的时间（以秒为单位）。默认是5秒。
  • sizeOfQueue
    如果线程池使用后备队列，则使用直接切换的最大大小是多少？默认是使用SynchronousQueue。
  • fairnessPolicy
    一个布尔值，用于配置线程池是否支持吞吐量的公平性。缺省值为false以支持吞吐量。
• 元素
  solr.xml中的元素允许你自定义Solr报告的度量标准。可以定义不应该返回的系统属性，或定义自定义供应商和记者。
  在默认的solr. xml 中，将看不到任何配置

2.1.3 替换solr.xml中的JVM系统属性

Solr支持在solr.xml的JVM系统属性值的变量替换，它允许运行时指定各种配置选项。语法是：${propertyname[:option default value]}。这允许定义Solr启动时可以覆盖的默认值。如果未指定默认值，则必须在运行时指定该属性，否则该solr.xml文件将在分析时生成错误。
在启动JVM时通常使用-D标志指定的任何JVM系统属性都可以用作solr.xml文件中的变量。

例如，在下面显示的solr.xml文件中，socketTimeout和connTimeout值都被设置为“0”。但是，如果你使用bin/solr -DsocketTimeout=1000开启Solr，则HttpShardHandlerFactory的socketTimeout的选项要使用1000毫秒的值覆盖，而重写的connTimeout选项将继续使用默认属性值“0”。

  
    ${socketTimeout:0}
    ${connTimeout:0}
  

2.2 core.properties

核心发现意味着创建核心就像core.properties在磁盘上的文件一样简单。
该core.properties文件是一个简单的Java属性文件，其中每行只是一个key=value对，例如：name=core1。请注意，不需要使用引号。
最小的core.properties文件看起来像下面的例子。但是，它也可以是空的
name=my_core_name

2.2.1 安置core.properties

Solr核心是通过在solr.home子目录下放置一个名为core.properties的文件来配置的。对树的深度没有先验限制，对于可以定义的内核数量也没有限制。核心可能在树中的任何地方，但核心可能不在现有核心下定义

可以将Solr分割成多个核心，每个核心都有自己的配置和索引。核心可以专用于单个应用程序或非常不同的应用程序，但所有内容都通过一个通用的管理界面进行管理。您可以即时创建新的Solr核心，关闭核心，甚至可以将一个正在运行的核心替换为另一个核心，而不用停止或重新启动Solr。
如有必要，你的core.properties文件可以是空的。假设core.properties位于./cores/core1（相对于solr_home），但是是空的。在这种情况下，核心名称被假定为“core1”。instanceDir将是包含core.properties（即，./cores/core1）的文件夹。dataDir将会是../cores/core1/data，等等。

2.2.2 定义core.properties文件

最小的core.properties文件是一个空文件，在这种情况下，所有的属性默认是适当的。

Java属性文件允许hash（#）或bang（!）字符指定注释到行尾（comment-to-end-of-line）。
以下属性可用：

• name
SolrCore的名称。在使用CoreAdminHandler运行命令时，将使用此名称来引用SolrCore。
• config
  给定核心的配置文件名称。默认是solrconfig.xml
• schema
  给定核心的架构文件名称。默认值是schema.xml，但是请注意，如果使用的是托管模式（默认行为），那么此属性的任何值如果与有效值managedSchemaResourceName不匹配，将被读取一次，备份并转换为托管模式使用
• dataDir
  核心的数据目录（存储索引的位置）可以是绝对路径名，也可以是相对于instanceDir值的路径。默认的是data
• configSet
  如果需要，定义的configset的名称可用于配置内核
• properties
  此核心的属性文件的名称。该值可以是绝对路径名或相对于instanceDir值的路径。
• transient
  如果为true，如果Solr达到transientCacheSize，则核心可以被卸载。如果未指定，则默认为 false。按照最近最少使用的顺序卸载内核。在SolrCloud模式下不建议将其设置为true。
• loadOnStartup
  如果为true，则默认如果未指定，则在Solr启动时加载核心。在SolrCloud模式下不建议将此设置为false。
• coreNodeName
  仅在SolrCloud中使用，这是承载此副本的节点的唯一标识符。默认情况下coreNodeName会自动生成，但通过显式设置此属性允许你手动分配新的核心来替换现有的副本。例如，通过从具有新主机名或端口的新计算机上进行备份恢复来更换发生硬件故障的计算机时，这可能很有用。
• ulogDir
  此核心（SolrCloud）的更新日志的绝对或相对目录。
• shard
  将此核心分配给（SolrCloud）的分片。
• collection
  这个核心的集合的名称是（SolrCloud）的一部分。
• roles
  未来的SolrCloud参数或用户标记节点以供自己使用的方式。

转载于:https://www.w3cschool.cn/solr_doc/solr_doc-uo952hrm.html