嚴(yán)格來說，我這篇內(nèi)容，主要是根據(jù)Solr in Action關(guān)于配置的說明栖榨，以及參考Solr的wiki寫的算是讀書筆記吧昆汹，所有的圖片默認來自Solr in Action這本書。
這本書我覺得對學(xué)習(xí)Solr來說非常有用婴栽，雖然目前沒有中文版满粗，另外對于其理解可能有偏差的地方，大家謹(jǐn)慎閱讀愚争。
一映皆、總覽
solr的配置重要的有三個：solr.xml、solrConfig.xml轰枝、schema.xml
solr.xml 是整個Solr節(jié)點的配置捅彻，是定義關(guān)于core的管理、collection分片狸膏、solr云
和http請求處理沟饥，不過目前改動不多，也沒仔細研究湾戳。
solrConfig.xml：關(guān)于core或collection的主要配置信息贤旷。
schema.xml ：定義索引中的文檔結(jié)構(gòu)，包括字段名砾脑、字段類型幼驶、字段處理方法等，類似于表結(jié)構(gòu)定義韧衣，比它更復(fù)雜盅藻。
二、Solr啟動過程
1畅铭、solr啟動的時候會找Java的全局變量：solr.solr.home 氏淑，作為根目錄。
2硕噩、solr到根目錄下面的每個子目錄假残，去查找是否包含core.properties的文件，有的話自動啟動這個collection或core的恢復(fù)工作炉擅。
core.properties 配置文件主要配置辉懒，core或collection名字、shard分片信息谍失、存儲的數(shù)據(jù)和日志信息以及定義的schemal.xml等眶俩。
在恢復(fù)過程中，solr會在這個子目錄下面的conf文件夾下去找solrconfig.xml的配置快鱼。
下圖是solr的例子程序啟動過程：
三颠印、solrconfig.xml 配置說明
3.1 基本概述
基本說明
1纲岭、在solr的管理界面上選擇具體的core就可以在files里面找到這個配置文件。
2嗽仪、solr的配置的xml元素里面有兩個比較特別的元素荒勇，一個是標(biāo)示是命名的數(shù)組，
標(biāo)示是排序的name/pairs對闻坚。
3沽翔、如何使修改的配置生效那，可以通過：前臺core管理地方通過reload或通過http請求進行reload窿凤。
比如：http://xx.xx.xx.xx:8983/solr/admin/collections?action=RELOAD&name=testspeed3
具體內(nèi)容
1仅偎、solr使用的Lucene版本、使用到的Jar路徑配置雳殊；JMX配置橘沥，用于MBeans監(jiān)控。
2夯秃、定義如何處理查詢座咆、如何處理索引的內(nèi)容。
3.2 查詢配置
solr最重要的功能之一是查詢仓洼，我們看下當(dāng)我們發(fā)起一個查詢的時候介陶，它的處理過程如何的，
發(fā)起的solr的http的ulr例子如下：
如果按照solr官方的利用Jetty服務(wù)器的話色建，那么處理過程如下圖：
組件調(diào)用說明：
1哺呜、客戶端發(fā)送HTTP的GET請求，查詢關(guān)鍵字作為一個部分發(fā)送給Jetty服務(wù)器箕戳。
2某残、Jetty通過查詢路徑中的/solr上下文，通過調(diào)度器將這個請求映射到solr這個
web程序中去陵吸。
3玻墅、solr請求處理器，利用collection1這個路徑來確定core或collection名字壮虫，通過select來找到注冊在
solrconfig.xml中的請求處理器椭豫。
4、solrconfig.xml中注冊的查詢請求處理器執(zhí)行一系列配置組件去處理旨指。
5、按照solrconfig.xml中配置的返回處理組件喳整，去設(shè)置返回的具體格式谆构，執(zhí)行返回。
查詢請求處理器定義：
explicit
10
text
solr.SearchHandler 最終被解析為：org.apache.solr.handler.component.SearchHandler這個類進行處理框都。
solr其他的配置類似搬素。
solr的查詢過程的詳細情況分為幾個階段，如下圖：
1、請求參數(shù)裝飾
1）defaults ?- 幫忙指定默認參數(shù)熬尺。
2）invariants-設(shè)置特定參數(shù)為固定值摸屠，重寫客戶端提供的值粱哼。
3）append ? - 在客戶端的參數(shù)基礎(chǔ)上進行參數(shù)的添加季二。
2、 第一組件
可選擇配置的揭措，用于查詢處理前的預(yù)處理胯舷。
3、查詢組件鏈
至少包含查詢組件绊含，用于執(zhí)行具體的查詢工作桑嘶。
4、最后組件
用于處理查詢后最后工作躬充，比如拼寫檢查組件逃顶。
具體的定義，可以看下solrconfig.xml中提供的一個/browse定義的相關(guān)查詢整個過程的配置充甚。
3.3 搜索器（Searcher）
搜索器說明
在solr中以政，具體執(zhí)行的搜索工作是通過搜索器執(zhí)行的，如上面的圖所示津坑。在一個solr節(jié)點中妙蔗，只有一個注冊的搜索器。
它是一個基于Lucene索引的可讀快照疆瑰，當(dāng)文檔被添加到索引中眉反，不是立刻可以搜索到。
讓新添加的文檔可以被搜索到穆役，需要關(guān)閉老的搜索器寸五，打開新的搜索器。一般來說commit操作就會執(zhí)行這個操作耿币。
這個過程是比較耗時的梳杏，關(guān)閉老的搜索器的時候，如果有用戶正在查詢淹接，你的關(guān)閉動作需要等待十性。
另外所有的緩存都是基于舊的索引的，所以所有的緩存將失效塑悼，除非重新預(yù)熱劲适。
預(yù)熱搜索器
如上文所述，搜索器在commit后需要重新打開厢蒜，如果原來用戶正在執(zhí)行查詢霞势，緩存數(shù)據(jù)完全失效了烹植，會促使重新執(zhí)行查詢，
導(dǎo)致用戶體驗差愕贡，所以需要預(yù)熱草雕。
一般來說，預(yù)熱做兩個事情固以，一執(zhí)行預(yù)熱語句墩虹、二用新的查詢到的緩存數(shù)據(jù)代替老的緩存數(shù)據(jù)。
注意嘴纺，多的預(yù)熱語句败晴，將會導(dǎo)致打開新的搜索器變慢，影響實時性栽渴，頻繁提交的話將會導(dǎo)致內(nèi)存等占用過大問題尖坤。
使用冷搜索器
如果說預(yù)熱好的搜索器稱為熱的搜索器:)雖然沒看到這個說法，那么沒有預(yù)熱的搜索器稱為冷搜索器闲擦，配置如下：
false 如果這個配置為true慢味，則來查詢的時候，如果沒有注冊的
搜索器墅冷，有的搜索器正在預(yù)熱纯路，那不管是否預(yù)熱完成，直接使用這個搜索器寞忿。
（這里面有個矛盾驰唬，既然所有的搜索器都是在新的預(yù)熱好，老的才被關(guān)閉的腔彰，那么這種情況怎么存在叫编，也許是第一次執(zhí)行查詢的時候）。
最大預(yù)熱搜索器
當(dāng)每次commit都會打開一個新的搜索器進行預(yù)熱霹抛，那么如果commit操作在程序里面控制搓逾，在并發(fā)的情況下，可能有多個搜索器被打開杯拐，
有個配置項：2霞篡，通過它來配置可以打開的最大搜索器的個數(shù)，超過這個閥值端逼，
commit操作會失敗朗兵，如果經(jīng)常因為這個失敗，要看下是不是因為預(yù)熱的時間過長顶滩。
3.4 緩存配置
solr中緩存管理
1）緩存的尺寸和管理策略
Solr中設(shè)置緩存的尺寸是對象的數(shù)量矛市，當(dāng)超過這個數(shù)量的時候，Solr利用相關(guān)策略進行清除诲祸。
有兩個主要策略LRU（即Least Recently Used ）將最近最少使用的實體移出緩存浊吏；
LFU（least frequently used）是將最少使用次數(shù)的實體移出緩存，過濾器緩存比較適合LFU策略救氯。
有個誤區(qū)是在內(nèi)存準(zhǔn)許的情況下找田，盡可能設(shè)置你的緩存為盡可能的大。這個認識是錯誤的着憨。
因為在commit后墩衙，緩存會失效，這將導(dǎo)致JVM回收這些內(nèi)存甲抖，緩存大，導(dǎo)致JVM回收垃圾時間長准谚，
服務(wù)被暫停的時間長挫剑。
2）緩存的命中和拆遷
命中率是指在緩存中發(fā)現(xiàn)一個查詢請求的比例。代表你的程序從緩存中獲得的好處柱衔。
期望是100%樊破，驅(qū)逐數(shù)量顯示根據(jù)前面的緩存策略，多少對象被驅(qū)逐出緩存唆铐，拆遷量大
可能意味著你的緩存設(shè)置的小哲戚。
3）緩存對象的失效
在solr中，所有的緩存對象和搜索器都是關(guān)聯(lián)的艾岂，只要這個搜索器不關(guān)閉顺少，這些緩存就是有效的。
4）自動預(yù)熱新緩存
在一個commit之后王浴，新的搜索器被打開脆炎，但是不立刻關(guān)閉老的搜索器，直到這個新的搜索器被完全預(yù)熱叼耙。這個晚關(guān)閉策略主要用于填充新的搜索器的緩存腕窥。
每個solr緩存都支持一個autowarmCount的屬性去設(shè)置最大的對象數(shù)量或者老的緩存的尺寸比例，去自動預(yù)熱筛婉。
過濾器緩存（ Filter Cache）
過濾器緩存影響最終文檔結(jié)果簇爆，不影響打分。當(dāng)你執(zhí)行不同的查詢語句爽撒，而相同過濾條件的時候入蛆，過濾器緩存就可以起作用。
過濾器緩存可以跨查詢應(yīng)用硕勿，可以顯著優(yōu)化查詢的性能哨毁。
配置如下：
size="512"
initialSize="512"
autowarmCount="0"/>
當(dāng)你的過濾條件復(fù)雜，或你索引中的文檔數(shù)量很多的時候源武，過濾器的創(chuàng)建和保存在內(nèi)存中是很耗時間的扼褪，所以你希望可以預(yù)熱過濾器緩存想幻。如果一個過濾在你的程序中對很多請求都通用，那么緩存過濾器是有意義的话浇。
每個對象在緩存中都有個key脏毯，在過濾器緩存中，這個key就是過濾器的查詢語句幔崖，比如前面例子中：manu:belkin. 當(dāng)預(yù)熱一個過濾器緩存時候食店，舊的緩存中的key被抽取出來，在新的搜索器上被重新執(zhí)行赏寇。如果你有上百個過濾器緩存吉嫩，那么在預(yù)熱的時候，solr必須執(zhí)行這個100個過濾器的查詢嗅定，這將消耗大量的時間自娩。
我們建議預(yù)熱的過濾器緩存，應(yīng)該將autowarmCount設(shè)置為一個比較小的值露戒。此外建議使用
LFU策略椒功，下面是建議的配置：
過濾緩存器所占用的內(nèi)存大小，當(dāng)然和你在內(nèi)存中緩存的文檔數(shù)量有關(guān)智什，需要的內(nèi)存是你文檔數(shù)這么多的byte內(nèi)存动漾。
1000萬的文檔數(shù)大概占1.2MB內(nèi)存。
查詢結(jié)果緩存（Query result cache）
查詢結(jié)果集緩存保存的是查詢結(jié)果集荠锭。多次執(zhí)行同一個查詢的時候旱眯，后面的查詢結(jié)果一般從查詢結(jié)果緩存中直接得到，而不是在索引中再次執(zhí)行相同的查詢证九，這是優(yōu)化花費高查詢的強大方法删豺。
查詢結(jié)果集緩存定義如下：
size="512" ?initialSize="512" autowarmCount="0">
查詢結(jié)果集緩存了查詢語句作為key，內(nèi)部的Lucene文檔ID鏈表作為value愧怜。
文檔ID在索引中增加新的文檔的時候或合并的時候可能發(fā)生變化呀页，所以預(yù)熱的時候，
緩存值需要被重新計算拥坛。
為了預(yù)熱一個結(jié)果集蓬蝶，solr必須重新執(zhí)行查詢，相同的建議是保持autowarmCount為一個較小的值而不是默認的0猜惋，你將從中獲益丸氛。還有些關(guān)于些雜項來設(shè)置查詢結(jié)果集。
查詢結(jié)果窗口大小
查詢窗口 元素著摔，在你執(zhí)行一個查詢的時候缓窜，給你提供額外的頁面。
假設(shè)你的程序一頁提供10個文檔，在大多數(shù)情況下禾锤，用戶只看第一和第二頁私股。你可以設(shè)置這個值為20，這樣在查看第二頁的時候就不用再次查詢了时肿。
一般情況下庇茫，這個值設(shè)置為你一頁需要查詢的文檔數(shù)量2-3倍，多了會給你的查詢帶來不必要的負擔(dān)螃成。
查詢結(jié)果最大文檔緩存
在前面，給緩存設(shè)置的值的大小查坪，代表緩存的數(shù)量寸宏，每個緩存的最大大小也可以設(shè)置一個值。
200就是設(shè)置一個緩存實體可以緩存的最大文檔數(shù)量偿曙。
準(zhǔn)許延遲字段加載
具體配置為：true氮凝，設(shè)置了后，如果你的查詢是查詢文檔集
中的一部分望忆，那么只有需要的字段才被加載罩阵，其他字段不加載。
（默認的值為true启摄。這樣solr在根據(jù)讀取Document信息時稿壁，如果enableLazyFieldLoading為True，把要返回的Field集合封裝為一個SetNonLazyFieldSelector歉备，
這里的Field的值都是立即加載的傅是，即到索引庫里把該Field的值取出來保存到Doc中的。doc的其他的Field的值則是通過延遲加載的蕾羊。
也是就在document調(diào)用具體的get(String name)方式時喧笔，由LazyField去取值的」暝伲可見設(shè)置延遲加載為enableLazyFieldLoading為True书闸，
而且我們要返回的Field也很少時，那我們?nèi)プx索引庫所花的時間就少了）
文檔緩存（Document Cache）
查詢結(jié)果緩存是保存匹配查詢的一系列文檔內(nèi)部ID利凑，即使查詢結(jié)果在緩存中浆劲。solr仍然需要從磁盤中加載搜索結(jié)果的文檔信息。文檔緩存截碴，存儲的key為內(nèi)部文檔ID梳侨，值為從磁盤加載進來的文檔內(nèi)容。因此查詢結(jié)果集緩存可以利用文檔緩存去查詢在查詢結(jié)果集中對應(yīng)的文檔信息日丹。
size="512"
initialSize="512"
autowarmCount="0"/>
字段值緩存（Field Cache）
它在排序的時候使用走哺，嚴(yán)格來說屬于Lucen來管理的。字段值緩存提供了通過文檔ID來快速訪問字段值哲虾。
