CN115934252A - 一种基于Kafka实现全自动负载均衡消费消息的方法及系统 - Google Patents
一种基于Kafka实现全自动负载均衡消费消息的方法及系统 Download PDFInfo
- Publication number
- CN115934252A CN115934252A CN202211571635.8A CN202211571635A CN115934252A CN 115934252 A CN115934252 A CN 115934252A CN 202211571635 A CN202211571635 A CN 202211571635A CN 115934252 A CN115934252 A CN 115934252A
- Authority
- CN
- China
- Prior art keywords
- topic
- consumer
- application server
- kafka
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种基于Kafka实现全自动负载均衡消费消息的方法及系统,该方法包括步骤:S1、对kafka对应主题topic信息进行可视化管理;S2、应用服务器启动时,获取本地IP信息,标记该应用服务器在集群内在线运行;S3、每间隔第一特定时间,集群内应用服务器的其中一个在线运行的应用服务器负责检查所有kafka的topic信息表变动情况,并更新topic消费者表;S4、每间隔第二特定时间,所有集群内应用服务器基于topic信息表变动情况按照负载均衡算法进行负载均衡kafka消费者进程并同步更新topic消费者表。本申请集群应用服务器自动化读取并按照动态变化的topic信息进行启停服务器,应用系统不再需要通过新增代码去触发创建消费者进程,高效提高了开发的工作效率和系统的稳定性。
Description
技术领域
本发明涉及微服务网关技术领域,具体涉及一种基于Kafka实现全自动负载均衡消费消息的方法及系统。
背景技术
Kafka作为一种消息中间件,是解决分布式系统消息传递问题的重要手段。Kafka中主要有生产者(Producer)、消费者(Consumer)和代理(Broker),一般来说Kafka的集群有多个代理节点组成,当生产者产生新的消息的时候,都会被划分并归类到某个主题中,每个主题被划分为多个分区,这些分区被部署在多个Broker上,由生产者持续不断地向某个类型的主题(Topic)发送消息,由代理服务器暂时存储不同主题的消息,然后转发给消费者,最后由消费者处理生产者产生的消息。随着大数据时代的到来,越来越多的场景都在使用消息中间件,而Kafka最大的特点就是收发消息非常快。在大数据时代,它可以快速处理基于不同数据源或终端消费者行为而产生的海量流数据。
由于公司业务不断多元化、复杂化,且随着技术快速的发展和迭代,可视化简单配置化,即可实现可扩展强、高可用架构至关重要。
发明内容
为了克服上述技术缺陷,本发明的第一个方面提供一种基于Kafka实现全自动负载均衡消费消息的方法,其包括步骤:
S1、通过可视化配置模块对kafka对应主题topic信息进行可视化管理;
S2、应用服务器启动时,获取本地IP信息,通过IP作为唯一标识,标记该应用服务器在集群内在线运行;
S3、每间隔第一特定时间,集群内应用服务器的其中一个在线运行的应用服务器负责检查所有kafka的topic信息表变动情况,根据topic信息表变动情况将topic消费者表配置做更新调整;
S4、每间隔第二特定时间,所有集群内应用服务器基于topic信息表变动情况,在应用服务器集群内按照负载均衡算法进行负载均衡kafka消费者进程并同步更新topic消费者表;
第二特定时间小于第一特定时间。
进一步地,所述步骤S1包括以下步骤:
S11、可视化查询所有topic数据并创建新的topic信息,topic信息包括topic名称、分区数、是否在线状态、启停状态、有效期截至日和创建时间等;
S12、可视化修改topic分区数,来动态创建消费者提升消息的吞吐量;
S13、可视化启停topic对应消费者,来实现实时上线/下线消费者进程,并可设置有效期来控制topic对应消费者生命周期;
S14、可视化查询topic对应消费者进程在应用服务器集群的分布情况,对消费者进程进行全方位把控。
进一步地,所述步骤S2包括以下分步骤:
S21、获取该应用服务器本地的IP地址;
S22、查询MySQL数据库中的应用服务器表是否存在对应IP,如果不存在,则表示新应用机器,进行新增一条应用服务器记录;如果存在,则再次更新该应用服务器记录的心跳时间以及将状态标识为在线。
进一步地,所述步骤S3包括以下分步骤:
S31、集群内服务器通过redis锁机制,抢到redis锁的应用服务器每间隔第一特定时间定时任务查询MySQL数据库中的topic信息表,并获取在用topic信息,在用topic信息包括topic名称、分区数量、有效期截至日期和启停状态;
S32、轮询步骤S31中查询出的topic信息表,通过topic名称,查询topic消费者表对应记录信息,判断分区数量topic消费者表记录数是否一致,如果分区数量大于topic消费者表记录数,则新增topic消费者表记录;如果分区数量小于topic消费者表记录数,则删除最大分区编号对应的topic消费者记录;
S33、移除下线的topic信息配置,将步骤S31中查询出的topic信息表与当前应用服务器已存在的topic信息对比,如果当前应用服务器已存在的topic信息数据,而查询出的topic信息表不存在该topic信息,则表示该topic信息下线,移除当前应用服务器的topic信息以及对应的消费者相关信息数据。
进一步地,所述步骤S4包括以下分步骤:
S41、每间隔第二特定时间,所有集群内应用服务器检查其他应用服务器心跳是否超时,查询所有在线状态应用服务器,如果应用服务器的心跳最新时间与当前时间的间隔大于第一阈值,则标记该应用服务器为下线并更新应用服务器表;第一阈值小于第二阈值;
S42、每间隔第二特定时间,检查本应用服务器所有消费者是否存在标记下线情况,如果是,则将该消费者进行下线处理,同时记录下线日志;
S43、每间隔第二特定时间,检查应用服务器kafka分区负载情况与实际负载数是否发生变化,如果存在不一样,则按照负载均衡算法将对应的消费者进行下线或上线处理。
进一步地,如果存在需要上线的消费者,会按照以下负载均衡算法逻辑在应用集群内进行负载均衡:当topic分区数等于应用服务器数量时,在集群每一个应用服务器上线一个消费者进程;当topic分区数大于集群数量时,计算出分区数量÷应用服务器数量的商值,首先,取商值的整数,在集群的每一个应用服务器上创建商值的整数个消费者进程,其次,取商值的余数,对机器号小于等于余数的每一个应用服务器分别创建一个消费者进程。
本发明的第二个方面提供一种基于Kafka实现全自动负载均衡消费消息的系统,其包括可视化配置模块、若干动态监听模块和若干自动负载均衡消费者模块,可视化配置模块设于统一管理平台中,应用集群中的每一个应用服务器中均分别设有一个动态监听模块和一个自动负载均衡消费者模块;
所述可视化配置模块用于对kafka对应主题topic信息进行可视化管理;
所述动态监听模块用于应用服务器启动时,获取本地IP信息,通过IP作为唯一标识,标记该应用服务器在集群内在线运行;还用于每间隔第一特定时间,集群内应用服务器的其中一个在线运行的应用服务器负责检查所有kafka的topic信息表变动情况,根据topic信息表变动情况将topic消费者表配置做更新调整;
所述自动负载均衡消费者模块用于每间隔第二特定时间,所有集群内应用服务器基于topic信息表变动情况,在应用服务器集群内按照负载均衡算法进行负载均衡kafka消费者进程并同步更新topic消费者表,第二特定时间小于第一特定时间。
进一步地,所述可视化配置模块用于:(1)可视化查询所有topic数据并创建新的topic信息,topic信息包括topic名称、分区数、是否在线状态、启停状态、有效期截至日和创建时间等;(2)可视化修改topic分区数,来动态创建消费者提升消息的吞吐量;(3)可视化启停topic对应消费者,来实现实时上线/下线消费者进程,并可设置有效期来控制topic对应消费者生命周期;(4)可视化查询topic对应消费者进程在应用服务器集群的分布情况,对消费者进程进行全方位把控。
进一步地,所述动态监听模块用于:(1)获取该应用服务器本地的IP地址;(2)查询MySQL数据库中的应用服务器表是否存在对应IP,如果不存在,则表示新应用机器,进行新增一条应用服务器记录;如果存在,则再次更新该应用服务器记录的心跳时间以及将状态标识为在线;
所述动态监听模块还用于:(1)集群内服务器通过redis锁机制,抢到redis锁的应用服务器每间隔第一特定时间定时任务查询MySQL数据库中的topic信息表,并获取在用topic信息,在用topic信息包括topic名称、分区数量、有效期截至日期和启停状态;(2)轮询(1)查询出的topic信息表,通过topic名称,查询topic消费者表对应记录信息,判断分区数量topic消费者表记录数是否一致,如果分区数量大于topic消费者表记录数,则新增topic消费者表记录;如果分区数量小于topic消费者表记录数,则删除最大分区编号对应的topic消费者记录;(3)移除下线的topic信息配置,将(1)中查询出的topic信息表与当前应用服务器已存在的topic信息对比,如果当前应用服务器已存在的topic信息数据,而查询出的topic信息表不存在该topic信息,则表示该topic信息下线,移除当前应用服务器的topic信息以及对应的消费者相关信息数据。
进一步地,所述自动负载均衡消费者模块用于:(1)每间隔第二特定时间,所有集群内应用服务器检查其他应用服务器心跳是否超时,查询所有在线状态应用服务器,如果应用服务器的心跳最新时间与当前时间的间隔大于第一阈值,则标记该应用服务器为下线并更新应用服务器表,第一阈值小于第二阈值;(2)每间隔第二特定时间,检查本应用服务器所有消费者是否存在标记下线情况,如果是,则将该消费者进行下线处理,同时记录下线日志;(3)每间隔第二特定时间,检查应用服务器kafka分区负载情况与实际负载数是否发生变化,如果存在不一样,则按照负载均衡算法将对应的消费者进行下线或上线处理。
采用了上述技术方案后,与现有技术相比,具有以下有益效果:
本申请中的基于Kafka实现全自动负载均衡消费消息的系统通过在集群应用中的每一个应用服务器中增设动态监听模块和自动负载均衡消费者模块,从而优化了现有的负载均衡方法。基于中间件Kafka实现全自动负载均衡维护消费者进程方法是一种基于topic分区数(topic分区与消费者一对一),自动负载均衡创建消费者实现将服务器资源进行最大化利用、零代码实现启停消费者、自动化提升消息处理能力。在大数据时代,它可以快速处理基于不同数据源或终端消费者行为而产生的海量流数据。
具体地,本发明的优点包括:
1、负载均衡创建动态消费者:基于kafka创建topic分区数,动态负载均衡到消费者应用集群上,充分自动化提高消息的处理和响应能力。
2、灵活自动化创建、启停消费者:当topic新增分区时,该方法自动监听并创建相应的消费者,且当topic配置上线或下线时,也能快速的进行启停对应消费者进程。
3、本发明基于Kafka中间件实现全自动负载消费者进程,可根据topic分区数和状态动态负载均衡创建或启停消费者,适用于多样化的大数据加工或清洗场景,比如:消费者在终端(APP、PC)的所有行为数据、多数据源统一清洗业务。
4、本发明运营人员只需要可视化管理topic信息,即可实现kafka的消费者进程动态管理,零代码在集群内扩分区或新增topic的消费消息情况,可通过可视化查看kafka的消费者进程在集群内负载情况,根据情况扩充集群节点或调整topic分区数,来增加消息处理的吞吐量性能。
5、本发明通过增加可视化配置维护,集群应用服务器自动化读取并按照动态变化的topic信息进行启停服务器,应用系统不再需要通过新增代码去触发创建消费者进程,高效提高了开发的工作效率和系统的稳定性。
附图说明
图1为本发明一实施例的基于Kafka实现全自动负载均衡消费消息的系统的整体架构结构图;
图2所示为本发明所实施的可视化创建topic信息图;
图3所示为本发明所实施的可视化查看topic的消费者分布集群信息图;
图4所示为本发明所实施的集群服务器心跳检测流程图;
图5所示为本发明所实施的集群负载均衡启停消费者流程图。
具体实施方式
以下结合附图与具体实施例进一步阐述本发明的优点。本领域技术人员应当理解,下面所具体描述的内容是说明性的而非限制性的,不应以此限制本发明的保护范围。
如图1所示,本实施例中的基于Kafka实现全自动负载均衡消费消息的系统包括可视化配置模块、若干动态监听模块和若干自动负载均衡消费者模块。可视化配置模块设于统一管理平台中。应用集群包括n个应用服务器,每一个应用服务器中分别包括一个动态监听模块、一个自动负载均衡消费者模块和Kafka集群模块。MySQL数据库中存储有topic信息表、topic消费者表和应用服务器表。
所述中间件kafka的topic信息表可视化配置新增或修改分区数,根据到期时间上线和下线topic服务。应用服务器启动,刷新集群服务器信息,然后上线负载均衡计算出的消费者进程。所述应用服务器每五分钟配置刷新,刷新topic信息表,创建维护对应分区消费者信息,由topic消费者表维护,并将topic信息以及topic消费者信息加载到内存中。所述应用服务器每分钟监听,根据应用机器数结合内存topic消费者信息,根据topic明细以及分区数变化,集群服务器进行负载均衡创建消费者,并更新topic消费者表维护分区消费在线\下线情况。
采用上述基于Kafka实现全自动负载均衡消费消息的系统进行全自动负载均衡消费消息的方法包括以下步骤:
S1、通过可视化配置模块对kafka对应主题topic信息进行可视化管理。
S11、如图2所示,可视化配置管理topic信息是通过前端web页完成的:可视化查询所有topic数据并创建新的topic信息,topic信息包括topic名称、分区数、是否在线状态、启停状态、有效期截至日和创建时间等;
S12、可视化修改topic分区数,来动态创建消费者提升消息的吞吐量;
S13、可视化启停topic对应消费者,来实现实时上线/下线消费者进程,并可设置有效期来控制topic对应消费者生命周期;
S14、如图3所示,可视化查询topic对应消费者进程在应用服务器集群的分布情况,对消费者进程进行全方位把控。
S2、当应用服务器启动时,获取本地IP信息,通过IP作为唯一标识,标记该应用服务器在集群内在线运行。
S21、通过获取该应用服务器本地Ipv4的IP地址(machineIp=NetUtil.localIpv4s().toString();),来查询当前服务器在配置表中实际情况;
S22、查询MySQL数据库中的应用服务器表是否存在对应IP,如果不存在,则表示新应用机器,进行新增一条应用服务器记录;如果存在,则代表只是重启服务,则更新该应用服务器记录的心跳时间以及状态标识为在线,标记当前服务器心跳检测一次。
S3、每间隔第一特定时间,集群内应用服务器的其中一个在线运行的应用服务器负责检查所有kafka的topic信息表变动情况,根据topic信息表变动情况将topic消费者表配置做更新调整。
S31、集群内服务器通过redis锁机制,抢到redis锁的应用服务器每间隔第一特定时间(所述第一特定时间为≤20分钟的任一时间,例如每5分钟)定时任务查询MySQL数据库中的topic信息表,并获取在用topic信息,也通过全局变量设置执行冷却时间3分钟,保障同一节点不会重复执行,在用topic信息包括topic名称、分区数量、有效期截至日期和启停状态;
S32、轮询步骤S31中查询出的topic信息表,通过topic名称,查询topic消费者表对应记录信息,判断分区数量topic消费者表记录数是否一致,如果分区数量大于topic消费者表记录数,则新增topic消费者表记录;如果分区数量小于topic消费者表记录数,则删除最大分区编号对应的topic消费者记录;
S33、移除下线的topic信息配置,将步骤S31中查询出的topic信息表与当前应用服务器已存在的topic信息对比,如果当前应用服务器已存在的topic信息数据,而查询出的topic信息表不存在该topic信息,则表示该topic信息下线,移除当前应用服务器的topic信息以及对应的消费者相关信息数据。
S4、每间隔第二特定时间,所有集群内应用服务器基于topic信息表变动情况,在应用服务器集群内按照负载均衡算法进行负载均衡kafka消费者进程并同步更新topic消费者表,第二特定时间小于第一特定时间。
topic消费者表包括:应用服务器表管理集群情况、topic信息表统一管理topic分区情况以及上线、下线逻辑、topic消费者表用于真实表达消费者进程上线、下线情况以及消费者分布在集群机器情况。
S41、如图4所示,每间隔第二特定时间(所述第二特定时间为≤5分钟的任一时间,例如定时任务每分钟执行一次),所有集群内应用服务器对自身应用服务器进行心跳检测,检查应用服务器心跳是否超时,查询所有在线状态应用服务器,如果应用服务器的心跳最新时间与当前时间的间隔大于第一阈值(示例地,第一阈值为5分钟),则标记该应用服务器为下线并更新应用服务器表;如果应用服务器的心跳最新时间与当前时间的间隔大于第二阈值(示例地,第二阈值为1天),则删除应用服务器表中的该应用服务器记录;如果心跳检测结果没有超时,代表在集群内该节点正常运行,直接记录集群服务器表对应IP的心跳时间和状态,让集群服务器知晓当前节点正常运行;
S42、通过抢redis锁机制,在所有节点中的其中一个节点,运行监控程序:①剔除无效机器②分配机器号(每一个应用服务器按照顺序序号预设有固定的机器号,存在机器号(即IP)的机器(即应用服务器)会自动创建消费者)。每间隔第二特定时间(所述第二特定时间为≤5分钟的任一时间,例如每分钟),检查本应用服务器所有消费者是否存在标记下线情况,如果是,则将该消费者进行下线处理,同时记录下线日志;
S43、每间隔第二特定时间(所述第二特定时间为≤5分钟的任一时间,例如每分钟),检查应用服务器kafka分区负载情况与实际负载数是否发生变化,如果存在不一样,则按照负载均衡算法将对应的消费者进行下线或上线处理,如图5所示。
每分钟检查kafka分区、集群机器,根据kafka分区的情况进行负载均衡,启动或停止当前机器的消费者。基于集群内各个应用服务器的使用情况,如果存在需要上线的消费者,会按照以下负载均衡算法逻辑在应用集群内进行负载均衡:
(1)当topic分区数等于应用服务器数量时,在集群每一个应用服务器上线一个消费者进程;
(2)当topic分区数大于集群数量时,计算出分区数量÷应用服务器数量的商值,首先,取商值的整数,在集群的每一个应用服务器上创建商值的整数个消费者进程,其次,取商值的余数,对机器号小于等于余数的每一个应用服务器分别创建一个消费者进程,换句话说,集群应用中消费者数量小的有优先创建消费者进程的权利。
示例地,假设分区数量为7,应用服务器一共有3个,应用服务器的机器号依次对应为1、2、3。分区数量÷应用服务器数量=7÷3=2…1(商值的整数为2,余数为1)。
第一步:在集群每一个应用服务器上创建2个(商值的整数)消费者进程;
第二步:对机器号小于等于1的每一个应用服务器,本实施例为机器号为1的应用服务器,再进一步创建1个(商值的余数)消费者进程。
综上,机器号为1的应用服务器共启动3个消费者进程;机器号为2的应用服务器共启动2个消费者进程;机器号为3的应用服务器共启动2个消费者进程。
S44、通过可视化查询kafka消费者进程负载在各个应用服务器,使用该查询能及时定位某个topic的消费者分布应用服务器情况,遇到topic消费者异常问题能快速到指定应用服务器去查看。
应当注意的是,本发明的实施例有较佳的实施性,且并非对本发明作任何形式的限制,任何熟悉该领域的技术人员可能利用上述揭示的技术内容变更或修饰为等同的有效实施例,但凡未脱离本发明技术方案的内容,依据本发明的技术实质对以上实施例所作的任何修改或等同变化及修饰,均仍属于本发明技术方案的范围内。
Claims (10)
1.一种基于Kafka实现全自动负载均衡消费消息的方法,其特征在于,包括步骤:
S1、通过可视化配置模块对kafka对应主题topic信息进行可视化管理;
S2、应用服务器启动时,获取本地IP信息,通过IP作为唯一标识,标记该应用服务器在集群内在线运行;
S3、每间隔第一特定时间,集群内应用服务器的其中一个在线运行的应用服务器负责检查所有kafka的topic信息表变动情况,根据topic信息表变动情况将topic消费者表配置做更新调整;
S4、每间隔第二特定时间,所有集群内应用服务器基于topic信息表变动情况,在应用服务器集群内按照负载均衡算法进行负载均衡kafka消费者进程并同步更新topic消费者表;第二特定时间小于第一特定时间。
2.根据权利要求1所述的基于Kafka实现全自动负载均衡消费消息的方法,其特征在于,所述步骤S1包括以下步骤:
S11、可视化查询所有topic数据并创建新的topic信息,topic信息包括topic名称、分区数、是否在线状态、启停状态、有效期截至日和创建时间等;
S12、可视化修改topic分区数,来动态创建消费者提升消息的吞吐量;
S13、可视化启停topic对应消费者,来实现实时上线/下线消费者进程,并可设置有效期来控制topic对应消费者生命周期;
S14、可视化查询topic对应消费者进程在应用服务器集群的分布情况,对消费者进程进行全方位把控。
3.根据权利要求1所述的基于Kafka实现全自动负载均衡消费消息的方法,其特征在于,所述步骤S2包括以下分步骤:
S21、获取该应用服务器本地的IP地址;
S22、查询MySQL数据库中的应用服务器表是否存在对应IP,如果不存在,则表示新应用机器,进行新增一条应用服务器记录;如果存在,则再次更新该应用服务器记录的心跳时间以及将状态标识为在线。
4.根据权利要求1所述的基于Kafka实现全自动负载均衡消费消息的方法,其特征在于,所述步骤S3包括以下分步骤:
S31、集群内服务器通过redis锁机制,抢到redis锁的应用服务器每间隔第一特定时间定时任务查询MySQL数据库中的topic信息表,并获取在用topic信息,在用topic信息包括topic名称、分区数量、有效期截至日期和启停状态;
S32、轮询步骤S31中查询出的topic信息表,通过topic名称,查询topic消费者表对应记录信息,判断分区数量topic消费者表记录数是否一致,如果分区数量大于topic消费者表记录数,则新增topic消费者表记录;如果分区数量小于topic消费者表记录数,则删除最大分区编号对应的topic消费者记录;
S33、移除下线的topic信息配置,将步骤S31中查询出的topic信息表与当前应用服务器已存在的topic信息对比,如果当前应用服务器已存在的topic信息数据,而查询出的topic信息表不存在该topic信息,则表示该topic信息下线,移除当前应用服务器的topic信息以及对应的消费者相关信息数据。
5.根据权利要求1所述的基于Kafka实现全自动负载均衡消费消息的方法,其特征在于,所述步骤S4包括以下分步骤:
S41、每间隔第二特定时间,所有集群内应用服务器检查其他应用服务器心跳是否超时,查询所有在线状态应用服务器,如果应用服务器的心跳最新时间与当前时间的间隔大于第一阈值,则标记该应用服务器为下线并更新应用服务器表;第一阈值小于第二阈值;如果应用服务器的心跳最新时间与当前时间的间隔大于第二阈值;
S42、每间隔第二特定时间,检查本应用服务器所有消费者是否存在标记下线情况,如果是,则将该消费者进行下线处理,同时记录下线日志;
S43、每间隔第二特定时间,检查应用服务器kafka分区负载情况与实际负载数是否发生变化,如果存在不一样,则按照负载均衡算法将对应的消费者进行下线或上线处理。
6.根据权利要求5所述的基于Kafka实现全自动负载均衡消费消息的方法,其特征在于,如果存在需要上线的消费者,会按照以下负载均衡算法逻辑在应用集群内进行负载均衡:当topic分区数等于应用服务器数量时,在集群每一个应用服务器上线一个消费者进程;当topic分区数大于集群数量时,计算出分区数量÷应用服务器数量的商值,首先,取商值的整数,在集群的每一个应用服务器上创建商值的整数个消费者进程,其次,取商值的余数,对机器号小于等于余数的每一个应用服务器分别创建一个消费者进程。
7.一种基于Kafka实现全自动负载均衡消费消息的系统,其特征在于,包括可视化配置模块、若干动态监听模块和若干自动负载均衡消费者模块,可视化配置模块设于统一管理平台中,应用集群中的每一个应用服务器中均分别设有一个动态监听模块和一个自动负载均衡消费者模块;
所述可视化配置模块用于对kafka对应主题topic信息进行可视化管理;
所述动态监听模块用于应用服务器启动时,获取本地IP信息,通过IP作为唯一标识,标记该应用服务器在集群内在线运行;还用于每间隔第一特定时间,集群内应用服务器的其中一个在线运行的应用服务器负责检查所有kafka的topic信息表变动情况,根据topic信息表变动情况将topic消费者表配置做更新调整;
所述自动负载均衡消费者模块用于每间隔第二特定时间,所有集群内应用服务器基于topic信息表变动情况,在应用服务器集群内按照负载均衡算法进行负载均衡kafka消费者进程并同步更新topic消费者表,第二特定时间小于第一特定时间。
8.根据权利要求7所述的基于Kafka实现全自动负载均衡消费消息的系统,其特征在于,所述可视化配置模块用于:(1)可视化查询所有topic数据并创建新的topic信息,topic信息包括topic名称、分区数、是否在线状态、启停状态、有效期截至日和创建时间等;(2)可视化修改topic分区数,来动态创建消费者提升消息的吞吐量;(3)可视化启停topic对应消费者,来实现实时上线/下线消费者进程,并可设置有效期来控制topic对应消费者生命周期;(4)可视化查询topic对应消费者进程在应用服务器集群的分布情况,对消费者进程进行全方位把控。
9.根据权利要求7所述的基于Kafka实现全自动负载均衡消费消息的系统,其特征在于,
所述动态监听模块用于:(1)获取该应用服务器本地的IP地址;(2)查询MySQL数据库中的应用服务器表是否存在对应IP,如果不存在,则表示新应用机器,进行新增一条应用服务器记录;如果存在,则再次更新该应用服务器记录的心跳时间以及将状态标识为在线;
所述动态监听模块还用于:(1)集群内服务器通过redis锁机制,抢到redis锁的应用服务器每间隔第一特定时间定时任务查询MySQL数据库中的topic信息表,并获取在用topic信息,在用topic信息包括topic名称、分区数量、有效期截至日期和启停状态;(2)轮询(1)查询出的topic信息表,通过topic名称,查询topic消费者表对应记录信息,判断分区数量topic消费者表记录数是否一致,如果分区数量大于topic消费者表记录数,则新增topic消费者表记录;如果分区数量小于topic消费者表记录数,则删除最大分区编号对应的topic消费者记录;(3)移除下线的topic信息配置,将(1)中查询出的topic信息表与当前应用服务器已存在的topic信息对比,如果当前应用服务器已存在的topic信息数据,而查询出的topic信息表不存在该topic信息,则表示该topic信息下线,移除当前应用服务器的topic信息以及对应的消费者相关信息数据。
10.根据权利要求7所述的基于Kafka实现全自动负载均衡消费消息的系统,其特征在于,所述自动负载均衡消费者模块用于:(1)每间隔第二特定时间,所有集群内应用服务器检查其他应用服务器心跳是否超时,查询所有在线状态应用服务器,如果应用服务器的心跳最新时间与当前时间的间隔大于第一阈值,则标记该应用服务器为下线并更新应用服务器表,第一阈值小于第二阈值;(2)每间隔第二特定时间,检查本应用服务器所有消费者是否存在标记下线情况,如果是,则将该消费者进行下线处理,同时记录下线日志;(3)每间隔第二特定时间,检查应用服务器kafka分区负载情况与实际负载数是否发生变化,如果存在不一样,则按照负载均衡算法将对应的消费者进行下线或上线处理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211571635.8A CN115934252A (zh) | 2022-12-08 | 2022-12-08 | 一种基于Kafka实现全自动负载均衡消费消息的方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211571635.8A CN115934252A (zh) | 2022-12-08 | 2022-12-08 | 一种基于Kafka实现全自动负载均衡消费消息的方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115934252A true CN115934252A (zh) | 2023-04-07 |
Family
ID=86553315
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211571635.8A Pending CN115934252A (zh) | 2022-12-08 | 2022-12-08 | 一种基于Kafka实现全自动负载均衡消费消息的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115934252A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117473125A (zh) * | 2023-11-07 | 2024-01-30 | 鱼快创领智能科技(南京)有限公司 | 一种数据分析可视化的方法 |
-
2022
- 2022-12-08 CN CN202211571635.8A patent/CN115934252A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117473125A (zh) * | 2023-11-07 | 2024-01-30 | 鱼快创领智能科技(南京)有限公司 | 一种数据分析可视化的方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109960710B (zh) | 数据库之间的数据同步方法和系统 | |
US20170279687A1 (en) | Context graph generation | |
CN107992392B (zh) | 一种用于云渲染系统的自动监控修复系统和方法 | |
CN111274052A (zh) | 数据分发方法、服务器及计算机可读存储介质 | |
CN109271602B (zh) | 深度学习模型发布方法及装置 | |
CN101632093A (zh) | 用于使用统计学分析来管理性能故障的系统和方法 | |
CN112506870B (zh) | 数据仓库增量更新方法、装置及计算机设备 | |
US20170279660A1 (en) | Context graph augmentation | |
CN113312153B (zh) | 一种集群部署方法、装置、电子设备及存储介质 | |
CN112737800A (zh) | 服务节点故障定位方法、调用链生成方法及服务器 | |
CN109828886B (zh) | 一种容器云环境下的ci/cd监控方法和系统 | |
CN111010318A (zh) | 发现物联网终端设备失联的方法、系统和设备影子服务器 | |
CN115934252A (zh) | 一种基于Kafka实现全自动负载均衡消费消息的方法及系统 | |
CN110619014A (zh) | 一种基于etl的数据抽取方法 | |
CN111897643B (zh) | 线程池配置系统、方法、装置和存储介质 | |
CN112579289A (zh) | 一种可智能调度的分布式解析引擎方法及装置 | |
CN111756778B (zh) | 一种服务器磁盘清理脚本推送的方法、装置和存储介质 | |
CN111651302A (zh) | 分布式数据库备份方法,装置及系统 | |
CN110532105B (zh) | 一种消息队列消费者进程的控制方法、系统及装置 | |
CN113157701A (zh) | 一种oracle数据库的双活机制部署方法及装置 | |
CN111162938A (zh) | 数据处理系统及方法 | |
CN115718690A (zh) | 一种数据准确性监控系统和方法 | |
CN114020431A (zh) | 一种任务调度方法及系统 | |
CN113835916A (zh) | 一种基于Ambari大数据平台的告警方法、系统及设备 | |
US20230385113A1 (en) | Progress Monitoring Service |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |