Solr4.8.0源码分析(25)之SolrCloud的Split流程

Solr4.8.0源码分析(25)之SolrCloud的Split流程(一)

题记:昨天有位网友问我SolrCloud的split的机制是如何的,这个还真不知道,所以今天抽空去看了Split的原理,大致也了解split的原理了,所以也就有了这篇文章。本系列有两篇文章,第一篇为core split,第二篇为collection split。

1. 简介

  这里首先需要介绍一个比较容易混淆的概念,其实Solr的HTTP API 和 SolrCloud的HTTP API是不一样,如果接受到的是Solr的HTTP API,比如"http://localhost:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2",该方法对应的是CoreAdminHandler 。而"http://localhost:8983/solr/admin/collections?action=SPLITSHARD&collection=core0&shard=shard1",该方法对应的是CollectionsHandler.所以发送不同的HTTP 命令效果是不一样的。两个命令的代码分支是在以下SolrDispatchFilter中形成的:

 1         // Check for the core admin page
 2         if( path.equals( cores.getAdminPath() ) ) {
 3           handler = cores.getMultiCoreHandler();
 4           solrReq =  SolrRequestParsers.DEFAULT.parse(null,path, req);
 5           handleAdminRequest(req, response, handler, solrReq);
 6           return;
 7         }
 8         boolean usingAliases = false;
 9         List<String> collectionsList = null;
10         // Check for the core admin collections url
11         if( path.equals( "/admin/collections" ) ) {
12           handler = cores.getCollectionsHandler();
13           solrReq =  SolrRequestParsers.DEFAULT.parse(null,path, req);
14           handleAdminRequest(req, response, handler, solrReq);
15           return;
16         }

2. Core的Split

讲过了core api 和collection的api,那么我们开始来讲core的split。core的split命令在第一小节中已经讲到,如下所示:"cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2" ,以上命令的意思是将core0切分成core1和core2(core0还是继续保留并对外提供服务的)。除了上述命令,还有以下几个配置参数:

  • path,path是指core0索引最后切分好后存放的路径,它支持多个,比如cores?action=SPLIT&core=core0&path=path1&path=path2。
  • targetCore,就是将core0索引切分好后放入targetCore中(targetCore必须已经建立),它同样支持多个,请注意path和targetCore两个参数必须至少存在一个。
  • split.key, 根据该key进行切分,默认为unique_id.
  • ranges, 哈希区间,默认按切分个数进行均分。
  • 由此可见Core的Split api是较底层的借口,它可以实现将一个core分成任意数量的索引(或者core)。

接下来我们来了解下Core的Split的源码,流程图如下:

由于代码较多,这里就不贴出来了,可以查看SolrIndexSplitter.java和CoreAdminHandle.java,DirectUpdateHandle2.java对照着比较下,剩下的要补充几点:

1. Core Split是底层的实现接口,它在进行Split的时候不会去对原core的数据进行任何操作,所以即使过程中出现任何问题都不会影响原数据,且在split过程中原core一直在服务的。

2. Core Split可以实现一个core split为多个core,它即支持单机模式下的split也支持集群模式下对一个shard进行split,Collection的split底层就是调用该接口的。

3. 上图流程图中我分成了三列,分别对应三个步骤:

  • 解析split请求(最左),主要是确立好hash区间。
  • 对Segment中的docs进行切分(中间),切分好的数据是存放在FixedBitSet里面,FixedBitSet是Solr存放的doc id的集合,通过特定的格式进行存储,这在后文中将会具体介绍。
  • 将切分好的数据addindex到新的core或者path下,addIndex本质上是进行merge。但是在进行addIndex时候需要注意,addindex传入多少个segment它就会将这些Segment合并成一个Segment,所以如果一下子传入大量的Segment,最后会合并成一个很大的segment,这过程中符合很大。而Split中是每一次传入一个Segment,这样的结果就是出现很多个较小的Segment。
  • 最后Split是按新的core或者path依次来的,split完成之后并不会立马就可见,需要人为的进行一下reload操作。

总结:

本文介绍了Core Split的流程以及原理,为Collection Split的介绍做了个奠基。

时间: 2024-12-24 21:53:16

Solr4.8.0源码分析(25)之SolrCloud的Split流程的相关文章

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三)

Solr4.8.0源码分析(22)之 SolrCloud的Recovery策略(三) 本文是SolrCloud的Recovery策略系列的第三篇文章,前面两篇主要介绍了Recovery的总体流程,以及PeerSync策略.本文以及后续的文章将重点介绍Replication策略.Replication策略不但可以在SolrCloud中起到leader到replica的数据同步,也可以在用多个单独的Solr来实现主从同步.本文先介绍在SolrCloud的leader到replica的数据同步,下一篇

