solr緩存學習

sor緩存

雖然solr的檢索速度很快，可是當搜索服務的請求變得很是複雜的時候，咱們仍是會發現搜索會出現一些性能上的問題。其實不少用戶的請求頗有不少類似的地方，

好比（一）：它們多是不一樣用戶的同一個請求,或者這個用戶僅僅是進行了翻頁的操做;（二）：用戶的過濾條件會有重合的地方，好比它們在同一個類目下進行了不一樣的查詢；

針對這兩個問題，其實咱們能夠經過設置solr的緩存來使查詢速度變快從而提升性能。

 

solr的cache類型：

（1）filterCache過濾器緩存：這個緩存主要是針對fq進行的。一般用戶會在一個固定的業務場景下進行不一樣的查詢，而啓用這個緩存會大大地提升搜索性能。

（2）queryResultCache查詢結果緩存：須要知足query、filterquery sortFiled一致才行。若是屢次執行一個查詢，其實看到的是緩存取出的結果，並非去索引的結果。對要耗費大量計算資源的查詢來講，這是一種比較高效的解決方式。

queryResultWindowSize：咱們能夠去設置查詢結果窗口大小，好比咱們每頁展現20個商品，若是用戶大多數狀況下去瀏覽第一頁第二頁那麼咱們能夠把queryResultWindowSize設置爲40，這樣就能夠避免用戶查看第二頁時再次執行查詢請求。（這個能夠經過跑數據來決定咱們要設置的值）

enableLazyFieldLoading：通常咱們置爲true，避免拉到沒必要要的字段

（3）documentCache文檔緩存：裏面存儲了文檔的內容，若是索引更新的比較快，結果文檔也常在變化，那麼文檔緩存可能會把資源耗費在對應用程序性能無益的地方。可是若是索引更新頻率很低，那麼文檔緩存可能有助於提升應用程序的性能。

（4）filedCache字段值緩存：這個緩存主要是lucene來管理，而不是solr來管理。它提供了能夠快速訪問字段值的途徑，主要是用在sort和facet是使用。

（4）filedValueCache多值字段緩存：主要用於存儲multivalued Field，同上面的filedCache，它是solr特有的緩存，若是你不配置在solrconfig.xml那麼它會自動初始化爲(初始大小10，最大10000），這樣可能會有內存溢出的風險。

 

搜索器：

在這裏就不對搜索器進行很細緻的介紹了，由於本文檔不是主要介紹搜索器的，而搜索器的一些操做可能會用到緩存且對緩存形成影響，在這提一下。

1.當你在對solr進行一次硬提交（普通提交）的時候，你能夠選擇打開搜索器或者不打開，若是不打開可能會致使搜索不可見，由於搜索器存的只是索引的只讀視圖，當你對索引改變時，須要從新啓動一個搜索器來從新加載只讀視圖。而一個新的搜索器的加載，會致使緩存的失效，致使那段時間用戶的體驗不好。

2.當你進行軟提交的時候cache（filterCache、queryResultCache、fieldvaluecache ）都會失效，若是進行一個很頻繁的軟提交，那麼緩存幾乎是不可用的

3.若是你打開了opensearch爲true那麼你能夠選擇對搜索器進行預熱。

這裏有一個連接很好地講了軟提交和硬提交https://hacpai.com/article/1489704451481?m=0。

 

緩存大小：

從緩存大小來講，咱們不能把緩存設置的太大，不然它會消耗jvm的大部份內存。solr可以將全部的緩存都保存在內存中，不會溢出到硬盤上，solr爲了控制緩存的大小要求每一個緩存都要配置它們的上限。當數量達到上限時，solr將採用LRU最久未使用置換法或LFU最近最少使用置換法回收一部分空間。

LRU：當緩存達到上限且須要添加新對象時，solr將會置換緩存中最久未被請求過的對象。

LFU：該方法根據緩存對象被請求頻率的高低決定緩存對象被回收的次序。（過濾器緩存是使用這個的好地方）

注意：通常咱們會有一個誤區，就是若是咱們內存足夠，緩存應該設置得越大越好。其實否則，由於一旦緩存失效，那麼JVM須要進行大量的垃圾回收工做，若是不對緩存作合適的調整那麼可能會致使JVM長時間在作垃圾回收工做，而暫停服務。