关于solr云相关知识

1、认识系统架构

1.1、集群概述

1.1.1、单点服务器的问题

我们之所以要学习集群，是因为单点服务器，存在一系列的问题。

我们以前学习的JavaEE项目，都是部署在一台Tomcat上，所有的请求，都由这一台服务器处理，存在很大风险：

A：并发处理能力有限。因为单服务器的性能有限制。所以单台Tomcat的最大连接数有限制，

B：容错率低，一旦服务器故障，整个服务就无法访问了。

eBay于 1999年6月停机22小时的事故，中断了约230万的拍卖，使eBay的股票下降了9.2个百分点。

C：单台服务器计算能力低，无法完成复杂的海量数据计算。

提高CPU主频和总线带宽是最初提供计算机性能的主要手段。但是这一手段对系统性能的提供是有限的。接着人们通过增加CPU个数和内存容量来提高性能，于是出现了向量机，对称多处理机(SMP)等。但是当CPU的个数超过某一阈值，这些多处理机系统的可扩展性就变的极差。主要瓶颈在于CPU访问内存的带宽并不能随着CPU个数的增加而有效增长。与SMP相反，集群系统的性能随着CPU个数的增加几乎是线性变化的

1.1.2、集群的特点

集群是是指将多台服务器集中在一起，每台服务器都实现相同的业务，做相同的事情。但是每台服务器并不是缺一不可，存在的作用主要是缓解并发压力和单点故障转移问题。可以利用一些廉价的符合工业标准的硬件构造高性能的系统。实现：高扩展、高性能、低成本、高可用！

注意：该图中最大的特点就是，每个Tomcat都完成相同的业务，但是分担着不同用户的访问，它们并不是缺一不可，如果一个Tomcat出现故障，网站依旧可以运行。

伸缩性（Scalability）

在一些大的系统中，预测最终用户的数量和行为是非常困难的，伸缩性是指系统适应不断增长的用户数的能力。提高这种并发会话能力的一种最直观的方式就增加资源（CPU，内存，硬盘等），集群是解决这个问题的另一种方式，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务，我们只需要将新的服务器加入集群中即可，对于客户来看，服务无论从连续性还是性能上都几乎没有变化，好像系统在不知不觉中完成了升级

高可用性（High availability）

单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账单处理这样一些关键的应用程序是不能容忍哪怕是几分钟的死机。它们需要这样一些服务在任何时间都可以访问并在可预期的合理的时间周期内有响应。高可用性集群的出现是为了使集群的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份，并且因此使系统环境对于用户是一致的。

负载均衡（Load balancing）

负载均衡集群为企业需求提供了更实用的系统。如名称所暗示的，该系统使负载可以在计算机集群中尽可能平均地分摊处理。该负载可能是需要均衡的应用程序处理负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。

高性能 (High Performance )

通常，第一种涉及为集群开发并行编程应用程序，以解决复杂的科学问题。这是并行计算的基础，尽管它不使用专门的并行超级计算机，这种超级计算机内部由十至上万个独立处理器组成。但它却使用商业系统，如通过高速连接来链接的一组单处理器或双处理器 PC，并且在公共消息传递层上进行通信以运行并行应用程序。因此，您会常常听说又有一种便宜的 Linux 超级计算机问世了。但它实际是一个计算机集群，其处理能力与真的超级计算机相等

1.2、分布式架构

1.2.1、传统架构

A：系统过于庞大，开发维护困难

B：功能间耦合度太高

C：无法针对单个模块进行优化

D：无法进行水平扩展

1.2.2、分布式架构

分布式是指将多台服务器集中在一起，每台服务器都实现总体中的不同业务，做不同的事情。并且每台服务器都缺一不可，如果某台服务器故障，则网站部分功能缺失，或导致整体无法运行。存在的主要作用是大幅度的提高效率，缓解服务器的访问和存储压力。

