Solr集群架构概述及delta-import详细配置

简介:

背景

由于项目原因,重新熟悉了下Solr,版本为3.6,搭建了主从Solr服务,并使用DIH从RDBMS数据源增量更新索引。

其实也没什么技术含量,就是简单做个总结,分别从部署架构增量更新两个方面说明下。


Solr Replication

solr的主从其实是他的replication集群,从本质上说是通过ReplicationHandler来实现的,除了solr server之间可以互相同步之外,每个solr实例内部的core之间也是可以实现同步的,而能自身同步自身的实例称为Repeater,它的存在是为了分担master的同步开销,即由它来同步master里需要向外同步的core,然后所有的slave都从Repeater处同步相应的core。


具体配置方面,master的solrconfig.xml里的requestHandler配置为:

<requestHandler name="/replication" class="solr.ReplicationHandler">
	<lst name="master">
		<str name="replicateAfter">startup</str>
		<str name="replicateAfter">commit</str>
		<str name="backupAfter">optimize</str>
		<str name="confFiles">schema.xml,stopword.dic,db-data-config.xml,dataimport.properties</str>
		<str name="commitReserveDuration">00:01:00</str>
	</lst>
</requestHandler>
在confFiles里可以指定在同步过程中,slave需要一并同步过去的文件。slave端 solrconfig.xml里的配置为:

<requestHandler name="/replication" class="solr.ReplicationHandler">
	<lst name="slave">
		<str name="masterUrl">http://yf-rd-crm-cdc-db06.yf01.baidu.com:8888/solr/core0/replication</str>
		<str name="pollInterval">00:00:20</str>
		<str name="compression">internal</str>
		<str name="httpConnTimeout">5000</str>
		<str name="httpReadTimeout">10000</str>
	</lst>
</requestHandler>
其中pollInterval是发出同步请求的间隔时间,上述配置为每20s会去sync一次。后面的http参数都是默认值。对slave和master来说,主要的配置不同就在这个handler里,其他部分可以一致。我的solr主从比较简单,大致如下。


如果对solr的搜索还有分片和负载均衡的要求,可以参考下solr4.0之后支持的SolrCloud,适合 high scale, fault tolerant, distributed indexing and search capabilities。我没有选择SolrCloud,主要原因是数据量也不是很大,不需要分片。本来想参考SolrCloud,看能不能为请求的负载均衡提供些什么优势,后来还是放弃了,负载这块在solrj的搜索服务里简单做了下轮训。网上看到也有人用Nginx为多个Tomcat容器做负载均衡,不过这个出发点和架构上的层次又有些不一样。


Solr DataImportHandler

DataImportHandler可以为solr的索引配置数据源,我的数据源是mysql,基本配置可以参考SolrDoc里的内容。不重复。

主要的坑在需要在web.xml里添加下面这个配置

<listener>
   <listener-class>org.apache.solr.handler.dataimport.scheduler.ApplicationListener</listener-class>
</listener>
但是这个类并不存在于solr的主要几个包里,需要额外导入,包 下载链接在这里。需要在webapps/solr.war下的WEB-INF/lib里添加这个包,还要添加下dist下的两个dataimporthandler有关的两个jar。此外把上面的listener配置添加到WEB-INF/web.xml内。特别注意的是, 需要jdk7才能正常启动,否则会报错。

具体DIH相关的配置再详细列一下,首先在solrconfig.xml里配置Handler:

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
	<lst name="defaults">
		<str name="config">db-data-config.xml</str>
	</lst>
</requestHandler>
具体db-data-config.xml里是sql逻辑和映射field,放在core/conf内,

<dataConfig>
	<dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver"
		url="jdbc:mysql://ip:port/db_name"
		user="root" password="root" />
	<document name="tb_core">
		<entity name="tb_core_table" pk="table_id"
			query="select table_id, code, name, description, freq_id, bytes, first_date, owner, secret_level, charset_id, field_term, 
                            line_term, null_format, subj_id, gmt_modify from tb_core_table"
			deltaQuery="select table_id, code, name, description, freq_id, bytes, first_date, owner, secret_level, charset_id, field_term, 
                            line_term, null_format, subj_id, gmt_modify from tb_core_table where gmt_modify > '${dataimporter.last_index_time}'">
			<field column="table_id" name="table_id" />
			<field column="code" name="code" />
			<field column="name" name="name" />
			<field column="description" name="description" />
			<field column="description" name="subject_path" />
			<field column="freq_id" name="freq_id" />
			<field column="bytes" name="bytes" />
			<field column="first_date" name="first_date" />
			<field column="owner" name="owner" />
			<field column="secret_level" name="secret_level" />
			<field column="charset_id" name="charset_id" />
			<field column="field_term" name="field_term" />
			<field column="line_term" name="line_term" />
			<field column="null_format" name="null_format" />
			<field column="subj_id" name="subj_id" />
			<field column="gmt_modify" name="entity_modify" />
			<entity name="tb_core_column" pk="col_id"
				query="select col_id, table_id, code, name, description, gmt_modify from tb_core_column where table_id='${tb_core_table.table_id}'"
				deltaQuery="select col_id, table_id, code, name, description, gmt_modify from tb_core_column where gmt_modify > '${dataimporter.last_index_time}'"
				parentDeltaQuery="select table_id, code, name, description, freq_id, bytes, first_date, owner, secret_level, charset_id, field_term, 
                                    line_term, null_format, subj_id, gmt_modify from tb_core_table where table_id = ${tb_core_column.table_id}">
				<field column="col_id" name="column_id" />
				<field column="code" name="column_code" />
				<field column="name" name="column_name" />
				<field column="description" name="column_description" />
				<field column="gmt_modify" name="column_modify" />
			</entity>
		</entity>
	</document>
