sor緩存

雖然solr的檢索速度很快，但是當搜索服務的請求變得非常復雜的時候，我們還是會發現搜索會出現一些性能上的問題。其實很多用戶的請求很有很多相似的地方，

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

針對這兩個問題，其實我們可以通過設置solr的緩存來使查詢速度變快從而提高性能。

搜索器：

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

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長時間在做垃圾回收工作，而暫停服務。

solr的cache類型：

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

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

這裏提到一點，我們可以去設置查詢結果窗口大小，比如我們每頁展示20個商品，如果用戶大多數情況下去瀏覽第一頁第二頁那麽我們可以把queryResultWindowSize設置為40，這樣就可以避免用戶查看第二頁時再次執行查詢請求。（這個可以通過跑數據來決定我們要設置的值）

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

（4）filedValueCache字段值緩存：

solr緩存學習