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中进行大批量数据的排序（好比拿最大值是时候）。

解决方案：优化业务方每一次取排序数据的量