A MQTT subscriber service application cluster management method and system

By introducing resource monitoring module and scheduling center into the MQTT subscription service application cluster, dynamically schedule subscription connections, solving the problems of high availability and high stability in subscription service management, realizing load balancing and failure recovery, reducing costs and Management complexity.

CN114416339BActive Publication Date: 2024-12-24ZERO HOLE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202111518461.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-12-13
Publication Date
2024-12-24
Estimated Expiration
2041-12-13

AI Technical Summary

Technical Problem

In the prior art, the MQTT subscription service management method is difficult to ensure high availability and high stability, especially in the case of a large number of subscription service applications, and cannot effectively achieve dynamic fault tolerance, resulting in data exceptions and loss, and is connected across MQTT servers. It is costly and complex in management.

Method used

The subscription service application cluster management method is adopted, including resource monitoring module and scheduling center. By reporting performance data and flag data every once in a while, dynamically schedule subscription connections to deploy high-load connections to low-load servers to achieve load balancing and Failure recovery.

Benefits of technology

It realizes the high availability and stability of the MQTT subscription service application cluster, reduces costs, simplifies management, reduces data flow and server resource waste, and solves the problems of single point of failure and data exceptions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114416339B_ABST
    Figure CN114416339B_ABST
Patent Text Reader

Abstract

The present application provides a MQTT subscriber service application cluster management method and system, which relates to the field of cluster management technology. The system includes: a subscriber service application cluster, a resource monitoring module and a scheduling center; the subscriber service application cluster includes multiple subscriber service applications, and one subscriber service application is deployed on a server. The method includes: every first time period, each subscriber service application in the subscriber service application cluster reports performance data and flag data corresponding to the performance data to the resource monitoring module; the resource monitoring module performs structured processing on the performance data and flag data to obtain monitoring information of the subscriber service application cluster; the scheduling center dynamically schedules the subscriber connection of each subscriber service application in the subscriber service application cluster according to the monitoring information in the monitoring resource module; the present application can ensure the high availability and high stability of the subscriber service application cluster service and realize dynamic fault tolerance.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to, but is not limited to, the field of cluster management technology, and in particular to a method and system for managing an MQTT subscriber service application cluster. Background Art

[0002] MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol based on the Publish / Subscribe model. This protocol can provide real-time and reliable message services to remote devices with very little code and limited bandwidth, so it is widely used in the Internet of Things.

[0003] The application method is mainly that the device side connects to the MQTT service through the protocol, and then the device side, as the publisher of the message, publishes the real-time message to a special link topic, while the IoT platform connects to the MQTT service and subscribes to the corresponding topic to become the subscriber of the message.

[0004] Usually, the IoT platform will manage thousands of devices at the same time. Due to various business issues, the IoT platform needs to subscribe to a large number of different topics to achieve the business requirements of receiving data from different devices. Therefore, in order to achieve the integration of massive device data, an IoT platform must subscribe to a large number of topics. At the same time, various IoT platforms often connect to each other, so an IoT platform also needs to subscribe to topics of different MQTT servers to achieve device data connection.

[0005] In order to meet the above requirements, it is very important to do a good job in MQTT subscriber technology management in the construction of the Internet of Things platform.

[0006] In the prior art, many manufacturers usually manage MQTT subscribers by bridging data from the MQTT server to the MQ (Message Queue) service, and then processing the message data in the MQ consumer. However, bridging data services usually require service fees to achieve this, and many open source MQTT services do not support this function. When it is necessary to process services such as device data authentication, device data flow limiting, and data filtering, business processing can only be placed on the MQ consumer for processing. This approach will generate a large amount of garbage data streams on the MQ consumer. In many cloud servers, MQ messages are charged by the piece, which will also generate a lot of additional costs. Moreover, this method is not suitable for the need to connect data across MQTT servers on the IoT platform. When different IoT platforms need to be connected, data bridging cannot be done on the MQTT server. It is usually necessary to write a MQTT subscriber service to implement subscription and receive data, and then forward it to MQ in the subscription service. This method of writing an independent subscriber is usually difficult to manage and prone to single point failures, resulting in data anomalies and loss.

[0007] In view of this, it is necessary to improve the existing MQTT subscriber service application cluster management method to ensure the high availability and high stability of the overall subscriber service application cluster service in the case of a large number of subscriber service applications, and achieve dynamic fault tolerance. Summary of the invention

[0008] The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

[0009] The embodiments of the present application provide a method and system for managing an MQTT subscriber service application cluster to solve one or more technical problems existing in the prior art and at least provide a beneficial choice or create conditions.