注意：该图中最大特点是：每个Web服务器（Tomcat）程序都负责一个网站中不同的功能，缺一不可。如果某台服务器故障，则对应的网站功能缺失，也可以导致其依赖功能甚至全部功能都不能够使用。

因此，分布式系统需要运行在集群服务器中，甚至分布式系统的每个不同子任务都可以部署集群

1.3、分布式集群综合架构

一般分布式中的每一个节点，都可以做集群。这样的系统架构，我们通常称为分布式集群架构。

1.4、代理技术

1.4.1、正向代理（Forward Proxy）

一般情况下，如果没有特别说明，代理技术默认说的是正向代理技术。关于正向代理的概念如下： 正向代理(forward)是一个位于客户端【用户A】和原始服务器(origin server)【服务器B】之间的服务器【代理服务器Z】，为了从原始服务器取得内容，用户A向代理服务器Z发送一个请求并指定目标(服务器B)，然后代理服务器Z向服务器B转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

简单来说，正向代理就是代理服务器替代访问方【用户A】去访问目标服务器【服务器B】

为什么需要使用正向代理？

1.4.1.1、 访问本无法访问的服务器B

great firewall

被服务器屏蔽（wow）

1.4.1.2、加速访问服务器B

1.4.1.3、Cache作用

如果在用户A访问服务器B某数据J之前，已经有人通过代理服务器Z访问过服务器B上得数据J，那么代理服务器Z会把数据J保存一段时间，如果有人正好取该数据J，那么代理服务器Z不再访问服务器B，而把缓存的数据J直接发给用户A。

1.4.1.4、客户端访问授权

1.4.1.5、隐藏访问者的行踪

服务器B并不知道访问自己的实际是用户A，因为代理服务器Z代替用户A去直接与服务器B进行交互。如果代理服务器Z被用户A完全控制（或不完全控制），会惯以“肉鸡”术语称呼。

总结一下：正向代理是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。

1.4.2、反向代理（reverse proxy）

反向代理正好与正向代理相反，对于客户端而言代理服务器就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端。 使用反向代理服务器的作用如下：

1.4.2.1、保护和隐藏原始资源服务器

用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答，从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。

1.4.2.2、负载均衡

当反向代理服务器不止一个的时候，我们甚至可以把它们做成集群，当更多的用户访问资源服务器B的时候，让不同的代理服务器Z（x）去应答不同的用户，然后发送不同用户需要的资源。

而且反向代理服务器像正向代理服务器一样拥有CACHE的作用，它可以缓存原始资源服务器B的资源，而不是每次都要向原始资源服务器B请求数据，特别是一些静态的数据，比如图片和文件。

简单来说，反向代理就是反向代理服务器替代原始服务器【服务器B】让【用户A】去访问

2、Zookeeper分布式协调服务

2.1、什么是Zookeeper

Zookeeper是集群分布式中大管家

分布式集群系统比较复杂，子模块很多，但是子模块往往不是孤立存在的，它们彼此之间需要协作和交互，各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调——这就是ZooKeeper

Zookeeper 是为分布式应用程序提供高性能协调服务的工具集合，也是Google的Chubby一个开源的实现，是Hadoop 的分布式协调服务。

2.2、Zookeeper的集群结构

在ZooKeeper集群当中，集群中的服务器角色有两种：1个Leader和多个Follower，具体功能如下：

1）领导者(leader)，负责进行投票的发起和决议，监控集群中的(follower)是否存活（心跳机制），进行分配资源

2）follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票

特点：

A：Zookeeper：一个leader，多个follower组成的集群

B：全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的

C：数据更新原子性，一次数据更新要么成功，要么失败

D：实时性，在一定时间范围内，client能读到最新数据

E：半数机制：整个集群中只要有一半以上存活，就可以提供服务。因此通常Zookeeper由2n+1台servers组成，每个server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。为了保证Leader选举能过得到多数的支持，所以ZooKeeper集群的数量一般为奇数。对于2n+1台server，只要有n+1台（大多数）server可用，整个系统保持可用

