--lvpei.cnblogs.com 翻譯自http://wiki.apache.org/solr/SolrCaching ,翻譯的很差，不如看原版。

Solr緩存與Solr的索引搜索器（SolrIndexSearcher）息息相關(guān)的，而眾所周知，索引的結(jié)構(gòu)很難做出大的變動，效率也是板上釘釘?shù)氖虑椤Ｒ虼颂岣咚饕阉髌鞯氖褂眯剩怪谌魏尉彺娑寄軌蚋咝Р⒖芍赜檬悄壳靶枰覀內(nèi)プ龅墓ぷ鳌Ｔ赟olr中所提到的緩存和我們平常遇到的緩存不同。在Solr中的緩存對象將不會在一段時間之后過期，也就是說，只要索引搜索器是存在的，那么高速緩存對象也一定存在。

滿足索引搜索器服務(wù)的要求，并在一個新的搜索器被打開，新的會自動后臺預(yù)熱，原來的那個搜索器仍然滿足對外服務(wù)的要求。新的搜索器就緒時，它將作為當(dāng)前搜索被注冊，并將處理以后新的搜索請求。而舊的搜索器在把它當(dāng)前所有搜索請求完成后，將會關(guān)閉。當(dāng)前新的搜索器被做為自動預(yù)熱的根源。在打開一個新的搜索者時其高速緩存可能會預(yù)先設(shè)定或者自動預(yù)熱，并使用舊的搜索器的數(shù)據(jù)緩存。目前有兩種緩存實現(xiàn)——solr.search.LRUCache(LRU=最近最少使用內(nèi)存中)，和solr.search.FastLRUCache。

常見的緩存配置參數(shù)

class

您想要使用、可實現(xiàn)的SolrCache實現(xiàn)的

solr.search.LRUCache

solr.search.FastLRUCache

size

最大高速緩存中的條目數(shù)。initialSize

autowarmCount

從舊的緩存中需要預(yù)熱的緩存對象數(shù)量。在打開一個新的搜索器時其高速緩存可能會從緩存中舊的搜索器所屬的緩存對象預(yù)設(shè)或者"autowarmed"。autowarmCount是將新的搜索在重新生成的緩存條目數(shù)。現(xiàn)在可以將autowarmCount指定為百分比（即：90%）可計算相對現(xiàn)有緩存中的項的數(shù)目。

TypesofCachesandExampleConfiguration

FilterCache

過濾器緩存（filterCache）存儲無序的文檔編號列表。此緩存有三個不同的目的：

1、過濾器緩存存儲任何solr明確要求執(zhí)行的過濾查詢結(jié)果（fq參數(shù)）。每個過濾器和緩存分別執(zhí)行。閑暇時用它來限制查詢所返回結(jié)果的數(shù)量.）

2、過濾器緩存是用于在某些情況下，小面。（特別是，當(dāng)TermEnum方法是使用一個filterCache項為每個測試項補充說。）

3、過濾器緩存可能被用來進行排序，如果<useFilterForSortedQuery/>配置選項設(shè)置為true在solfconfig.xml。

如果使用fieldCache的方法，建議設(shè)置filterCache大小比例。

QueryResultCache

此緩存中存儲的文檔id，是按某些條件查詢結(jié)果排序的有序的集。

在queryResultCache的內(nèi)存使用情況明顯小于在filterCache，因為它只存儲文檔由查詢返回給用戶的id。

DocumentCache

存儲在documentCache是從磁盤中提取的Lucene的文檔對象。越是字段存儲在磁盤上，這種緩存的內(nèi)存使用量將越高。

User/GenericCaches

用戶/通用緩存，通過SolrIndexSearcher.getCache(),cacheLookup(),目的是使用戶/應(yīng)用程序級數(shù)據(jù)的簡單緩存。參數(shù)應(yīng)指定為實現(xiàn)solr.search.CacheRegenerator。

LuceneFieldCache

Lucene具有一個低級別"字段緩存"，用于進行排序（和在某些情況下faceting）。

總結(jié)

以上是生活随笔為你收集整理的Solr的缓存体系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。