首先聲明，我們團隊在使用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中進行大批量數據的排序（比如拿最大值是時候）。
解決方案：優化業務方每一次取排序數據的量
