wbq813 Record Space

One who wants to wear the crown bear the crown.

ToC
SolrCloud 部署
/    

SolrCloud 部署 Updated!

SolrCloud 部署与原理

1. 部署

通过网上博客的比较,内置zk的方式比较简单,这里暂时使用这种方式。本文部分图片整理自互联网,如有侵权请联系删除。

  1. 规划

    参数解释
    shards3每个collection分为3块
    replicationFactor2冗余备份一次
    总块数6-

    假设我打算使用3台服务器部署solrcloud,因此有3个节点,每个节点相当于一台服务器,这里我只创建了一个collection,分为3个shard,每个shard备份一次,总共3*2个部分;node1保存2个,node2 保存2个,node3保存2个shard。
    借用网上一个图:
    分布式集群架构图

  2. 将solr/server/solr 目录下的zoo.cfg和solr.xml 复制到每一个node的solr_home下

  3. 按照自己的需求配置和修改solrconfig.xml 和schema.xml,比如自定义filed。

  4. 自行启动第一个节点

    	./bin/solr -c -p 8983 -s solr_home/node1
    

    这里的8983是设置example时的第一个节点的端口号,请保持一致。这里没有指定zk的端口号,默认时solr端口号+1000,这里是9983.

  5. 自行启动其余节点

    	./bin/solr -c -p 7001 -s solr_home/node2 -z 127.0.0.1:9983
    	./bin/solr -c -p 7002 -s solr_home/node3 -z 127.0.0.1:9983
    

    我这里是在同一台机器上测试,因此都使用不同的端口。

  6. 选择配置的类型,basic_configs data_driven_schema_configs sample_techporducts_configs 然后根据选择的类型复制 solr/server/solr/configsets 里边的示例配置文件到自定义的solr_home;

  7. 创建collection

    	bin/solr create -c collection1 -d solr_home/conf/collection1/ -shards 3 -replicationFactor 2 -p 8983
    

    这里-d之后指定配置文件的路径,配置文件会被上传到zookeeper。
    image.png

  8. 想任意一个节点插入数据,solrcloud会自动分配到不同的shard。

2. 原理

  1. 创建索引
    20151217015401414.png
    以solrj构建索引为例:
  • 当SolrJ发送update请求给CloudSolrServer ,CloudSolrServer会连接至Zookeeper获取当前SolrCloud的集群状态,并会在/clusterstate.json 和/live_nodes 注册watcher,便于监视Zookeeper和SolrCloud,这样做的好处有以下几点:

    • CloudSolrServer获取到SolrCloud的状态后,它能跟直接将document发往SolrCloud的leader,降低网络转发消耗。
    • 注册watcher有利于建索引时候的负载均衡,比如如果有个节点leader下线了,那么CloudSolrServer会立马得知,那它就会停止往下线leader发送document。
  • 路由document至正确的shard。CloudSolrServer 在发送document时候需要知道发往哪个shard,但是这里需要注意,单个document的路由非常简单,但是SolrCloud支持批量add,也就是说正常情况下N个document同时进行路由。这个时候SolrCloud就会根据document路由的去向分开存放document即进行分类(这里应该是有聚类,官方文档的说法见前面说的),然后进行并发发送至相应的shard,这就需要较高的并发能力。

  • Leader接受到update请求后,先将update信息存放到本地的update log,同时Leader还会给documrnt分配新的version,对于已存在的document,Leader就会验证分配的新version与已有的version,如果新的版本高就会抛弃旧版本,最后发送至replica。

  • 当只有一个Replica的时候,replica会进入recoveing状态并持续一段时间等待leader重新上线,如果在这段时间内,leader没有上线,replica会转成leader并有一些文档损失。(我的理解:如果leader挂了,请求还会发送成功????  )

  • 最后的步骤就是commit了,commit有两种,一种是softcommit,即在内存中生成segment,document是可见的(可查询到)但是没有写入磁盘,断电后数据丢失。另一种是hardcommit,直接将数据写入磁盘且数据可见。前一种消耗较少,后一种消耗较大。

每commit一次,就会重新生成一个ulog更新日志,当服务器挂掉,内存数据丢失,就可以从ulog中恢复

  1. Shard分裂
    20151217015557737.png

  2. 查询
    20151217015500409.png


Title: SolrCloud 部署
Author: wbq813
Traget: http://codeyourlife.cn/articles/2019/09/30/1569833989922.html

Comment