[0010] In a first aspect, an embodiment of the present application provides an MQTT subscriber service application cluster management method, which is applied to an MQTT subscriber service application cluster management system, the system comprising: a subscriber service application cluster, a resource monitoring module, and a scheduling center;

[0011] The subscriber service application cluster includes multiple subscriber service applications, one subscriber service application is deployed on one server, and the subscriber service application provides a unified interface for creating and destroying subscriber connections;

[0012] The method includes but is not limited to the following steps:

[0013] Every first time period, each subscriber service application in the subscriber service application cluster reports performance data and flag data corresponding to the performance data to the resource monitoring module;

[0014] The performance data includes: the average subscription rate of each subscriber connection in the subscriber service application in the most recent first time period, and the average server load of the server where the subscriber service application is located in the most recent second time period; the mark data includes: server address and timestamp;

[0015] The resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription end service application cluster;

[0016] The scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval; wherein the load threshold interval is the threshold interval of the server load.

[0017] In some embodiments, the resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription-side service application cluster, including:

[0018] The resource monitoring module obtains the performance data and the mark data;

[0019] The resource monitoring module combines the records of subscriber connection and the average subscription rate into key-value pair elements, and uses the average subscription rate as a sorting condition to sort the key-value pair elements from large to small according to the average subscription rate to obtain an ordered queue;

[0020] The resource monitoring module stores the ordered queue in a subscription rate hash bucket, and uses each server address in the ordered queue as a key value of the subscription rate hash bucket.

[0021] In some embodiments, the scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval, including:

[0022] The dispatch center periodically traverses the reporting time mapping table in the resource monitoring module through a timing thread;

[0023] The reporting time mapping table is used to store the key value of the mapping table and the corresponding value corresponding to the key value of the mapping table, wherein the corresponding value is the last time of the performance data most recently reported by each server address; the key value of the reporting time mapping table is the server address of the subscription end service application;

[0024] If the timestamp corresponding to the server address in the reporting time mapping table is less than the current time minus m first time periods, the scheduling center determines that the subscription service application corresponding to the server address has crashed;

[0025] The scheduling center reads the average subscription rate corresponding to the downtime subscription service application from the subscription rate hash bucket;

[0026] The dispatch center sorts the average subscription rates corresponding to the downtime subscription service applications to form a subscription rate queue;

[0027] The dispatch center uses a uniform distribution algorithm to evenly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service application corresponding to the element in the interval load queue, so as to evenly distribute the load of the subscriber service application cluster.

[0028] In some embodiments, the resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription-side service application cluster, and further includes:

[0029] Step S221, when reporting performance data, if the load of the reported performance data is less than the interval load, execute step S222, otherwise execute step S225;

[0030] Step S222, remove the load element corresponding to the subscription service application from the interval load queue and add it to the pre-processing low load queue; wherein the pre-processing low load queue is used to store key-value pair load elements consisting of a server address and a timestamp, each key-value pair load element contains an attribute value NL, and the attribute value NL indicates the number of times the load element is continuously less than the interval load;

[0031] Step S223, if the load element in the pre-processed high load queue is smaller than the load interval once continuously, then the attribute value NL corresponding to the load element is increased by 1, otherwise the attribute value NL corresponding to the load element is reset to 0 and moved back to the interval load queue;

[0032] Step S224, determining whether the attribute value NL corresponding to the load element is greater than the abnormal load constant value, if so, marking the load element as a low-load scheduling element and moving it to a queue to be scheduled;

[0033] Step S225, remove the load element corresponding to the subscription service application from the interval load queue and add it to the pre-processing high load queue; wherein the pre-processing high load queue is used to store key-value pair load elements consisting of a server address and a timestamp, each key-value pair load element contains an attribute value NH, and the attribute value NH indicates the number of times the load element is continuously greater than the interval load;

[0034] Step S226, if the load element in the pre-processed high load queue is greater than the load interval once continuously, then the attribute value NH corresponding to the load element is increased by 1, otherwise the attribute value NH corresponding to the load element is reset to 0 and moved to the interval load queue;

[0035] Step S227, determine whether the attribute value NH corresponding to the load element is greater than the abnormal load constant value. If so, mark the load element as a high-load scheduling element and move it to the queue to be loaded and scheduled.

[0036] In some embodiments, the scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval, further comprising:

[0037] The dispatch center obtains elements from the load-pending dispatch queue in real time through a dispatch execution thread;

[0038] The queue to be loaded for scheduling stores low load scheduling elements and high load scheduling elements;

