CN113452800B - Method for realizing load balance based on multiple Broker in MQTT protocol - Google Patents
Method for realizing load balance based on multiple Broker in MQTT protocol Download PDFInfo
- Publication number
- CN113452800B CN113452800B CN202111008831.XA CN202111008831A CN113452800B CN 113452800 B CN113452800 B CN 113452800B CN 202111008831 A CN202111008831 A CN 202111008831A CN 113452800 B CN113452800 B CN 113452800B
- Authority
- CN
- China
- Prior art keywords
- broker
- broker server
- request
- service
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- 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
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a method for realizing load balancing based on multiple Broker of MQTT protocol, which comprises the following steps: the equipment acquires the information of the gateway service and requests the gateway service; forwarding the request to the business service through the gateway service; the business service acquires and assembles all Broker information lists into keys, and judges parameter values forwarded by the gateway service; the business service acquires the equipment connection number corresponding to each Broker; the service acquires information of the Broker according to a load balancing algorithm; returning the information of the Broker to the equipment; the equipment sends a connect request to the Broker; assembling information of the Broker into a key; performing a self-increment operation on the redis; the Broker assembles the packet information and returns it to the device and maintains a heartbeat with the device. The invention can dynamically switch the Broker connected with the equipment without upgrading the equipment, and the connection number of the equipment is controllable.
Description
Technical Field
The invention relates to the technical field of communication, in particular to a method for realizing load balancing based on multiple Broker in an MQTT protocol.
Background
The MQTT protocol is used in smart devices to enable the devices to maintain long connections after establishing a connection with the Broker server (i.e., heartbeat detection mechanism). Most of the existing processing schemes are to generate certificate information (which may also be referred to as a certificate file, and includes a domain name or an IP address of a Broker server) for a device, and burn the certificate information into the device, at this time, the address of the Broker server is burned into the device, and the device acquires the address of the Broker server through the burned domain name or IP, so that the device establishes a connect connection with the Broker server through an MQTT protocol. This treatment solution has the following problems: firstly, the burning of the common certificate is the same domain name or IP, which causes the problem that a great deal of subsequent equipment is connected to the same Broker server and is possibly down; secondly, even if different domain names or different IPs are used, a certain device is connected to a fixed Broker server, if the Broker server is down, the device cannot be connected to the Broker server, the device needs to be upgraded and connected to a new Broker address, on one hand, connection of the device is affected, the device needs to perform a large amount of upgrading operations, and cannot restore the device to a normal state in time, on the other hand, the number of Broker connections is affected by the device certificate and the number of devices, and the number of the Broker servers may be uncontrollable, so that the number of devices connected to the Broker server is not easily controlled. Therefore, aiming at the technical design defects, it is necessary to provide a method for realizing load balancing based on multiple brokers in MQTT protocol, so as to solve the problem that the expansion of the number of devices does not affect the situation that the connection number of the Broker servers has a peak value, and ensure that burning of the device certificate does not limit a certain Broker server with fixed device connection, thereby solving the problem that the device cannot be connected due to the breakdown of a certain Broker server.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provides a method for realizing load balancing based on multiple Broker in an MQTT protocol.
The technical scheme of the invention is as follows:
a method for realizing load balancing based on multiple Broker in MQTT protocol comprises the following steps:
s1, the device obtains the configuration information of gateway service by reading the certificate information of the device itself, and initiates a request carrying the configuration information of the Broker server connected with the device last time to the gateway service according to the obtained configuration information;
s2, after the gateway service receives the request sent by the device, the gateway service forwards the request to the service through the route rule configured by the gateway service;
s3, after receiving the request forwarded by the gateway service, the service reads the configuration file to obtain the configuration information lists of all Broker servers, assembles the configuration information lists of each Broker server into a redis key, and determines, according to the parameter value in the request forwarded by the gateway service, that:
a. if the parameter value in the request forwarded by the gateway service is empty, continuing to execute step S4;
b. if the parameter value in the request forwarded by the gateway service is not null, assembling the request parameter received by the service and forwarded by the gateway service into a key of redis, and performing a self-decreasing operation on the value of the key assembled by the request parameter into the redis through the redis;
s4, the service acquires the device connection number corresponding to each Broker server from the redis according to the key assembled by the configuration information list of each Broker server in the step S3;
s5, after acquiring the device connection number of each Broker server from the redis, the service acquires the detailed information of the Broker servers according to the load balancing algorithm set in the configuration;
s6, returning the detailed information of the Broker server acquired in the step S5 to the equipment sending the request through the network;
s7, after acquiring the detailed information of the Broker server, the equipment creates an MQTT client, creates and executes a connect connection message by using the acquired detailed information of the Broker server, and sends a connect request to the Broker server where the acquired detailed information of the Broker server is located;
s8, after the Broker server receives the connect request of the equipment, the Broker server acquires the configuration information of the Broker server from the configuration file, and assembles the acquired configuration information into a key of redis;
s9, the redis performs a self-increment operation on the value according to the current key;
s10, after the step S9 is completed, the Broker server assembles the data packet information which needs to be returned;
and S11, the Broker server returns the data packet information to the equipment, the successful connection of the equipment is fed back, the configuration information of the Broker server is locally stored in the equipment, and the follow-up equipment keeps heartbeat with the current Broker server.
Further, the specific implementation manner of step S1 is: the device obtains the configuration information of the gateway service from the certificate information of the device in a mode of reading file streams, and initiates a request carrying the configuration information of the Broker server connected with the device last time to the gateway service according to the obtained configuration information of the gateway service.
Further, the routing rule of step S2 performs mapping configuration through the request path; and after receiving the request, the gateway service performs mapping through a RequestMapping path.
Further, the configuration information recorded in the configuration information list of each Broker server in step S3 includes an IP/domain name and a port of each Broker server, and the IP/domain name of each Broker server corresponds to a key value.
Further, the specific implementation manner of the step S5 of acquiring the detailed information of the Broker server through the load balancing algorithm includes:
a. if the load balancing algorithm adopts a random algorithm, the business service randomly generates Broker server node information from the configuration information lists of all Broker servers by using random numbers according to the configuration information lists of all Broker servers obtained from the current configuration;
b. if the load balancing algorithm adopts a polling algorithm, the business service marks the configuration information list of each Broker server as different characters according to the configuration information lists of all the Broker servers acquired from the current configuration, acquires the value of a key from redis according to the specially-assigned key, and compares the value with the configuration information lists marked as different characters of the Broker servers to acquire node information of the Broker servers.
Further, the specific implementation b further acquires a configuration information list of the Broker server from the configuration, acquires a value of a key from redis according to the specific key2, and acquires the polled Broker server node information by comparing the value with the configuration list.
Further, the specific implementation manner of step S6 is to forward a request to invoke a service through the gateway service according to a routing rule, acquire the detailed information of the Broker server through the load balancing algorithm of step S5, and return the detailed information to the gateway service, where the gateway service returns the received detailed information of the Broker server to the device sending the request through the network.
Further, the certificate information of the device includes a gateway address and a port;
the request initiated by the device to the gateway service is an http or https request.
By adopting the scheme, the invention has the following beneficial effects:
1. before the connection of the MQTT connect, http or https is adopted to request the address of a dynamic Broker server, so that the mode is more flexible, the expansion of the Broker server is facilitated, the Broker server connected with the equipment can be dynamically switched without upgrading the equipment, and the equipment can be timely recovered to a normal state;
2. the address of the Broker server for establishing connection is not determined by the equipment and the certificate any more, but the initiative of the connection is given to the server, the Broker server connected with the equipment is determined by the balance algorithm and the scheme of the server, and the equipment connection number of the Broker server is controllable;
3. the method is beneficial to the expansion of the example of the Broker, the Broker is expanded in the later period, only the Broker example needs to be added and the Broker server needs to be added to the business service, the configuration is read through the business service, the problem of the Broker example expansion can be solved by combining the balance algorithm configured by the business service, the expansion is more flexible, the equipment connection number of the Broker server is controllable, and the balance algorithm can be variously customized according to the requirement.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the structures shown in the drawings without creative efforts.
FIG. 1 is a flowchart illustrating steps of a method for implementing load balancing based on multiple Broker in MQTT protocol according to the present invention;
FIG. 2 is a timing diagram of the MQTT connection established by the device in the method for realizing load balancing based on multiple Broker in the MQTT protocol according to the invention;
fig. 3 is a flowchart of a device connection in the method for implementing load balancing based on multiple brokers in MQTT protocol according to the present invention.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
The invention is described in detail below with reference to the figures and the specific embodiments.
Referring to fig. 1 to 3, the present invention provides a method for implementing load balancing based on multiple brokers in MQTT protocol, including the following steps:
s1, the device obtains the configuration information of the gateway service by reading the certificate information of the device, and initiates an http or https request to the gateway service according to the obtained configuration information, wherein the request carries the configuration information of the Broker server connected with the device last time, and is used for obtaining the IP/address and port of the Broker server required by the MQTT client and recalculating the device connection number of the Broker server; specifically, the specific implementation manner of step S1 is: when the device is powered on and connected with WiFi, the device is equivalent to a microcomputer, and as the device is burned with a gateway address, an IP/domain name and a port which contain the mac address of the device, the gateway address of the device registered to a platform before the device leaves a factory, therefore, the device obtains the gateway address and the port of the gateway service from the certificate information burnt in the device (namely the certificate information of the device) by reading the file stream, namely, the certificate information of the device comprises a gateway address and a port, and initiates an http or https request carrying configuration information of a Broker server connected with the device last time to the gateway service according to the acquired gateway address and port, this request may be referred to as a pre-check request to establish a connect connection for an MQTT client, thereby obtaining the IP/address and the port of the Broker server required by the MQTT client, and recalculating the device connection number of the Broker server;
s2, after the gateway service receives the request sent by the device, the gateway service forwards the request to the service through the route rule configured by the gateway service, so that the service reads the configuration file to obtain the configuration information list of all the Broker servers; the routing rule in step S2 performs mapping configuration through the request path, and after receiving the request, the gateway service performs mapping through the RequestMapping path, for example: if the request path contains "/user", the gateway service requests the A service in the cloud service, and if the request path contains "/file", the gateway service requests the B service in the cloud service; specifically, one implementation code for configuring the routing rule is as follows:
spring:
application:
name: gateway
profiles:
active: dev
cloud:
gateway:
routes:
- id: first_route
uri: http://172.16.3.1:8899
predicates:
-Path =/user/. star// request address with user, request 172.16.3.1 server
filters:
- name: Hystrix
args:
name: default
fallbackUri: forward:/fallback
- id: second_route
uri: http://172.16.3.2:8888
predicates:
-Path =/file/. x// file in request address, request 172.16.3.2 server
filters:
# blown configuration
- name: Hystrix
args:
name: hystrix1
fallbackUri: forward:/fallback
；
S3, after receiving the request forwarded by the gateway service, the service reads the configuration file to obtain the configuration information lists of all the Broker servers, assembles the configuration information lists of each Broker server into a redis key, and judges according to the parameter values in the request forwarded by the gateway service:
a. if the parameter value in the request forwarded by the gateway service is null, which indicates that the device has not been connected before, i.e. the device is a new device, then the step S4 is continuously executed;
b. if the parameter value in the request forwarded by the gateway service is not null, which indicates that the device has previously performed connection, assembling the request parameter forwarded by the gateway service received by the service into a key1 of redis (which is a key of redis), and performing a self-subtraction operation on the value of the key1 through redis;
specifically, the configuration information recorded in the configuration information list of each Broker server in step S3 includes the IP/domain name and the port of each Broker server, and the configuration information list of all Broker servers is approximately: { [ "IP": "172.16.1.0", "port": "22" ] }, { [ "IP": "172.16.1.1", "port": "22" ] }; the IP/domain name of each Broker server corresponds to a key value;
s4, the service acquires the device connection number corresponding to each Broker server from the cache of redis according to the key assembled by the configuration information list of each Broker server in the step S3, and returns the device connection number of each Broker server to the service;
s5, after acquiring the device connection number of each Broker server from the redis, the service acquires the detailed information of the Broker servers according to the load balancing algorithm set in the configuration; specifically, the detailed specific implementation manner for acquiring the Broker server through the load balancing algorithm includes:
a. if the load balancing algorithm adopts a random algorithm, the business service randomly generates Broker server node information from the configuration information lists of all Broker servers by using random numbers according to the configuration information lists of all Broker servers obtained from the current configuration; specifically, an implementation code of random numbers is as follows:
Random random = new Random();
List<String> list = Lists.newArrayList();
add ("172.16.1.0"),/random elements
Add ("172.16.1.1"),/random elements
int index = random.nextInt(list.size());
String ip = list.get (index)// result obtained by stochastic algorithm
；
b. If the load balancing algorithm adopts a polling algorithm, the business service acquires configuration information lists { [ "IP": "172.16.1.0", "port": "22" ] }, { [ "IP": "172.16.1.1", "port": "22" ] } labels the configuration information lists as 0 and 1, respectively, i.e. configuration information list { [ "IP": "172.16.1.0", "port": "22" ] } is marked 0, and the configuration information list { [ "IP": "172.16.1.1", "port": "22" ] } is marked as 1, and a value of a specially-designated key (here, the key2 represents the specially-designated value) is obtained from a cache of the redis, the key2 is only used for obtaining which Broker server is currently polled, that is, when a polling algorithm is used by the load balancing algorithm, the service respectively marks the configuration information list of each Broker server as different characters, for example, by using numbers, according to the configuration information lists of all Broker servers currently obtained from the configuration, and obtains a value of key2 corresponding to the Broker server currently polled by the polling algorithm from the cache of the redis, and obtains a Broker server node information by comparing the value with the configuration information lists marked as different characters of the Broker servers and calculating a mapping relationship; for example: if the value of key2 is 0, return [ "IP": "172.16.1.1", "port": the Broker server node information of "22" ], that is, the Broker server node information of the Broker server corresponding to the configuration information list marked as 1 is returned, and the value of key2 of redis is set to 1; if the value of key2 is 1, return [ "IP": "172.16.1.0", "port": the Broker server node information of "22" ], that is, the Broker server node information of the Broker server corresponding to the configuration information list marked as 0 is returned, and the value of key2 of redis is set to 0;
s6, returning the detailed information of the Broker server acquired in the step S5 to the equipment terminal; the specific implementation manner of step S6 is to forward a request to call a service through the gateway service according to a routing rule, acquire the detailed information of the Broker server through the load balancing algorithm in step S5, and return the detailed information to the gateway service, where the gateway service returns the received detailed information of the Broker server to the device (i.e., the device terminal) sending the request through the network after receiving the detailed information of the Broker server;
s7, after acquiring the detailed information of the Broker server (i.e. the node information of the Broker server), the device creates an MQTT client, creates and executes a connect connection message by using the acquired detailed information of the Broker server, and sends a connect request to the Broker server where the acquired configuration information of the Broker server is; specifically, an implementation code for creating the MQTT client is as follows:
@Configuration
public class MqttConfig {
private static final Logger LOGGER = LoggerFactory.getLogger(MqttConfig.class);
public static final CHANNEL RECV = "recvMsgchannel"// CHANNEL of subscription message
public static final CHANNEL _ SEND = "sendMsgchannel"// CHANNEL on which message is issued
public static final String TOPIC = "topic";
/**
Obtaining configuration file information
**/
@Value("${mqtt.username}")
private String username;
@Value("${mqtt.password}")
private String password;
@Value("${mqtt.url}")
private String url;
@Value("${mqtt.send.clientId}")
private String senderClientId;
@Value("${mqtt.recv.clientId}")
private String recverClientId;
Connector of// MQTT client
@Bean
public MqttConnectOptions getMqttConnectOptions() {
MqttConnectOptions options = new MqttConnectOptions();
// whether session is cleared. false: the server will keep the connection record of the client, true: each time the server is connected with a new identity
options.setCleanSession(true);
options, setUserName (username);/connecting users
setPressword (password)
options & setServerURIs (url.split (","));/connected server urls
Setconnectiontimeout (10);// timeout (unit: s)
options, setkeepaliviterval (20);// keep alive heartbeat (unit: s), this method has no reconnection mechanism
return options;
}
// construct MQTT client
@Bean
public MqttPahoClientFactory mqttClientFactory() {
DefaultMqttPahoClientFactory factory = new DefaultMqttPahoClientFactory();
factory.setConnectionOptions(getMqttConnectOptions());
return factory;
}
// MQTT producer client
@Bean
@ServiceActivator(inputChannel = CHANNEL_SEND)
public MessageHandler mqttMsgSend() {
MqttPahoMessageHandler messageHandler = new MqttPahoMessageHandler(senderClientId, mqttClientFactory());
messageHandler.setAsync(true);
return messageHandler;
}
}
；
S8, after the Broker server receives the connect request of the device, the Broker server acquires the configuration information of the Broker server from the configuration file, and assembles the acquired configuration information (namely the configuration information of the Broker server) into a key of redis;
s9, the redis performs a self-increment operation on the value according to the current key, and at the moment, the device connection number of the Broker server is increased by one; specifically, the autonomic operation of redis is atomic;
s10, after the step S9 is completed, the Broker server assembles the data packet information which needs to be returned;
and S11, the Broker server returns the data packet information to the equipment, the successful connection of the equipment is fed back, the configuration information of the Broker server is locally stored in the equipment, and the follow-up equipment keeps heartbeat with the current Broker server.
Compared with the prior art, the invention has the following beneficial effects:
1. before the connection of the MQTT connect, http or https is adopted to request the address of a dynamic Broker server, so that the mode is more flexible, the expansion of the Broker server is facilitated, the Broker server connected with the equipment can be dynamically switched without upgrading the equipment, and the equipment can be timely recovered to a normal state;
2. the address of the Broker server for establishing connection is not determined by the equipment and the certificate any more, but the initiative of the connection is given to the server, the Broker server connected with the equipment is determined by the balance algorithm and the scheme of the server, and the equipment connection number of the Broker server is controllable;
3. the method is beneficial to the expansion of the example of the Broker, the Broker is expanded in the later period, only the Broker example needs to be added and the Broker server needs to be added to the business service, the configuration is read through the business service, the problem of the Broker example expansion can be solved by combining the balance algorithm configured by the business service, the expansion is more flexible, the equipment connection number of the Broker server is controllable, and the balance algorithm can be variously customized according to the requirement.
The present invention is not limited to the above preferred embodiments, and any modifications, equivalent substitutions and improvements made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (8)
1. A method for realizing load balancing based on multiple Broker in MQTT protocol is characterized by comprising the following steps:
s1, the device obtains the configuration information of gateway service by reading the certificate information of the device itself, and initiates a request carrying the configuration information of the Broker server connected with the device last time to the gateway service according to the obtained configuration information;
s2, after the gateway service receives the request sent by the device, the gateway service forwards the request to the service through the route rule configured by the gateway service;
s3, after receiving the request forwarded by the gateway service, the service reads the configuration file to obtain the configuration information lists of all Broker servers, assembles the configuration information lists of each Broker server into a redis key, and determines, according to the parameter value in the request forwarded by the gateway service, that:
a. if the parameter value in the request forwarded by the gateway service is empty, continuing to execute step S4;
b. if the parameter value in the request forwarded by the gateway service is not null, assembling the request parameter received by the service and forwarded by the gateway service into a key of redis, and performing a self-decreasing operation on the value of the key assembled by the request parameter into the redis through the redis;
s4, the service acquires the device connection number corresponding to each Broker server from the redis according to the key assembled by the configuration information list of each Broker server in the step S3;
s5, after acquiring the device connection number of each Broker server from the redis, the service acquires the detailed information of the Broker servers according to the load balancing algorithm set in the configuration;
s6, returning the detailed information of the Broker server acquired in the step S5 to the equipment sending the request;
s7, after acquiring the detailed information of the Broker server, the equipment creates an MQTT client, creates and executes a connect connection message by using the acquired detailed information of the Broker server, and sends a connect request to the Broker server where the acquired detailed information of the Broker server is located;
s8, after the Broker server receives the connect request of the equipment, the Broker server acquires the configuration information of the Broker server from the configuration file, and assembles the acquired configuration information into a key of redis;
s9, the redis performs a self-increment operation on the value according to the current key;
s10, after the step S9 is completed, the Broker server assembles the data packet information which needs to be returned;
and S11, the Broker server returns the data packet information to the equipment, the successful connection of the equipment is fed back, the configuration information of the Broker server is locally stored in the equipment, and the follow-up equipment keeps heartbeat with the current Broker server.
2. The method for realizing load balancing based on multiple brokers of MQTT protocol according to claim 1, wherein the step S1 is specifically implemented by: the device obtains the configuration information of the gateway service from the certificate information of the device in a mode of reading file streams, and initiates a request carrying the configuration information of the Broker server connected with the device last time to the gateway service according to the obtained configuration information of the gateway service.
3. The method for implementing load balancing based on multiple brokers in MQTT protocol according to claim 1, wherein the routing rule of step S2 is configured by mapping through a request path; and after receiving the request, the gateway service performs mapping through a RequestMapping path.
4. The method of claim 1, wherein the configuration information recorded in the configuration information list of each Broker server in step S3 includes an IP/domain name and a port of each Broker server, and the IP/domain name of each Broker server corresponds to a key value.
5. The method for realizing load balancing based on multiple Broker according to MQTT protocol of claim 1, wherein the specific implementation manner of the step S5 for obtaining detailed information of the Broker server through the load balancing algorithm includes:
a. if the load balancing algorithm adopts a random algorithm, the business service randomly generates Broker server node information from the configuration information lists of all Broker servers by using random numbers according to the configuration information lists of all Broker servers obtained from the current configuration;
b. if the load balancing algorithm adopts a polling algorithm, the business service marks the configuration information list of each Broker server as different characters according to the configuration information lists of all the Broker servers acquired from the current configuration, acquires the value of a key from redis according to the specially-assigned key, and compares the value with the configuration information lists marked as different characters of the Broker servers to acquire node information of the Broker servers.
6. The method of claim 5, wherein the specific implementation b further obtains a list of configuration information of the Broker server from the configuration, obtains a value of a key from redis according to the specific key2, and obtains polled Broker server node information by comparing the value with the configuration list.
7. The method according to claim 1, wherein the step S6 is specifically implemented by forwarding a request to invoke a service through the gateway service according to a routing rule, and then obtaining detailed information of the Broker server and returning the obtained detailed information to the gateway service through the load balancing algorithm in step S5, and the gateway service returns the received detailed information of the Broker server to the device sending the request through the network.
8. The method for implementing load balancing based on multiple brokers in MQTT protocol according to claim 2, wherein the certificate information of the device includes gateway address and port;
the request initiated by the device to the gateway service is an http or https request.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111008831.XA CN113452800B (en) | 2021-08-31 | 2021-08-31 | Method for realizing load balance based on multiple Broker in MQTT protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111008831.XA CN113452800B (en) | 2021-08-31 | 2021-08-31 | Method for realizing load balance based on multiple Broker in MQTT protocol |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113452800A CN113452800A (en) | 2021-09-28 |
| CN113452800B true CN113452800B (en) | 2021-11-30 |
Family
ID=77819088
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111008831.XA Active CN113452800B (en) | 2021-08-31 | 2021-08-31 | Method for realizing load balance based on multiple Broker in MQTT protocol |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113452800B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116095111B (en) * | 2022-12-30 | 2024-08-20 | 中联重科股份有限公司 | Configuration method and device of data acquisition equipment and platform server of Internet of things |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111651476A (en) * | 2020-05-18 | 2020-09-11 | 青岛海洋科学与技术国家实验室发展中心 | Quick matching method and system for MQTT theme in gateway of Internet of things |
| CN113242272A (en) * | 2021-03-24 | 2021-08-10 | 中国雄安集团数字城市科技有限公司 | MQTT service cluster-based session processing method and system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110011928B (en) * | 2019-04-19 | 2022-08-19 | 平安科技（深圳）有限公司 | Flow balancing load method and device, computer equipment and storage medium |
| CN111787066B (en) * | 2020-06-06 | 2023-07-28 | 王科特 | Internet of things data platform based on big data and AI |
| CN112104720B (en) * | 2020-09-03 | 2024-04-26 | 国电南瑞科技股份有限公司 | MQTT double-Broker data interaction method and system suitable for edge internet of things terminal |
| CN112867060B (en) * | 2021-01-18 | 2022-04-05 | 重庆邮电大学 | Downlink message queue processing method of LoRa network server |
| CN113190870A (en) * | 2021-05-27 | 2021-07-30 | 新华三技术有限公司 | Redis database access authority control method and device |
-
2021
- 2021-08-31 CN CN202111008831.XA patent/CN113452800B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111651476A (en) * | 2020-05-18 | 2020-09-11 | 青岛海洋科学与技术国家实验室发展中心 | Quick matching method and system for MQTT theme in gateway of Internet of things |
| CN113242272A (en) * | 2021-03-24 | 2021-08-10 | 中国雄安集团数字城市科技有限公司 | MQTT service cluster-based session processing method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113452800A (en) | 2021-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11582199B2 (en) | Scalable proxy clusters | |
| EP1560395B1 (en) | System and method for session reestablishment between client terminal and server | |
| JP5739023B2 (en) | System and method using a web proxy server to access a device having an assigned network address | |
| JP4648214B2 (en) | Call control apparatus and call control method | |
| US7415536B2 (en) | Address query response method, program, and apparatus, and address notification method, program, and apparatus | |
| JP5847853B2 (en) | System and method for accessing a device having an assigned network address | |
| US11336734B1 (en) | System and method for aggregating communication connections | |
| CN101997759A (en) | Service implementation method and service system | |
| US10812421B2 (en) | Conveying instant messages via HTTP | |
| JP3666654B2 (en) | Internet communication method {MethodforanInternetCommunication} | |
| CN113452800B (en) | Method for realizing load balance based on multiple Broker in MQTT protocol | |
| WO2011038639A1 (en) | Realizing method for end-to-end instant messaging, terminal and system for end-to-end instant messaging | |
| KR100702704B1 (en) | Notification System and Method Using Messenger | |
| US20140095922A1 (en) | System and method of failover for an initiated sip session | |
| US9699139B2 (en) | Communications system | |
| CN112769799B (en) | Centralized control equipment, intranet penetration method thereof and storage medium | |
| CN111641664B (en) | Crawler equipment service request method, device and system and storage medium | |
| CN105359494B (en) | System, device, method and network server node is presented in mirror image between website | |
| Cisco | Kerberos Commands | |
| US9015309B2 (en) | Networked probe system | |
| KR20050003598A (en) | Domain name service provide system and method using dual domain name server | |
| CN114499965B (en) | Internet surfing authentication method and system based on POP3 protocol | |
| CN115190168B (en) | Edge server management system and server cluster | |
| CN112543191B (en) | Load balancing method and device | |
| CN116232616A (en) | Equipment communication method and device based on MQTT protocol |
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 | ||
| CB03 | Change of inventor or designer information | ||
| CB03 | Change of inventor or designer information |
Inventor after: Xiong Hao Inventor after: Feng Jianshe Inventor after: Chen Jun Inventor after: Du Dongdong Inventor after: Wu Yuxiao Inventor after: Chen Gong Inventor after: Cheng Jianhong Inventor before: Qin Jiangwei Inventor before: Feng Jianshe Inventor before: Du Dongdong Inventor before: Luo Qiming Inventor before: Xiong Hao Inventor before: Yang Zhiyu Inventor before: Wu Yuxiao Inventor before: Cheng Jianhong Inventor before: Chen Gong Inventor before: Chen Jun |