1：solr中的时间问题
solr中显示的时间默认会比我们本机时间少八个小时，因为时区不一样。
在solr的web页面查看会发现时间少八个小时。
但是使用java代码操作的时候是整成的的，所以在这只需要知道sorl有这个现象就可以了。
可以给这个时间字段添加默认值。添加default字段即可
给last_modified字段添加默认值，是当前时间。
<field name="last_modified" type="date" indexed="true" stored="true" default="NOW"/>
2：solr中的主从
主要是解决了高并发的问题，可以使用ngix代理实现负载均衡。
主从结构，只能有一个主节点，可以有多个从节点。
并且只能在主节点实现添加数据，从节点一般执行查询操作，从节点会从主节点定时同步数据。
手工设置主从节点：
具体配置：
主节点：192.168.1.170
vi /usr/loca/solr-4.10.4/example/solr/collection1/conf/solrconfig.xml
找到第1240行，把这个配置注释去掉
<lst name="master">
<!-- replicateAfter的值表示从节点只能在主节点commit和startup之后才能同步到数据。 -->
<str name="replicateAfter">commit</str>
<str name="replicateAfter">startup</str>
<str name="confFiles">schema.xml,stopwords.txt</str>
</lst>
从节点：192.168.1.171
vi /usr/loca/solr-4.10.4/example/solr/collection1/conf/solrconfig.xml
找到第1240行，把这个配置注释去掉，修改里面的这个配置your-master-hostname
<lst name="slave">
<!-- 表示指定主节点地址，默认是指定collection1，如果是其他名称，需要显式指定 -->
<str name="masterUrl">http://192.168.1.170:8983/solr</str>
<!-- 表示同步的时机 -->
<str name="pollInterval">00:00:60</str>
</lst>
启动主节点，启动从节点，即可。在主机点添加数据，在从节点就可以查到了。
动态设置主从：
vi /usr/loca/solr-4.10.4/example/solr/collection1/conf/solrconfig.xml
找到1240行，改为如下配置
<lst name="${master:master}">
<str name="replicateAfter">commit</str>
<str name="replicateAfter">startup</str>
<str name="confFiles">schema.xml,stopwords.txt</str>
</lst>
<lst name="${slave:slave}">
<str name="masterUrl">http://${masterurl}:8983/solr</str>
<str name="pollInterval">00:00:60</str>
</lst>
把solr-4.10.4目录拷贝一份。
在192.168.1.170上启动主节点
java -Dslave=disabled -Dmasterurl="" -jar start.jar
在192.168.1.171上启动从节点
java -Dmaster=disabled -Dmasterurl=192.168.1.170 -jar start.jar
3：solr主从复制的过程
Replication 的实现
Master 是感知不到 Slave 的存在的， Slave 会周期性的轮询 Master 来查看当前的索引版本。如果 Slave 发现有新的版本，那么 Slave 启动复制进程。步骤如下：
1. Slave 发出一个 filelist 命令来收集文件列表。这个命令将返回一系列元数据（ size ， lastmodified ， 等等）
2. Slave 查看它本地是否有这些文件，然后它会开始下载缺失的文件 ( 使用命令 filecontent) 。如果连接失败，则下载终止。它将重试 5 次，如果仍然失败则放弃。
3. 文件被下载到了一个临时目录。因此，下载中途出错不会影响到 slave 。
4. 一个 commit 命令被 ReplicationHandler 执行，然后新的索引被加载进来
4：solrcloud
为什么会出现solrcloud
1）：高并发的问题
2）：索引数据过多导致单节点存储不下
solr的配置
solrcloud依赖于zookeeper，所以需要先配置好并启动,假设zookeeper启动在192.168.1.170上
集群规划如下：
solrcloud包含两个分片，每个分片都两个节点，一主一从。
所以需要四个solr服务
在这我们在一个节点上面启动4个solr来模拟
具体步骤
建议重新解压一个solr。
cd solr-4.10.4
cp -r example node1
cp -r example node2
cp -r example node3
cp -r example node4
cd node1
java java -DzkHost=192.168.1.170:2181 -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=myconf -jar start.jar
注意：这个启动命令指定了zookeeper的地址、分片的数量，配置信息。
再启动其他节点的时候就不需要指定分片数量和配置信息了
cd node2
java -DzkHost=192.168.1.170:2181 -Djetty.port=7574 -jar start.jar
cd node3
java -DzkHost=192.168.1.170:2181 -Djetty.port=8984 -jar start.jar
cd node4
java -DzkHost=192.168.1.170:2181 -Djetty.port=7575 -jar start.jar
这样启动完成之后，就可以到solr中查看solrcloud的集群及结构了。
http://192.168.1.170:8983/solr/#/~cloud
-Djetty.port：指定jetty的端口
-DzkHost：指定zookeeper的地址
-DnumShards=2 ：分片的个数
-Dbootstrap_confdir=./solr/collection1/conf：上传配置文件
-Dcollection.configName=myconf ：为配置文件起一个名称
注意：如果发现cloud中的集群机构和我们命令中指定的不一致，是因为之前的配置信息都保存在zookeeper中。
所以需要把之前的配置信息删掉,之后再重新执行创建集群的命令。
zookeeper/bin/zkCli.sh
rmr /clusterstate.json
5：使用java代码操作solrcloud
在这里就不能具体指定使用哪一个节点
需要指定zookeeper的地址
代码如下
String zkHost = "192.168.1.170:2181,192.168.1.171:2181";
CloudSolrServer server = new CloudSolrServer(zkHost );
//必须要知道默认collection的名称
server.setDefaultCollection("collection1");
SolrQuery query = new SolrQuery();
query.set("q", "*:*");
QueryResponse response = server.query(query);
SolrDocumentList results = response.getResults();
如果集群中某一个分片的节点都挂了，为了让集群可以正常提供查询服务，需要添加下面代码
solrQuery.setDistrib(false);//表示不使用分布式搜索
——————————————————————————————————————————————————————————————————
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
——————————————————————————————————————————————————————————————————
1：solr的提交方式
软提交：把数据提交到内存中，可以搜索到，
每次提交少量数据时使用这种方式
server.commit(true,true,true);
硬提交：把数据提交到磁盘中，可以搜索到。
批量提交时使用
server.commit
自动提交
自动软提交：默认没有开启
<autoSoftCommit>
<maxTime>1000</maxTime>
</autoSoftCommit>
自动硬提交：默认开启了，默认15秒执行一次
<autoCommit>
<maxDocs>1000</maxDocs>
<maxTime>15000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
注意：虽然软提交是把数据提交到内存中，但是solr停止，数据并不会丢失，
因为solr在没提交一条数据都会记录日志，solr后期会从日志中回复数据。
具体自动提交的详细解释，可以参考《solr优化中的第一点》
2：solr性能优化
具体自动提交的详细解释，可以参考《solr优化》
1：针对自动提交的配置
2：针对字段的store和indexed属性的配置
3：optimize功能，注意：虽然优化可以提高查询速度，但是不建议频繁执行，
因为会很消耗性能，建议定时执行。
4：jvm内存设置
5：尽量把solr和应用放在同一个服务器上。
6：尽量使用比较高的日志输出级别。
3：solr和hbase集成
他们两个集成，主要是使用solr的查询优点和hbase的通过row快速查询的特点。
具体的项目使用我提供的《solr+hbase原始》，在这个基础上进行改造，主要solrutils工具类中的两个方法
具体的前期solr配置参考《solr+hbase整合.txt》
最后会把上课期间完成的代码打包成《solr+hbase完成版》
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solr优化.txt：
1：Commit和SoftCommit
Commit，硬提交，Solr和Lucene原本存在的commit方式，负责把索引内容刷入磁盘。需要重新打开searcher，
Solr/Lucene才会对这部分内容可见可查，但是这样比较费性能。
SoftCommit，软提交，这是Solr新增的commit方式，Lucene没有。软提交负责将索引内容在内存中生成segment，
并使得索引内容对Solr可见可查，该提交方式是Commit的改善方式，保证了Solr的实时性同时又兼顾了性能。
在进行softcommit过程中需要进行预热(即将现在状态的searcher复制到新的searcher中，保证了旧的softcommit
数据不丢失)，虽然没有重新打开searcher那么费性能，但是预热频率过快还是会影响solr的性能。
在solrconfig.xml中可以配置自动硬提交和自动软提交
<!-自动硬提交->
<autoCommit>
<maxDocs>1000</maxDocs>
<maxTime>15000</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>
<!-自动软提交->
<autoSoftCommit>
<maxTime>1000</maxTime>
</autoSoftCommit>
maxDocs：当内存索引数量达到指定值的时候，将内存的索引DUMP(转储)到硬盘中，并通知searcher类加载新的索引。
maxTime:每隔指定的时间段，自动的COMMIT内存中的索引数据，并通知Searcher类加载新的索引。
最后openSearcher配置表示进行autocommit时候是否重新打开searcher，如果autocommit频繁又将
openSearcher设置为true,那么solr的性能压力会非常大。
一般会将autocommit的maxTime和maxDocs设的相对大点，对应的softcommit的maxTime设置小点，
这样即保证了性能又保证了实时性，当然具体的值需要根据索引的频率以及document的大小综合考虑
以上两种方式，以最先达到条件执行为准。
通常是1-10分钟自动触发硬提交，每秒钟自动触发软提交
注意：
1.Solr的softCommit是Write-ahead Logging的，所以不必担心softCommit的数据会丢失。Log数据就在$solrHome/collection/data/tlog/下。
2.solr关闭时会进行一次hard commit，所以不必担心关闭时(或kill process)softCommit数据会丢失。
kill -9时数据也不会丢失，因为这些数据都会记录在tlog目录下面的日志里面，当solr重启之后就会加载日志中的数据。
除非把日志文件删掉，数据才会丢失。
2：索引字段(indexed)和存储字段(stored)
2.1将所有只用于搜索的，而不需要作为结果的field（特别是一些比较大的field）的stored设置为false(例如：copyfield字段)
2.2将不需要被用于搜索的，而只是作为结果返回的field的indexed属性设置为false
2.3删除所有不必要的copyField声明
3：optimize
3.1在同样没有缓存的情况下，一个没有经过优化的索引的性能会比经过优化的索引的性能少10%
3.2优化的时候，会将所有的索引段合并成为一个索引段，所以，优化这个操作其实可以帮助避免“too many files”这个问题，这个错误是由文件系统抛出的。
3.3在索引阶段，不进行索引优化能够接受的话，就不进行索引优化optimize()，这是一个很耗时的操作，但是在查询阶段，
优化往往能够大幅度提高查询效率，所以可以考虑周期性的优化。
http://localhost:8983/solr/collection1/update?optimize=true&waitFlush=true&wt=json
4:OutOfMemoryErrors
如果你的solr实例没有被指定足够多的内存的话，java virtual machine也许会抛outof memoryError。
通过solr start -m 1g 设置jvm内存，使用solr start命令启动的时候JVM内存默认是512M
( java -Xms512m -Xmx512m -jar start.jar)
5：使用主从结构实现负载均衡和提高应用的健壮性
6：把solr和应用部署在同一台服务器上(省去网络通信)
7：使用尽可能高的Log输出等级，减少日志量。