[0039] When the obtained element is a high-load scheduling element, the subscription rate queue where the subscriber service application corresponding to the server address is located is obtained from the subscription rate hash bucket according to the server address of the high-load element; it is determined whether the load average value in the interval load queue is greater than the interval load average threshold; if not, the subscriber connection with the highest rate in the subscription rate queue is scheduled to the subscriber service application corresponding to the load element with the lowest load in the interval load queue, completing a round of high-load scheduling; if so, a server is obtained from the service resource library and deployed as a subscriber service application, and then the subscriber connection with a larger rate in the subscription rate queue is scheduled to the new subscriber service application, completing a round of high-load scheduling;

[0040] When the obtained element is a low-load scheduling element, the subscription rate queue where the subscriber service application corresponding to the server address is located is obtained from the subscription rate hash bucket according to the server address of the low-load element; the scheduling center adopts a uniform distribution algorithm to evenly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, and closes the subscriber service application corresponding to the low-load scheduling element to put the server where the subscriber service application is located back into the service resources to complete a round of low-load scheduling.

[0041] In some embodiments, the scheduling center uses a uniform distribution algorithm to uniformly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, including:

[0042] Get the number of elements in the subscription rate queue S1 and the number of elements in the interval load queue S2;

[0043] Among them, the interval load queue is used to store the key-value pair load elements composed of the server address and the timestamp. The key-value pair load elements in the interval load queue are dynamically sorted according to the timestamp size. The head of the interval load queue stores the key-value pair load elements corresponding to the subscriber service application with the highest load in the subscriber service application cluster, and the tail of the interval load queue stores the key-value pair load elements corresponding to the subscriber service application with the lowest load in the subscriber service application cluster. The key-value pair load elements entering the interval load queue are all in the load threshold range:

[0044] Sort the elements in the subscription rate queue from large to small, and divide the elements in the subscription rate queue into piles from large to small; wherein, let the size of the pile be Ds, if S1 / S2=0, then Ds=S1 / S2, otherwise Ds=S1 / S2+1;

[0045] Take the first n elements, multiply them by Ds and divide them into n heaps;

[0046] The subscriber connections in the n heaps are deployed in sequence to the subscriber service applications in the interval load queue sorted from small to large load.

[0047] In a second aspect, an embodiment of the present application further provides an MQTT subscriber service application cluster management system, the system comprising: a subscriber service application cluster, a resource monitoring module, and a scheduling center;

[0048] The subscriber service application cluster includes multiple subscriber service applications, and one subscriber service application is deployed on one server;

[0049] The subscriber service application is used to report performance data and flag data to the resource monitoring module every first time period;

[0050] The performance data includes: the average subscription rate of each subscriber connection in the subscriber service application in the most recent first time period, and the average server load of the server where the subscriber service application is located in the most recent second time period; the mark data includes: server address and timestamp;

[0051] A resource monitoring module, used to process the performance data and the mark data to obtain monitoring information of the subscription end service application cluster;

[0052] The scheduling center is used to dynamically schedule the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval; wherein the load threshold interval is the threshold interval of the server load.

[0053] The embodiments of the present application include: regularly reporting subscriber performance data through the subscriber service, and dynamically scheduling the server where the subscriber service is located in combination with the server resources of the subscriber service application cluster, thereby ensuring high availability and high stability of the overall service in the case of a large number of subscriber service application clusters, and achieving dynamic fault tolerance.

[0054] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The accompanying drawings are used to provide further understanding of the technical solution of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the technical solution of the present application and do not constitute a limitation on the technical solution of the present application.

[0056] Figure 1 It is a flowchart of an MQTT subscriber service application cluster management method provided by an embodiment of the present application;

[0057] Figure 2 It is a structural diagram of an MQTT subscriber service application cluster management system provided by an embodiment of the present application;

[0058] Figure 3It is a schematic diagram of applying a subscription rate hash bucket in one embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0060] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification, claims or the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0061] First, some concepts involved in the embodiments provided in this application are defined below:

[0062] like Figure 1 and Figure 2 As shown, Figure 1 It is a flowchart of an MQTT subscriber service application cluster management method provided by an embodiment of the present application. The MQTT subscriber service application cluster management method is applied to an MQTT subscriber service application cluster management system, and the system includes: a subscriber service application cluster, a resource monitoring module, and a scheduling center;

[0063] The subscriber service application cluster includes multiple subscriber service applications, one subscriber service application is deployed on one server, and the subscriber service application provides a unified interface for creating and destroying subscriber connections;

[0064] The method includes but is not limited to the following steps:

