CN117632531A - 集群中消息的处理方法、装置及存储介质 - Google Patents
集群中消息的处理方法、装置及存储介质 Download PDFInfo
- Publication number
- CN117632531A CN117632531A CN202210970115.8A CN202210970115A CN117632531A CN 117632531 A CN117632531 A CN 117632531A CN 202210970115 A CN202210970115 A CN 202210970115A CN 117632531 A CN117632531 A CN 117632531A
- Authority
- CN
- China
- Prior art keywords
- target
- cluster
- message
- node
- message queue
- 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
- 238000000034 method Methods 0.000 title claims abstract description 57
- 238000012545 processing Methods 0.000 title claims abstract description 23
- 238000004891 communication Methods 0.000 claims description 19
- 238000012544 monitoring process Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 7
- 230000008569 process Effects 0.000 description 10
- 230000009471 action Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
本申请涉及一种集群中消息的处理方法、装置及存储介质,其中,该方法包括:在接收到向目标可用区发送目标消息的情况下,确定所述目标消息所对应的目标集群,其中,所述目标可用区包括多个集群,一个所述集群包括多个节点和一个消息队列;将所述目标消息发送至与所述目标集群对应的消息队列。通过本申请,解决了现有技术中一个区域内仅通过一个消息队列来传递消息导致云服务平台运行效率较低的问题。
Description
技术领域
本申请涉及云服务领域,尤其涉及一种集群中消息的处理方法、装置及存储介质。
背景技术
目前,对于云服务中部署的每个Region(地域)的OpenStack(开源云操作系统)中,各个集群之间的通信都是通过RabbitMQ(消息队列)来传递消息,特别是计算节点作为主要使用方。如图1所示,通过AZ(avai lable zone,可用区)的划分来对大规模的资源进行管理,目前每个可用区共用一套OpenStack nova服务。用户访问时,请求到达Nova-Api,随后将消息发送给本区域的RabbitMQ,也即本区域下的所有AZ都使用同一个MQ(消息队列)。因此,随着计算节点增多,集群规模变大,消息队列压力越来越大导致虚拟机创建的调度越来越慢,使得整个云平台运行效率也较低。
发明内容
本申请提供了一种集群中消息的处理方法、装置及存储介质,以解决现有技术中一个区域内仅通过一个消息队列来传递消息导致云服务平台运行效率较低的问题。
第一方面,本申请提供了一种集群中消息的处理方法,包括:在接收到向目标可用区发送目标消息的情况下,确定所述目标消息所对应的目标集群,其中,所述目标可用区包括多个集群,一个所述集群包括多个节点和一个消息队列;将所述目标消息发送至与所述目标集群对应的消息队列。
第二方面,本申请提供了一种集群中消息的处理装置,包括:
确定模块,用于在接收到向目标可用区发送目标消息的情况下,确定所述目标消息所对应的目标集群,其中,所述目标可用区包括多个集群,一个所述集群包括多个节点和一个消息队列;第一发送模块,用于将所述目标消息发送至与所述目标集群对应的消息队列。
第三方面,提供了一种电子设备,包括处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
存储器,用于存放计算机程序;
处理器,用于执行存储器上所存放的程序时,实现第一方面任一项实施例所述的方法步骤。
第四方面,提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现如第一方面任一项实施例所述的方法步骤。
本申请实施例提供的上述技术方案与现有技术相比具有如下优点:
本申请实施例提供的该方法,在本申请实施例中,每一个集群都有对应的用来处理消息的消息队列,而不是一个可用区共用一个消息队列,因此,通过本申请实施例中的方式,在收到目标消息后,可以基于该目标消息确定对应的目标集群,进而将该目标消息发送至对应目标集群内的消息队列中,也就是说,通过本申请实施例中在可用区中的每一个集群中均设置有对应的消息队列,即如果目标消息对应的集群是集群A,则目标消息发送至集群A中的消息队列,如果目标消息对应的集群是集群B,则目标消息发送至集群B中的消息队列,而不是如现有技术中由于一个可用区共用一个消息队列,则发送至该可用区的消息只能达到这一个消息队列中,会导致消息队列中消息拥堵以及消息无法加入消息队列导致云服务平台效率较低,换言之,通过本申请实施例的方式,能够避免一个可用区内仅通过一个消息队列来传递消息导致云服务平台运行效率较低的问题,从而有效的提升了云服务平台的运行效率。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是现有技术中云平台中云服务的通信结构示意图;
图2为本申请实施例提供的一种集群中消息的处理方法的流程示意图之一;
图3为本申请实施例提供的一种集群中消息的处理方法的流程示意图之二;
图4为本申请实施例提供的云平台中云服务的通信结构示意图;
图5为本申请实施例提供的一种集群中消息的处理装置的结构示意图;
图6为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请提供的集群中消息的处理方法涉及云服务领域,其中,云服务的区域可以基于不同地理位置划分多个子区域,每个子区域可以根据实际情况设置一个或多个集群,每个集群中可以包括多个计算机(服务器)。在群集系统中,所有计算机都有一个通用名称:节点,所有网络客户都可以使用群集中任何系统上运行的服务。此外,集群必须能够协调和管理分离组件的错误和故障,并且能够透明地向集群添加组件。设置集群目的是降低单台服务器的计算压力,提高整体计算能力,而在集群中,可以通过直接增加节点来提高计算能力。
图2为本申请实施例提供的一种集群中消息的处理方法的流程示意图,如图2所示,该方法的步骤包括:
步骤202,在接收到向目标可用区发送目标消息的情况下,确定目标消息所对应的目标集群,其中,目标可用区包括多个集群,一个集群包括多个节点和对应的一个消息队列;
需要说明的是,如果本申请实施例中的云服务区域为省份A,且在具体示例中以城市为单位划分可用区,则该目标可用区可以是该省份A中的某一个城市,如城市B,进一步可以基于该城市B的所划分的片区来设置对应的集群,即一个片区对应一个集群。当然,上述仅仅是举例说明本申请中的云服务区域中集群的示例,在其他应用场景中可以根据实际需求设置相应的云服务中的可用区及其集群。
由于本申请涉及的是云服务领域,因此,本申请实施例中的目标消息是具有远程调用的功能,在具体示例中可以是远程调用服务(Remote Procedure Cal l,RPC)消息。RPC是指计算机A上的进程,调用另外一台计算机B上的进程,其中A上的调用进程被挂起,而B上的被调用进程开始执行,当值返回给A时,A进程继续执行。
步骤204,将目标消息发送至与目标集群对应的消息队列。
可见,在本申请实施例中,每一个集群都有对应的用来处理消息的消息队列,而不是一个可用区共用一个消息队列,因此,通过本申请实施例中的方式,在收到目标消息后,可以基于该目标消息确定对应的目标集群,进而将该目标消息发送至对应目标集群内的消息队列中,也就是说,通过本申请实施例中在可用区中的每一个集群中均设置有对应的消息队列,即如果目标消息对应的集群是集群A,则目标消息发送至集群A中的消息队列,如果目标消息对应的集群是集群B,则目标消息发送至集群B中的消息队列,而不是如现有技术中由于一个可用区共用一个消息队列,则发送至该可用区的消息只能达到这一个消息队列中,会导致消息队列中消息拥堵以及消息无法加入消息队列导致云服务平台效率较低,换言之,通过本申请实施例的方式,能够避免一个可用区内仅通过一个消息队列来传递消息导致云服务平台运行效率较低的问题,从而有效的提升了云服务平台的运行效率。
在本申请实施例的可选实施方式中,如图3所示,对于本申请实施例中的步骤202中涉及到的所述确定所述目标消息所对应的目标集群的方式,进一步可以包括:
步骤11,确定所述目标消息中是否携带有节点信息,其中,所述节点信息与所述目标集群关联;
步骤12,在所述目标消息中携带有所述节点信息的情况下,基于所述节点信息确定所述目标消息所对应的所述目标集群;
由于每一个集群可以包括一个或多个节点,因此,通过目标消息所携带的节点信息就能够直到该节点信息所对应的节点所在的集群,例如当前可用区有3个集群:集群A,集群B,集群C,且集群A中包括:节点1,节点2,节点3,;集群B中包括节点4,节点5,集群C中包括节点6,节点7,节点8,节点9;如果当前目标消息中携带有节点9的节点信息,该节点信息用来唯一标识节点的标识信息,则可以通过节点信息查找到对应的节点,即节点9,从而可以知道节点9所在集群C,则直接将该目标消息发送至集群C的消息队列中。
此外,在本申请实施例的可选实施方式中,本申请实施例中图3中方法还可以包括:
步骤13,在目标消息中未携带有节点信息的情况下,将目标消息发送至默认消息队列中。
可见,目标消息通常情况下均会携带所要发送至的集群中的节点的节点信息,因为要明确所要发送的目的地,但也会在极少情况下因为某些原因不会携带节点信息,因此,在目标消息未携带节点信息的情况下,则会将目标消息发送至默认消息队列,该默认消息队列可以是基于就近原则,默认为当前目标消息所在集群的消息队列,也可以是一个可用区中固定的某一个集群的消息队列中,也可以是一个可用区中所有消息队列中消息数量较少的消息队列中,具体默认消息队列的方式可以根据实际需求进行相应的设置。
在本申请实施例中由于集群中的多个节点中包括控制节点,基于此,本申请实施例中的上述步骤204中涉及到的将所述目标消息发送至与所述目标集群对应的消息队列的方式,进一步可以是:基于控制节点将目标消息发送至目标集群内的消息队列中。
对于该步骤204在具体示例中,如图4所示的本申请实施例中云平台中云服务的通信结构示意图,相比于现有技术,在本申请实施例中每一个集群均有对应的MQ,即集群1(Cluster1)中包括MQ,集群2(Cluster2)中也包括MQ,当然图4中仅仅是举例说明,如果该目标可用区还包括集群3,集群4等,则该集群3和集群4中也包括对应的MQ。基于该图4可知,本申请相比于现有技术,多个可用区共用Nova-API和scheduler的情况,在本申请中每一个集群中有对应的Nova-API(在OpenStack中负责维护和管理云环境的计算资源)和调度器scheduler(用于接收-一个虚拟机实例的请求,通过读取数据库的内容,从可用资源池中选择最合适的计算节点来创建新的虚拟机实例);其中,Nova-API和scheduler的组合相当于集群中的控制节点。也就是说,每一个集群均有对应的消息队列以及对应的控制节点,因此,在具体示例中如果目标消息为RPC消息,则在RPC消息数量较多时,也能够在控制节点的作用下根据RPC消息中是否携带节点信息及时处理RPC消息,例如,如果RPC消息达到Nova-API或scheduler后,先确定RPC消息中是否携带有节点信息,例如,集群1中的Nova-API接收到RPC消息后确定携带有集群2中的节点1的节点信息,则可以通过集群1中的控制节点将RPC消息发送至集群2中控制节点(scheduler)中,再由scheduler发送至集群2中的消息队列中;又或者,集群1中的Nova-API接收到RPC消息后确定未携带有节点信息,则直接将该RPC消息发送至当前集群(集群1)中的消息队列中。因此,通过每一个集群均设置对应的消息队列和对应的控制节点(Nova-API和scheduler)大大减轻了多个可用区共用一个消息队列的压力,从而能够大幅度提升云服务平台运行效率。
在本申请实施例的可选实施方式中,本申请实施例的方法还可以包括:
步骤208,利用目标可用区中目标集群内的控制节点向目标可用区中其他集群内的消息队列发送目标消息。
由于集群比较重要的是功能是负载均衡,因此,在某一个集群无法满足当前云服务需求的情况下,可以通过其他集群中的节点来协助,如图4所示,如果当前集群1中所有节点的负载均较高,则此时该集群中还有其他云服务需要集群中的节点来执行,则可以通过请求其他集群中的节点来协助执行该云服务,则该集群1中的节点1可以请求协助集群2中的节点1来协助执行,因此,集群1中的节点1可以基于当前集群中的控制节点(如调度器)向集群2中的消息队列发送RPC消息,该RPC消息中可以携带集群2中的节点1的节点信息,并携带所要请求的目的,也就是说,可以由调度器根据节点信息将RPC消息发送至其他集群或本集群,以实现集群的负载均衡,而且由于每一个集群中均设置有消息队列,在实现负载均衡过程对消息队列也不会造成负担,从而提升了云服务的运行效率。
步骤210,利用目标可用区中目标集群内的节点监听目标集群内的目标消息队列中的消息。
另外,本集群内的节点只能监听同一集群内消息队列中的消息,以避免集群中的节点监听其他集群中消息队列造成云服务的紊乱,而且通过监听同一集群内消息队列能够及时获取到对应的消息,提升云服务的运行效率。
通过上述本申请实施例中的一种集群中消息的处理方法,在本申请实施例中的,在云部署时,一个区域(region)可包括多个AZ,每个AZ又可以划分出多个计算集群(Cluster)。一个集群中的节点不允许跨AZ。这样可以在每个集群里部署一套消息队列。在具体示例中,在nova-api/scheduler发送RPC消息时,如果请求中有节点(host)信息,则通过host信息找到对应的集群,然后将消息发送到指定集群所在MQ。如果请求中未带host信息,则发送到默认当前所在集群MQ。也就是说,即使云服务中的计算节点增多,规模增大,消息队列也不会成为云服务性能瓶颈,通过本申请实施例的上述方式反而能够提升云服务的运行效率。
在本申请实施例的可选实施方式之前,在确定RPC消息中是否携带有节点信息之前,本申请实施例的方法还可以包括:
步骤200,设置多个区域,并将每一个区域分别划分为多个可用区;
步骤201,将每一个可用区域划分为多个集群,其中,目标区域为多个区域中的任意一个,目标可用区为一个目标区域所包括的多个可用区中的任意一个。
也就是说,在本申请实施例中可以利用云服务的覆盖范围可以进一步设置多个区域,该区域的划分可以基于地理位置进行划分,例如可以以省为单位,也就是说一个省为一个可用区,当然也可以有其他的划分方式,如市为单位进行划分,或者可以某一个地理标志进行划分,该地理位置的东南西北各划分为一个可用区。划分出区域后可以进一步对区域进行划分,划分出多个可用区以便后续管理。对于可用区中的集群可以基于节点的类型进行划分,即将同一类型的节点划分为同一集群,但在某些情况下,同一机房中可以包括多个集群的节点。基于此,如果同一集群中的节点类型一致,则消息队列中的消息的类型也是一致的,这样也能够提升节点监听本集群中消息队列中消息的效率。
对应于上述图2中的一种集群中消息的处理方法,本申请实施例还提供了一种集群中消息的处理装置,如图5所示,该装置包括:
确定模块52,用于在接收到向目标可用区发送目标消息的情况下,确定目标消息所对应的目标集群,其中,目标可用区包括多个集群,一个集群包括多个节点和一个消息队列;
第一发送模块54,用于将目标消息发送至与目标集群对应的消息队列。
可见,在本申请实施例中,每一个集群都有对应的用来处理消息的消息队列,而不是一个可用区共用一个消息队列,因此,通过本申请实施例中的方式,在收到目标消息后,可以基于该目标消息确定对应的目标集群,进而将该目标消息发送至对应目标集群内的消息队列中,也就是说,通过本申请实施例中在可用区中的每一个集群中均设置有对应的消息队列,即如果目标消息对应的集群是集群A,则目标消息发送至集群A中的消息队列,如果目标消息对应的集群是集群B,则目标消息发送至集群B中的消息队列,而不是如现有技术中由于一个可用区共用一个消息队列,则发送至该可用区的消息只能达到这一个消息队列中,会导致消息队列中消息拥堵以及消息无法加入消息队列导致云服务平台效率较低,换言之,通过本申请实施例的方式,能够避免一个可用区内仅通过一个消息队列来传递消息导致云服务平台运行效率较低的问题,从而有效的提升了云服务平台的运行效率。
可选地,本申请实施例的确定模块52还可以包括:第一确定单元,用于确定目标消息中是否携带有节点信息,其中,节点信息与目标集群关联;第二确定单元,用于在目标消息中携带有节点信息的情况下,基于节点信息确定目标消息所对应的目标集群;
可见,由于每一个集群可以包括一个或多个节点,因此,通过目标消息所携带的节点信息就能够直到该节点信息所对应的节点所在的集群,例如当前可用区有3个集群:集群A,集群B,集群C,且集群A中包括:节点1,节点2,节点3,;集群B中包括节点4,节点5,集群C中包括节点6,节点7,节点8,节点9;如果当前目标消息中携带有节点9的节点信息,该节点信息用来唯一标识节点的标识信息,则可以通过节点信息查找到对应的节点,即节点9,从而可以知道节点9所在集群C,则直接将该目标消息发送至集群C的消息队列中。
此外,确定模块52还可以包括:第三确定单元,用于在目标消息中未携带有节点信息的情况下,将目标消息发送至默认消息队列中。
可见,目标消息通常情况下均会携带所要发送至的集群中的节点的节点信息,因为要明确所要发送的目的地,但也会在极少情况下因为某些原因不会携带节点信息,因此,在目标消息未携带节点信息的情况下,则会将目标消息发送至默认消息队列,该默认消息队列可以是基于就近原则,默认为当前目标消息所在集群的消息队列,也可以是一个可用区中固定的某一个集群的消息队列中,也可以是一个可用区中所有消息队列中消息数量较少的消息队列中,具体默认消息队列的方式可以根据实际需求进行相应的设置。
可选地,本申请实施例中的多个节点中包括控制节点;该第一发送模块54进一步可以包括:发送单元,用于基于控制节点将目标消息发送至目标集群内的消息队列中。
在具体示例中,如图4所示的本申请实施例中云平台中云服务的通信结构示意图,相比于现有技术,在本申请实施例中每一个集群均有对应的MQ,即集群1(Cluster1)中包括MQ,集群2(Cluster2)中也包括MQ,当然图4中仅仅是举例说明,如果该目标可用区还包括集群3,集群4等,则该集群3和集群4中也包括对应的MQ。基于该图4可知,本申请相比于现有技术,多个可用区共用Nova-API和scheduler的情况,在本申请中每一个集群中有对应的Nova-API(在OpenStack中负责维护和管理云环境的计算资源)和调度器scheduler(用于接收-一个虚拟机实例的请求,通过读取数据库的内容,从可用资源池中选择最合适的计算节点来创建新的虚拟机实例);其中,Nova-API和scheduler的组合相当于集群中的控制节点。也就是说,每一个集群均有对应的消息队列以及对应的控制节点,因此,在具体示例中如果目标消息为RPC消息,则在RPC消息数量较多时,也能够在控制节点的作用下根据RPC消息中是否携带节点信息及时处理RPC消息,例如,如果RPC消息达到Nova-API或scheduler后,先确定RPC消息中是否携带有节点信息,例如,集群1中的Nova-API接收到RPC消息后确定携带有集群2中的节点1的节点信息,则可以通过集群1中的控制节点将RPC消息发送至集群2中控制节点(scheduler)中,再由scheduler发送至集群2中的消息队列中;又或者,集群1中的Nova-API接收到RPC消息后确定未携带有节点信息,则直接将该RPC消息发送至当前集群(集群1)中的消息队列中。因此,通过每一个集群均设置对应的消息队列和对应的控制节点(Nova-API和scheduler)大大减轻了多个可用区共用一个消息队列的压力,从而能够大幅度提升云服务平台运行效率。
可选地,本申请实施例中的装置还可以包括:第二发送模块,用于利用目标可用区中目标集群内的控制节点向目标可用区中其他集群内的消息队列发送目标消息。
由于集群比较重要的是功能是负载均衡,因此,在某一个集群无法满足当前云服务需求的情况下,可以通过其他集群中的节点来协助,如图4所示,如果当前集群1中所有节点的负载均较高,则此时该集群中还有其他云服务需要集群中的节点来执行,则可以通过请求其他集群中的节点来协助执行该云服务,则该集群1中的节点1可以请求协助集群2中的节点1来协助执行,因此,集群1中的节点1可以基于当前集群中的控制节点(如调度器)向集群2中的消息队列发送RPC消息,该RPC消息中可以携带集群2中的节点1的节点信息,并携带所要请求的目的,也就是说,可以由调度器根据节点信息将RPC消息发送至其他集群或本集群,以实现集群的负载均衡,而且由于每一个集群中均设置有消息队列,在实现负载均衡过程对消息队列也不会造成负担,从而提升了云服务的运行效率。
可选地,本申请实施例中的装置还可以包括:监听模块,用于利用目标可用区中目标集群内的节点监听目标集群内的目标消息队列中的消息。
可选地,本申请实施例中的装置还可以包括:第一处理模块,用于在在确定目标消息中是否携带有节点信息之前,设置多个区域,并将每一个区域分别划分为多个可用区;划分模块,用于将每一个可用区域划分为多个集群,其中,目标区域为多个区域中的任意一个,目标可用区为一个目标区域所包括的多个可用区中的任意一个。
也就是说,在本申请实施例中可以利用云服务的覆盖范围可以进一步设置多个区域,该区域的划分可以基于地理位置进行划分,例如可以以省为单位,也就是说一个省为一个可用区,当然也可以有其他的划分方式,如市为单位进行划分,或者可以某一个地理标志进行划分,该地理位置的东南西北各划分为一个可用区。划分出区域后可以进一步对区域进行划分,划分出多个可用区以便后续管理。对于可用区中的集群可以基于节点的类型进行划分,即将同一类型的节点划分为同一集群,但在某些情况下,同一机房中可以包括多个集群的节点。基于此,如果同一集群中的节点类型一致,则消息队列中的消息的类型也是一致的,这样也能够提升节点监听本集群中消息队列中消息的效率。
另外,本集群内的节点只能监听同一集群内消息队列中的消息,以避免集群中的节点监听其他集群中消息队列造成云服务的紊乱,而且通过监听同一集群内消息队列能够及时获取到对应的消息,提升云服务的运行效率。
如图6所示,本申请实施例提供了一种电子设备,包括处理器111、通信接口112、存储器113和通信总线114,其中,处理器111,通信接口112,存储器113通过通信总线114完成相互间的通信,
存储器113,用于存放计算机程序;
在本申请一个实施例中,处理器111,用于执行存储器113上所存放的程序时,实现前述任意一个方法实施例提供的一种集群中消息的处理方法,其所起到的技术效果也是类似的,在此不再赘述。
本申请实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现如前述任意一个方法实施例提供的一种集群中消息的处理方法步骤。
需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的具体实施方式,使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种集群中消息的处理方法,其特征在于,包括:
在接收到向目标可用区发送目标消息的情况下,确定所述目标消息所对应的目标集群,其中,所述目标可用区包括多个集群,一个所述集群包括多个节点和一个消息队列;
将所述目标消息发送至与所述目标集群对应的消息队列。
2.根据权利要求1所述的方法,其特征在于,所述确定所述目标消息所对应的目标集群,包括:
确定所述目标消息中是否携带有节点信息,其中,所述节点信息与所述目标集群关联;
在所述目标消息中携带有所述节点信息的情况下,基于所述节点信息确定所述目标消息所对应的所述目标集群。
3.根据权利要求2所述的方法,其特征在于,所述方法还包括:
在所述目标消息中未携带有所述节点信息的情况下,将所述目标消息发送至默认消息队列中。
4.根据权利要求1所述的方法,其特征在于,所述集群中包括控制节点;所述将所述目标消息发送至与所述目标集群对应的消息队列,包括:
基于所述控制节点将所述目标消息发送至所述目标集群内的消息队列中。
5.根据权利要求4所述的方法,其特征在于,所述方法还包括:
利用所述目标可用区中目标集群内的控制节点向所述目标可用区中其他集群内的消息队列发送所述目标消息。
6.根据权利要求1或5所述的方法,其特征在于,所述方法还包括:
利用所述目标可用区中目标集群内的节点监听所述目标集群内的目标消息队列中的消息。
7.根据权利要求1所述的方法,其特征在于,在确定所述目标消息中是否携带有节点信息之前,所述方法还包括:
设置多个区域,并将每一个所述区域分别划分为多个可用区;
将每一个所述可用区域划分为多个集群,其中,所述目标区域为所述多个区域中的任意一个,所述目标可用区为一个所述目标区域所包括的多个可用区中的任意一个。
8.一种集群中消息的处理装置,其特征在于,包括:
确定模块,用于在接收到向目标可用区发送目标消息的情况下,确定所述目标消息所对应的目标集群,其中,所述目标可用区包括多个集群,一个所述集群包括多个节点和一个消息队列;
第一发送模块,用于将所述目标消息发送至与所述目标集群对应的消息队列。
9.一种电子设备,其特征在于,包括处理器、通信接口、存储器和通信总线,其中,处理器,通信接口,存储器通过通信总线完成相互间的通信;
存储器,用于存放计算机程序;
处理器,用于执行存储器上所存放的程序时,实现权利要求1-7中任一项所述的方法步骤。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的方法步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210970115.8A CN117632531A (zh) | 2022-08-12 | 2022-08-12 | 集群中消息的处理方法、装置及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210970115.8A CN117632531A (zh) | 2022-08-12 | 2022-08-12 | 集群中消息的处理方法、装置及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117632531A true CN117632531A (zh) | 2024-03-01 |
Family
ID=90018639
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210970115.8A Pending CN117632531A (zh) | 2022-08-12 | 2022-08-12 | 集群中消息的处理方法、装置及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117632531A (zh) |
-
2022
- 2022-08-12 CN CN202210970115.8A patent/CN117632531A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11704144B2 (en) | Creating virtual machine groups based on request | |
CN108737270B (zh) | 一种服务器集群的资源管理方法和装置 | |
EP3667500B1 (en) | Using a container orchestration service for dynamic routing | |
CN109743415B (zh) | 一种公有云网络弹性ip实现方法及系统 | |
CN107924383B (zh) | 用于网络功能虚拟化资源管理的系统和方法 | |
CN112000448A (zh) | 基于微服务架构的应用管理方法 | |
US7287179B2 (en) | Autonomic failover of grid-based services | |
US20100077250A1 (en) | Virtualization based high availability cluster system and method for managing failure in virtualization based high availability cluster system | |
CN109150987B (zh) | 基于主机层和容器层的两层式容器集群弹性扩容方法 | |
CN113742031B (zh) | 节点状态信息获取方法、装置、电子设备及可读存储介质 | |
CN109117252B (zh) | 基于容器的任务处理的方法、系统及容器集群管理系统 | |
CN106991008B (zh) | 一种资源锁管理方法、相关设备及系统 | |
CN109783151B (zh) | 规则变更的方法和装置 | |
US7966394B1 (en) | Information model registry and brokering in virtualized environments | |
CN114979286B (zh) | 容器服务的访问控制方法、装置、设备及计算机存储介质 | |
CN113382077A (zh) | 微服务调度方法、装置、计算机设备和存储介质 | |
CN111913784B (zh) | 任务调度方法及装置、网元、存储介质 | |
CN114301980A (zh) | 容器集群的调度方法、装置、系统及计算机可读介质 | |
CN111245634A (zh) | 一种虚拟化管理方法及装置 | |
CN112631680A (zh) | 微服务容器调度系统、方法、装置和计算机设备 | |
US10896077B2 (en) | Messaging abstraction layer for integration with message oriented middleware platforms | |
CN115225645B (zh) | 一种服务更新方法、装置、系统和存储介质 | |
CN109005071B (zh) | 一种决策部署方法和调度设备 | |
CN114615268B (zh) | 基于Kubernetes集群的服务网络、监控节点、容器节点及设备 | |
CN115987872A (zh) | 一种基于资源路由的云系统 |
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 |