2.3、Zookeeper的leader选主机制

2.3.1、全新集群

以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么.
1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5启动,同4一样,当小弟.

2.3.2、非全新集群

那么，初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。

需要加入数据id、leader id和逻辑时钟。

数据id：数据新的id就大，数据每次更新都会更新id。

Leader id：就是我们配置的myid中的值，每个机器一个。

逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说:  如果在同一次选举中,那么这个值应该是一致的 ;  逻辑时钟值越大,说明这一次选举leader的进程最新.

选举的标准就变成：

　　1、逻辑时钟小的选举结果被忽略，重新投票

　　2、统一逻辑时钟后，数据id大的胜出

　　3、数据id相同的情况下，leader
id大的胜出

根据这个规则选出leader。

2.4、Zookeeper的作用

Zookeeper包含一个简单的原语集，分布式应用程序可以基于它实现命名服务、配置维护、集群选主等：

命名服务：注册节点信息，形成有层次的目录结构（类似Java的包名）。

配置维护：配置信息的统一管理和动态切换

集群选主：确保整个集群中只有一个主，其它为从。并且当主挂了后，可以从新选主

3、SolrCloud概述

3.1、什么是SolrCloud

单点的Solr服务的问题：

A：能存储的数据量有限，如果是海量数据，无法存储

B：容易出现单点故障

C：对高并发的处理能力差

如果我们的需要处理海量数据、应对高并发请求，并且让我们的服务实现高可用。那么就必须要搭建SolrCloud了。反之，如果数据量很少，请求并发低的情况下，是不需要SolrCloud的，单点Solr就够了

SolrCloud(solr
云)是Solr提供的分布式搜索方案，可以解决海量数据的
分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡

3.1、SolrCloud结构简介

为了实现海量数据的存储，我们会把索引进行分片（Shard），把分片后的数据存储到不同Solr节点。

为了保证节点数据的高可用，避免单点故障，我们又会对每一个Shard进行复制，产生很多副本（Replicas），每一个副本对于一个Solr节点中的一个core

用户访问的时候，可以访问任何一个会被自动分配到任何一个可用副本进行查询，这样就实现了负载均衡。

逻辑结构：

Collection：在SolrCloud集群中逻辑意义上的完整的索引。一般会包含多个Shard（分片），如果大于1个分片，那么就是分布式存储。

Shard: Collection的逻辑分片。每个Shard被化成一个或者多个replicas（副本），通过选举确定哪个是Leader（主），其它为从

Replica: Shard的一个副本，存储在Solr集群的某一台机器中（就是一个节点），对应这台Solr的一个Core。

Leader: 赢得选举的Shard replicas。每个Shard有多个Replicas，这几个Replicas需要选举来确定一个Leader。选举可以发生在任何时间，但是通常他们仅在某个Solr实例发生故障时才会触发。当索引documents时，SolrCloud会传递它们到此Shard对应的leader，leader再分发它们到全部Shard的replicas

分片数量越多，每一片的数据就越少，每一个副本的数据就越少。但是一般不要多于机器数量

分片数量越少，每一片的数据就越多，每一个副本的数据就越多。

副本数量越少，总数据量越少， 这样可以减少每一台机器上的数据量，会降低高可用性，提高数据存储上限。

副本数量越多，总数据量越多，会增加每一台机器上的数据量，但是会提高整个集群的高可用性。

4、SolrCloud的搭建

4.1、基本环境

我们需要三台服务器，也就是三台虚拟机。分别是：

192.168.56.101

192.168.56.102

192.168.56.103

每台及其上都需要部署以下环境：

JDK：基本Java运行环境

Tomcat：装载Solr服务

Solr-4.10.2：Solr服务

Zookeeper：对Solr云进行管理

理论上应该给每台机器分别安装，但是我们是虚拟机，我们可以先安装一台，然后把虚拟机进行复制！

4.2、单机部署

4.2.1、Centos6.5安装

4.2.2、JDK安装

4.2.3、Tomcat安装

4.2.4、Solr安装

4.2.5、zookeeper安装

4.2.5.1.上传zookeeper的安装包

4.2.5.2.解压缩安装包

tar -zxvf zookeeper-3.4.5.tar.gz

4.2.5.3.重命名目录

某些机器无法识别标点，因此我们可以把目录的名称做修改：

mv zookeeper-3.4.5 zookeeper

4.2.5.4.修改配置文件

　　A：进入zookeeper/conf目录

　　B：复制模板文件

cp zoo_sample.cfg    zoo.cfg

　　C：修改配置文件信息，添加以下内容

vi zoo.cfg

　　要添加的内容：

dataDir=/usr/local/myapp/zookeeper/data

dataLogDir=/usr/local/myapp/zookeeper/log

server.1=192.168.56.101:2888:3888
server.2=192.168.56.102:2888:3888
server.3=192.168.56.103:2888:3888

注意：模板文件中已经有一个dataDir参数，我们一定要把这个删除，或者在这个基础上修改

dataDir：数据目录

dataLogDir：日志目录

server.1=x.x.x.x:port1:port2 指定所有zookeeper的节点信息

server后的数字是节点ID，port1是心跳端口，port2是数据端口

4.2.5.5.创建数据目录和日志目录

我们在配置文件里指定了数据和日志目录。所以我们需要创建这些目录

A：先进入zookeeper目录

B：创建目录

mkdir –m 755 data
mkdir –m 755 log

这样两个命令可以在创建目录的同时指定文件夹的权限

4.2.5.6.添加节点ID信息

进入data目录，创建文件myid，并且写上ID信息：1

vi myid

插入id：1

注意，其它节点的ID必须与配置文件中的ID一致，分别是2和3

4.2.5.7.配置zookeeper的环境变量，可以在任何位置使用zookeeper命令

　　A：vi /etc/profile(修改文件)

　　B：添加内容：

export ZOOKEEPER_HOME=/usr/local/myapp/zookeeper
export PATH=$PATH:$ZOOKEEPER_HOME/bin

　　C：重新编译文件：

source /etc/profile

4.2.5.8.zookeeper命令：

启动zookeeper：

zkServer.sh start

停止zookeeper：

zkServer.sh stop

查看状态：

zkServer.sh status

4.2.5.9.如果出现错误：

先stop 掉原zk

zkServer.sh stop

然后以./zkServer.sh start-foreground方式启动，会看到启动日志

zkServer.sh start-foreground

4.3、集群部署

4.3.1、修改tomcat启动文件，添加zookeeper的地址信息

修改：tomcat文件夹下的bin目录中的catalina.sh文件，添加以下信息：

export JAVA_OPTS="-Dsolr.solr.home=/usr/local/myapp/solr-4.10.2/example/solr -DzkHost=192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181"

-Dsolr.solr.solr.home指定的是Solr索引库位置

-DzkHost指定的是三个zookeeper的ip和客户端端口信息

这样tomcat启动后，solr服务就可以到zookeeper中注册自己的信息，或者获取其它节点信息。

4.3.2、复制虚拟机（也可以重新安装）

4.3.2.1.复制虚拟机，这里我们复制2台即可

4.3.2.2.修改其它2台虚拟机的IP，设为静态IP

分别为192.168.56.102和192.168.56.103

4.3.3、启动zookeeper集群

4.3.3.1.修改102和103机器中的zookeeper的节点ID

修改zookeeper目录中 data/myid的内容，分别为2和3

4.3.3.2.分别启动三台虚拟机中的zookeeper

zkServer.sh start

查看状态:

zkServer.sh status

停止：

zkServer.sh stop