[0065] Step S100: every first time period, each subscriber service application in the subscriber service application cluster reports performance data and flag data corresponding to the performance data to the resource monitoring module;

[0066] The performance data includes: the average subscription rate Vcn of each subscriber connection in the subscriber service application in the most recent first time period, and the average server load Lc of the server where the subscriber service application is located in the most recent second time period; the mark data includes: server address and timestamp;

[0067] Step S200, the resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription-side service application cluster;

[0068] In step S300, the scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval; wherein the load threshold interval is the threshold interval of the server load.

[0069] In the embodiments provided in the present application, the scheduling center schedules the subscriber connection according to the real-time dynamic load of the server. In some embodiments, the threshold interval of the server load can be pre-set or directly read; the subscriber performance data is reported periodically by the subscriber service, and the server where the subscriber service is located is dynamically scheduled in combination with the server resources of the subscriber service application cluster, thereby ensuring the high availability and high stability of the overall service in the case of a large number of subscriber service application clusters, and realizing dynamic fault tolerance.

[0070] In some embodiments, the subscriber service application cluster includes multiple subscriber service applications, and multiple subscriber connections can be created on one subscriber service application through Java multithreading technology. For ease of management, only one subscriber service application is deployed on one server, and the subscriber service application provides a unified interface for creating and destroying subscriber connections.

