首先声明一下，我们团队在使用solrcloud的过程中踩到了一些坑。我的同事（小雷和首富）做了一个总结，我把他们列在我的博客上记录：

Solr默认使用的时区是UTC时区，DB中使用的是CST时区，两个时区本身相差8小时。可以通过修改 Solr 启动配置 SOLR_TIMEZONE="UTC+08:00" 将时区设置为 CST。注意：修改 SOLR_TIMEZONE 只起到导入数据时自动时区转换的作用。即使修改了上面的配置，Solr 在显示数据时仍然使用 UTC 时区，在与 solrj 交互时仍需要手动转换时区。

在构建 Solr 集群时，不同机器上的核心有不同的名称。例如：

http://www.zhucesz.com/:8983有financeLog_shard1_replca1核心

http://www.zhucesz.com/:8983有financeLog_shard1_replca2核心

http://www.zhucesz.com/:8983有financeLog_shard1_replca3核心

三个核心共同组成一个名为 FinanceLog 的集群。

如果三台机器都配置了域名http://www.zhucesz.com/，则无法通过ngx做负载均衡，因为需要在具体位置的url中指定对应的核心名称。例如，

http://www.zhucesz.com/:8983/solr/financeLog_shard1_replica1

解决方案通过solrj提供的SolrCloudClient通过Zookeeper地址访问。

SolrClient第一次连接耗时较长可以通过 setZkConnectTimeout() 方法设置时间来设置更长的超时时间。

Solr 对中文的原生支持很差，只能用一个词来分词。比如“真的很开心”只能分词：真、开心、心。这样，在搜索“新开”时，该词条也会被搜索到。这不是我们想要的。

解决方案：使用 ICUTokenizer 替换 Solr 默认的 Tokenizer。 ICUTokenizer对中文的分词比较好，只能将“真的很开心”分词成：真的、开心、真的开心。

添加 Solr 启动配置1000记录超过 1s 的查询。

可以将 CONSOLE 的日志级别从 INFO 调整为 WARN；或者控制日志文件的大小，如：

http://www.zhucesz.com/://http://www.zhucesz.com/\n

http://www.zhucesz.com/

http://www.zhucesz.com/

保证记录多达10G的日志文件。

Solr的配置文件分为两部分，一份留在本地，一份留在Zookeeper中。 Zookeeper中留下的配置只需要先下载，再修改，最后上传回Zookeeper，无需重启。配置更改留在本地后，需要重启当前服务器才能生效。

使用bin目录下的http://www.zhucesz.com/脚本上传下载配置文件。

Solr集群恢复最坏情况下需要两倍于当前核心的存储空间，所以有时会出现磁盘空间不足的情况。

Solr 本身记录上次执行增量导入的时间time，设置为time1，下次通过SELECT * FROM finance_log WHERE update_time >= time1查找增量数据。

数据丢失的根本原因是DB中某条记录的update_time不是该记录实际提交的时间（即出现在DB中的时间）。

比如 0?2DB 在 8:00:00 执行 update 语句更新一条数据后，数据的 update_time 会设置为 8:00:00，对应事务实际提交的时间（执行提交）。也许是 8:00:20。假设Solr在8:00:10执行增量导入，执行后最后一次更新时间记录为8:00:10。此时，由于尚未提交数据的更新状态，因此不会更新对应的 Solr 数据。下次增量导入时，通过SELECT * FROM finance_log WHERE update_time >= 8:00:10发现增量数据不包含数据，即数据丢失。

0?2

表现

solr上线后，我们发现了几个性能问题

0?2

分析：可能和我们的VM配置有关，当我们切换到多CPU单核（8个CPU）时，CPU占用率上升

分析：初步怀疑是young heap设置过小

解决方案：使用G1GC增加Xmn安装后，吞吐量明显提升（85->98）

0?2

分析：观察日志，发现有很多OOM错误。通过分析一个solr JVM Heap，发现solr dump中的FieldCache占用5G左右（不能是GC），在solrcloud中fieldCache的配置是无法控制的，它是由底层lucene控制的，它用于排序和分面，也就是说在我们的业务中，我们会对solr中的大批量数据进行排序（比如取最大值的时候）。

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

0?2

0?2

转载于：http://www.zhucesz.com/