solrconfig.xml配置檔案主要定義了SOLR的一些處理規則，包括索引資料的存放位置，更新，刪除，查詢的一些規則配置。
下面將對solrconfig進行詳細描述：
1 <luceneMatchVersion>4.8</luceneMatchVersion> 表示solr底層使用的是lucene4.8
2 <lib dir="../../../contrib/extraction/lib" regex=".*.jar" /> 表示solr引用包的位置,當dir對應的目錄不存在時候，會忽略此屬性
3 <dataDir>${solr.data.dir:}</dataDir> 定義了索引資料和日誌檔案的存放位置
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 name="DirectoryFactory"
class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}">
<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>
5 <codecFactory class="solr.SchemaCodecFactory"/><schemaFactory class="ClassicIndexSchemaFactory"/>
編解碼允許使用自定義的編解碼器。例如：如果想啟動per-field DocValues格式, 可以在solrconfig.xml裡面設定SchemaCodecFactory：
docValuesFormat=”Lucene42″: 這是預設設定，所有資料會被載入到堆記憶體中。
docValuesFormat=”Disk”: 這是另外一個實現，將部分資料儲存在磁碟上。
docValuesFormat=”SimpleText”: 文字格式，非常慢，用於學習。
6 <indexConfig>
用於設定索引的低階別的屬性
1） <filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/> //限制token最大長度
2） <writeLockTimeout>1000</writeLockTimeout> //IndexWriter等待解鎖的最長時間（毫秒）
3） <maxIndexingThreads>12</maxIndexingThreads> //生成索引時使用的最大執行緒數.
4） <useCompoundFile>false</useCompoundFile>
//solr預設為false。如果為true,索引檔案減少,檢索效能降低,追求平衡。通過將很多 Lucene 內部檔案整合到單一一個檔案來減少使用中的檔案的數量。這可有助於減少 Solr 使用的檔案控制程式碼數目，代價是降低了效能。除非是應用程式用完了檔案控制程式碼
5） <ramBufferSizeMB>100</ramBufferSizeMB> //快取
6） <maxBufferedDocs>1000</maxBufferedDocs> //快取。兩個同時定義時命中較低的那個。在合併記憶體中文件和建立新段之前，定義所需索引的最小文件數。段是用來儲存索引資訊的 Lucene 檔案。較大的值可使索引時間變快但會犧牲較多的記憶體。
7）
`<mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
<int name="maxMergeAtOnce">20</int>
<int name="segmentsPerTier">20</int>
</mergePolicy>`
//合併策略。
8） <mergeFactor>10</mergeFactor> //合併因子,每次合併多少個segments。決定低水平的 Lucene 段被合併的頻率。較小的值（最小為 2）使用的記憶體較少但導致的索引時間也更慢。較大的值可使索引時間變快但會犧牲較多的記憶體。
9） <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/> //合併排程器。
10） <lockType>${solr.lock.type:native}</lockType> //鎖。
11） <unlockOnStartup>false</unlockOnStartup> //unlockOnStartup告知Solr 忽略在多執行緒環境中用來保護索引的鎖定機制。在某些情況下，索引可能會由於不正確的關機或其他錯誤而一直處於鎖定，這就妨礙了新增和更新。將其設定為 true 可以禁用啟動鎖定，進而允許進行新增和更新。
12） <termIndexInterval>128</termIndexInterval> //Lucene loads terms into memory 間隔
13） <reopenReaders>true</reopenReaders> //重新開啟,替代先關閉-再開啟。
14） <deletionPolicy class="solr.SolrDeletionPolicy"> //提交刪除策略,必須實現org.apache.lucene.index.IndexDeletionPolicy
15） <str name="maxCommitsToKeep">1</str> //最多持有提交點的數量
16） <str name="maxOptimizedCommitsToKeep">0</str> //最多持有優化提交點的數量
17） <str name="maxCommitAge">2MINUTES</str> OR <str name="maxCommitAge">1DAY</str><br> //一旦達到指定的時間刪除所有的提交點
18） <infoStream file="INFOSTREAM.txt">false</infoStream>//相當於把建立索引時的日誌輸出。<lockType>${solr.lock.type:native}</lockType>
設定索引庫的鎖方式，主要有三種：
⑴.single：適用於只讀的索引庫，即索引庫是定死的，不會再更改
⑵.native：使用本地作業系統的檔案鎖方式，不能用於多個solr服務共用同一個索引庫。Solr3.6 及後期版本使用的預設鎖機制。
⑶.simple：使用簡單的檔案鎖機制
19) <maxMergeDocs> 2147483647 </maxMergeDocs> //控制可由 Solr 合併的 Document 的最大數。較小的值 (< 10,000) 最適合於具有大量更新的應用程式。
20) <maxFieldLength> 10000 </maxFieldLength>
//對於給定的 Document，控制可新增到 Field 的最大條目數，進而截斷該文件。如果文件可能會很大，就需要增加這個數值。然而，若將這個值設定得過高會導致記憶體不足錯誤。
（預設設定 <filter class="solr.LimitTokenCountFilterFactory" maxTokenCount="10000"/>）
7 updateHandler節點<updateLog><str name="dir">${solr.ulog.dir:}</str></updateLog>
設定索引庫更新日誌，預設路徑為solr home下面的data/tlog。隨著索引庫的頻繁更新，tlog檔案會越來越大，所以建議提交索引時採用硬提交方式，即批量提交。
`<autoCommit>
<maxDocs>10000</maxDocs>
<maxTime>${solr.autoCommit.maxTime:5000}</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>`
自動硬提交方式:maxTime：設定多長時間提交一次maxDocs：設定達到多少文件提交一次openSearcher：文件提交後是否開啟新的searcher，
如果false，文件只是提交到index索引庫，搜尋結果中搜不到此次提交的文件；如果true，既提交到index索引庫，也能在搜尋結果中搜到此次提交的內容。
`<autoSoftCommit>`
`<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>`
`</autoSoftCommit>` //軟提交；
1、把記憶體檔案fsync到磁碟，但不建立index descriptor。也就是說原索引和現在的索引還互不感知，所以如果jvm崩潰，那這部分索引就沒了。
2、可以重新開啟searcher，使得新的索引可以被查詢到。
`<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>`
//一個postCommit的事件被觸發當每一個提交之後，
PS：自己的一些見解，solr提交索引的方式共有三種，通過solr api去提交的方式效能很差，不建議採用；個人建議還是採用autocommit的自動提交，雖然比較消耗資源，但是能最大限度儲存意外造成的索引丟失的情況；
更多資訊，請檢視https://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
8 Query查詢節點<maxBooleanClauses>1024</maxBooleanClauses>
設定boolean 查詢中，最大條件數。在範圍搜尋或者字首搜尋時，會產生大量的 boolean 條件，
如果條件數達到這個數值時，將丟擲異常，限制這個條件數，可以防止條件過多查詢等待時間過長。
快取方法http://www.cnblogs.com/phinecos/archive/2012/05/24/2517018.html
`<!-- 過濾器快取 -->
<filterCache class="solr.FastLRUCache"
size="32768"
initialSize="32768"
autowarmCount="512"/>`
`<!-- 查詢結果快取 -->
<queryResultCache class="solr.FastLRUCache"
size="8192"
initialSize="8192"
autowarmCount="512"/>`
`<!-- 查詢文件快取 -->
<documentCache class="solr.FastLRUCache"
size="4096"
initialSize="4096"
autowarmCount="0"/>`
`<!-- 自定義快取 -->
<cache name="perSegFilter"
class="solr.search.LRUCache"
size="4096"
initialSize="4096"
autowarmCount="4096"
regenerator="solr.NoOpRegenerator" />`
`<!-- 欄位值快取 -->
<fieldValueCache class="solr.FastLRUCache"
size="512"
autowarmCount="128"
showItems="32" />`
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的全域性鎖，所以併發性效果方面稍差。
`<enableLazyFieldLoading>true</enableLazyFieldLoading>` //某些欄位延時載入，以提高效能，例如內容較多的壓縮檔案
`<queryResultWindowSize>50</queryResultWindowSize>` //Result Window Size 優化queryResultCache結果cache
`<queryResultMaxDocsCached>800</queryResultMaxDocsCached>` //查詢結果文件的最大快取數
`<!-- 與請求相關的監聽器 -->
<!-- QuerySenderListener使用NamedList的陣列和每個序列NamedList的執行一個本地查詢請求。-->
<listener event="newSearcher" class="solr.QuerySenderListener">
<arr name="queries">
</arr>
</listener>
<listener event="firstSearcher" class="solr.QuerySenderListener">
<arr name="queries">
<lst>
<str name="q">static firstSearcher warming in solrconfig.xml</str>
</lst>
</arr>
</listener>
<useColdSearcher>true</useColdSearcher>` //使用雲搜尋
`<maxWarmingSearchers>8</maxWarmingSearchers>`
//該引數用於設定最大的 searcher 數量，這些 searcher 實現預熱好的，隨時可以呼叫。如果超過這個數量，將會報錯。在一個只讀的索引庫中，2個預熱的 searcher 是相對合理的，如果是讀寫的索引庫中，根據記憶體和cpu的大小可以給一個相對大一點的值。
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="20480"
addHttpRequestToContext="false"/>`
`<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>`
10 requestHandler（請求處理器）
提供了類似webservice的功能，可以通過http請求solr搜尋
Configuration<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 name="/query" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
<str name="wt">json</str> //顯示格式
<str name="indent">true</str>
<str name="df">text</str>
</lst>
</requestHandler>`
這些引數定義了需要返回多少結果（定義值為10），通過引數df定義了搜尋的域預設為“text”域。echoParams引數定義了查詢中的在除錯資訊返回的客戶端請求中的引數。
另外還要注意在列表中這些預設值定義方法的 變化：當引數是String，integer或其他型別時，定義型別是不同的。
更多資訊，請檢視https://wiki.apache.org/solr/CoreQueryParameters?action=fullsearch&context=180&value=echoParams&titlesearch=Titles
所有這些在搜尋部分描述的引數可以在任何SearchHandlers中定義為預設值（這些引數的細節資訊請參考搜尋部分）
除了這些預設值，還有一些選擇可用於SearchHandler，包括了下面的這些內容：
appends：這個設定允許在使用者查詢中新增引數的定義。這些引數可能是過濾查詢，或者其他可以被加入每一個查詢的查詢規則。在Solr中沒有機制允許客戶端覆蓋這些新增，所以你應當確定你總是需要在查詢中加入這些引數。
`<lst name="appends">
<str name="fq">inStock:true</str>
</lst>`
在這個例子中，過濾查詢“inStock:true”會新增到每一個查詢上。
Invariants：這個設定允許定義不會被客戶端覆蓋的引數。在invariants部分定義的值總是會被使用，而不考慮使用者或客戶端預設的或新增的值。
`<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。
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 類。
更多資訊，請參考http://wiki.apache.org/solr/SolrRequestHandler#head-3dfff37b7cc549669ba241eb6050ffdbc80d7e78