SolrCloud(solr 云)是Solr提供的分布式搜索方案,当你须要大规模,容错,分布式索引和检索能力时使用SolrCloud。当一个系统的索引数据量少的时候是不须要使用SolrCloud的,当索引量很大,搜索请求并发很高,这时须要使用SolrCloud来知足这些需求。SolrCloud是基于Solr和Zookeeper的分布式搜索方案,它的主要是使用Zookeeper做为集群的配置信息中心。node
1)集中式的配置信息web
2)自动容错数据库
3)近实时搜索编程
4)查询时自动负载均衡segmentfault
顾名思义zookeeper就是动物园管理员,他是用来管hadoop(大象)、Hive(蜜蜂)、pig(小猪)的管理员,Apache Hbase和Apache Solr 的分布式集群都用到了zookeeper;Zookeeper:是一个分布式的、开源的程序协调服务,是hadoop项目下的一个子项目。浏览器
1、配置管理服务器
在咱们的应用中除了代码外,还有一些就是各类配置。好比数据库链接等。通常咱们都是使用配置文件的方式,在代码中引入这些配置文件。可是当咱们只有一种配置,只有一台服务器,而且不常常修改的时候,使用配置文件是一个很好的作法,可是若是咱们配置很是多,有不少服务器都须要这个配置,并且还多是动态的话使用配置文件就不是个好主意了。这个时候每每须要寻找一种集中管理配置的方法,咱们在这个集中的地方修改了配置,全部对这个配置感兴趣的均可以得到变动。好比咱们能够把配置放在数据库里,而后全部须要配置的服务都去这个数据库读取配置。可是,由于不少服务的正常运行都很是依赖这个配置,因此须要这个集中提供配置服务的服务具有很高的可靠性。通常咱们能够用一个集群来提供这个配置服务,可是用集群提高可靠性,那如何保证配置在集群中的一致性呢?这个时候就须要使用一种实现了一致性协议的服务了。Zookeeper就是这种服务,它使用Zab这种一致性协议来提供一致性。如今有不少开源项目使用Zookeeper来维护配置,好比在HBase中,客户端就是链接一个Zookeeper,得到必要的HBase集群的配置信息,而后才能够进一步操做。还有在开源的消息队列Kafka中,也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也普遍的使用Zookeeper管理一些配置来实现服务治理。网络
2、名字服务架构
名字服务这个就很好理解了。好比为了经过网络访问一个系统,咱们得知道对方的IP地址,可是IP地址对人很是不友好,这个时候咱们就须要使用域名来访问。可是计算机是不能是别域名的。怎么办呢?若是咱们每台机器里都备有一份域名到IP地址的映射,这个却是能解决一部分问题,可是若是域名对应的IP发生变化了又该怎么办呢?因而咱们有了DNS这个东西。咱们只须要访问一个你们熟知的(known)的点,它就会告诉你这个域名对应的IP是什么。在咱们的应用中也会存在不少这类问题,特别是在咱们的服务特别多的时候,若是咱们在本地保存服务的地址的时候将很是不方便,可是若是咱们只须要访问一个你们都熟知的访问点,这里提供统一的入口,那么维护起来将方便得多了。并发
3、分布式锁
其实在第一篇文章中已经介绍了Zookeeper是一个分布式协调服务。这样咱们就能够利用Zookeeper来协调多个分布式进程之间的活动。好比在一个分布式环境中,为了提升可靠性,咱们的集群的每台服务器上都部署着一样的服务。可是,一件事情若是集群中的每一个服务器都进行的话,那相互之间就要协调,编程起来将很是复杂。而若是咱们只让一个服务进行操做,那又存在单点。一般还有一种作法就是使用分布式锁,在某个时刻只让一个服务去干活,当这台服务出问题的时候锁释放,当即fail over到另外的服务。这在不少分布式系统中都是这么作,这种设计有一个更好听的名字叫Leader Election(leader选举)。好比HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁仍是有区别的,因此使用的时候要比同一个进程里的锁更谨慎的使用。
4、集群管理
在分布式的集群中,常常会因为各类缘由,好比硬件故障,软件故障,网络问题,有些节点会进进出出。有新的节点加入进来,也有老的节点退出集群。这个时候,集群中其余机器须要感知到这种变化,而后根据这种变化作出对应的决策。好比咱们是一个分布式存储系统,有一个中央控制节点负责存储的分配,当有新的存储进来的时候咱们要根据如今集群目前的状态来分配存储节点。这个时候咱们就须要动态感知到集群目前的状态。还有,好比一个分布式的SOA架构中,服务是一个集群提供的,当消费者访问某个服务时,就须要采用某种机制发现如今有哪些节点能够提供该服务(这也称之为服务发现,好比Alibaba开源的SOA框架Dubbo就采用了Zookeeper做为服务发现的底层机制)。还有开源的Kafka队列就采用了Zookeeper做为Cosnumer的上下线管理。
集群的结构大体以下,一个zookeeper集群负责管理配置文件和投票选举,solr集群共俩分片,每一个分片一主一仆。
1 # cd zookeeper1 2 # mkdir data 3 # echo 1 >> data/myid
1 cd conf # 进入zookeeper config目录 2 cp zoo_sample.cfg zoo.cfg # 复制一份配置文件,并修改内
修改配置信息以下:
重点关注最后四行
dataDir:就是刚刚建立的目录,有个myid文件表示当前节点id(咱们填的1)
clientPort:外部访问solrcloud时链接的端口,由于solr交给zookeeper管理了
server.zookeeper_nodeId=zookeeper_ip:选举端口:投票端口,选举和投票在不一样端口进行
# bin/zkServer.sh start # 启动zookeeper
# bin/zkServer.sh stop # 关闭节点
节点所有启动后,能够查看节点状态
# bin/zkServer.sh status
本次实验目录设置
solr7_conf是配置文件,要把该配置文件上传到zookeeper管理,后面会说
三个zookeeper集群,四个solr集群,solr中的docs和example文件夹能够删除,以下图
#修改 bin/solr.in.sh SOLR_HOST="本机ip" SOLR_PORT="程序运行端口" #分布式时ip不同,端口同样,伪分布式时,ip同样,端口不同 #可选操做 SOLR_PORT=8981 ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183" #若是不指定这两个,能够在solr启动时指定
solr_home, 配置指定你建立的索引库位置所在,默认就在安装目录的server/solr中
本人配置:
#solr1
SOLR_HOST="192.168.1.105" SOLR_PORT="8981"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#solr2
SOLR_HOST="192.168.1.105" SOLR_PORT="8982"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#solr3
SOLR_HOST="192.168.1.105" SOLR_PORT="8983"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#solr4
SOLR_HOST="192.168.1.105" SOLR_PORT="8984"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#没有在配置文件中指定ZK_HOST 和 SOLR_PORT的在启动要指定
solr1/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8981 -force"
solr2/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8982 -force"
solr3/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8983 -force"
solr4/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8984 -force"
本次测试启动:
solr1/bin/solr start -cloud -force"
solr2/bin/solr start -cloud -force"
solr3/bin/solr start -cloud -force"
solr4/bin/solr start -cloud -force"
参数解释:
-c / -cloud 以solrcloud方式启动
-z 指定zookeeper集群的地址和客户端链接端口,以逗号隔开
-p 指定端口
后两个在有配置的状况下能够省
在任意一台机器
$ /opt/solr-6.6.0/bin/solr create_collection -c collection1 -shards 2 -replicationFactor 2 -force
create_collection 建立集合,只有在cloud模式下有效
-c
指定库(collection)名称 -shards
指定分片数量,可简写为 -s ,索引数据会分布在这些分片上 -replicationFactor
每一个分片的副本数量,每一个碎片由至少1个物理副本组成
或者浏览器输入:
http://192.168.1.105:8982/solr/admin/collections?action=CREATE&name=collection2&numShards=2&replicationFactor=2
配置文件上传到ZooKeeper 集群
可用参数(全部参数都是必需的)
-n <name>
在ZooKeeper中设置的配置名称,能够经过管理界面,点击菜单,Cloud 选中 Tree / configs 下查看,配置列表 -d <configset dir>
配置设置为上传的路径。路径须要有一个“conf”目录,依次包含solrconfig.xml等。最好能够提供绝对路径 -z <zkHost>
Zookeeper IP 端口,多个zk用"," 分隔
SolrCloud是经过Zookeeper集群来保证配置文件的变动及时同步到各个节点上,因此,能够将配置文件上传到Zookeeper集群。
$ solr1/bin/solr zk upconfig -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -n myconfig -d ../solr7_conf/conf
删除上传到ZooKeeper 集群的solr 配置
rm
删除-r
递归删除
$ solr1/bin/solr zk rm -r /configs/myconfig -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183
响应
Connecting to ZooKeeper at node1:2181,node2:2181,node3:2181 ... Removing Zookeeper node /configs/mynewconfig from ZooKeeper at node1:2181,node2:2181,node3:2181 recurse: true
solr1/bin/solr status
配置目录是否被其余集合使用。若是没有,那么该目录将从SolrCloud 集群 中删除
solr1/bin/solr delete -c collection1
有时候上面方法删不掉,用下面这个
删除collection1.
浏览器输入:
http://192.168.1.105:8983/solr/admin/collections?action=DELETE&name=collection1
四个节点分别调用
bin/solr stop
$ bin/solr healthcheck -c test_collection -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183
# 若是指定了 ZK_HOST和端口,随便找个节点目录输入输入: bin/solr healthcheck -c collection
虽然solr如今支持页面直接添加field域,可是fieldType仍是须要本身预先指定,因此要把配置文件从zookeeper中down下来,修改后再up上去(同名会自动覆盖)
# down下来配置 solr1/bin/solr zk downconfig -n myconfig -d /home/conf 修改managed-schema,添加中文分词器 以下: <fieldType name="text_ik" class="solr.TextField"> <analyzer class="org.wltea.analyzer.lucene.IKAnalyzer"/> </fieldType> 这样就加入了中文分词器IK 而后须要把相关jar包和IK的配置文件分别放在server/solr-webapps/webapp/WEB-INF下的lib和classes中 最后上传配置文件便可 solr1/bin/solr zk upconfig -n myconfig -d /home/conf
效果图:
最后用solrj测试下:
导入maven依赖
写个测试程序:
单点测试:
集群测试:待了解