Solr4.8.0源码分析(17)之SolrCloud索引深入(4)

Solr4.8.0源码分析(17)之SolrCloud索引深入(4) 前面几节以add为例已经介绍了solrcloud索引链建索引的三步过程,delete以及deletebyquery跟add过程大同小异,这里暂时就不介绍了.由于commit流程较为特殊,那么本节主要简要介绍下commit的流程. 1. SolrCloud的commit流程 SolrCloud的commit流程同样分为三步,本节主要简单介绍下三步过程. 1.1 LogUpdateProcessor LogUpdateProces

Solr4.8.0源码分析(14)之SolrCloud索引深入(1)

Solr4.8.0源码分析(14) 之 SolrCloud索引深入(1) 上一章节<Solr In Action 笔记(4) 之 SolrCloud分布式索引基础>简要学习了SolrCloud的索引过程,本节开始将通过阅读源码来深入学习下SolrCloud的索引过程. 1. SolrCloud的索引过程流程图 这里借用下<solrCloud Update Request Handling 更新索引流程>流程图: 由上图可以看出,SolrCloud的索引过程主要通过一个索引链过程来实

Solr4.8.0源码分析(23)之SolrCloud的Recovery策略(四)

Solr4.8.0源码分析(23)之SolrCloud的Recovery策略(四) 题记:本来计划的SolrCloud的Recovery策略的文章是3篇的,但是没想到Recovery的内容蛮多的,前面三章分别介绍了Recovery的原理和总体流程,PeerSync策略,Replication策略.本章主要介绍我在实际生产环境中碰到的recovery的几个问题,以及前面漏下的几个点. 一. 日志中多次出现"Stopping recovery for zkNodeName= ..." 我在

Solr4.8.0源码分析(20)之SolrCloud的Recovery策略(一)

Solr4.8.0源码分析(20)之SolrCloud的Recovery策略(一) 题记: 我们在使用SolrCloud中会经常发现会有备份的shard出现状态Recoverying,这就表明SolrCloud的数据存在着不一致性,需要进行Recovery,这个时候的SolrCloud建索引是不会写入索引文件中的(每个shard接受到update后写入自己的ulog中).关于Recovery的内容包含三篇,本文是第一篇介绍Recovery的原因以及总体流程. 1. Recovery的起因 Rec

Solr4.8.0源码分析(16)之SolrCloud索引深入(3)

Solr4.8.0源码分析(16)之SolrCloud索引深入(3) 前面两节学习了SolrCloud索引过程以及索引链的前两步,LogUpdateProcessorFactory和DistributedUpdateProcessor.本节将详细介绍了索引链的第三步DirectUpdateHandler2和UpdateLog. 1. DirectUpdateHandler2.ADD DirectUpdateHandler2过程包含了Solr到Lucene的索引过程,在整个索引链中是最复杂也最重要

Solr4.8.0源码分析(24)之SolrCloud的Recovery策略(五)

Solr4.8.0源码分析(24)之SolrCloud的Recovery策略(五) 题记:关于SolrCloud的Recovery策略已经写了四篇了,这篇应该是系统介绍Recovery策略的最后一篇了.本文主要介绍Solr的主从同步复制.它与前文<Solr4.8.0源码分析(22)之SolrCloud的Recovery策略(三)>略有不同,前文讲到的是SolrCloud的leader与replica之间的同步,不需要通过配置solrconfig.xml来实现.而本文主要介绍单机模式下,利用so

Solr4.8.0源码分析(21)之SolrCloud的Recovery策略(二)

Solr4.8.0源码分析(21)之SolrCloud的Recovery策略(二) 题记:  前文<Solr4.8.0源码分析(20)之SolrCloud的Recovery策略(一)>中提到Recovery有两种策略,一是PeerSync和Replication.本节将具体介绍下PeerSync策略. PeeySync是Solr的优先选择策略,每当需要进行recovery了,Solr总是会先去判断是否需要进入PeerSync,只有当PeerSync被设置为跳过或者PeerSync时候发现没符合

Solr4.8.0源码分析(10)之Lucene的索引文件(3)

Solr4.8.0源码分析(10)之Lucene的索引文件(3) 1. .si文件 .si文件存储了段的元数据,主要涉及SegmentInfoFormat.java和Segmentinfo.java这两个文件.由于本文介绍的Solr4.8.0,所以对应的是SegmentInfoFormat的子类Lucene46SegmentInfoFormat. 首先来看下.si文件的格式 头部(header) 版本(SegVersion) doc个数(SegSize) 是否符合文档格式(IsCompoundF