solrcloud使用中遇到的問題及解決方式

首先聲明，咱們團隊在使用solrcloud過程當中踩了一些坑，同事(曉磊和首富)進行了總結，我列到個人博客上作記錄用：

Q：爲何Solr裏面的時間比數據庫裏面早8小時?

Solr默認採用的時區是UTC時區，而DB中用的則是CST時區，這兩個時區自己就相差了8個小時。能夠經過修改Solr啓動配置SOLR_TIMEZONE="UTC+08:00"將時區設置爲CST。注意：修改SOLR_TIMEZONE只在導入數據時起到自動轉換時區的做用。即便修改了以上配置，Solr在展現數據時任然採用UTC時區，經過solrj交互時任然須要手動轉換時區。

Q：Solr集羣配置域名沒法做用。

在搭建Solr集羣時，不一樣機器上的核心具備不一樣的命名例如：

127.0.0.1:8983上有financeLog_shard1_replca1核

127.0.0.2:8983上有financeLog_shard1_replca2核

127.0.0.3:8983上有financeLog_shard1_replca3核

三個核共同組成了名爲financeLog的集羣。

若是爲三臺機器配置solr.nonobank.com域名，經過ngx來作負載均衡是不行的，由於在具體方位時url中須要指定相應的核名。如

http://127.0.0.1:8983/solr/financeLog_shard1_replica1

解決方案，經過solrj提供的SolrCloudClient，經過Zookeeper地址進行訪問。

Q：SolrClient鏈接Zookeeper超時問題

SolrClient首次鏈接須要較長的時間能夠經過setZkConnectTimeout()方法設置一個較長的超時時間。

Q：關於Solr中文分詞問題

Solr對中文的原生支持較差，只能單個字分詞，如「真開心」只能分詞成：真、開、心，這樣在搜索「心開」時該條一樣會被搜索出來，這不是咱們所想要的。

解決方案：使用ICUTokenizer替代solr默認的Tokenizer，ICUTokenizer對中文有較好的分詞，能夠將「真開心」只能分詞成：真、開心、真開心。

Q：如何記錄較慢的查詢

在Solr啓動配置中添加<slowQueryThresholdMillis>1000</slowQueryThresholdMillis>將超過1s的查詢記錄。

Q：Solr日誌量太大

能夠將CONSOLE的日誌級別由INFO調整爲WARN；或者控制日誌文件的大小，如：

log4j.appender.CONSOLE=org.apache.log4j.RollingFileAppender

log4j.appender.CONSOLE.MaxFileSize=1000MB

log4j.appender.CONSOLE.MaxBackupIndex=10

保證最多記錄10G的日誌文件。

Q：修改Solr配置是否須要重啓服務器

Solr的配置文件分爲兩部分，一部分留在本地，一部分留在Zookeeper，留在Zookeeper的配置只需先下載，再修改，最後再上傳回Zookeeper便可，無需重啓。留在本地的配置修改後須要重啓當前服務器纔會生效。

使用bin目錄下的zkcli.sh腳本完成配置文件的上傳下載。

Q：Solr集羣沒法恢復

Solr集羣恢復在最壞的狀況下須要2倍當前core的存儲空間，因此有時會出現磁盤空間不夠的狀況。

Q：經過solr自帶的delta-import增量導入會丟數據

Solr自己會記錄最後一次執行增量導入的時間，設爲time1，下一次經過執行 SELECT * FROM finance_log WHERE update_time >= time1 找出增量數據。

丟失數據的根本緣由在於DB中一條記錄的update_time並非該條記錄實際提交的時間（即出如今DB中的時間）。

例如， DB在8:00:00執行一條update語句更新一條數據data後，data的update_time會被設置爲8:00:00，而對應事務實際提交（執行commit）的時間多是 8:00:20。假設Solr在8:00:10時執行增量導入，執行後會記錄最後一次更新時間爲8:00:10，此時因爲data的更新狀態還沒有被提交，其對應Solr數據不會被更新。下一次執行增量導入時經過SELECT * FROM finance_log WHERE update_time >= 8:00:10找出增量的數據時並不包含data，即data被丟失了。

 

性能方面

solr上線後咱們發現了幾個性能方面的問題

Q： Solr在多核狀況下只能使用一個CPU，以下圖所示，一共有8個核，永遠只有一個核在工做

 

分析：有可能和咱們的VM配置有關，咱們換成多CPU單核的狀況下（8個CPU），CPU使用率上去了

Q：Solr GC 吞吐量低，以下圖所示，gc的吞吐量只有85%

分析： 初步懷疑是young heap設置了過小

解決方案：使用G1GC，增大了Xmn後吞吐量提高很明顯 （85%-> 98%）

 

Q：Out of Memory

分析：觀察log發現有不少OOM的錯誤，經過分析一臺solr的JVM Heap，發現solr dump中的FieldCache佔了大約5G（不能被GC），fieldCache這個配置在solrcloud不能控制，是底層的lucene來控制，它是用來作sorting 和faceting的，也就是說咱們業務中會在solr中進行大批量數據的排序（好比拿最大值是時候）。

解決方案：優化業務方每一次取排序數據的量