CN108199912A - 一种异地多活的分布式消息的管理、消费方法及装置 - Google Patents
一种异地多活的分布式消息的管理、消费方法及装置 Download PDFInfo
- Publication number
- CN108199912A CN108199912A CN201711350875.4A CN201711350875A CN108199912A CN 108199912 A CN108199912 A CN 108199912A CN 201711350875 A CN201711350875 A CN 201711350875A CN 108199912 A CN108199912 A CN 108199912A
- Authority
- CN
- China
- Prior art keywords
- consumption
- cluster
- business
- business cluster
- module
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/14—Arrangements for monitoring or testing data switching networks using software, i.e. software packages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Computer Security & Cryptography (AREA)
- Environmental & Geological Engineering (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明实施例提供了一种异地多活的分布式消息的管理方法、消费方法及装置,所述管理方法包括:健康检查中心检查服务端的每个业务集群是否可用;如果所述健康检查中心检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。本发明实施例中,健康检查中心对服务端业务集群的可用性进行检查,并标记可用的业务集群的集群优先级,以便于为消费端提供集群优先级最高的业务集群进行连接消费,从而提高了业务集群的高可用性。
Description
技术领域
本发明涉及计算机技术领域,特别是涉及一种异地多活的分布式消息的管理方法、消费方法及装置。
背景技术
Kafka是一个分布式的、可分区的、可复制的分布式消息系统,Kafka以集群的方式运行,可以由一个或多个服务组成。分布式消息系统作为分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。Kafka集群是其中的典型代表。现有Kafka集群都是分开部署运维的,由于Kafka集群数量众多,Kafka集群之间是通过数据中心(DC,datacenter)来为消费者提供服务的,一旦某个数据中心出现了问题,会造成与该数据中心连接所有Kafka集群不能为消费者提供服务,消费者需要进行Kafka集群切换,以及在消费者切换到新的Kafka集群后,需要重新消费,会产生大量的重复消息,从而降低了消费者的满意度。
因此,如何实现跨数据中心的服务高可用以及在消费者切换集群过程中减少生成的重复消息是目前有待解决的技术问题。
发明内容
本发明实施例所要解决的技术问题是提供一种异地多活的分布式消息的管理方法和消费方法,以解决现有技术中不能实现跨数据中心的服务的高可用,导致消费者在切换集群过程造成大量重复消息,降低满意度的问题。
相应的,本发明实施例还提供了一种异地多活的分布式消息的管理装置和消费装置,用以保证上述方法的实现及应用。
为了解决上述问题,,本发明是通过如下技术方案实现的:
第一方面提供一种异地多活的分布式消息的管理方法,所述方法包括:
健康检查中心检查服务端的每个业务集群是否可用;
如果所述健康检查中心检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。
可选的,所述为可用的所述至少两个业务集群标记优先级具体包括:
所述健康检查中心按照预定规则标记可用的所述至少两个业务集群的集群优先级。
可选的,所述健康检查中心检查服务端的每个业务集群是否可用,具体包括:
所述健康检查中心通过心脏跳动heart beat检查每个业务集群是否可用。
可选的,所述方法还包括:
所述健康检查中心获取每个业务集群记录的每个消费端的消费起点偏移值;
所述健康检查中心根据所述消费起点偏移值设置每个消费终端的消费进度;
所述健康检查中心将所述消费进度同步给其余业务集群指定的zookeeper中。
第二方面提供一种异地多活的分布式消息的消费方法,所述方法包括:
消费端监测服务端的至少两个业务集群是否可用;
如果所述消费端监测到所述至少两个业务集群均可用,则从健康检查中心获取可用的至少两个业务集群的集群优先级;
所述消费端选择集群优选级高的业务集群作为主业务集群;
所述消费端连接选择的所述主业务集群进行消费。
可选的,所述方法还包括:
在开始消费后,所述消费端继续监测所述主业务集群是否可用;
在所述消费端监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;
连接重新选择的所述主业务集群进行消费。
可选的,所述方法还包括:
在连接重新选择的所述主业务集群进行消费前,计算消费端的消费起点偏移值;
根据所述消费起点偏移值重新设置所述消费端的消费进度;
按照重新设置的消费进度连接到重新选择的所述主业务集群进行消费。
可选的,按照下述公式计算消费起点偏移值:
offset A=offset B-Lag-调整因子offset A≤0,
其中,所述offsetA为业务集群A上一个主题topic消息的消费起点偏移值;
所述offsetB为业务集群B上所述topic目前的消费偏移值;
所述Lag为业务集群B上所述topic消息消费的滞后值;
所述调整因子为调整常量。
第三方面提供一种异地多活的分布式消息的管理装置,所述装置包括:
检查模块,用于检查服务端的至少两个业务集群的是否可用;
第一标记模块,用于所述检查模块检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。
可选的,所述第一标记模块,具体用于在所述检查模块检查到至少两个业务集群均可用时,按照预定规则标记可用的所述至少两个业务集群的集群优先级。
可选的,所述检查模块,具体用于通过心脏跳动heart beat检查每个业务集群是否可用。
可选的,所述装置还包括:
获取模块,用于获取每个业务集群记录每个消费端的消费起点偏移值;
设置模块,用于根据所述消费起点偏移值设置每个消费终端的消费进度;
同步模块,用于将所述消费进度同步给其余业务集群指定的zookeeper中。
第四方面提供一种异地多活的分布式消息的消费装置,所述装置包括:
监测模块,用于监测服务端的至少两个业务集群是否可用;
第一获取模块,用于在所述监测模块监测到所述至少两个业务集群均可用时,从健康检查中心获取可用的至少两个业务集群的集群优先级;
第一选择模块,用于选择集群优选级高的业务集群作为主业务集群;
第一消费模块,用于连接选择的所述主业务集群进行消费。
可选的,所述装置还包括:第三选择模块和第三消费模块,其中,
所述监测模块,还用于在开始消费后,继续监测所述主业务集群是否可用;
所述第三选择模块,用于在所述检测模块监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;
所述第三消费模块,用于连接重新选择的所述主业务集群进行消费。
可选的,所述装置还包括:
计算模块,用于在所述第三消费模块进行消费前,计算消费端初始化的消费起点偏移值;
所述设置模块,还用于根据所述计算模块计算的消费起点偏移值重新设置所述消费端的消费进度;
第三消费模块,还用于按照重新设置的消费进度连接到重新选择的所述主业务集群进行消费。
可选的,所述计算模块按照下述公式计算消费起点偏移值:
offset A=offset B-Lag-调整因子offset A≤0,
其中,所述offsetA为业务集群A上一个主题topic消息的消费起点偏移值;
所述offsetB为业务集群B上所述topic目前的消费偏移值;
所述Lag为业务集群B上所述topic消息消费的滞后值;
所述调整因子为调整常量。
与现有技术相比,本发明实施例包括以下优点:
本发明实施例中,消费终端通过监测服务器端所有业务集群的可用性,并从健康检查中心获取可用的所有业务集群的集群优先级,然后,选择集群优先级最该的业务集群作为主业务集群进行连接消费。也就是说,本发明实施例中,消费端从自身监测到服务端的可用业务集群中,选择集群优先级最高的业务集群进行连接消费,从而提高了业务集群的高可用性。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
图1是本发明实施例提供的一种异地多活的分布式消息的管理方法的流程图;
图2是本发明实施例提供的一种异地多活的分布式消息的消费方法的流程图;
图3是本发明实施例提供的一种异地多活的分布式消息的消费方法的另一流程图;
图4是本发明实施例提供的一种异地多活分布式消息的消费方法的另一流程图;
图5是本发明实施例提供的一种异地多活分布式消息的管理装置的结构示意图;
图6是本发明实施例提供的一种异地多活的分布式消息的消费装置的另一结构示意图;
图7是本发明实施例提供的一种异地多活的分布式消息的消费装置的另一结构示意图;
图8是本发明实施例提供的一种异地多活的分布式消息消费系统的结构示意图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
还请参阅图1,为本发明实施例提供的一种异地多活的分布式消息的管理方法的流程图,所述方法包括:
步骤101:健康检查中心检查服务端的每个业务集群是否可用;
该步骤中,服务端的健康检查中心(HCC,Health Check Center)与所有业务进群分别连接,用来检查每个业务集群的是否可用(即存活情况),具体的,HCC通常使用心脏跳动(heart beat)来检查每个集群是否可用,如果可用,为可用的所述至少两个业务集群标记集群优先级。
该实施例中,每个业务集群都有指定的zookeeper,zookeeper中存储业务集群的业务集群信息。
目前,每个指定的Zookeeper中存储的业务集群是以临时节点的方式存储的。HCC在检查每个业务集群是否可用时,主要是通过检查心脏跳动(heart beat)在超时(timeout)时间内是否存在,如果心脏跳动在超时时间还存在,则说明该业务集群可用,即临时节点仍然存在;如果失去心跳,则说明业务集群不可用,需要在zookeeper中删除该临时节点。
步骤102:如果所述健康检查中心检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。
在该步骤中,HCC在检查到一个或多个业务集群可用时,在可用的每个业务集群指定的zookeeper中的保留所述业务集群信息,则为可用的所述至少两个业务集群标记集群优先级。具体可以按照预定规则标记可用的所述至少两个业务集群的集群优先级,其中,预定规则可以按照两个业务集群是否同数据库DC来设定等。比如,业务集群A的优先级为P1,业务集群B的优先级为P2,按照约定规则设定P1>P2等。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述方法还可以包括:如果所述健康检查中心检查到所述至少两个业务集群中只有一个业务集群可用,则为可用的所述业务集群标记集群优先级。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述方法还可以包括:如果所述健康检查中心检查到有业务集群不可用,则删除不可用所述业务集群指定zookeeper中的所述业务集群信息。
该实施例中,在HCC检查到有至少一个业务集群不可用时,删除不可用业务集群指定zookeeper中不可用的业务集群信息,即将zookeeper中不可用的临时节点,后续消费端不再访问该业务集群,消费端会切换到新的业务集群。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述方法还可以包括:HCC获取每个业务集群记录每个消费端的消费起点偏移值;所述健康检查中心根据所述消费起点偏移值设置每个消费终端的消费进度;然后,将所述消费进度同步给其余业务集群指定的zookeeper。
本发明实施例中,HCC对服务端业务集群的可用性进行检查,并标记可用的业务集群的集群优先级,以便于为消费端提供集群优先级最高的业务集群进行连接消费,从而提高了业务集群的高可用性。
请参阅图2,为本发明实施例提供的一种异地多活的分布式消息的消费方法的流程图,所述方法包括:
步骤201:消费端监测服务端的至少两个业务集群的是否可用;
该步骤中,消费端集群中的每个消费端(或者是消息接收端集群中的每个消息接收端)先监测服务端的所有业务集群是否可用(即业务集群是否存活),消费端每次消费过程中只能连接一个主业务集群,而这个主业务集群的具体信息是由服务端预先为消费端选定优先级该的业务集群。
该实施例中,可以通过封装的软件开发工具包(SDK,Software Development KitWindows)来监测业务集群是否可用,其具体的监测过程对于本领域技术人员来说,已是熟知技术,在此不再赘述。
本实施例中的业务集群可以是Kafka集群。
步骤202:如果所述消费端监测到所述至少两个业务集群均可用,从健康检查中心获取可用的至少两个业务集群的集群优先级;
该步骤中,如果消费端监测到服务端的一个或多个业务集群均可用,则从健康检查中心获取该可用的一个或多个业务集群的集群优先级。
步骤203:所述消费端选择集群优选级高的业务集群作为主业务集群;
该步骤中,消费端从所述至少两个业务集群中选择集群优先级最高的一个业务集群作为主业务集群,即将选择的业务集群标记为主业务集群。
步骤204:所述消费端连接选择的所述主业务集群进行消费。
该实施例中,当中心zookeeper故障或者没有中心zookeeper时,消费端集群中的每个消费端将从监测到的可以业务集群中选择一个集群优先级最该的业务集群,并将其作为主业务集群进行连接消费。
需要说明的是,本实施例中的业务集群为Kafka集群(下述实施例同),每个Kafka集群有多个Kafka实例(server)组成,每个实例都是一个代理(broker)。
本发明实施例中,消费终端通过监测服务器端所有业务集群的可用性,并从健康检查中心获取可用的所有业务集群的集群优先级,然后,选择集群优先级最该的业务集群作为主业务集群进行连接消费。也就是说,本发明实施例中,消费端从自身监测到服务端的可用业务集群中,选择集群优先级最高的业务集群进行连接消费,从而提高了业务集群的高可用性。
还请参阅图3,为本发明实施例提供的一种异地多活的分布式消息的消费方法的另一流程图。该实施例在上述实施例的不同之处在于,消费端只监测到一个业务集群可用,所述方法包括:
步骤301:消费端监测服务端的至少两个业务集群是否可用;
该步骤同步骤201,具体详见上述,在此不再赘述。
步骤302:如果所述消费端监测到所述至少两个业务集群中只有一个业务集群可用,则从健康检查中心获取可用的一个业务集群的集群优先级;
步骤303:所述消费端选择集群优选级高的业务集群作为主业务集群;
该步骤中,消费端监测到服务端只有一个业务集群可用,则将标记该可用的一个业务集群的集群优先级为最高,即将该可用的业务集群标记为主业务集群。
步骤304:所述消费端连接选择的所述主业务集群进行消费。
本发明实施例中,消费端在监测到服务端的只有一个可用业务集群,将该业务集群标记为主业务集群,然后连接到该业务集群进行消费,从而提高了业务集群的高可用性。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述方法还可以包括:如果监测到所述至少两个业务集群中没有一个业务集群可用,则消费端停止向所述两个业务集群中的任一个业务集群进行消费。
还请参阅图4,为本发明实施例提供的一种异地多活的分布式消息的消费方法的另一流程图,该实施例与上述实施例的不同之处在于,当消费端开始消费后,继续监测与该消费端连接的主业务集群的可用性,并在该主业务集群不可用时,切换到新的业务集群进行消费,具体包括:
步骤401:在开始消费后,消费端监测所述主业务集群是否可用;
在消费端开始消费后,消费端继续监测该主业务集群的可用性,即业务集群的存活性。期监测的方式与上述监测业务集群是否的可用的方式相同,具体详见上述,在此不再赘述。
步骤402:在所述监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;
消费端在监测到主业务集群不可用时,选择次优先级高的业务集群作为新的主业务集群。
步骤403:连接重新选择的所述主业务集群进行消费。
消费端与重新选择的主业务集群建立连接并开始消费。
可选的,在另一实施例中,该实施例在上述实施例的基础上上,所述方法还可以包括:
在所述消费端连接重新选择的所述主业务集群进行消费前,计算消费端的消费起点偏移值;
根据所述消费起点偏移值重新设置所述消费端的消费进度;
按照重新设置的消费进度连接到重新选择的所述主业务集群进行消费。
其中,该实施例中,消费端计算消费端的消费起点偏移值,可以利用抵消同步(Offset Syncer)应用来计算每个消费端在对应业务集群上消费的消费起点偏移值,其具体的计算公式为:offset A=offset B-Lag-调整因子,offset A≤0。
其中,offsetA为业务集群A上某个主题(topic)信息的消费起点偏移值;
offsetB为业务集群B上所述topic信息目前的消费偏移值;
Lag为业务集群B上所述topic消费的滞后值,其计算公式为:Lag=LogSize-Offset,其中Offset值可以从Zookeeper中获取,offset为业务集群(比如kafka集群)中某个主题(topic)单独partation被标记为已经消费的消费偏移值;Logsize为业务集群(比如kafka集群)中某个topic单独partation的消息总量。其中,Partition为Topic包含的分区,通常情况下Topic有0-8一共9个分区。
调整因子,是为了进一步提高准确性而设置的调整值,即调整常量。可以根据消费速度、切换时间灵活设置。其计算公式为:QPS*Time-Intervel(校准期),其中,QPS为监测消费端的每秒查询率(Query Per Second)。根据所述消费起点偏移值重新设置所述消费端的消费进度;
也就是说,消费端根据消费起点偏移值重新设置消费进度,以便于在切换到主业务集群上按照重新设定消费进度进行消费,最大程度上减少了消息的重复消费。
本发明实施例中,当消费端连接主业务集群开始消费时,消费端就开始监测该主业务集群的可用性,如果监测到该主业务集群不可用时,重新选择主业务集群,并计算消费端初始化的消费起点偏移值;然后根据所述消费起点偏移值重新设置所述消费端的消费进度;并与重新选择的主业务集群进行连接,最后按照重新设置的消费进度在连接的所述主业务集群进行消费。本实施例不但提高了业务集群的高可用性,而且在消费端切换到新的业务集群后,按照重新设置的消费进度开始消费,大幅度减少消息的重复消费。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明实施例并不受所描述的动作顺序的限制,因为依据本发明实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本发明实施例所必须的。
参照图5,为本发明实施例提供的一种异地多活分布式消息管理装置的结构示意图,所述装置包括:检查模块51和第一标记模块52,其中,
检查模块51,用于检查服务端的至少两个业务集群的是否可用;具体用于通过心脏跳动heart beat检查每个业务集群是否可用
第一标记模块52,用于所述检查模块51检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。具体用于在所述检查模块51检查到至少两个业务集群均可用时,按照预定规则标记可用的所述至少两个业务集群的集群优先级。
可选的,在另一实施例中,所述装置还可以包括:第二标记模块61,其结构示意图如图6所示,其中,
第二标记模块61,用于在所述检查模块51检查到所述至少两个业务集群中只有一个业务集群可用,则为可用的所述业务集群标记集群优先级;
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述装置还可以包括:删除模块(图中未示),用于在所述检查模块检查到所述至少两个业务集群中没有一个业务集群可用时,从不可用业务集群指定的zookeeper中删除所述业务集群的信息。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述装置还可以包括:获取模块,设置模块和同步模块(图中未示),其中,
获取模块,用于获取每个业务集群记录每个消费端的消费起点偏移值;
设置模块,用于根据所述消费起点偏移值设置每个消费终端的消费进度;
同步模块,用于将所述消费进度同步给其余业务集群指定的zookeeper中。
可选的,所述装置可以集成在消费端集群中的每个消费端上,也可以独立部署,本实施例不作限制作。
所述装置中各个模块的功能和作用的实现过程详见上述方法中对应步骤的实现过程,在此不再赘述。
还请参阅图7,为本发明实施例提供的一种异地多活的分布式消息的消费装置的另一结构示意图,所述装置包括:监测模块71、第一获取模块72、第一选择模块73和第一消费模块74,其中,
监测模块71,用于监测服务端的至少两个业务集群是否可用;
第一获取模块72,用于在所述监测模块监测到所述至少两个业务集群均可用时,从健康检查中心获取可用的至少两个业务集群的集群优先级;
第一选择模块73,用于选择集群优选级高的业务集群作为主业务集群;
第一消费模块74,用于连接选择的所述主业务集群进行消费。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述装置还可以包括:第二选择模块和第二消费模块(图中未示),其中,
第二选择模块,用于在所述监测模块监测到所述至少两个业务集群中只有一个业务集群可用,则选择所述可用的业务集群作为主业务集群;
第二消费模块,用于连接所述第二选择模块选择的所述主业务集群进行消费。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述装置还可以包括:停止发送模块,用于在所述监测模块监测到所述至少两个业务集群中没有一个业务集群可用时,停止向所述两个业务集群中的任一个业务集群进行消费。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述装置还可以包括:第三选择模块和第三消费模块(图中未示),其中,
所述监测模块,还用于在开始消费后,继续监测所述主业务集群是否可用;
第三选择模块,用于在所述检测模块监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;
第三消费模块,用于连接重新选择的所述主业务集群进行消费。
可选的,在另一实施例中,该实施例在上述实施例的基础上,所述装置还可以包括:计算模块(图中未示),其中,
计算模块,用于在第三消费模块进行消费前,计算消费端初始化的消费起点偏移值;
所述设置模块,还用于根据所述计算模块计算的消费起点偏移值重新设置所述消费端的消费进度;
所述第三消费模块,还用于按照重新设置的消费进度连接到重新选择的所述主业务集群进行消费。
其中,所述计算模块按照下述公式计算消费起点偏移值:
offset A=offset B-Lag-调整因子offset A≤0,
其中,所述offsetA为业务集群A上一个主题topic消息的消费起点偏移值;
所述offsetB为业务集群B上所述topic目前的消费偏移值;
所述Lag为业务集群B上所述topic消息消费的滞后值,其计算公式为:Lag=LogSize-Offset,其中Offset值可以从Zookeeper中获取,offset为业务集群(比如kafka集群)中某个主题(topic)单独partation被标记为已经消费的消费偏移值;Logsize为业务集群(比如kafka集群)中某个topic单独partation的消息总量。其中,Partition为Topic包含的分区,通常情况下Topic有0-8一共9个分区;
所述调整因子,是为了进一步提高准确性而设置的调整值,即调整常量。可以根据消费速度、切换时间灵活设置。其计算公式为:QPS*Time-Intervel(校准期),其中,QPS为监测消费端的每秒查询率(Query Per Second)。根据所述消费起点偏移值重新设置所述消费端的消费进度;
也就是说,消费端根据消费起点偏移值重新设置消费进度,以便于在切换到主业务集群上按照重新设定消费进度进行消费,最大程度上减少了消息的重复消费。
可选的,所述装置可以集成在消费端,也可以独立部署,本实施例不作限制作。
所述装置中各个模块的功能和作用的实现过程详见上述方法中对应步骤的实现过程,在此不再赘述。
还请参阅图8,为本发明实施例提供的一种异地多活的分布式消息的消费系统结构示意图,所述系统包括:模拟复用器80(AQM,Analogue Multiplexer Quantizer),生产端81、服务端82和消费端83。为了便于说明,本实施例中,生产端81以包括Producer1和Producer2为例,服务端82以包括健康检查中心821(HCC,Health Check Center)、业务集群(Kafka)A和业务集群(Kafka)B,以及KafkaA对应的ZookeeperA,和Kafka B对应的ZookeeperB为例,消费端83以包括Consumer1和Consumer2为例。
该实施例中,假如,AQM80向Producer1发送北京电信消息;向Producer2发送北京联通消息;下面以Producer1为例来说明。Producer2的与Producer1类似;
Producer1在接收到该北京电信消息后,监测服务端82的KafkaA和KafkaB是否可用;如果监测到所述KafkaA和KafkaB均可用,则Producer1将所述Producer1发布的消息(即接收到的北京电信消息)分别发送给所述KafkaA和KafkaB;KafkaA和KafkaB分别将存储接收到的北京电信消息,而ZookeeperA的作用主要是用来维护和监控KafkaA存储的数据的状态变化,通过监控这些数据状态的变化,从而可以达到基于数据的集群管理。同理,ZookeeperB的作用主要是用来维护和监控KafkaB存储的数据的状态变化,通过监控这些数据状态的变化,从而可以达到基于数据的集群管理。
所述Producer1从所述KafkaA和KafkaB中选择一个Kafka作为消费端连接的主Kafka;其选择的过程为:Producer1从服务端82的中心zookeeper中获取分布式锁;然后通过所述分布式锁从所述KafkaA和KafkaB中选择一个Kafka作为主Kafka,比如,将选择的标记为主Kafka。然后,Producer1将所述主KafkaA的信息更新到可用的KafkaB以及健康检查中心HCC中。服务端82的KafkaB以及健康检查中心HCC存储接收到的主KafkaA的信息。
服务端82的健康检查中心821检查服务端的每个业务集群(比如KafkaA和KafkaB)是否可用;如果所述健康检查中心821检查到至少两个业务集群(比如KafkaA和KafkaB)均可用,则为可用的所述至少两个业务集群标记集群优先级,比如,KafkaA的优先级为P1,KafkaB的优先级为P2,且P1>P2,其中,优先级的高低是按照约定规则或人为规定设定的。
之后,所述健康检查中心821获取每个业务集群记录的每个消费端的消费起点偏移值;根据所述消费起点偏移值设置每个消费终端的消费进度;并将所述消费进度同步给其余业务集群指定的zookeeper中。比如,健康检查中心821获取KafkaA记录的Consumer1的消费起点偏移值,并根据该消费起点偏移值设置Consumer1的消费进度,然后,将Consumer1的消费进度同步给KafkaB的zookeeperB中。
此外,健康检查中心HCC还检查服务端的每个业务集群是否可用,如果检查到有业务集群可用,则在可用的业务集群的指定zookeeper中的保留所述业务集群信息;如果检查到有业务集群不可用,则删除不可用所述业务集群的指定zookeeper中的所述业务集群信息。
消费端(比如Consumer1)监测服务端的至少两个业务集群(比如KafkaA和KafkaB)是否可用;如果监测到所述至少两个业务集群(比如KafkaA和KafkaB)均可用,则从健康检查中心821获取可用的至少两个业务集群(比如KafkaA和KafkaB)的集群优先级;然后选择集群优选级高的业务集群作为主业务集群;比如选择优先级高的KafkaA作为主业务集群。最后连接选择的所述主业务集群进行消费。
在开始消费后,所述消费端继续监测所述主业务集群是否可用;并在所述消费端监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;并计算消费端的消费起点偏移值;根据所述消费起点偏移值重新设置所述消费端的消费进度;最后按照重新设置的消费进度连接重新选择的所述主业务集群进行消费。
对于装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本发明所提供的上述方法和装置,进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (16)
1.一种异地多活的分布式消息的管理方法,其特征在于,包括:
健康检查中心检查服务端的每个业务集群是否可用;
如果所述健康检查中心检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。
2.根据权利要求1所述的方法,其特征在于,所述为可用的所述至少两个业务集群标记优先级具体包括:
所述健康检查中心按照预定规则标记可用的所述至少两个业务集群的集群优先级。
3.根据权利要求1或2所述的方法,其特征在于,所述健康检查中心检查服务端的每个业务集群是否可用,具体包括:
所述健康检查中心通过心脏跳动heart beat检查每个业务集群是否可用。
4.根据权利要求1或2所述的方法,其特征在于,还包括:
所述健康检查中心获取每个业务集群记录的每个消费端的消费起点偏移值;
所述健康检查中心根据所述消费起点偏移值设置每个消费终端的消费进度;
所述健康检查中心将所述消费进度同步给其余业务集群指定的zookeeper中。
5.一种异地多活的分布式消息的消费方法,其特征在于,包括:
消费端监测服务端的至少两个业务集群是否可用;
如果所述消费端监测到所述至少两个业务集群均可用,则从健康检查中心获取可用的至少两个业务集群的集群优先级;
所述消费端选择集群优选级高的业务集群作为主业务集群;
所述消费端连接选择的所述主业务集群进行消费。
6.根据权利要求5所述的方法,其特征在于,还包括:
在开始消费后,所述消费端继续监测所述主业务集群是否可用;
在所述消费端监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;
连接重新选择的所述主业务集群进行消费。
7.根据权利要求6所述的方法,其特征在于,还包括:
在连接重新选择的所述主业务集群进行消费前,计算消费端的消费起点偏移值;
根据所述消费起点偏移值重新设置所述消费端的消费进度;
按照重新设置的消费进度连接到重新选择的所述主业务集群进行消费。
8.根据权利要求7所述的方法,其特征在于,按照下述公式计算消费起点偏移值:
offset A=offset B-Lag-调整因子 offset A≤0,
其中,所述offsetA为业务集群A上一个主题topic消息的消费起点偏移值;
所述offsetB为业务集群B上所述topic目前的消费偏移值;
所述Lag为业务集群B上所述topic消息消费的滞后值;
所述调整因子为调整常量。
9.一种异地多活的分布式消息的管理装置,其特征在于,包括:
检查模块,用于检查服务端的至少两个业务集群的是否可用;
第一标记模块,用于所述检查模块检查到至少两个业务集群均可用,则为可用的所述至少两个业务集群标记集群优先级。
10.根据权利要求9所述的装置,其特征在于,
所述第一标记模块,具体用于在所述检查模块检查到至少两个业务集群均可用时,按照预定规则标记可用的所述至少两个业务集群的集群优先级。
11.根据权利要求9或10所述的装置,其特征在于,
所述检查模块,具体用于通过心脏跳动heart beat检查每个业务集群是否可用。
12.根据权利要求9或10所述的装置,其特征在于,还包括:
获取模块,用于获取每个业务集群记录每个消费端的消费起点偏移值;
设置模块,用于根据所述消费起点偏移值设置每个消费终端的消费进度;
同步模块,用于将所述消费进度同步给其余业务集群指定的zookeeper中。
13.一种异地多活的分布式消息的消费装置,其特征在于,包括:
监测模块,用于监测服务端的至少两个业务集群是否可用;
第一获取模块,用于在所述监测模块监测到所述至少两个业务集群均可用时,从健康检查中心获取可用的至少两个业务集群的集群优先级;
第一选择模块,用于选择集群优选级高的业务集群作为主业务集群;
第一消费模块,用于连接选择的所述主业务集群进行消费。
14.根据权利要求13所述的装置,其特征在于,还包括:第三选择模块和第三消费模块,其中,
所述监测模块,还用于在开始消费后,继续监测所述主业务集群是否可用;
所述第三选择模块,用于在所述检测模块监测到所述主业务集群不可用时,从获取的所述集群优先级中重新选择次集群优先级高的一个业务集群作为消费的主业务集群;
所述第三消费模块,用于连接重新选择的所述主业务集群进行消费。
15.根据权利要求14所述的装置,其特征在于,还包括:
计算模块,用于在所述第三消费模块进行消费前,计算消费端初始化的消费起点偏移值;
所述设置模块,还用于根据所述计算模块计算的消费起点偏移值重新设置所述消费端的消费进度;
第三消费模块,还用于按照重新设置的消费进度连接到重新选择的所述主业务集群进行消费。
16.根据权利要求15所述的装置,其特征在于,所述计算模块按照下述公式计算消费起点偏移值:
offset A=offset B-Lag-调整因子 offsetA≤0,
其中,所述offsetA为业务集群A上一个主题topic消息的消费起点偏移值;
所述offsetB为业务集群B上所述topic目前的消费偏移值;
所述Lag为业务集群B上所述topic消息消费的滞后值;
所述调整因子为调整常量。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711350875.4A CN108199912B (zh) | 2017-12-15 | 2017-12-15 | 一种异地多活的分布式消息的管理、消费方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711350875.4A CN108199912B (zh) | 2017-12-15 | 2017-12-15 | 一种异地多活的分布式消息的管理、消费方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108199912A true CN108199912A (zh) | 2018-06-22 |
CN108199912B CN108199912B (zh) | 2020-09-22 |
Family
ID=62574523
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201711350875.4A Active CN108199912B (zh) | 2017-12-15 | 2017-12-15 | 一种异地多活的分布式消息的管理、消费方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108199912B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109828826A (zh) * | 2019-01-10 | 2019-05-31 | 新华三云计算技术有限公司 | 一种任务进度的轮询方法、装置及系统 |
CN111726388A (zh) * | 2019-03-22 | 2020-09-29 | 苏宁易购集团股份有限公司 | 一种跨集群高可用的实现方法、装置、系统及设备 |
WO2020211364A1 (zh) * | 2019-04-16 | 2020-10-22 | 平安科技(深圳)有限公司 | 实现网关异地多活的方法、装置、计算机设备及存储介质 |
Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050289390A1 (en) * | 2004-06-29 | 2005-12-29 | Tsunehiko Baba | Failover method for a cluster computer system |
CN101945056A (zh) * | 2009-06-29 | 2011-01-12 | 软件Ag公司 | 基于策略的jms中间件群的系统和/或方法 |
CN102377686A (zh) * | 2010-08-10 | 2012-03-14 | 阿里巴巴集团控股有限公司 | 一种消息订阅系统、消息订阅方法及装置 |
CN102404390A (zh) * | 2011-11-07 | 2012-04-04 | 广东电网公司电力科学研究院 | 高速实时数据库的智能化动态负载均衡方法 |
CN103581307A (zh) * | 2013-10-17 | 2014-02-12 | 北京邮电大学 | 一种基于集群的发布/订阅系统及其可靠性保障方法 |
CN104023083A (zh) * | 2014-06-23 | 2014-09-03 | 广东睿江科技有限公司 | 日志收集集群负载均衡的方法及装置 |
CN105868033A (zh) * | 2016-04-06 | 2016-08-17 | 江苏物联网研究发展中心 | 基于Redis实现优先级消息队列的方法及系统 |
CN105897508A (zh) * | 2016-04-01 | 2016-08-24 | 锐捷网络股份有限公司 | 一种分布式数据中心业务处理的方法和核心交换机 |
CN106789741A (zh) * | 2016-12-26 | 2017-05-31 | 北京奇虎科技有限公司 | 消息队列的消费方法及装置 |
CN106844055A (zh) * | 2017-01-25 | 2017-06-13 | 北京百分点信息科技有限公司 | 一种任务的执行方法和装置 |
CN106933672A (zh) * | 2015-12-30 | 2017-07-07 | 阿里巴巴集团控股有限公司 | 一种分布式环境协调消费队列方法和装置 |
CN107111697A (zh) * | 2014-10-15 | 2017-08-29 | 艾拉物联公司 | 对于所连接的消费者设备的基于角色的访问控制 |
CN107463468A (zh) * | 2016-06-02 | 2017-12-12 | 北京京东尚科信息技术有限公司 | 缓存管理方法及其设备 |
CN107465735A (zh) * | 2017-07-31 | 2017-12-12 | 杭州多麦电子商务股份有限公司 | 分布式消息系统 |
-
2017
- 2017-12-15 CN CN201711350875.4A patent/CN108199912B/zh active Active
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050289390A1 (en) * | 2004-06-29 | 2005-12-29 | Tsunehiko Baba | Failover method for a cluster computer system |
CN101945056A (zh) * | 2009-06-29 | 2011-01-12 | 软件Ag公司 | 基于策略的jms中间件群的系统和/或方法 |
CN102377686A (zh) * | 2010-08-10 | 2012-03-14 | 阿里巴巴集团控股有限公司 | 一种消息订阅系统、消息订阅方法及装置 |
CN102404390A (zh) * | 2011-11-07 | 2012-04-04 | 广东电网公司电力科学研究院 | 高速实时数据库的智能化动态负载均衡方法 |
CN103581307A (zh) * | 2013-10-17 | 2014-02-12 | 北京邮电大学 | 一种基于集群的发布/订阅系统及其可靠性保障方法 |
CN104023083A (zh) * | 2014-06-23 | 2014-09-03 | 广东睿江科技有限公司 | 日志收集集群负载均衡的方法及装置 |
CN107111697A (zh) * | 2014-10-15 | 2017-08-29 | 艾拉物联公司 | 对于所连接的消费者设备的基于角色的访问控制 |
CN106933672A (zh) * | 2015-12-30 | 2017-07-07 | 阿里巴巴集团控股有限公司 | 一种分布式环境协调消费队列方法和装置 |
CN105897508A (zh) * | 2016-04-01 | 2016-08-24 | 锐捷网络股份有限公司 | 一种分布式数据中心业务处理的方法和核心交换机 |
CN105868033A (zh) * | 2016-04-06 | 2016-08-17 | 江苏物联网研究发展中心 | 基于Redis实现优先级消息队列的方法及系统 |
CN107463468A (zh) * | 2016-06-02 | 2017-12-12 | 北京京东尚科信息技术有限公司 | 缓存管理方法及其设备 |
CN106789741A (zh) * | 2016-12-26 | 2017-05-31 | 北京奇虎科技有限公司 | 消息队列的消费方法及装置 |
CN106844055A (zh) * | 2017-01-25 | 2017-06-13 | 北京百分点信息科技有限公司 | 一种任务的执行方法和装置 |
CN107465735A (zh) * | 2017-07-31 | 2017-12-12 | 杭州多麦电子商务股份有限公司 | 分布式消息系统 |
Non-Patent Citations (1)
Title |
---|
余浩维,: ""PaaS云中Web容器及调度的设计与实现"", 《中国优秀硕士学位论文全文数据库-信息科技辑》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109828826A (zh) * | 2019-01-10 | 2019-05-31 | 新华三云计算技术有限公司 | 一种任务进度的轮询方法、装置及系统 |
CN109828826B (zh) * | 2019-01-10 | 2021-11-09 | 新华三云计算技术有限公司 | 一种任务进度的轮询方法、装置及系统 |
CN111726388A (zh) * | 2019-03-22 | 2020-09-29 | 苏宁易购集团股份有限公司 | 一种跨集群高可用的实现方法、装置、系统及设备 |
WO2020211364A1 (zh) * | 2019-04-16 | 2020-10-22 | 平安科技(深圳)有限公司 | 实现网关异地多活的方法、装置、计算机设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN108199912B (zh) | 2020-09-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108322358A (zh) | 异地多活的分布式消息发送、处理、消费方法及装置 | |
CN108199912A (zh) | 一种异地多活的分布式消息的管理、消费方法及装置 | |
CN110213371A (zh) | 消息消费方法、装置、设备及计算机存储介质 | |
CN108469989A (zh) | 一种基于集群性能的反馈式自动扩缩容方法及系统 | |
CN107506213A (zh) | 动态配置方法、装置、存储介质和计算机设备 | |
CN103631873B (zh) | 一种数据压缩方法及存储系统 | |
CN108255592A (zh) | 一种Quartz集群定时任务处理系统及方法 | |
US20130212257A1 (en) | Computer program and monitoring apparatus | |
CN107612787A (zh) | 一种基于Openstack开源云平台的云主机故障检测方法 | |
CN103324715B (zh) | 一种灾备系统可用性检测方法及装置 | |
CN108540341A (zh) | 资源监控方法及装置 | |
CN108595316A (zh) | 分布式应用的生命周期管理方法、管理器、设备和介质 | |
CN105610947A (zh) | 一种高可用分布式队列服务实现方法、装置和系统 | |
CN106209943A (zh) | 通讯节点的选择方法及装置 | |
CN105527948B (zh) | 一种基于工业过程的大规模分布式数据采集系统及方法 | |
CN108062243A (zh) | 执行计划的生成方法、任务执行方法及装置 | |
US11902362B2 (en) | Topology-aware load balancing method and apparatus, and computer device | |
JP2004088779A (ja) | 異種の測定値群を整合させる方法及び装置 | |
CN106598700A (zh) | 基于pacemaker的虚拟机的秒级高可用实现方法 | |
CN108737573A (zh) | 一种分布式存储集群及其服务响应控制方法、装置和设备 | |
CN110333986A (zh) | 一种保障redis集群可用性的方法 | |
CN107423942A (zh) | 一种业务流转的方法及装置 | |
CN107682411A (zh) | 一种大规模sdn控制器集群及网络系统 | |
CN106506256A (zh) | 一种基于平台+插件的设备监控系统及方法 | |
CN109495543A (zh) | 一种ceph集群中监视器的管理方法及装置 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |