首先声明，我们团队在使用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中进行大批量数据的排序（比如拿最大值是时候）。
解决方案：优化业务方每一次取排序数据的量