</dataConfig>
上面的逻辑里,table和column是一对多的关系,而两个table内都有最近更新时间字段(gmt_modify),任何一方的更新都要触发整个索引的增量更新,所以这是一个嵌套的例子。在SolrDoc里也有类似的嵌套写法,相对而言属于delta-import稍微高级些的写法。大家可以参考下。

<dataConfig>
    <dataSource driver="org.hsqldb.jdbcDriver" url="jdbc:hsqldb:/temp/example/ex" user="sa" />
    <document>
            <entity name="item" pk="ID" query="select * from item"
                deltaImportQuery="select * from item where ID=='${dih.delta.id}'"
                deltaQuery="select id from item where last_modified > '${dih.last_index_time}'">
                <entity name="feature" pk="ITEM_ID"
                    query="select DESCRIPTION as features from FEATURE where ITEM_ID='${item.ID}'"
                    deltaQuery="select ITEM_ID from FEATURE where last_modified > '${dih.last_index_time}'"
                    parentDeltaQuery="select ID from item where ID=${feature.ITEM_ID}"/>
            <entity name="item_category" pk="ITEM_ID, CATEGORY_ID"
                    query="select CATEGORY_ID from item_category where ITEM_ID='${item.ID}'"
                    deltaQuery="select ITEM_ID, CATEGORY_ID from item_category where last_modified > '${dih.last_index_time}'"
                    parentDeltaQuery="select ID from item where ID=${item_category.ITEM_ID}">
                <entity name="category" pk="ID"
                        query="select DESCRIPTION as cat from category where ID = '${item_category.CATEGORY_ID}'"
                        deltaQuery="select ID from category where last_modified > '${dih.last_index_time}'"
                        parentDeltaQuery="select ITEM_ID, CATEGORY_ID from item_category where CATEGORY_ID=${category.ID}"/>
            </entity>
        </entity>
    </document>
</dataConfig>
最重要的是,在solr_home/conf内需要一个负责调度的文件:dataimport.properties(不同于core/conf下的dataimport.properties,那个dataimport.properties会自动生成,记录的是最近一次更新的时间)

#################################################
#                                               #
#       dataimport scheduler properties         #
#                                               #
#################################################

#  是否同步功能
#  1 - 开启 ; 否则不开启
syncEnabled=1

# 需要同步的solr core
syncCores=core0

#  solr server名称或ip地址
#  默认为localhost
server=localhost

#  solr server端口
#  默认80
port=8888

# webapp name
webapp=solr

#  application context
# webapp=metadata-search

#  同步URL参数 
params=/dataimport?command=delta-import&clean=false&commit=true

#  调度区间
#  默认30分钟
interval=1
这部分就需要开头讲的
org.apache.solr.handler.dataimport.scheduler.ApplicationListener
的配置,否则启动后,之前的xml是不生效的。


Solr Server服务架构

结合Solr更新、主从和内部的一些主要模块,画了一个服务架构图如下。



(全文完)


目录
相关文章
|
2月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
167 0
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
6月前
|
人工智能 运维 安全
AI 安全架构概述
AI 安全架构涵盖数据采集、模型训练、推理部署等阶段,确保安全性、隐私与合规。其核心组件包括数据层、模型层、推理层、应用层和运维层,针对数据安全威胁(如数据投毒)、模型窃取、对抗攻击及系统漏洞等风险,提出数据加密、对抗训练、联邦学习等防御策略,并强调开发前、开发中和部署后的最佳实践,以降低 AI 解决方案的安全风险。
555 13
|
6月前
|
网络协议 Java 应用服务中间件
框架源码私享笔记(01)Tomcat核心架构功能 | 配置详解
本文首先分享了《活出意义来》一书序言中的感悟,强调成功如同幸福,不是刻意追求就能得到,而是全心投入时的副产品。接着探讨了Tomcat的核心功能与架构解析,包括网络连接器(Connector)和Servlet容器(Container),并介绍了其处理HTTP请求的工作流程。文章还详细解释了Tomcat的server.xml配置文件,涵盖了从顶级容器Server到子组件Connector、Engine、Host、Context等的配置参数及作用,帮助读者理解Tomcat的内部机制和配置方法。
|
5月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
5月前
|
存储 NoSQL Redis
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构
|
6月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
415 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
6月前
|
存储 SQL 并行计算
【赵渝强老师】达梦数据库MPP集群的架构
达梦数据库提供大规模并行处理(MPP)架构,以低成本实现高性能并行计算,满足海量数据存储和复杂查询需求。DM MPP采用完全对等无共享体系,消除主节点瓶颈,通过多节点并行执行提升性能。其执行流程包括主EP生成计划、分发任务、各EP并行处理及结果汇总返回。为确保高可用性,建议结合数据守护部署。
140 0
|
9月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
10月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
226 3

热门文章

最新文章