[0071] In one embodiment, the subscriber service application needs to report the average subscription rate Vcn of each subscriber connection within 5 seconds in the subscriber service application to the resource monitoring module every 5 seconds, and each subscriber connection record is a connection record Mcn; and the average server load timestamp Tc of the server where the subscriber service application is located within one minute needs to be reported to the resource monitoring module every 5 seconds. In order to distinguish the performance data reported by each subscriber service application, it is necessary to add the server address IP (for example, the server's LAN IP address) and timestamp Tc when reporting the performance data, so the monitoring information reported by the subscriber service application includes a mapping list of timestamp Tc, server address IP, average subscription rate Vcn and connection record Mcn.

[0072] The main responsibility of the resource monitoring module is to collect the performance data reported by the MQTT subscriber service application cluster every 5 seconds, and analyze and store this data as the basis for the dispatch center's scheduling. The resource monitoring module uses the data storage structure to assist the dispatch center in connecting the subscriber to the subscriber service application cluster for deployment and scheduling.

[0073] In the embodiment provided by the present application, the monitoring information is a data storage structure, including: an application subscription rate hash bucket, a reporting time mapping table, a preprocessing low load queue, a preprocessing high load queue, an interval load queue, and a queue to be loaded and scheduled, which is described in detail below.

[0074] refer to Figure 3 In one embodiment, step S200 includes but is not limited to the following steps:

[0075] Step S211, the resource monitoring module obtains the performance data and flag data;

[0076] Step S212, the records Mcn of subscriber connection and the average subscription rate Vcn are combined into a key-value pair element, and the average subscription rate Vcn is used as a sorting condition, and the key-value pair elements are sorted from large to small according to the average subscription rate Vcn to obtain an ordered queue;

[0077] Step S213: store the ordered queue in a subscription rate hash bucket, and use each server address in the ordered queue as a key value of the subscription rate hash bucket.

[0078] It should be noted that when the subscriber service application reports performance data, the performance data of the subscriber service application corresponding to the key value of the subscription rate hash bucket in the subscription rate hash bucket is updated.

[0079] In addition, in one embodiment, step S300 includes but is not limited to the following steps:

[0080] Step S311, the dispatch center periodically traverses the reporting time mapping table in the resource monitoring module through a timing thread;

[0081] The reporting time mapping table is used to store the key value of the mapping table and the corresponding value corresponding to the key value of the mapping table, wherein the corresponding value is the last time of the performance data most recently reported by each server address; the key value of the reporting time mapping table is the server address of the subscription end service application;

[0082] It should be noted that this embodiment provides a processing method for fault recovery scheduling; in the resource monitoring module, a reporting time mapping table is used to maintain the last reporting time of the performance data reported by the subscription-end service application, and in the scheduling center, a timing thread is used to periodically traverse the reporting time mapping table to monitor the working status of the subscription-end server.

[0083] Step S312: If the timestamp Tc corresponding to the server address IP in the reporting time mapping table is less than the current time minus m first time periods, the scheduling center determines that the subscription end service application corresponding to the server address IP has crashed;

[0084] It should be noted that the value of m depends on the actual situation. In one embodiment, m=5;

[0085] Step S313, the scheduling center reads the average subscription rate corresponding to the downtime subscription service application from the subscription rate hash bucket;

[0086] Step S314, the scheduling center sorts the average subscription rates corresponding to the downtime subscription service applications to form a subscription rate queue;

[0087] Step S315 , the scheduling center uses a uniform distribution algorithm to uniformly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, so as to uniformly distribute the load on the subscriber service application cluster.

[0088] In addition, in one embodiment, step S200 further includes but is not limited to the following steps:

[0089] Step S221, when reporting performance data, if the load of the reported performance data is less than the interval load, execute step S222, otherwise execute step S225;

[0090] Step S222, remove the load element corresponding to the subscription service application from the interval load queue and add it to the pre-processing low load queue; wherein the pre-processing low load queue is used to store the key-value pair load elements consisting of the server address IP and the timestamp Tc, each key-value pair load element contains an attribute value NL, and the attribute value NL indicates the number of times the load element is continuously less than the interval load;

[0091] Step S223, if the load element in the pre-processed high load queue is smaller than the load interval once continuously, then the attribute value NL corresponding to the load element is increased by 1, otherwise the attribute value NL corresponding to the load element is reset to 0 and moved back to the interval load queue;

[0092] Step S224, determining whether the attribute value NL corresponding to the load element is greater than the abnormal load constant value, if so, marking the load element as a low-load scheduling element and moving it to a queue to be scheduled;

[0093] This ensures that only the subscriber service applications corresponding to the load elements that have low load for a long time will be scheduled with low load;

[0094] Step S225, remove the load element corresponding to the subscription service application from the interval load queue and add it to the pre-processing high load queue; wherein the pre-processing high load queue is used to store the key-value pair load elements consisting of the server address IP and the timestamp Tc, each key-value pair load element contains an attribute value NH, and the attribute value NH indicates the number of times the load element is continuously greater than the interval load;

[0095] Step S226, if the load element in the pre-processed high load queue is greater than the load interval once continuously, then the attribute value NH corresponding to the load element is increased by 1, otherwise the attribute value NH corresponding to the load element is reset to 0 and moved to the interval load queue;

[0096] Step S227, determine whether the attribute value NH corresponding to the load element is greater than the abnormal load constant value. If so, mark the load element as a high-load scheduling element and move it to the queue to be loaded and scheduled.

[0097] This ensures that only the subscriber service applications corresponding to the load elements that have a high load for a long time will be scheduled under high load.

[0098] It should be noted that, in this embodiment, by defining an upper limit on the frequency of continuous low load or high load, if the frequency is exceeded, it is considered that the load is abnormal and scheduling is triggered; specifically, steps S222 to S224 execute a low-load scheduling method, the purpose of which is to destroy all subscriber-side connections in subscriber-side service applications with a load less than PL, and redeploy them in subscriber-side service applications that are in the load threshold interval and have sufficient resources, thereby releasing low-load server resources and saving server resources; steps S225 to S227 execute a high-load scheduling method, in the subscriber-side connection list of subscriber-side service applications with a load greater than PH, subscriber-side connections with higher subscription rates are destroyed and redeployed in subscriber-side service applications that are in the load threshold interval and have sufficient resources, thereby achieving load uniformity; wherein PL is the lower threshold of the load threshold interval, and PH is the high threshold of the load threshold interval.

[0099] In addition, in one embodiment, step S300 further includes but is not limited to the following steps:

[0100] Step S321, the scheduling center obtains elements from the load scheduling queue in real time through a scheduling execution thread;

[0101] The queue to be loaded for scheduling stores low load scheduling elements and high load scheduling elements;

[0102] Step S322, when the acquired element is a high-load scheduling element, the subscription rate queue where the subscriber service application corresponding to the server address IP is located is acquired from the subscription rate hash bucket according to the server address IP of the high-load element;

[0103] Step S323, determine whether the load average value in the interval load queue is greater than the interval load average threshold; if not, schedule the subscriber connection with the highest rate in the subscription rate queue to the subscriber service application corresponding to the load element with the lowest load in the interval load queue, completing a round of high load scheduling; if so, obtain a server from the service resource library and deploy it as a subscriber service application, and then schedule the subscriber connection with a larger rate in the subscription rate queue to the new subscriber service application, completing a round of high load scheduling;

[0104] The interval load average threshold is the average value of the thresholds at both ends of the load threshold interval, that is, (PL+PH) / 2;

[0105] In one embodiment, the subscriber end with a larger rate is a subscriber end connection that is in the top 50% after the rates in the subscription rate queue are sorted from large to small;

[0106] Step S324, when the acquired element is a low-load scheduling element, the subscription rate queue where the subscriber service application corresponding to the server address IP is located is acquired from the subscription rate hash bucket according to the server address IP of the low-load element;

[0107] In step S325, the scheduling center uses a uniform distribution algorithm to evenly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, and closes the subscriber service application corresponding to the low-load scheduling element to put the server where the subscriber service application is located back into the service resources, completing a round of low-load scheduling.

[0108] It should be noted that this embodiment provides a method for processing dynamic load scheduling; a scheduling execution thread will exist in the scheduling center to continuously obtain elements from the queue to be scheduled, and execute the method for dynamic load scheduling.

[0109] In addition, in one embodiment, the scheduling center uses a uniform distribution algorithm to uniformly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, including but not limited to the following steps:

[0110] Step S351, obtaining the number of elements S1 in the subscription rate queue and the number of elements S2 in the interval load queue;

[0111] Among them, the interval load queue is used to store the key-value pair load elements composed of the server address IP and the timestamp Tc. The key-value pair load elements in the interval load queue are dynamically sorted according to the size of the timestamp Tc. The head of the interval load queue stores the key-value pair load elements corresponding to the subscriber service application with the highest load in the subscriber service application cluster, and the tail of the interval load queue stores the key-value pair load elements corresponding to the subscriber service application with the lowest load in the subscriber service application cluster. The key-value pair load elements entering the interval load queue are all in the load threshold range:

[0112] It can be understood that the elements in the subscription rate queue refer to the subscriber service application, and the elements in the interval load queue refer to the key-value pair load elements.

[0113] Step S352, sorting the elements in the subscription rate queue from large to small, and dividing the elements in the subscription rate queue into a heap from large to small; wherein, assuming the size of the heap is Ds, if S1 / S2=0, then Ds=S1 / S2, otherwise Ds=S1 / S2+1;

[0114] Step S353, take the first n elements, multiply them by Ds respectively and divide them into n heaps;

[0115] Step S354, the subscriber connections in the n heaps are deployed in sequence to the subscriber service applications in the interval load queue sorted from small to large according to load.

[0116] Specifically, the subscriber service applications in the interval load queue are sorted from small to large according to the load, and the subscriber connections in the n piles are sequentially deployed to the subscriber service applications in the interval load queue. That is, the subscriber connection sorted in the first pile is correspondingly deployed to the subscriber service application with the smallest load in the interval load queue, and so on, the subscriber connections sorted in the subsequent piles are sequentially deployed to the subscriber service applications sorted from small to large according to the load in the interval load queue.

[0117] Please refer again Figure 2 , Figure 2 It is a structural diagram of an MQTT subscriber service application cluster management system provided by an embodiment of the present application, the system comprising: a subscriber service application cluster, a resource monitoring module, and a scheduling center;

[0118] The subscriber service application cluster includes multiple subscriber service applications, and one subscriber service application is deployed on one server;

[0119] The subscriber service application is used to report performance data and flag data to the resource monitoring module every first time period;

[0120] The performance data includes: the average subscription rate Vcn of each subscriber connection in the subscriber service application in the most recent first time period, and the average server load Lc of the server where the subscriber service application is located in the most recent second time period; the mark data includes: server address and timestamp;

[0121] A resource monitoring module, used to process the performance data and the mark data to obtain monitoring information of the subscription end service application cluster;

[0122] The scheduling center is used to dynamically schedule the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval; wherein the load threshold interval is the threshold interval of the server load.

[0123] In addition, in one embodiment, the system further comprises:

[0124] The resource server center is used to manage the server resources to be used in the subscription service application cluster, and is mainly used by the scheduling center. The server resources to be used in the subscription service application cluster are recorded in the form of a service resource library.

[0125] In addition, in one embodiment, the system further comprises:

[0126] The subscriber information management center is used to manage the basic information of all subscriber connections in the subscriber service application cluster. The scheduling center will redeploy the subscriber connection according to the specific information corresponding to the subscriber connection each time it is rescheduled. The connection record Mcn in the resource monitoring module is the unique identifier of each subscriber connection, and the corresponding specific subscriber connection information is mainly stored in the subscription information db. The specific subscriber connection information mainly includes the topic, MQTT server address IP, MQTT server port, subscriber connection client ID, subscriber connection account password, subscriber connection encryption method, and storage path of the subscriber connection authentication certificate. Therefore, the subscriber information management center mainly provides an interface for querying specific subscriber connection information based on the connection record Mcn. When deploying the subscriber connection, it is necessary to deploy it according to the query specific information.

[0127] Compared with the prior art, the embodiments provided in this application have the following technical effects:

[0128] 1. The technical solution provided in this application can realize access to massive device-side data across multiple MQTT services.

[0129] 2. While the technical solution provided by this application supports the access of massive devices, the subscription-side service application can filter device data according to business needs, reducing unnecessary data flow to MQ.

[0130] 3. Compared with the technical solution of bridging data to MQ on the MQTT server side, the technical solution provided by this application can achieve access to a large number of devices at a lower cost and more flexibly.

[0131] 4. The technical solution provided in this application realizes full utilization of server computing resources by dynamically scheduling subscriber connections based on server load, while also reducing waste of server resources through low-load scheduling.

[0132] 5. The technical solution provided in this application can realize fault recovery of subscriber connection and solve the problem of management difficulty of independent subscribers.

[0133] It will be appreciated by those skilled in the art that all or some of the steps and systems in the above-mentioned application methods can be implemented as software, firmware, hardware and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include a computer storage medium (or a non-transitory medium) and a communication medium (or a temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, disk storage or other magnetic storage device, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0134] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above-mentioned implementation mode. Technical personnel familiar with the field can also make various equivalent deformations or substitutions without violating the spirit of the present application. These equivalent deformations or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A method for managing an MQTT subscriber service application cluster, characterized in that: The MQTT subscriber service application cluster management method is applied to an MQTT subscriber service application cluster management system, the system comprising: a subscriber service application cluster, a resource monitoring module, and a scheduling center; The subscriber service application cluster includes multiple subscriber service applications, one subscriber service application is deployed on one server, and the subscriber service application provides a unified interface for creating and destroying subscriber connections; The method includes but is not limited to the following steps: Every first time period, each subscriber service application in the subscriber service application cluster reports performance data and flag data corresponding to the performance data to the resource monitoring module; The performance data includes: the average subscription rate of each subscriber connection in the subscriber service application in the most recent first time period, and the average server load of the server where the subscriber service application is located in the most recent second time period; the mark data includes: server address and timestamp; The resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription end service application cluster; The scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval; wherein the load threshold interval is the threshold interval of the server load.

2. The MQTT subscriber service application cluster management method according to claim 1, characterized in that: The resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription-side service application cluster, including: The resource monitoring module obtains the performance data and the mark data; The resource monitoring module combines the records of subscriber connection and the average subscription rate into key-value pair elements, and uses the average subscription rate as a sorting condition to sort the key-value pair elements from large to small according to the average subscription rate to obtain an ordered queue; The resource monitoring module stores the ordered queue in a subscription rate hash bucket, and uses each server address in the ordered queue as a key value of the subscription rate hash bucket.

3. The MQTT subscriber service application cluster management method according to claim 2, characterized in that: The scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval, including: The dispatch center periodically traverses the reporting time mapping table in the resource monitoring module through a timing thread; The reporting time mapping table is used to store the key value of the mapping table and the corresponding value corresponding to the key value of the mapping table, wherein the corresponding value is the last time of the performance data most recently reported by each server address; the key value of the reporting time mapping table is the server address of the subscription end service application; If the timestamp corresponding to the server address in the reporting time mapping table is less than the current time minus m first time periods, the scheduling center determines that the subscription service application corresponding to the server address has crashed; The scheduling center reads the average subscription rate corresponding to the downtime subscription service application from the subscription rate hash bucket; The dispatch center sorts the average subscription rates corresponding to the downtime subscription service applications to form a subscription rate queue; The dispatch center uses a uniform distribution algorithm to evenly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service application corresponding to the element in the interval load queue, so as to evenly distribute the load of the subscriber service application cluster.

4. The MQTT subscriber service application cluster management method according to claim 1, characterized in that: The resource monitoring module performs structured processing on the performance data and the mark data to obtain monitoring information of the subscription end service application cluster, and further includes: Step S221, when reporting performance data, if the load of the reported performance data is less than the interval load, execute step S222, otherwise execute step S225; Step S222, remove the load element corresponding to the subscription service application from the interval load queue and add it to the pre-processing low load queue; wherein the pre-processing low load queue is used to store key-value pair load elements consisting of a server address and a timestamp, each key-value pair load element contains an attribute value NL, and the attribute value NL indicates the number of times the load element is continuously less than the interval load; Step S223, if the load element in the pre-processed high load queue is smaller than the load interval once continuously, then the attribute value NL corresponding to the load element is increased by 1, otherwise the attribute value NL corresponding to the load element is reset to 0 and moved back to the interval load queue; Step S224, determining whether the attribute value NL corresponding to the load element is greater than the abnormal load constant value, if so, marking the load element as a low-load scheduling element and moving it to a queue to be scheduled; Step S225, remove the load element corresponding to the subscription service application from the interval load queue and add it to the pre-processing high load queue; wherein the pre-processing high load queue is used to store key-value pair load elements consisting of a server address and a timestamp, each key-value pair load element contains an attribute value NH, and the attribute value NH indicates the number of times the load element is continuously greater than the interval load; Step S226, if the load element in the pre-processed high load queue is greater than the load interval once continuously, then the attribute value NH corresponding to the load element is increased by 1, otherwise the attribute value NH corresponding to the load element is reset to 0 and moved to the interval load queue; Step S227, determine whether the attribute value NH corresponding to the load element is greater than the abnormal load constant value. If so, mark the load element as a high-load scheduling element and move it to the queue to be loaded and scheduled.

5. The MQTT subscriber service application cluster management method according to claim 4, characterized in that: The scheduling center dynamically schedules the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval, further comprising: The dispatch center obtains elements from the load-pending dispatch queue in real time through a dispatch execution thread; The queue to be loaded for scheduling stores low load scheduling elements and high load scheduling elements; When the obtained element is a high-load scheduling element, the subscription rate queue where the subscriber service application corresponding to the server address is located is obtained from the subscription rate hash bucket according to the server address of the high-load element; it is determined whether the load average value in the interval load queue is greater than the interval load average threshold; if not, the subscriber connection with the highest rate in the subscription rate queue is scheduled to the subscriber service application corresponding to the load element with the lowest load in the interval load queue, completing a round of high-load scheduling; if so, a server is obtained from the service resource library and deployed as a subscriber service application, and then the subscriber connection with a larger rate in the subscription rate queue is scheduled to the new subscriber service application, completing a round of high-load scheduling; When the obtained element is a low-load scheduling element, the subscription rate queue where the subscriber service application corresponding to the server address is located is obtained from the subscription rate hash bucket according to the server address of the low-load element; the scheduling center adopts a uniform distribution algorithm to evenly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, and closes the subscriber service application corresponding to the low-load scheduling element to put the server where the subscriber service application is located back into the service resources to complete a round of low-load scheduling.

6. The MQTT subscriber service application cluster management method according to claim 3 or 5, characterized in that: The scheduling center uses a uniform distribution algorithm to uniformly distribute all subscriber connections received by the subscriber service application in the subscription rate queue to the subscriber service applications corresponding to the elements in the interval load queue, including: Get the number of elements in the subscription rate queue S1 and the number of elements in the interval load queue S2; Among them, the interval load queue is used to store the key-value pair load elements composed of the server address and the timestamp. The key-value pair load elements in the interval load queue are dynamically sorted according to the timestamp size. The head of the interval load queue stores the key-value pair load elements corresponding to the subscriber service application with the highest load in the subscriber service application cluster, and the tail of the interval load queue stores the key-value pair load elements corresponding to the subscriber service application with the lowest load in the subscriber service application cluster. The key-value pair load elements entering the interval load queue are all in the load threshold range: Sort the elements in the subscription rate queue from large to small, and divide the elements in the subscription rate queue into piles from large to small; wherein, let the size of the pile be Ds, if S1 / S2=0, then Ds=S1 / S2, otherwise Ds=S1 / S2+1; Take the first n elements, multiply them by Ds and divide them into n heaps; The subscriber connections in the n heaps are deployed in sequence to the subscriber service applications in the interval load queue sorted from small to large load.

7. An MQTT subscriber service application cluster management system, characterized in that: The system includes: a subscription-side service application cluster, a resource monitoring module, and a scheduling center; The subscriber service application cluster includes multiple subscriber service applications, and one subscriber service application is deployed on one server; The subscriber service application is used to report performance data and flag data to the resource monitoring module every first time period; The performance data includes: the average subscription rate of each subscriber connection in the subscriber service application in the most recent first time period, and the average server load of the server where the subscriber service application is located in the most recent second time period; the mark data includes: server address and timestamp; A resource monitoring module, used to process the performance data and the mark data to obtain monitoring information of the subscription-side service application cluster; The scheduling center is used to dynamically schedule the subscriber-side connections of each subscriber-side service application in the subscriber-side service application cluster according to the monitoring information in the monitoring resource module, so as to deploy the subscriber-side connections with higher average subscription rates to the subscriber-side service applications corresponding to the servers in the lower load threshold interval, and deploy the subscriber-side connections with lower average subscription rates to the subscriber-side service applications corresponding to the servers in the higher load threshold interval; wherein the load threshold interval is the threshold interval of the server load.