CN108199912B - 一种异地多活的分布式消息的管理、消费方法及装置 - Google Patents

一种异地多活的分布式消息的管理、消费方法及装置 Download PDF

Info

Publication number
CN108199912B
CN108199912B CN201711350875.4A CN201711350875A CN108199912B CN 108199912 B CN108199912 B CN 108199912B CN 201711350875 A CN201711350875 A CN 201711350875A CN 108199912 B CN108199912 B CN 108199912B
Authority
CN
China
Prior art keywords
consumption
cluster
service
available
service cluster
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.)
Active
Application number
CN201711350875.4A
Other languages
English (en)
Other versions
CN108199912A (zh
Inventor
冯浩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing QIYI Century Science and Technology Co Ltd
Original Assignee
Beijing QIYI Century Science and Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing QIYI Century Science and Technology Co Ltd filed Critical Beijing QIYI Century Science and Technology Co Ltd
Priority to CN201711350875.4A priority Critical patent/CN108199912B/zh
Publication of CN108199912A publication Critical patent/CN108199912A/zh
Application granted granted Critical
Publication of CN108199912B publication Critical patent/CN108199912B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Telephonic Communication Services (AREA)
  • Medical Treatment And Welfare Office Work (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-调整因子，offset A≤0，
其中，所述offsetA为业务集群A上一个主题topic消息的消费起点偏移值；
所述offsetB为业务集群B上所述topic目前的消费偏移值；
所述Lag为业务集群B上所述topic消息消费的滞后值；
所述调整因子为调整常量。
CN201711350875.4A 2017-12-15 2017-12-15 一种异地多活的分布式消息的管理、消费方法及装置 Active CN108199912B (zh)

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 CN108199912A (zh) 2018-06-22
CN108199912B true 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)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109828826B (zh) * 2019-01-10 2021-11-09 新华三云计算技术有限公司 一种任务进度的轮询方法、装置及系统
CN111726388A (zh) * 2019-03-22 2020-09-29 苏宁易购集团股份有限公司 一种跨集群高可用的实现方法、装置、系统及设备
CN110177007B (zh) * 2019-04-16 2022-03-18 平安科技（深圳）有限公司 实现网关异地多活的方法、装置、计算机设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101945056A (zh) * 2009-06-29 2011-01-12 软件Ag公司 基于策略的jms中间件群的系统和/或方法
CN102377686A (zh) * 2010-08-10 2012-03-14 阿里巴巴集团控股有限公司 一种消息订阅系统、消息订阅方法及装置
CN103581307A (zh) * 2013-10-17 2014-02-12 北京邮电大学 一种基于集群的发布/订阅系统及其可靠性保障方法
CN105897508A (zh) * 2016-04-01 2016-08-24 锐捷网络股份有限公司 一种分布式数据中心业务处理的方法和核心交换机

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4353005B2 (ja) * 2004-06-29 2009-10-28 株式会社日立製作所 クラスタ構成コンピュータシステムの系切替方法
CN102404390B (zh) * 2011-11-07 2013-11-27 广东电网公司电力科学研究院 高速实时数据库的智能化动态负载均衡方法
CN104023083B (zh) * 2014-06-23 2017-12-12 广东睿江云计算股份有限公司 日志收集集群负载均衡的方法及装置
US9473504B2 (en) * 2014-10-15 2016-10-18 Ayla Networks, Inc. Role based access control for connected consumer devices
CN106933672B (zh) * 2015-12-30 2021-04-13 阿里巴巴集团控股有限公司 一种分布式环境协调消费队列方法和装置
CN105868033A (zh) * 2016-04-06 2016-08-17 江苏物联网研究发展中心 基于Redis实现优先级消息队列的方法及系统
CN107463468A (zh) * 2016-06-02 2017-12-12 北京京东尚科信息技术有限公司 缓存管理方法及其设备
CN106789741B (zh) * 2016-12-26 2020-02-18 北京奇虎科技有限公司 消息队列的消费方法及装置
CN106844055B (zh) * 2017-01-25 2020-02-28 北京百分点信息科技有限公司 一种任务的执行方法和装置
CN107465735B (zh) * 2017-07-31 2020-08-14 杭州多麦电子商务股份有限公司 分布式消息系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101945056A (zh) * 2009-06-29 2011-01-12 软件Ag公司 基于策略的jms中间件群的系统和/或方法
CN102377686A (zh) * 2010-08-10 2012-03-14 阿里巴巴集团控股有限公司 一种消息订阅系统、消息订阅方法及装置
CN103581307A (zh) * 2013-10-17 2014-02-12 北京邮电大学 一种基于集群的发布/订阅系统及其可靠性保障方法
CN105897508A (zh) * 2016-04-01 2016-08-24 锐捷网络股份有限公司 一种分布式数据中心业务处理的方法和核心交换机

Also Published As

Publication number Publication date
CN108199912A (zh) 2018-06-22

Similar Documents

Publication Publication Date Title
CN108322358B (zh) 异地多活的分布式消息发送、处理、消费方法及装置
CN108199912B (zh) 一种异地多活的分布式消息的管理、消费方法及装置
US8880927B2 (en) Time synchronization method and system for multicore system
CN103581276B (zh) 集群管理装置、系统、业务客户端及相应方法
CN105703940A (zh) 一种面向多级调度分布式并行计算的监控系统及监控方法
CN113704354B (zh) 一种数据同步方法及装置、计算机设备、存储介质
CN105471960A (zh) 一种私有云与公有云的信息交互系统及方法
CN112333249B (zh) 一种业务服务系统及方法
CN103780615B (zh) 一种在多个服务器间客户端会话数据共享方法
CN102984501A (zh) 一种网络视频录像集群系统
CN109173270B (zh) 一种游戏服务系统和实现方法
US20150317371A1 (en) Method, device, and system for peer-to-peer data replication and method, device, and system for master node switching
CN109921942B (zh) 云平台切换控制方法、装置、系统及电子设备
CN108228393A (zh) 一种可扩展的大数据高可用的实现方法
CN103780497A (zh) 一种云平台下可扩展的分布式协调服务管理方法
CN108063832B (zh) 一种云存储系统及其存储方法
CN112631764A (zh) 任务调度方法、装置、计算机设备和计算机可读介质
CN111726388A (zh) 一种跨集群高可用的实现方法、装置、系统及设备
CN108170527B (zh) 一种异地多活的分布式消息消费方法及装置
CN111262892A (zh) 一种多ros的服务发现系统
CN110324564A (zh) 一种视频会议数据同步方法及装置
JP2009086741A (ja) 異種ノード混在の分散環境における分散処理制御方法、そのシステム及びそのプログラム
CN113765690A (zh) 集群切换方法、系统、装置、终端、服务器及存储介质
CN109005246B (zh) 一种数据的同步方法、装置及系统
CN104079663A (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
GR01 Patent grant
GR01 Patent grant