4.3.3.3.使用zookeeper的客户端控制台，查看zookeeper信息

Zookeeper提供了自己的客户端命令行工具，与Linux的命令非常相似。

　　A：启动客户端工具：

zkCli.sh –server ip:port

　　这里的参数可以省略，如果省略，默认访问的是本机的zookeeper节点即：localhost:2181

　　B：显示根目录下、文件： ls / 使用 ls 命令来查看当前 ZooKeeper 中所包含的内容

　　C：显示根目录下、文件： ls2 / 查看当前节点数据并能看到更新次数等数据

　　D：创建文件，并设置初始内容： create /zk "test" 创建一个新的 znode节点“ zk ”以及与它关联的字符串

　　E：获取文件内容： get /zk 确认 znode 是否包含我们所创建的字符串

　　F：修改文件内容： set /zk "zkbak" 对 zk 所关联的字符串进行设置

　　G：删除文件： delete /zk 将刚才创建的 znode 删除

　　H：退出客户端： quit

　　I：帮助命令： help

4.3.4、修改Solr配置文件，配置集群的中每台Solr服务的IP和端口

4.3.4.1.进入/usr/local/myapp/solr-4.10.2/example/solr目录

4.3.4.2.修改solr.xml文件

<solrcloud>
    <str name="host">192.168.56.101</str>
    <int name="hostPort">8080</int>
    <str name="hostContext">${hostContext:solr}</str>
    <int name="zkClientTimeout">${zkClientTimeout:30000}</int>
    <bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>
</solrcloud>

我们访问一台Solr服务的地址，一般是这样的：http://192.168.56.101:8080/solr

而在这里的几个参数，分别对应这个地址的一些信息：

host：就是Solr服务的IP地址，每台机器配置为自己的IP

hostPort：就是监听端口，我们是Tomcat服务，因此是8080

hostContext：就是访问的路径，这里缺省值是solr，我们不用改

4.3.5、将Solr配置文件上传到Zookeeper中，有Zookeeper统一管理

由于zookeeper统一管理solr的配置文件（主要是schema.xml、solrconfig.xml）， solrCloud各各节点使用zookeeper管理的配置文件。以后无论创建任何的core，本地的配置文件都没用了，使用的都是zookeeper的配置文件

执行下边的命令将/usr/local/myapp/solr-4.10.2/example/solr/collection1/conf/下的配置文件上传到zookeeper：

sh /usr/local/myapp/solr-4.10.2/example/scripts/cloud-scripts/zkcli.sh -zkhost 192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181 -cmd upconfig -confdir /usr/local/myapp/solr-4.10.2/example/solr/collection1/conf/ -confname solrconf

解释：

/usr/local/myapp/solr-4.10.2/example/scripts/cloud-scripts/zkcli.sh    ： Solr提供的访问Zookeeper的脚本文件
-zkhost 192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181    ： 指定Zookeeper的地址信息
-cmd upconfig                                                          ： 指定操作的命令。这里是上传配置
-confdir /usr/local/myapp/solr-4.10.2/example/solr/collection1/conf/　 ： 指定要上传的配置文件目录，我们上传Solr的样例中的配置
-confname solrconf　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ： 指定注册到Zookeeper中后配置文件目录名称

4.3.6、启动SolrCloud

4.3.6.1.启动每一台服务器中的Solr服务（其实就是启动Tomcat）

4.3.6.2.访问SolrCloud，查看云的状态

4.4、通过管理界面查看和操作SolrCloud

4.4.1、SolrCloud的操作命令：

Solr采用的是类似WebService的API接口，采用Http方式进行访问，因此，其操作命令都是一些URL联接及对应参数

4.4.1.1.创建core命令：

http://192.168.56.101:8080/solr/admin/collections?action=CREATE&name=myCollection1&numShards=3&replicationFactor=2&maxShardsPerNode=8&property.schema=schema.xml&property.config=solrconfig.xml

参数说明：

name                ：指明collection名称
numShards           ：指明分片数
replicationFactor   ：指明副本数
maxShardsPerNode    ： 每个节点最大分片数（默认为1）
property.schema     ：指定使用的schema.xml，这个文件必须在zookeeper上。
property.config     ：指定使用的solrconfig.xml，这个文件必须在zookeeper上。

4.4.1.2.删除Collection命令；

http://192.168.56.101:8080/solr/admin/collections?action=DELETE&name=collection1

4.4.1.3.查询所有的Collection

http://192.168.56.101:8080/solr/admin/collections?action=LIST

4.4.1.4.显示集群的状态

http://192.168.56.101:8080/solr/admin/collections?action=CLUSTERSTATUS

4.4.1.5.分裂shard

http://192.168.56.101:8080/solr/admin/collections?action=SPLITSHARD&collection=myCollection2&shard=shard2

4.4.1.6.删除shard

http://192.168.56.101:8080/solr/admin/collections?action=DELETESHARD&collection=myCollection2&shard=shard1

更多的命令请参数官方文档：

apache-solr-ref-guide-4.10.pdf

注意：

启动solrCloud需要先启动solrCloud依赖的所有zookeeper服务器，再启动每台solr服务器。

如果服务器跟服务器之间无法通讯，查看每台服务器的/etc/hosts 里面是否配置了其他服务器的IP地址和hostname

4.4.2、SolrCloud测试

4.4.2.1.创建索引

测试：在一台Solr上创建的索引，从其它solr服务上可以查询到

4.4.2.2.查询索引：

从任意一台Solr上查询索引，选择任意的一个分片，都会返回一个完整的结果

4.4.2.3.测试高可用

三台服务器，任意挂掉一台，依然不会影响使用，事实上，只要剩余的机器上，有完整的shard分片信息，都不影响使用。不管剩余几台服务器

4.4.2.4.测试数据自动同步

当一个节点挂掉时，如果有索引的更新，那么这个节点启动后，会自动同步新的数据

4.4.2.5.测试系统的伸缩性

如果我们启动新的Solr服务，那么这个服务也可以融入集群中。

5、使用SolrJ访问SolrCloud

与单机Solr相比，API仅仅是在创建SolrServer时发生了改变，其它没有变化。

单机采用的是：HttpSolrServer

SolrCloud采用的是：CloudSolrServer

5.1、添加或修改数据

@Test
public void testWrite() throws Exception{
    // 创建SolrServer
    CloudSolrServer server = new CloudSolrServer("192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181");
    // 指定要访问的Collection名称
    server.setDefaultCollection("collection1");

    // 创建Document对象
    SolrInputDocument document = new SolrInputDocument();
    // 添加字段
    document.addField("id", "20");
    document.addField("title", "duang手机，自带特效的手机，值得拥有");

    // 添加Document到Server
    server.add(document);
    // 提交
    server.commit();
}

5.2、删除数据

@Test
public void testDelete() throws Exception{
    // 创建SolrServer
    CloudSolrServer server = new CloudSolrServer("192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181");
    // 指定要访问的Collection名称
    server.setDefaultCollection("collection1");
    // 根据ID删除
    server.deleteById("20");
    // 提交
    server.commit();
}

5.3、查询数据

@Test
public void testSearch() throws Exception {
    // 创建SolrServer
    CloudSolrServer server = new CloudSolrServer("192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181");
    // 指定要访问的Collection名称
    server.setDefaultCollection("collection1");

    // 查找数据
    QueryResponse response = server.query(new SolrQuery("title:手机"));

    // 以document形式解析数据
    SolrDocumentList documentList = response.getResults();
    // 遍历
    for (SolrDocument solrDocument : documentList) {
        System.out.println(solrDocument.getFieldValue("id"));
        System.out.println(solrDocument.getFieldValue("title"));
    }
}