CN114500660B

CN114500660B - Request processing method, device, equipment and computer readable storage medium

Info

Publication number: CN114500660B
Application number: CN202011149887.2A
Authority: CN
Inventors: 何成洋; 程向往; 胡宗棠; 申栋
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Suzhou Software Technology Co Ltd
Priority date: 2020-10-23
Filing date: 2020-10-23
Publication date: 2023-11-03
Anticipated expiration: 2040-10-23
Also published as: CN114500660A

Abstract

The application provides a request method, a request device, a request equipment and a computer readable storage medium; the method comprises the following steps: receiving a function request transmitted by a terminal; sending a query request corresponding to the function request to a persistence layer; receiving a query result returned by the persistence layer; the query result is generated by the persistence layer according to persistence data; and executing the function operation corresponding to the function request according to the query result. By the method and the device, bandwidth can be saved, and service performance of each service node in the service layer can be improved.

Description

Request processing method, device, equipment and computer readable storage medium

Technical Field

The present application relates to communications technologies, and in particular, to a method, an apparatus, a device, and a computer readable storage medium for processing a request.

Background

The internet of things (The Internet of Things) is characterized in that any object or process needing to be monitored, connected and interacted is collected in real time through various devices and technologies such as various information sensors, radio frequency identification technologies, global positioning systems, infrared sensors and laser scanners, various needed information such as sound, light, heat, electricity, mechanics, chemistry, biology and positions of the object or process is collected, and the ubiquitous connection of the object and the person is realized through various possible network access, so that intelligent sensing, identification and management of the object and the process are realized. The internet of things digitizes the real world, zooms in scattered information, integrates digital information of objects, is widely applied, and the application field mainly comprises the following aspects: the method has very wide market and application scenes in the fields of transportation and logistics, industrial manufacturing, health medical treatment, intelligent environment (home, office, factory), personal and social fields and the like.

In the trunking mode in the internet of things, millions of terminals are connected to different service nodes, and the terminals can issue and receive messages on any service node. After a message is published, the message needs to be pushed to a corresponding subscription terminal as required, which needs to solve the problem of routing the message between different service nodes. I.e. the terminal to be pushed needs to be found according to the subscription relation of each terminal, and then the message is forwarded to the service node to which the terminal is connected.

Each time any service node receives the connection/disconnection/subscription/unsubscribe request of a terminal, the connection/disconnection/subscription unsubscribe request is broadcasted to other service nodes, so that subscription relation data of all terminals under the current local area network needs to be stored in each service node. After a terminal corresponding to one service node sends a state change request, the state change message is sent to all other service nodes through the service node in a broadcasting mode, so that the service node which does not need to receive the state change message also receives the state change message, the safety of the state change message is not guaranteed, the problem of information flooding is caused, and a large amount of bandwidth is wasted.

Disclosure of Invention

The embodiment of the application provides a request processing method, a request processing device and a computer readable storage medium.

The technical scheme of the embodiment of the application is realized as follows:

the embodiment of the application provides a method, which comprises the following steps:

a request processing method applied to a service layer, the service layer including at least one service node, the method comprising: receiving a function request transmitted by a terminal; sending a query request corresponding to the function request to a persistence layer; receiving a query result returned by the persistence layer; the query result is generated by the persistence layer according to persistence data; and executing the function operation corresponding to the function request according to the query result.

The embodiment of the application provides a device, which comprises:

a memory for storing executable instructions;

and the processor is used for realizing the method provided by the embodiment of the application when executing the executable instructions stored in the memory.

The embodiment of the application provides a computer readable storage medium, which stores executable instructions for causing a processor to execute the method provided by the embodiment of the application.

The embodiment of the application has the following beneficial effects:

according to the embodiment of the application, the service layer stores the subscription relation and/or the connection relation required by the function request in the persistence data of the persistence layer, when the service node receives the function request of the terminal and needs to update the subscription relation and/or the connection relation, the service layer can update the subscription relation and/or the connection relation only by sending the query request to the persistence layer.

Drawings

FIG. 1 is a schematic diagram of an alternative architecture of a request processing system architecture provided by an embodiment of the present application;

FIG. 2 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 4 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 5 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 7 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 8 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 9 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 10 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 11 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 12 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 13 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 14 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 15 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application;

FIG. 16 is a schematic flow chart of an alternative method of processing a request according to an embodiment of the present application;

FIG. 17 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 18 is a schematic flow chart of an alternative method of processing requests according to an embodiment of the present application;

FIG. 19 is a schematic flow chart of an alternative method of processing a request according to an embodiment of the present application;

FIG. 20 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 21 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 22 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 23 is a schematic flow chart of an alternative method for processing requests according to an embodiment of the present application;

FIG. 24 is a schematic view of a general framework of a design provided by an embodiment of the present application;

FIG. 25A is a schematic diagram of a persistent node downtime provided by an embodiment of the present application;

FIG. 25B is a schematic diagram illustrating interaction between a service layer and a persistence layer according to an embodiment of the present application;

FIG. 26 is a schematic diagram of an interaction flow between a service layer and a persistence layer when the service layer processes a CONNECT message according to an embodiment of the present application;

FIG. 27 is a schematic diagram of an interaction flow between a service layer and a persistence layer when the service layer processes SUBSCRIBE messages according to an embodiment of the present application;

FIG. 28 is a schematic diagram of an interaction flow between a service layer and a persistence layer when the service layer processes a PUBLISH message according to an embodiment of the present application;

fig. 29 is a schematic diagram of an interaction flow between a service layer and a persistence layer when the service layer processes an UNSUBSCRIBE message according to an embodiment of the present application;

FIG. 30 is a schematic diagram of an interaction flow between a service layer and a persistence layer when the service layer processes a DICONNECT message according to an embodiment of the present application;

fig. 31 is a schematic diagram of an interaction flow between a Broker processing internet of things device terminal and a persistent layer when the terminal is disconnected abnormally;

FIG. 32 is a schematic diagram of a request processing device according to an embodiment of the present application;

FIG. 33 is a schematic diagram of a request processing device according to an embodiment of the present application;

fig. 34 is a schematic diagram of a hardware entity of a device according to an embodiment of the present application.

Detailed Description

The present application will be further described in detail with reference to the accompanying drawings, for the purpose of making the objects, technical solutions and advantages of the present application more apparent, and the described embodiments should not be construed as limiting the present application, and all other embodiments obtained by those skilled in the art without making any inventive effort are within the scope of the present application.

Referring to fig. 1, fig. 1 is a schematic diagram of an alternative architecture of a request processing system 100 according to an embodiment of the present application, in order to support a request processing application, a terminal 200 (illustratively, a terminal 200-1, a terminal 200-2, and a terminal 200-3) are connected to a service layer 300. The service layer 300 includes at least one service node (service node 300-1, service node 300-2, and service node 300-3 are exemplarily shown), wherein the terminal 200 can establish a connection with the service layer 300 by establishing a connection with the at least one service node. Each service node in the service layer is connected to the persistence layer 400, wherein the persistence layer 400 includes one hosting persistent node and at least one backup persistent node (the hosting persistent node 400-1, the backup persistent node 400-2, and the backup persistent node 400-3 are exemplarily shown) connected to the hosting persistent node. Each service node in service layer 300 establishes a connection with persistence layer 400 by establishing a connection with hosting persistent node 400-1.

The service layer is used for receiving the function request transmitted by the terminal and sending a query request corresponding to the function request to the persistent layer; the persistence layer generates a query result according to the persistence data and sends the query result to the service layer; the service layer is also used for executing the function operation corresponding to the function request according to the query result.

Referring to fig. 2, fig. 2 is a schematic flowchart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 2.

In step 202, the service layer receives a function request transmitted by the terminal.

In some embodiments, the service layer includes at least one service node, wherein each service node may establish a connection with at least one terminal. The communication protocol between the service node and the terminal may be one of internet of things communication protocols such as hypertext transfer protocol (HTTP), websocket, extensible messaging and presentation protocol (XMPP, extensible Messaging and Presence Protocol), coAP protocol (CoAP, the Constrained Application Protocol), message queue telemetry transport (MQTT, message Queuing Telemetry Transport), etc., which are not limited in this application, and in order to facilitate understanding of the scheme of the application, the following schemes are described by taking the MQTT protocol as an example.

In this embodiment, taking the MQTT protocol as an example of a communication protocol between a terminal and any one of service nodes in a service layer, the terminal may send a connection request, a disconnection request, a subscription request, an unsubscribe request, and other function requests to the service node connected to the terminal.

In this embodiment, the terminal may establish a communication connection with a service node in the service layer, and when the terminal needs to send a function request, the terminal may send the function request to the service node through the communication connection. At this time, the service layer may implement the function request transmitted by the receiving terminal through the service node that establishes the communication connection with the terminal.

In step 204, the service layer sends a query request corresponding to the function request to the persistence layer.

In step 206, the service layer receives the query result returned by the persistence layer; the query results are generated by the persistence layer from the persistence data.

In some embodiments, the connection relationships and subscription relationships of the various terminals in the request processing system are not maintained in the various service nodes of the service layer, but in the persistence layer. After the service layer receives the function request sent by the terminal, determining data to be queried according to the request type of the function request, and sending a corresponding query request to the persistence layer according to the data to be queried. Taking a function request as an example of a release request, after a service node P in a service layer receives the release request of a terminal on a target theme, the service node P can determine that data to be queried comprises a target terminal subscribed to the target theme, a target service node connected with the target terminal and a state of the target service node according to the type of the request, and sends a corresponding query request to a persistent layer according to the data to be queried, and the persistent layer returns the queried data to the service node P.

In some embodiments, the persistence layer performs a query operation in the persistence data according to the query request, and sends a query result to a service node connected to the terminal, and the service layer receives the query result returned by the persistence layer through the service node connected to the terminal. On the basis of the above-mentioned request for issuing a function, the service layer receives the query result through the service node P.

In step 208, the service layer performs a function operation corresponding to the function request according to the query result.

In some embodiments, after receiving the query result, that is, after receiving the data to be queried, the service layer executes the function operation corresponding to the function request according to the query result. On the basis of taking the function request as a release request as an example, after receiving the target terminal subscribed to the target theme, the target service node connected with the target terminal and the state of the target service node, the service layer determines the route information according to the state of the target service node, and sends the function corresponding to the release request to the target terminal according to the route information.

As can be seen from the above exemplary implementation of fig. 2 by the embodiment of the present application, in the embodiment of the present application, by storing the subscription relationship and/or connection relationship required by the function request in the persistent data of the persistent layer, when the service node receives the function request of the terminal and needs to update the subscription relationship and/or connection relationship, the service node only needs to send a query request to the persistent layer to complete the update of the subscription relationship and/or connection relationship.

In some embodiments, referring to fig. 3, fig. 3 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 2, further includes steps 302 to 304 before step 202.

In step 302, each service node sends heartbeat messages to the persistence layer at a preset frequency.

In some embodiments, the persistence data stored in the persistence layer further includes node state data for each service node in the service layer, wherein the node state data may include a node internet protocol address (IP, internet Protocol) and a node survival state of the service node, among others.

In this embodiment, each service node in the service layer sends a heartbeat message to the persistent layer according to a preset frequency, where the heartbeat message may carry a current node IP of the service node, and after the persistent layer receives the heartbeat message sent by the service node according to the preset frequency, the node state data of the service node may be updated in the persistence data, that is, the node IP of the service node is updated, and the node survival state is set to be a survival state. And under the condition that the persistent layer does not receive the heartbeat message sent by the service node within a preset period of time, the node state data of the service node can be updated in the persistent data, namely, the node survival state is set to be a fault state.

In step 304, the service layer receives a heartbeat acknowledgment message returned by the persistence layer.

In this embodiment, each service node in the service layer receives a heartbeat acknowledgment message corresponding to the heartbeat message returned by the persistence layer.

As can be seen from the above exemplary implementation of fig. 3 according to the embodiment of the present application, the embodiment of the present application sends the heartbeat message to the persistence layer through each service node, so that the persistence data stored in the persistence layer can be updated in real time, that is, the accuracy of the node state data of each service node in the persistence data is improved. Meanwhile, because the node state data of the service node is stored in the persistent layer, when the node state of the service node is changed, the node state data of the service node in the persistent data can be updated in real time through a heartbeat mechanism.

In some embodiments, referring to fig. 4, fig. 4 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 2, further includes steps 402 to 404 before step 202.

In step 402, each service node sends a node status request to the persistence layer at a preset frequency.

In step 404, the service layer receives a node status response generated and returned by the persistence layer according to the node status data of each service node; the node status response includes node status data for a service node in a surviving state of the at least one service node.

In some embodiments, the persistence data stored in the persistence layer further includes node state data for each service node in the service layer, wherein the node state data may include a node IP and node survival state of the service node, and the like.

In some embodiments, each service node in the service layer requests to the persistence layer according to a preset frequency node status request for requesting node status data of all service nodes in the current service layer. After receiving the node state request sent by any service node, the persistence layer traverses the node state data of all the service nodes in the persistence data, and determines the service nodes in a survival state. The persistence layer transmits node state data of all the service nodes in the surviving state to the arbitrary service node of the service layer through the node state response.

It should be noted that the node status request in step 402 may be sent simultaneously with the heartbeat message provided in fig. 3, that is, when the service node sends the node status request according to the preset frequency, the heartbeat message does not need to be sent again, because when the service node sends the node status request according to the preset frequency, it is already indicated that the service node is in the surviving state. Correspondingly, the node status response in step 404 may be received simultaneously with the heartbeat acknowledgment message provided in fig. 3, i.e. the node status response sent by the persistence layer may already indicate that the persistence layer is in a surviving state, without the persistence layer having to send the heartbeat acknowledgment message again.

As can be seen from the above exemplary implementation of fig. 4 according to the embodiment of the present application, the embodiment of the present application sends the node status request to the persistence layer through each service node, so that each service node can obtain the node status data of each service node in the current service layer. Meanwhile, because the node state data of the service node is stored in the persistent layer, when the node state of the service node is changed, the node state data of the service node in the persistent data can be updated in real time through a heartbeat mechanism, and other service nodes can acquire the latest node state data of all service nodes through node state requests.

In some embodiments, referring to fig. 5, fig. 5 is a schematic flowchart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 2, in a case where a function request sent by a terminal is a connection request, step 202 shown in fig. 2 may be updated to step 500, step 204 may be implemented through steps 502 to 504, step 206 may be updated to step 506, and step 208 may be updated to step 508, which will be described in connection with the steps shown in fig. 5.

In step 500, the service layer receives a connection request transmitted by a terminal.

In some embodiments, the terminal may also send a connection request to the service layer, where the terminal has not established a communication connection with any service node in the service layer, and the terminal may send a connection request to any service node therein to request connection to the service node. The service layer may receive the connection request through the service node.

In step 502, the service layer obtains a connection relationship and a subscription relationship of a terminal carried in a connection request.

In some embodiments, the connection request may carry a packet identifier (Packet Identifier), a terminal identifier (Client Identifier), a clear Session identifier, legacy data (Will Message), and a connection relationship of the request packet. The connection relation comprises node identifiers of service nodes to be connected by the terminal; the subscription relationship includes a purge session identification and a legacy data for the terminal.

In step 504, the service layer sends a connection query request carrying a connection relationship and a subscription relationship to the persistence layer.

In some embodiments, in response to a received connection request, the service layer may acquire a connection relationship and a subscription relationship of a terminal carried in the connection relationship, where the connection relationship may include a correspondence between the terminal identifier and a service node, and the subscription relationship may include a legacy data of the terminal. The service layer sends a connection query request carrying the connection relationship and the subscription relationship of the terminal to the persistence layer. After receiving the connection inquiry request, the persistence layer acquires terminal state data of the terminal from the persistence data, and updates the terminal state data of the terminal according to the connection relationship and the subscription relationship of the terminal carried in the subscription inquiry request.

In step 506, the service layer receives a connection query result returned by the persistence layer; the connection query result is generated when the persistence layer queries and/or updates the connection relationship and the subscription relationship of the terminal in the persistence data.

In some embodiments, after receiving the connection query request, the persistence layer acquires a connection relationship and a subscription relationship of the terminal carried in the connection query request, and updates and stores the connection relationship and the subscription relationship of the terminal carried in the subscription query request into terminal state data of the terminal in the persistence data. Meanwhile, the persistent layer also generates a connection query result comprising a connection relation storage result corresponding to the connection relation and a subscription relation storage result corresponding to the subscription relation, and sends the connection query result to the service layer. The service layer receives the connection query result. Wherein, for the connection relationship, the persistence layer updates the connection relationship to the terminal state data of the terminal; for subscription relationships, i.e., for the legacy data of the terminal, the persistence layer will store the legacy data into the terminal state data of the terminal.

In step 508, the service layer sends connection feedback corresponding to the connection request to the terminal according to the connection query result.

In some embodiments, after receiving the connection query result, the persistence layer sends the connection relationship storage result and the subscription relationship storage result to the terminal in a connection feedback manner.

For example, for a connection request sent by the terminal C1, the service layer receives the connection request through a service node P1 that requests to establish a connection with the C1, and obtains a subscription relationship (a clearing session identifier and a legacy data of C1) and a connection relationship (the C1 requests to connect to P1) of the C1 carried in the connection request; the service layer sends a connection query request carrying the subscription relation and the connection relation of the C1 to the persistent layer through the P1, the persistent layer acquires terminal state data of the C1, namely the historical connection relation and the historical subscription relation of the C1, and the persistent layer can replace the historical connection relation by using the C1 connection relation (the C1 request is connected to the P1) carried in the connection request to realize updating and storage of the C1 connection relation; the persistence layer can replace the historical subscription relationship by using the subscription relationship (the clearing session identifier and the legacy data of C1) of C1 carried in the connection request, so as to realize the update storage of the C1 subscription relationship; the persistence layer can also add the subscription relation (the clearing session identifier and the legacy data of C1) of C1 carried in the connection request to the historical subscription relation, so as to realize the reservation and storage of the C1 subscription relation. The persistence layer may save the behavior record in the storage process and send the behavior record to the service layer as a connection query result. The connection query results may include connection relationship storage results and subscription relationship storage results. After receiving the connection query result, the service layer sends the connection relation storage result and the subscription relation storage result to the terminal C1 through a connection feedback mode.

As can be seen from the above exemplary implementation of fig. 5 by the embodiment of the present application, after receiving a connection request sent by a terminal, the embodiment of the present application can update terminal status data of the terminal in a persistence layer in time, so that a release message of a target topic in the connection request can be obtained in time. Meanwhile, because the terminal state data of the terminal is stored in the persistent layer, when the subscription relation and/or the connection relation are required to be updated, the updating of the terminal state data can be completed only by sending a subscription inquiry request to the persistent layer.

In some embodiments, referring to fig. 6, fig. 6 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 5, between any step after step 500, further includes steps 602 to 606, which will be described in conjunction with the steps shown in fig. 6.

In step 602, the service layer acquires the legacy data of the terminal carried in the connection request.

In some embodiments, after the service layer receives the connection request, it queries whether there is legacy data for the terminal in the connection request. In the case that the connection request carries the legacy data, the service layer may acquire the legacy data.

In step 604, the service layer sends a legacy update request carrying legacy data to the persistence layer.

In step 606, the service layer receives the legacy update results returned by the persistence layer in the event that the persistence layer updates the persistence data according to the legacy data and generates the legacy update results.

In some embodiments, when the persistence layer queries that the terminal does not have historical legacy data, the legacy data is stored, and when the persistence layer queries that the terminal has historical legacy data, the legacy data is used to update and replace the historical legacy data of the terminal. Meanwhile, the persistence layer can store the behavior record in the process of storing the remains data, and the behavior record is sent to the service layer as a remains updating result. The service layer receives the remains update result, the remains update result can be used for representing whether remains data are stored in the persistent data, and the remains update result can be used for representing the update mode of the remains data.

As can be seen from the above exemplary implementation of fig. 6 according to the embodiment of the present application, when receiving a connection request, the service layer in the embodiment of the present application further obtains the data of the legacy data therein, and stores the data of the legacy data of the terminal in the persistent layer in time, so that when the terminal is disconnected, the latest data of the legacy data can be sent to the target terminal subscribing the data of the legacy in time. Meanwhile, since the remains data of the terminal are stored in the persistent layer, when the remains data are required to be updated, the remains data can be updated only by sending a remains update request to the persistent layer.

In some embodiments, referring to fig. 7, fig. 7 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and based on the above embodiments, the method further includes steps 702 to 706, which will be described with reference to the steps shown in fig. 7.

In step 702, the service layer receives a disconnection request transmitted by the terminal.

In some embodiments, the terminal may also send a disconnect request to the service layer, wherein the terminal has established a communication connection with one of the service nodes in the service layer, through which the terminal may send the disconnect request to the service layer.

In this embodiment, the service layer may receive the disconnection request through the service node, where the disconnection request is sent by a terminal connected to the service node.

In step 704, the service layer sends a legacy delete request corresponding to the disconnect request to the persistence layer.

In some embodiments, in response to receiving the disconnection request, the service layer may send a legacy delete request carrying a terminal identification of the terminal to the persistence layer. After receiving the remains deleting request, the persistent layer queries the corresponding remains data in the persistent data, deletes the remains data under the condition that the remains data is found, generates a deleting result, and sends the remains deleting result carrying the deleting result to the service layer.

In step 706, the service layer receives the results of the deletion of the legacy sent by the persistence layer.

As can be seen from the above exemplary implementation of fig. 7 by the embodiment of the present application, after receiving the disconnection request sent by the terminal, the embodiment of the present application can delete the legacy data of the terminal in the persistent layer in time. Meanwhile, since the remains data of the terminal are stored in the persistent layer, when the remains data need to be deleted, the deletion of the remains data can be completed only by sending a remains deletion request to the persistent layer.

In some embodiments, referring to fig. 8, fig. 8 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and based on the above embodiments, the method further includes steps 802 to 804, which will be described in connection with the steps shown in fig. 8.

In step 802, in the event of an abnormal disconnection of the terminal, the service layer sends a legacy query request to the persistence layer.

In some embodiments, the case that the terminal is abnormally disconnected may further include: (1) the service layer discovers an I/O error or network error; (2) the terminal does not send heartbeat packets on time; (3) The terminal does not send a DISCONNECT request (DISCONNECT packet) before disconnecting; (4) the terminal disconnects due to a protocol error.

In step 804, the service layer receives a legacy query result returned by the persistence layer.

In some embodiments, the persistence layer receives a legacy inquiry request sent by the service layer under the condition that the terminal is abnormally disconnected, and inquires the legacy data of the terminal in the persistence data to generate a legacy inquiry result. The remains inquiry result is used for representing whether remains data of the terminal exist in the persistence data, and the remains inquiry result also carries the remains data of the terminal under the condition that remains data of the terminal exist in the persistence data.

As can be seen from the above exemplary implementation of fig. 8 by the embodiment of the present application, in the case of abnormal disconnection of the terminal, the embodiment of the present application can query and obtain the corresponding legacy query result in time at the persistent layer.

In some embodiments, referring to fig. 9, fig. 9 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 8, after step 804, steps 902 to 906 may be further included, which will be described in connection with the steps shown in fig. 9.

In step 902, in the case that the legacy inquiry result carries the legacy data of the terminal, the service layer sends a legacy subscription terminal inquiry request to the persistence layer.

In some embodiments, after step 804, after the legacy inquiry result inquires the legacy data of the terminal, the service layer sends a legacy subscription terminal inquiry request to the persistent layer to obtain terminal state data of the legacy subscription terminal subscribed to the legacy data and node state data of the target service node connected to each legacy subscription terminal.

In step 904, the service layer receives a query result of the legacy subscription terminal returned by the persistence layer; the query result of the legacy subscription terminal includes terminal state data of at least one legacy subscription terminal subscribing to the legacy data, and node state data of a target service node connected to each legacy subscription terminal.

In some embodiments, after receiving a query request of a legacy subscription terminal sent by a service layer, the persistence layer queries at least one legacy subscription terminal subscribing to the legacy data in persistence data, can acquire terminal state data of each legacy subscription terminal according to terminal state data of each terminal stored in persistence data, can acquire a target terminal connected with each legacy subscription terminal according to connection relation of each legacy subscription terminal, and can acquire node state data of a target service node connected with each legacy subscription terminal in combination with node state data of each service node stored in persistence data. And transmitting a query result of the legacy subscription terminal carrying terminal state data of at least one legacy subscription terminal subscribing to the legacy data and node state data of a target service node connected with each legacy subscription terminal to a service layer.

In step 906, the service layer sends the legacy data to the at least one legacy subscription terminal through the target service node in the surviving state according to the terminal state data of the at least one legacy subscription terminal and the node state data of the target service node.

In some embodiments, the service layer sends the legacy data to the at least one legacy subscription terminal via a target service node in a surviving state among the at least one target service node after receiving the terminal state data of the at least one legacy subscription terminal and the node state data of the target service node.

As can be seen from the above exemplary implementation of fig. 9 by the embodiment of the present application, in the case that the result of the query of the legacy is carried with the legacy data of the terminal, the embodiment of the present application can timely acquire the terminal state data of at least one legacy subscription terminal subscribing to the legacy data and the node state data of the target service node in the persistent layer, thereby improving the request processing efficiency.

In some embodiments, referring to fig. 10, fig. 10 is a schematic flowchart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 2, in a case where a function request sent by a terminal is a subscription request, step 202 shown in fig. 2 may be updated to step 1000, step 204 may be implemented through steps 1002 to 1004, step 206 may be updated to step 1006, and step 208 may be updated to step 1008, which will be described in connection with the steps shown in fig. 10.

In step 1000, the service layer receives a subscription request transmitted by a terminal.

In some embodiments, the terminal may also send a subscription request to the service layer, wherein the terminal has established a communication connection with one of the service nodes in the service layer, through which the terminal may send the subscription request to the service layer.

In this embodiment, the service layer may receive the subscription request through the service node, where the subscription request is sent by a terminal connected to the service node.

In step 1002, the service layer obtains a connection relationship and a subscription relationship of a terminal carried in a subscription request.

In some embodiments, the subscription request may carry a package identifier (Packet Identifier), subscription relationship, and connection relationship for the request package. The subscription relation comprises at least one target theme to which the terminal needs to subscribe and a service quality level (QoS, quality of Service Level) corresponding to each target theme; the connection relation includes the node identification of the service node to which the terminal is currently connected.

In step 1004, the service layer sends a subscription query request carrying a connection relationship and a subscription relationship to the persistence layer.

In some embodiments, in response to receiving the subscription request, the service layer may send a subscription query request to the persistence layer carrying the connection relationship and the subscription relationship of the terminal. After receiving the subscription inquiry request, the persistence layer acquires terminal state data of the terminal from the persistence data, and updates the terminal state data of the terminal according to the connection relationship and the subscription relationship of the terminal carried in the subscription inquiry request.

In step 1006, the service layer receives a subscription query result returned by the persistence layer; the subscription query result is generated when the persistence layer stores the connection relationship and the subscription relationship of the terminal in the persistence data.

In some embodiments, after receiving the subscription query request, the persistence layer acquires a connection relationship and a subscription relationship of the terminal carried in the subscription query request, and updates and stores the connection relationship and the subscription relationship of the terminal carried in the subscription query request into terminal state data of the terminal in the persistence data. Meanwhile, the persistence layer also generates a subscription inquiry result comprising a connection relation storage result corresponding to the connection relation and a subscription relation storage result corresponding to the subscription relation, and sends the subscription inquiry result to the service layer. The service layer receives the subscription query result.

In some embodiments, the persistence layer also queries the reserved message matching the subscription relationship according to the subscription relationship carried in the subscription query request. After the persistent layer queries the reservation message matched with the subscription relation, the reservation message is carried in the subscription query result and is sent to the service layer. Correspondingly, in the case that the persistence layer queries the reserved message of the target theme, the subscription query result received by the service layer also carries the reserved message.

In step 1008, the service layer sends subscription feedback corresponding to the subscription request to the terminal according to the subscription query result.

In some embodiments, after receiving the subscription query result, the persistence layer sends the connection relationship storage result and the subscription relationship storage result to the terminal in a subscription feedback manner.

For example, for a subscription request sent by a terminal C2, a service layer receives the subscription request through a service node P2 connected with the C2, and obtains a subscription relationship (C2 subscribes to a T2 topic) and a connection relationship (C2 is connected to P2) of the C2 carried in the subscription request; the service layer sends a subscription query request carrying the subscription relation and the connection relation of C2 to the persistent layer through P2, the persistent layer acquires terminal state data of C2, namely the historical connection relation and the historical subscription relation of C2, and the persistent layer can replace the historical connection relation by using the C2 connection relation (C2 is connected with P2) carried in the subscription request to realize updating and storage of the C2 connection relation; the persistence layer can replace the historical subscription relationship by using the subscription relationship (C2 subscription T2 theme) of C2 carried in the subscription request, so as to realize the update storage of the C2 subscription relationship; the persistence layer can also add the C2 subscription relationship (C2 subscription T2 theme) carried in the subscription request to the historical subscription relationship, so as to realize the reservation and storage of the C2 subscription relationship. The persistence layer may save the behavior record in the storage process and send the behavior record to the service layer as a result of the subscription query. The subscription query result may include a connection relationship store result and a subscription relationship store result. After receiving the subscription inquiry result, the service layer sends the connection relation storage result and the subscription relation storage result to the terminal C2 through subscription feedback.

As can be seen from the above exemplary implementation of fig. 10 by the embodiment of the present application, after receiving a subscription request sent by a terminal, the embodiment of the present application can update terminal status data of the terminal in a persistence layer in time, so that a publishing message of a target topic in the subscription request can be obtained in time. Meanwhile, because the terminal state data of the terminal is stored in the persistent layer, when the subscription relation and/or the connection relation are required to be updated, the updating of the terminal state data can be completed only by sending a subscription inquiry request to the persistent layer.

In some embodiments, referring to fig. 11, fig. 11 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 2, in a case where a function request sent by a terminal is a publish request, step 202 shown in fig. 2 may be updated to step 1100, step 204 may be implemented through steps 1102 to 1104, step 206 may be updated to step 1106, and step 208 may be updated to step 1108, which will be described in connection with the steps shown in fig. 11.

In step 1100, the service layer receives a release request transmitted by the terminal.

In some embodiments, the terminal may also send a release request to the service layer, wherein the terminal has established a communication connection with one of the service nodes in the service layer, through which the terminal may send the release request to the service layer.

In this embodiment, the service layer may receive the release request through the service node, where the release request is sent by a terminal connected to the service node.

In step 1102, the service layer obtains a target topic carried in the publication request.

In some embodiments, the publishing request may carry a packet identifier (Packet Identifier) of the request packet, a target topic, a quality of service level (QoS, quality of Service Level) corresponding to the target topic, and a Payload (Payload), where the Payload is the content actually published in the publishing request, and the sending may be a picture, any coded text, and encrypted data.

In step 1104, the service layer sends a publishing query request carrying the target topic to the persistence layer.

In some embodiments, in response to receiving the publish request, the service layer may send a publish query request carrying the target topic to the persistence layer. After receiving the inquiry request, the persistence layer inquires at least one target terminal subscribed to the target subject in the persistence data, acquires terminal state data of the at least one target terminal, and acquires target service nodes connected with the at least one target terminal according to the connection relation of the terminal state data terminals of the at least one target terminal, so that node state data of each target service node can be acquired.

In step 1106, the service layer receives the issued query result returned by the persistence layer; the publishing query result includes terminal state data of at least one target terminal subscribed to the target topic and node state data of a target service node connected to each target terminal.

In some embodiments, after the persistence layer receives the issue query request, the persistence layer acquires a target topic carried in the issue query request, and acquires terminal state data of the at least one target terminal and node state data of the at least one target service node in the persistence data through the target topic. Meanwhile, the persistence layer also generates a release query result comprising terminal state data of at least one target terminal and node state data of at least one target service node, and sends the release query result to the service layer. The service layer receives the issued query result.

In step 1108, the service layer sends a release feedback corresponding to the release request to the at least one target terminal through the target service node in the surviving state according to the terminal state data of the at least one target terminal and the node state data of the target service node.

In some embodiments, after receiving the terminal state data of at least one target terminal and the node state data of at least one target service node, the service layer sends a release feedback corresponding to the release request to the at least one target terminal through a target service node in a surviving state in the at least one target service node, that is, sends a payload in the release request to the at least one target terminal through a target service node in a surviving state in the at least one target service node.

For example, for the release request sent by the terminal C3, the service layer receives the release request through the service node P3 connected to the C3, and obtains the target topic T3 carried in the release request; the service layer sends a release query request carrying a target theme T3 to the persistent layer through the P3, the persistent layer acquires terminal state data of at least one target terminal subscribed to the target theme T3, namely the connection relation and the subscription relation of at least one target terminal, and according to the connection relation of at least one target terminal, a target service node connected with the at least one target terminal can be acquired, and then node state data of each target service node can be acquired. The persistence layer may transmit the terminal state data of the at least one target terminal and the node state data of the at least one target service node to the service layer as a result of the issued query. After receiving the release inquiry result, the service layer determines a target service node in a survival state in the at least one target service node, and sends release feedback corresponding to the release request to each target terminal through the target service node in the survival state corresponding to each target terminal according to the connection relation of each target terminal, wherein the release feedback can be a payload in the release request.

As can be seen from the above exemplary implementation of fig. 11 by the embodiment of the present application, after receiving a release request sent by a terminal, the embodiment of the present application can quickly obtain, from a persistence layer, terminal state data of a target terminal corresponding to the release request and node state data of a target service node connected to each target terminal, so that release feedback corresponding to the release request can be timely sent to the target terminal. Meanwhile, as the terminal state data of each terminal and the node state data of each service node are stored in the persistent layer, when a message is required to be issued, the acquisition of the target terminal and the route information can be completed only by sending an issue inquiry request to the persistent layer.

In some embodiments, referring to fig. 12, fig. 12 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 2, in a case where a function request sent by a terminal is a unsubscribe request, step 202 shown in fig. 2 may be updated to step 1200, step 204 may be implemented through steps 1202 to 1204, step 206 may be updated to step 1206, and step 208 may be updated to step 1208, which will be described in connection with the steps shown in fig. 12.

In step 1200, the service layer receives an unsubscribe request transmitted by the terminal.

In some embodiments, the terminal may also send an unsubscribe request to the service layer, where the terminal has established a communication connection with one of the service nodes in the service layer, through which the terminal may send the unsubscribe request to the service layer.

In this embodiment, the service layer may receive the unsubscribe request through a service node, where the unsubscribe request is sent by a terminal connected to the service node.

In step 1202, the service layer obtains a relationship to be unsubscribed of the terminal carried in the unsubscribe request.

In some embodiments, the subscription request may carry a package identifier (Packet Identifier) of the request package and a relationship to be unsubscribed. The relation to be unsubscribed comprises at least one target theme which the terminal needs to unsubscribe.

In step 1204, the service layer sends an unsubscribe query request carrying a relationship to be unsubscribed to the persistence layer.

In some embodiments, in response to receiving the unsubscribe request, the service layer may send an unsubscribe query request carrying the relationship to be unsubscribed of the terminal to the persistence layer. After receiving the unsubscribe query request, the persistence layer acquires terminal state data of the terminal from the persistence data, and updates the terminal state data of the terminal according to the relationship to be unsubscribed of the terminal carried in the unsubscribe query request.

In step 1206, the service layer receives an unsubscribe query result returned by the persistence layer; the unsubscribe query result is generated when the persistence layer deletes the relationship to be unsubscribed of the terminal in the persistence data.

In some embodiments, after receiving the unsubscribe query request, the persistence layer obtains a relationship to be unsubscribed of the terminal carried in the unsubscribe query request, and updates terminal state data of the terminal in the persistence data according to the relationship to be unsubscribed of the terminal carried in the unsubscribe query request, that is, deletes a subscription relationship corresponding to the relationship to be unsubscribed in the terminal state data of the terminal. Meanwhile, the persistence layer also generates an unsubscribe query result and sends the unsubscribe query result to the service layer. The unsubscribe query result may include a deletion record when the persistence layer deletes a subscription relationship corresponding to the relationship to be unsubscribed in the terminal state data of the terminal. The service layer receives the subscription query result.

In step 1208, the service layer sends an unsubscribe feedback corresponding to the unsubscribe request to the terminal according to the unsubscribe query result.

In some embodiments, after receiving the unsubscribe query result, the persistence layer sends the deletion record therein to the terminal in a manner of unsubscribe feedback.

For example, for a unsubscribe request sent by the terminal C4, the service layer receives the unsubscribe request through the service node P4 connected to the C4, and obtains a to-be-unsubscribed relationship (C4 unsubscribe T4 topic) of the C4 carried in the unsubscribe request; the service layer sends an unsubscribe query request carrying the to-be-unsubscribed relation of C4 to the persistence layer through P4, the persistence layer acquires terminal state data of C4, namely the historical subscription relation of C4, and the persistence layer can delete the subscription relation corresponding to the to-be-unsubscribed relation in the historical subscription relation. The persistence layer may save the deletion record in the deletion process, and send the deletion record to the service layer as a unsubscribe query result, where the unsubscribe query result may include a deletion result of the relationship to be unsubscribed. After receiving the unsubscribe query result, the service layer sends the deletion record therein to the terminal C4 in a manner of unsubscribe feedback.

As can be seen from the above exemplary implementation of fig. 12 according to the embodiment of the present application, after receiving the unsubscribe request sent by the terminal, the embodiment of the present application can update the terminal status data of the terminal in the persistence layer in time. Meanwhile, because the terminal state data of the terminal is stored in the persistent layer, when the subscription relation and/or the connection relation are required to be updated, the updating of the terminal state data can be completed only by sending a subscription inquiry request to the persistent layer.

In some embodiments, referring to fig. 13, fig. 13 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 13.

In step 1302, the persistence layer receives a query request sent by a service layer; the inquiry request is generated by the service layer according to the function request transmitted by the terminal.

In some embodiments, the persistent layer includes a hosting persistent node and at least one backup persistent node, where the hosting persistent node and the backup persistent node are designed by using a Raft algorithm, so that reliability and disaster recovery capability of the persistent layer can be ensured.

In this embodiment, in the persistent layer, a plurality of persistent nodes form a Raft group, only one host node (Leader node) is in a group, and the rest is backup persistent nodes (impeller nodes), wherein the host node provides data service for the service layer, the persistent data of the host node is consistent with the backup persistent nodes, and when the host node fails and is down, the backup persistent nodes start to compete for selection, so that new host nodes continue to provide service, and high availability of the persistent layer is ensured. Meanwhile, the persistence layer adopts a Multi-Raft-Group architecture, so that the fragmentation storage of state data such as subscription relations and the like is realized, the problem of bottleneck of read-write performance of a single Raft Leader node is solved, and the high performance of the persistence layer is ensured.

In step 1304, the persistence layer generates a query result from the persistence data.

In step 1306, the persistence layer sends the query result to the service layer; the query result is used for indicating the service layer to execute the function operation corresponding to the function request.

As can be seen from the above exemplary implementation of FIG. 13 according to the embodiment of the present application, by setting a hosting persistent node and at least one backup persistent node in the persistent layer, the read-write performance of the persistent layer can be improved, and the availability of the persistent layer can be improved. In addition, the service layer stores the subscription relation and/or connection relation required by the function request in the persistence data of the persistence layer, when the service node receives the function request of the terminal and needs to update the subscription relation and/or connection relation, the service layer can update the subscription relation and/or connection relation only by sending the query request to the persistence layer.

In some embodiments, referring to fig. 14, fig. 14 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 14.

In step 1402, the persistence layer receives heartbeat messages sent by each service node at a preset frequency.

In step 1404, the persistence layer generates a heartbeat acknowledgment message from the heartbeat message sent by each service node.

In step 1406, the persistence layer sends a heartbeat acknowledgment message to each service node.

In some embodiments, referring to fig. 15, fig. 15 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 15.

In step 1502, the persistence layer receives node status requests sent by each serving node according to a preset frequency.

In step 1504, the persistence layer generates a node status response from the node status data of each service node; the node status response includes node status data for a service node in a surviving state of the at least one service node.

In step 1506, the persistence layer sends a node feedback message to each serving node.

In some embodiments, referring to fig. 16, fig. 16 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, based on fig. 13, in a case where a query request sent by a service layer is a connection query request, steps 1302 to 1306 shown in fig. 2 may be updated to steps 1602 to 1608, which will be described in connection with the steps shown in fig. 16.

In step 1602, the persistence layer receives a connection query request sent by the service layer; the connection inquiry request is generated by the service layer according to the connection request sent by the terminal.

In step 1604, the persistence layer obtains the connection relationship and the subscription relationship of the terminal carried in the connection query request.

In step 1606, the persistence layer queries and/or updates the connection relationship and subscription relationship of the terminal in the persistence data and generates a connection query result.

In step 1608, the persistence layer sends the connection query result to the service layer; the connection inquiry result is used for indicating the service layer to send connection feedback corresponding to the connection request to the terminal.

In some embodiments, referring to fig. 17, fig. 17 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and based on fig. 16, steps 1702 to 1706 are further included between any steps, and will be described in conjunction with the steps shown in fig. 17.

In step 1702, a persistence layer receives a legacy update request sent by a service layer; the heritage update request is generated by the service layer according to the heritage data of the terminal carried in the connection request.

In step 1704, the persistence layer updates persistence data based on the legacy data and generates a legacy update result.

In step 1706, the persistence layer sends the legacy update results to the service layer.

In some embodiments, referring to fig. 18, fig. 18 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 18.

In step 1802, the persistence layer receives a legacy delete request sent by the service layer; the heritage deletion request is generated by the service layer according to a disconnection request sent by the terminal.

In step 1804, the persistence layer deletes the legacy data of the terminal and generates a legacy delete result.

In step 1806, the persistence layer sends the legacy delete result to the service layer.

In some embodiments, referring to fig. 19, fig. 19 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 19.

In step 1902, the persistence layer receives a legacy query request sent by the service layer in the event of an abnormal disconnection of the terminal.

In step 1904, the persistence layer queries the persistence data for the legacy data of the terminal, and generates a legacy query result; the legacy inquiry result is used for representing whether legacy data of the terminal exist in the persistent data; under the condition that the persisted data contains the legacy data of the terminal, the legacy inquiry result also carries the legacy data of the terminal.

In some embodiments, referring to fig. 20, fig. 20 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 20.

In step 2002, the persistence layer receives a legacy subscription terminal query request sent by the service layer.

In step 2004, the persistence layer queries at least one legacy subscription terminal that subscribes to legacy data.

In step 2006, the persistence layer generates a legacy subscription terminal query result according to the persistence data; the query result of the heritage subscription terminal comprises terminal state data of at least one heritage subscription terminal and node state data of a target service node connected with each heritage subscription terminal.

In step 2008, the persistence layer sends the query result of the legacy subscription terminal to the service layer; the query result of the legacy subscription terminal is used for indicating the service layer to send the legacy data to at least one legacy subscription terminal through the target service node in the survival state.

In some embodiments, referring to fig. 21, fig. 21 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 21.

In step 2102, a persistence layer receives a subscription query request sent by a service layer; the subscription inquiry request is generated by the service layer according to the subscription request sent by the terminal.

In step 2104, the persistence layer obtains a connection relationship and a subscription relationship of the terminal carried in the subscription query request.

In step 2106, the persistence layer stores the connection relationship and the subscription relationship of the terminal in the persistence data and generates a subscription query result.

In step 2108, the persistence layer sends the subscription query result to the service layer; the connection query result is used for indicating the service layer to send subscription feedback corresponding to the subscription request to the terminal.

In some embodiments, the subscription relationship includes a target topic, and in the case of querying a retention message of the target topic, the subscription query result also carries the retention message.

In some embodiments, referring to fig. 22, fig. 22 is a schematic flowchart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 22.

In step 2202, the persistence layer receives a release query request sent by the service layer; the issuing inquiry request is generated by the service layer according to the issuing request sent by the terminal.

In step 2204, the persistence layer obtains a target topic carried in the issued query request.

In step 2206, the persistence layer queries at least one target terminal subscribing to the target topic according to the persistence data and generates a published query result; the issued query result includes terminal state data of at least one target terminal and node state data of a target service node connected to each target terminal.

In step 2208, the persistence layer sends the published query result to the service layer; the issuing inquiry result is used for indicating the service layer to send issuing feedback corresponding to the issuing request to at least one target terminal through the target service node in the survival state.

In some embodiments, referring to fig. 23, fig. 23 is a schematic flow chart of an alternative method for processing a request according to an embodiment of the present application, and will be described with reference to the steps shown in fig. 23.

In step 2302, the persistence layer receives an unsubscribe query request sent by the service layer; the unsubscribe query request is generated by the service layer according to the unsubscribe request sent by the terminal.

In step 2304, the persistence layer obtains the relationship to be unsubscribed carried in the unsubscribe query request.

In step 2306, the persistence layer deletes the to-be-unsubscribed relationship of the terminal in the persistence data and generates an unsubscribed query result.

In step 2308, the persistence layer sends the unsubscribe query result to the service layer; the unsubscribe query result is used for indicating the service layer to send unsubscribe feedback corresponding to the unsubscribe request to the terminal.

In the following, an exemplary application of the embodiment of the present application in a practical application scenario will be described.

The definition of the internet of things (The Internet of Things) is very simple: all articles are connected with the Internet through information sensing equipment such as radio frequency identification and the like, so that intelligent identification and management are realized. The integration application of the internet of things with ubiquitous computing through intelligent perception and recognition technology is called as the third wave of development of world information industry after the computer and the internet. The internet of things digitizes the real world, zooms in scattered information, integrates digital information of objects, is widely applied, and the application field mainly comprises the following aspects: the method has very wide market and application scenes in the fields of transportation and logistics, industrial manufacturing, health medical treatment, intelligent environment (home, office, factory), personal and social fields and the like.

The Internet of things for realizing the Internet of everything is realized, and most importantly, the communication between equipment is realized in the Internet. The communication protocols which are common in the communication of the internet of things in the internet now comprise: HTTP, websocket, XMPP, COAP, MQTT. In contrast to several other communication protocols, MQTT is a "lightweight" communication protocol based on publish/subscribe (pub/sub) mode, which was built on the TCP/IP protocol and published by IBM in 1999. The MQTT considers the difference of the computing performance of different devices when designing the protocol, so all protocols are encoded and decoded by adopting a binary format, and the encoding and decoding formats are very easy to develop and realize. The minimum data packet is only 2 bytes, and the method has good adaptability to a low-power-consumption low-speed network. There is a very sophisticated QoS mechanism, and depending on the traffic scenario, three messaging modes can be selected at most once, at least once, just once. The method runs on the TCP protocol, supports the TLS (TCP+SSL) protocol at the same time, and ensures the safety well.

In case of interconnection of things, numerous devices, the performance of a single MQTT server is limited, and the connection requirements of numerous devices are difficult to meet, and a high-availability cluster of the MQTT server is particularly important in the application of the Internet of things. The current open-source MQTT proxy server supporting the cluster mode (comprising a message queue supporting the MQTT protocol) mainly comprises EMQ and Apache ActiveMQ. The Mosquitto official does not give a cluster solution. In trunked mode, millions of terminals are connected to different nodes, and a terminal can publish messages and publish messages at any node. After a message is published, the message needs to be pushed to a corresponding subscription terminal as required, which needs to solve the problem of routing the message between different nodes. I.e. the terminal to be pushed needs to be found according to the subscription relation of each terminal, and then the message is forwarded to the node to which the terminal is connected. The solution to this problem for ActiveMQ, mosquitto and EMQ is as follows:

every time a connection/disconnection/subscription/unsubscribe request of a terminal is received, the request is broadcast to other nodes, and the total subscription relation data is stored in each node. Considering network problems occurring at any time among nodes and downtime and recovery of the nodes, data inconsistency can occur among the nodes, and the cluster provides a retry mechanism after broadcasting failure. In addition, when a certain node is out of the cluster due to downtime and the like, after the node is rejoined, other nodes can send all subscription data to the node so as to prevent the subscription data of the node from being lost.

It can be seen that the drawbacks of the conventional technique are as follows:

(1) Large-scale clusters cannot be supported.

Assuming that there are N serving nodes in the cluster, each serving node needs to maintain a long connection with the other N-1 serving nodes, and each connect/close connect/subscribe/unsubscribe request generates N-1 RPC calls. When the serving node size increases, these PRC requests occupy a lot of bandwidth and exhibit geometric growth, which drastically decreases performance. If a broadcasting mode is adopted, a host computer which does not need to receive the information can also receive the information, the safety of the information is not guaranteed, the information in the same network segment is flooded, and a large amount of bandwidth is wasted.

(2) Data consistency problems, performance problems, etc. are difficult to solve.

The problem of inconsistent data among service nodes caused by unstable network and downtime/restoration of the service nodes is difficult to solve. Even though ActiveMQ, mosquitto-cluster or EMQ proposed the respective solutions, there are problems of complex logic, performance impact, etc.

The ActiveMQ has two cluster modes, one is a Master/Slave cluster mode, the cluster mode depends on a Zookeeper, the complexity of the system is increased, the management is troublesome, and the system does not have the characteristic of load balancing; another is the Broker Clusters approach, where messages can be forwarded between multiple service nodes (brokers), but messages are stored on only one Broker and must be restarted once it fails.

The Mosquick-cluster supports horizontal expansion, but when the cluster size is larger, when a new terminal (Client) subscribes/unsubscribes, all other readers are required to be notified, and when the network between the Client and the reader clusters is unstable, a great number of requests are generated between the clusters of the readers and frequently reconnect to send subscription/unsubscribe messages, so that the performance is influenced.

The EMQ message server cluster is based on Erlang/OTP distributed design, all nodes of the same cluster of the EMQ message server can copy a route table mapped by a theme (Topic) and a Broker node, when a plurality of terminals are provided, the memory occupied by the route table is not small when the subscription theme is provided, and the memory of the server is ensured to be sufficient; in addition, when the cross-border point persistent session is processed, if the node maintaining the persistent session fails, the service is abnormal.

According to the embodiment of the application, a computing and storage separation architecture design is adopted, a connection relation and subscription relation data persistence layer is designed based on a Raft algorithm, a computing service layer is stateless, and the persistence layer has the function of a registration center, so that a high-performance, elastic expansion and contraction and high-availability message queue system oriented to the Internet of things is realized.

As shown in fig. 24, a schematic diagram of a general framework of a design provided by an embodiment of the present application is provided, where MQTT Broker starts and stores own information in a persistence layer, and the Broker may obtain other Broker information from the persistence layer, and form a Broker cluster with each other. The internet of things equipment is connected to a Broker cluster through a load balancing server, and the Broker cluster persists the connection relation and subscription relation data of the internet of things equipment to a persistence layer. The service layer does not hold the state data of the connection relationship and the subscription relationship, so the Broker node is stateless and can support unlimited horizontal expansion. The persistent layer is designed based on a Raft algorithm, and when a Leader of the persistent layer is down, a new Leader is generated in a race in the Follower to provide service for a Broker cluster. Meanwhile, the persistence layer adopts a Multi-Raft-Group architecture design, stored state data is stored in a slicing way when necessary, the performance bottleneck problem of a single Raft cluster Leader node is solved, and the overall high availability and horizontal expansion of the persistence layer are realized. According to the scheme, the fact that the Broker service providing layer is not tightly coupled with the subscription relation persistence layer is defined, the Broker does not hold subscription relation data, and each connection/closing connection/subscription/unsubscribe request of the Internet of things equipment only generates one call of the service layer to the subscription relation persistence layer. The persistent layer maintains subscription relation data, so that even if a service-providing Broker fails and is down, the internet of things equipment is reconnected to other broaders, and MQTT messages can still be normally received and transmitted without sending unnecessary subscription messages. The scheme of the application supports the elastic expansion and contraction of the Broker and the persistent layer and large-scale clustering. The durability layer designed based on the Raft algorithm ensures data consistency and integrally improves the high availability performance of the system.

In some embodiments, the service layer is separate from the persistence layer architecture. Wherein:

(1) Persistent layer: the method is designed based on a Raft algorithm and used for guaranteeing the reliability and disaster recovery capability of a persistent layer. The method is responsible for maintaining connection relation data and subscription relation data of the connection of the internet of things equipment to the Broker, such as an address of the Broker, a Will Message (Will Message), a reservation Message (RetainMessage), an offline Message, a subscribed Topic (Topic), a Message service quality (QoS) of the subscribed Topic, a clear session flag (clearsession) and the like, to which the MQTT terminal of the internet of things equipment is connected. In addition, the persistence layer also maintains related information of the Broker node, such as the Broker node IP, the survival status, etc., and has the function of a registry, and the implementation mode refers to the service layer description. In the persistent layer, a plurality of storage nodes form a Raft group, only one Leader node is arranged in one group, the rest is a Follower node, the Follower node provides data service for the Broker layer, the Follower node data are consistent with the Leader node, when the Follower node is down due to failure, the Follower node starts to compete, a new Leader node is generated to continue providing service, and the high availability of the persistent layer is ensured. Meanwhile, the persistence layer adopts a Multi-Raft-Group architecture, so that the fragmentation storage of state data such as subscription relations and the like is realized, the problem of bottleneck of read-write performance of a single Raft Leader node is solved, and the high performance of the persistence layer is ensured.

For example, please refer to a schematic diagram of a persistent node failure downtime provided in fig. 25A. Before a fault occurs, a persistence node 1, a persistence node 2, a persistence node 3, a persistence node 4 and a persistence node 5 exist in the persistence layer, wherein the persistence node 1 is a hosting persistence node, the rest nodes are backup persistence nodes, after the fault occurs, the hosting persistence node 1 and the backup hosting persistence node 2 have faults, the persistence node 3, the persistence node 4 and the persistence node 5 can reselect and remove new hosting persistence nodes, and the persistence node 3 shown in the figure becomes the main persistence node to continue to provide services.

(2) Service layer: each Broker needs to dynamically perceive the currently surviving Broker in the cluster, where if a third party component (such as a zookeeper or etcd) is used to save the current online status of each Broker, the complexity of the overall solution design will be increased, and many burdens will be caused on actual deployment and operation and maintenance work. Referring to FIG. 25B, a schematic diagram of interaction between a service layer and a persistence layer is provided, wherein the implementation of a lightweight registry by the persistence layer is considered to provide functions of service registration and service discovery. Each Broker instance stores its own information to the persistence layer when started and periodically sends heartbeat packets to maintain its own online state. Other broaders can dynamically perceive other broaders in the cluster in near real time by accessing the persistence layer. Whether a new Broker is added into the cluster or the Broker in the cluster is down due to a fault, other schekers which can work normally can dynamically sense the state information, and the routing of messages among the schekers is completed. And a plurality of broaders form a cluster to provide service for the MQTT terminal of the Internet of things equipment.

In some embodiments, the application also provides an interaction scenario between the service layer and the persistent layer. In the proposal, the service layer has more interaction scenes with the persistent layer, and the interaction scenes are described in a classified manner according to the message types sent by the equipment terminal of the Internet of things. In the following flow, some description such as message inspection of the service layer is omitted, and interaction between the service layer and the persistent layer is mainly introduced.

In some embodiments, as shown in fig. 26, the present application further provides an interaction flow with the persistence layer when the service layer processes the CONNECT message (connection request).

In step 2602, after receiving the heartbeat packet of the Broker and the request for sensing the cluster survival Broker, the persistence layer updates the state information of the current Broker, queries the state of the survival Broker, and returns the state to the Broker for performing message routing between the cluster Broker when the PUBLISH message is processed subsequently;

in step 2604, if the CONNECT Message includes a Will Message (Will Message), the service layer invokes the persistence layer to store the Will Message;

in step 2606, after the persistence layer receives the request from the Broker to query whether subscription relationship data exists, if the subscription relationship data exists in the persistence layer, updating the clearsession of the subscription relationship; and the service layer creates a CONNACK message according to the response of the persistence layer.

In some embodiments, as shown in fig. 27, the present application further provides an interaction flow with the persistence layer when the service layer processes a SUBSCRIBE message (subscription request).

In step 2702, the persistence layer processes the heartbeat and the perceived request of the Broker;

in step 2704, the persistence layer performs storage persistence after receiving the connection relationship and subscription relationship data sent by the Broker; the persistence layer queries the reservation message matching the subscription relationship and returns to the Broker so that the Broker pushes the reservation message to the newly connected terminal.

In some embodiments, as shown in fig. 28, the present application further provides an interaction flow between the service layer and the persistence layer when the service layer processes the PUBLISH message (issue request).

In step 2802, the persistence layer processes the heartbeat and the sensing request of the Broker;

in step 2804, after receiving a request from a Broker to save a reservation Message, the persistence layer persists the reservation Message, so as to send the reservation Message to a newly connected terminal subscribed to the Message when the Broker processes the SUBSCRIBE Message;

in step 2806, after the persistence layer receives the Broker request, the request is: the terminal subscribed to the PUBLISH message theme (Topic) and the state of the connected Broker are queried, and the persistence layer queries corresponding information and returns the corresponding information to the Broker so that the Broker can perform message pushing and message routing.

In some embodiments, as shown in fig. 29, the present application further provides an interaction flow with the persistence layer when the service layer processes an UNSUBSCRIBE message (UNSUBSCRIBE request).

In step 2902, the persistence layer processes the Broker heartbeat and the perception request as above;

in step 2904, after the persistence layer receives the request from the Broker to unsubscribe, the persistence layer updates the subscription relationship data, and returns a corresponding unsubscribe message to be created by the Broker.

In some embodiments, as shown in FIG. 30, the present application also provides an interaction flow with the persistence layer when the service layer processes the DICONNECT message (cancels the connection request)

In step 3002, the persistence layer processes the heartbeat and the sensing request of the Broker;

in step 3004, after receiving a request for deleting a Will Message (Will Message) sent by a Broker, if the corresponding Will Message exists in the persistent layer, executing a deletion logic, and if not, not executing any operation; the persistence layer returns a processing response.

In some embodiments, as shown in fig. 31, the present application further provides an interaction flow with the persistence layer when the Broker processes that the terminal of the internet of things device is disconnected abnormally.

In step 3102, the persistence layer processes the heartbeat and the perceived request of the Broker;

in step 3104, the persistence layer receives a request from the Broker to query the Will Message (Will Message), queries the Will Message, and returns a response;

In step 3106, if the legacy message exists, the Broker will continue to send a request to query the status of the terminal subscribed to the legacy message and the Broker connected thereto, and the persistence layer receives the request to query and returns a response to facilitate message pushing and message routing by the Broker; if the legacy message does not exist, the processing logic ends.

Compared with the prior art in the industry, the technical scheme provided by the invention has the following important distinguishing points and key points: the operation and storage separation architecture of the message queue system of the Internet of things; the service layer and the persistent layer are separated, nodes in the Broker cluster do not hold the connection relation and subscription relation data of the equipment end of the Internet of things, the data are held and maintained by the persistent layer, and the persistent layer provides a data service interface for the Broker cluster. The Broker node has no state, and can support expansion and contraction without limitation. The persistent layer has the function of a registry; the node state data in the Broker cluster is reported to the persistence layer at regular time, and the persistence layer has the role of a registration center, so that the system structure is simplified, and the operation, maintenance and maintenance cost is reduced. The persistence layer counts the states of the Broker cluster nodes, and the Broker cluster nodes dynamically sense the states of the cluster nodes in quasi-real time from the persistence layer.

The embodiment of the application also supports the elastic expansion and contraction of the Broker cluster and the high-performance large-scale cluster. In the related technical scheme, when the size of a Broker cluster is increased, millions, tens of millions or even billions of internet of things equipment are accessed into the cluster, each Broker in the cluster needs to maintain full-scale connection information and subscription information, and RPC calls among Broker nodes in the cluster also grow in geometric scale along with the number of the Broker nodes, so that the large-scale cluster performance is rapidly reduced. In the embodiment of the application, the nodes in the Broker cluster do not fully hold the connection relationship and the subscription relationship, but hold the information by the persistence layer, so that the cluster performance cannot be reduced along with the increase of the number of the Broker nodes, the large-scale cluster can be realized, and the billions-level access requirement of the Internet of things equipment is met. The persistence layer in the technical scheme also has the role of a registry, provides service for the service layer to dynamically sense the state data of other nodes in the cluster, and avoids the operation, maintenance and maintenance cost caused by using a third party component (etcd and the like).

The embodiment of the application also ensures the consistency of data and has strong fault tolerance capability. In the related technical scheme, the problem of inconsistent data among nodes caused by unstable network and downtime/recovery of the nodes is difficult to solve. Even if the molquito-cluster or EMQTT etc. propose respective solutions: all data of the clusters are held by all nodes, but the problems of complex logic, influence on performance and the like exist. In the embodiment of the application, the cluster data is maintained by the persistent layer, the nodes in the Broker cluster acquire the connection relationship and subscription relationship data from the persistent layer, the problem of data consistency is effectively solved, and the service is not affected by the failure of the Broker nodes. Consistency assurance of the persistence layer can be achieved by adopting a Raft algorithm.

Based on the foregoing embodiments, an embodiment of the present application further provides a request processing apparatus, where the request processing apparatus includes each module included, and each unit included in each module may be implemented by a processor in a terminal; of course, the method can also be realized by a specific logic circuit; in practice, the processor may be a central processing unit (Central Processing Unit, CPU), microprocessor (Micro Processing Unit, MPU), digital signal processor (Digital Signal Processor, DSP) or field programmable gate array (Field Programmable Gate Array, FPGA), etc.

Fig. 32 is a schematic diagram of a composition structure of a request processing apparatus according to an embodiment of the present application, as shown in fig. 32, the request processing apparatus 3200 includes a first receiving module 3201, a first sending module 3202, a second receiving module 3203, and an executing module 3204, where:

a first receiving module 3201, configured to receive a function request transmitted by a terminal;

a first sending module 3202, configured to send a query request corresponding to the function request to a persistence layer;

a second receiving module 3203, configured to receive a query result returned by the persistence layer; the query results are generated by the persistence layer from the persistence data.

And an execution module 3204, configured to execute a function operation corresponding to the function request according to the query result.

Fig. 33 is a schematic structural diagram of a request processing apparatus according to an embodiment of the present application, as shown in fig. 33, the request processing apparatus 3300 includes a third receiving module 3301, a generating module 3302, and a second sending module 3303, where:

a third receiving module 3301, configured to receive a query request sent by a service layer; the query request is generated by the service layer according to a function request transmitted by the terminal;

a generating module 3302, configured to generate a query result according to the persistent data;

a second sending module 3303, configured to send the query result to the service layer; the query result is used for indicating the service layer to execute the function operation corresponding to the function request.

It should be noted here that: the description of the apparatus embodiments above is similar to that of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, please refer to the description of the embodiments of the method of the present application.

It should be noted that, in the embodiment of the present application, if the request processing method is implemented in the form of a software functional module, and sold or used as a separate product, the request processing method may also be stored in a computer readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing a terminal (which may be a smart phone with a camera, a tablet computer, etc.) to perform all or part of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, an optical disk, or other various media capable of storing program codes. Thus, embodiments of the application are not limited to any specific combination of hardware and software.

Correspondingly, an embodiment of the application provides a computer readable storage medium, on which a computer program is stored, which computer program, when being executed by a processor, implements the steps of the request processing method according to any of the above embodiments.

Correspondingly, in the embodiment of the application, a chip is also provided, and the chip comprises a programmable logic circuit and/or program instructions, and when the chip runs, the chip is used for realizing the steps in the request processing method in any one of the above embodiments.

Correspondingly, in an embodiment of the application, there is also provided a computer program product for implementing the steps of the request processing method of any of the above embodiments, when the computer program product is executed by a processor of a terminal.

Based on the same technical concept, the embodiment of the application provides equipment for implementing the request processing method described in the embodiment of the method. Fig. 34 is a schematic hardware entity diagram of an apparatus according to an embodiment of the present application, as shown in fig. 34, where the apparatus 3400 includes a memory 3410 and a processor 3420, where the memory 3410 stores a computer program that can be run on the processor 3420, and the processor 3420 implements steps in any of the request processing methods according to the embodiments of the present application when executing the program.

The memory 3410 is configured to store instructions and applications executable by the processor 3420, and may also cache data (e.g., image data, audio data, voice communication data, and video communication data) to be processed or processed by the respective modules in the processor 3420 and the terminal, and may be implemented by a FLASH memory (FLASH) or a random access memory (Random Access Memory, RAM).

The processor 3420 implements the steps of any one of the request processing methods described above when executing a program. The processor 3420 generally controls the overall operation of the terminal 3400.

The processor may be at least one of an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a digital signal processor (Digital Signal Processor, DSP), a digital signal processing device (Digital Signal Processing Device, DSPD), a programmable logic device (Programmable Logic Device, PLD), a field programmable gate array (Field Programmable Gate Array, FPGA), a central processing unit (Central Processing Unit, CPU), a controller, a microcontroller, and a microprocessor. It will be appreciated that the electronic device implementing the above-mentioned processor function may be other, and embodiments of the present application are not limited in detail.

The computer readable storage medium/Memory may be a Read Only Memory (ROM), a programmable Read Only Memory (Programmable Read-Only Memory, PROM), an erasable programmable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), an electrically erasable programmable Read Only Memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic random access Memory (Ferromagnetic Random Access Memory, FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a Read Only optical disk (Compact Disc Read-Only Memory, CD-ROM); but may also be various terminals such as mobile phones, computers, tablet devices, personal digital assistants, etc., that include one or any combination of the above-mentioned memories.

It should be noted here that: the description of the storage medium and the terminal embodiments above is similar to that of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the storage medium and terminal embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application. The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In several embodiments provided by the present application, it should be understood that the disclosed terminal and method may be implemented in other manners. The above-described terminal embodiments are merely illustrative, and for example, the division of the units is merely a logical function division, and there may be other division manners in actual implementation, such as: multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. In addition, the various components shown or discussed may be coupled or directly coupled or communicatively coupled to each other via some interface, whether indirectly coupled or communicatively coupled to devices or units, whether electrically, mechanically, or otherwise. The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units; can be located in one place or distributed to a plurality of network units; some or all of the units may be selected according to actual needs to achieve the purposes of the embodiment of the present application.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may be separately used as one unit, or two or more units may be integrated in one unit; the integrated units may be implemented in hardware or in hardware plus software functional units.

Alternatively, the above-described integrated units of the present application may be stored in a computer-readable storage medium if implemented in the form of software functional modules and sold or used as separate products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing an apparatus automatic test line to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a removable storage device, a ROM, a magnetic disk, or an optical disk.

The methods disclosed in the method embodiments provided by the application can be arbitrarily combined under the condition of no conflict to obtain a new method embodiment.

The features disclosed in the several methods or terminal embodiments provided by the application can be arbitrarily combined under the condition of no conflict to obtain new method embodiments or terminal embodiments.

The foregoing is merely an embodiment of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of request processing, applied to a service layer, the service layer including at least one service node, the method comprising:

receiving a function request transmitted by a terminal;

sending a query request corresponding to the function request to a persistence layer;

receiving a query result returned by the persistence layer; the query result is generated by the persistence layer according to persistence data; the persistence data includes node state data for each of the service nodes;

executing the function operation corresponding to the function request according to the query result; wherein,

The method further comprises the steps of:

each service node sends a node state request to the persistent layer according to a preset frequency;

receiving node state responses generated and returned by the persistent layer according to the node state data of each service node; the node status response includes node status data for a service node of the at least one service node that is in a surviving state.

2. The request processing method according to claim 1, the method further comprising:

each service node sends heartbeat messages to the persistent layer according to the preset frequency;

and receiving a heartbeat confirmation message returned by the persistence layer.

3. The request processing method according to claim 1, the persistence data includes terminal state data of at least one terminal, the terminal state data including a connection relationship and a subscription relationship of the terminal;

the function request includes a connection request; the sending the query request message corresponding to the function request to the persistence layer includes: acquiring a connection relationship and a subscription relationship of the terminal carried in the connection request; sending a connection query request carrying the connection relationship and the subscription relationship to the persistence layer;

The step of receiving the query result returned by the persistence layer, and executing the function operation corresponding to the function request according to the query result, including: receiving a connection query result returned by the persistence layer; the connection query result is generated when the persistence layer queries and/or updates the connection relation and the subscription relation of the terminal in the persistence data; and sending connection feedback corresponding to the connection request to the terminal according to the connection query result.

4. A request processing method according to claim 3, the method further comprising:

obtaining the heritage data of the terminal carried in the connection request;

transmitting a legacy update request carrying the legacy data to the persistence layer;

and under the condition that the persistence layer updates the persistence data according to the remains data and generates a remains updating result, receiving the remains updating result returned by the persistence layer.

5. The request processing method according to claim 4, the method further comprising:

receiving a disconnection request sent by the terminal;

transmitting a legacy delete request corresponding to the disconnection request to the persistence layer;

And receiving a remain deleting result sent by the persistence layer.

6. The request processing method according to claim 4, the method further comprising:

under the condition that the terminal is disconnected abnormally, a legacy inquiry request is sent to the persistent layer;

and receiving a legacy inquiry result returned by the persistence layer.

7. The request processing method according to claim 6, the method further comprising:

under the condition that the remains inquiry result carries remains data of the terminal, transmitting a remains subscription terminal inquiry request to the persistent layer;

receiving a query result of the legacy subscription terminal returned by the persistence layer; the inquiry result of the legacy subscription terminal comprises terminal state data of at least one legacy subscription terminal subscribing to the legacy data and node state data of a target service node connected with each legacy subscription terminal;

and according to the terminal state data of the at least one legacy subscription terminal and the node state data of the target service node, transmitting the legacy data to the at least one legacy subscription terminal through the target service node in a survival state.

8. The request processing method according to claim 1, the persistence data includes terminal state data of at least one terminal, the terminal state data including a connection relationship and a subscription relationship of the terminal;

The function request includes a subscription request; the sending the query request message corresponding to the function request to the persistence layer includes: acquiring a connection relationship and a subscription relationship of the terminal carried in the subscription request; sending a subscription inquiry request carrying the connection relation and the subscription relation to the persistence layer;

the step of receiving the query result returned by the persistence layer, and executing the function operation corresponding to the function request according to the query result, including: receiving a subscription inquiry result returned by the persistence layer; the subscription query result is generated when the persistence layer stores the connection relation and the subscription relation of the terminal in the persistence data; and sending subscription feedback corresponding to the subscription request to the terminal according to the subscription query result.

9. The request processing method according to claim 8, wherein the subscription relation includes a target topic, and the subscription query result further carries a reserve message of the target topic in the case that the persistent layer queries the reserve message.

10. The request processing method according to claim 1, the persistence data includes terminal state data of at least one terminal, the terminal state data including a connection relationship and a subscription relationship of the terminal;

The function request includes a release request; the sending the query request message corresponding to the function request to the persistence layer includes: acquiring a target theme carried in the release request; sending a query issuing request carrying the target theme to the persistence layer;

the step of receiving the query result returned by the persistence layer, and executing the function operation corresponding to the function request according to the query result, including: receiving a release query result returned by the persistence layer; the publishing query result comprises terminal state data of at least one target terminal subscribed to the target theme and node state data of a target service node connected with each target terminal; and sending release feedback corresponding to the release request to the at least one target terminal through the target service node in the survival state according to the terminal state data of the at least one target terminal and the node state data of the target service node.

11. The request processing method according to claim 1, wherein the persistence data includes terminal status data of at least one terminal, the terminal status data including a connection relationship and a subscription relationship of the terminal,

The function request comprises a unsubscribe request; the sending the query request message corresponding to the function request to the persistence layer includes: acquiring a relationship to be unsubscribed of the terminal carried in the unsubscribed request; sending an unsubscribe query request carrying the relationship to be unsubscribed to the persistence layer;

the step of receiving the query result returned by the persistence layer, and executing the function operation corresponding to the function request according to the query result, including: receiving an unsubscribe query result returned by the persistence layer; the unsubscribed query result is generated when the persistence layer deletes the relationship to be unsubscribed of the terminal in the persistence data; and sending unsubscribe feedback corresponding to the unsubscribe request to the terminal according to the unsubscribe query result.

12. A method of request processing, applied to a persistence layer, the method comprising:

receiving a query request sent by a service layer; the query request is generated by the service layer according to a function request transmitted by the terminal;

generating a query result according to the persistent data;

sending the query result to the service layer; the query result is used for indicating the service layer to execute the function operation corresponding to the function request; wherein,

The persistence data comprises node state data of each service node in the service layer; the method further comprises the steps of:

receiving node state requests sent by each service node according to preset frequency;

generating a node state response according to the node state data of each service node; the node status response includes node status data for a service node in a surviving state of the at least one service node;

and sending the node status response to each service node.

13. The request processing method according to claim 12, the method further comprising:

receiving heartbeat messages sent by each service node according to the preset frequency;

generating a heartbeat confirmation message according to the heartbeat message sent by each service node;

and sending the heartbeat confirmation message to each service node.

14. The request processing method according to claim 12, the persistence data includes terminal status data of at least one terminal, the terminal status data including a connection relationship and a subscription relationship of the terminal;

the query request comprises a connection query request sent by the service layer; the connection inquiry request is generated by the service layer according to the connection request sent by the terminal;

The generating the query result according to the persistent data includes: acquiring a connection relation and a subscription relation of the terminal carried in the connection inquiry request; querying and/or updating the connection relation and the subscription relation of the terminal in the persistent data, and generating a connection query result;

the sending the query result to the service layer includes: sending the connection query result to the service layer; and the connection query result is used for indicating the service layer to send connection feedback corresponding to the connection request to the terminal.

15. The request processing method according to claim 14, the method further comprising:

receiving a legacy update request sent by the service layer; the legacy update request is generated by the service layer according to the legacy data of the terminal carried in the connection request;

updating the persistence data according to the legacy data and generating a legacy updating result;

and sending the remains updating result to the service layer.

16. The request processing method according to claim 15, the method further comprising:

receiving a heritage deleting request sent by the service layer; the heritage deletion request is generated by the service layer according to a disconnection request sent by the terminal;

Deleting the heritage data of the terminal and generating a heritage deleting result;

and sending the remains deleting result to the service layer.

17. The request processing method according to claim 15, the method further comprising:

receiving a legacy inquiry request sent by the service layer under the condition that the terminal is disconnected abnormally;

querying the legacy data of the terminal in the persistence data to generate a legacy query result; the legacy inquiry result is used for representing whether legacy data of the terminal exist in the persistent data; and under the condition that the persisted data contains the legacy data of the terminal, the legacy inquiry result also carries the legacy data of the terminal.

18. The request processing method according to claim 17, the method further comprising:

receiving a query request of a legacy subscription terminal sent by the service layer;

querying at least one legacy subscription terminal subscribing to the legacy data;

generating a query result of the legacy subscription terminal according to the persistence data; the inquiry result of the legacy subscription terminal comprises terminal state data of at least one legacy subscription terminal and node state data of a target service node connected with each legacy subscription terminal;

Transmitting a query result of the heritage subscription terminal to the service layer; the query result of the legacy subscription terminal is used for indicating the service layer to send the legacy data to the at least one legacy subscription terminal through the target service node in the surviving state.

19. The request processing method according to claim 12, wherein the persistence data includes terminal status data of at least one terminal, the terminal status data including a connection relationship and a subscription relationship of the terminal,

the query request comprises a subscription query request sent by the service layer; the subscription inquiry request is generated by the service layer according to the subscription request sent by the terminal;

the generating the query result according to the persistent data includes: acquiring a connection relationship and a subscription relationship of the terminal carried in the subscription inquiry request; storing the connection relation and the subscription relation of the terminal in the persistent data, and generating a subscription inquiry result;

the sending the query result to the service layer includes: sending the subscription query result to the service layer; and the subscription inquiry result is used for indicating the service layer to send subscription feedback corresponding to the subscription request to the terminal.

20. The request processing method according to claim 19, wherein the subscription relation includes a target topic, and the subscription query result further carries a reserve message of the target topic if the reserve message is queried.

21. The request processing method according to claim 12, wherein the persistence data includes terminal status data of at least one terminal, the terminal status data including a connection relationship and a subscription relationship of the terminal,

the query request comprises a release query request sent by the service layer; the release inquiry request is generated by the service layer according to the release request sent by the terminal;

the generating the query result according to the persistent data includes: acquiring a target theme carried in the issued query request; querying at least one target terminal subscribed to the target subject according to the persistent data and generating a publishing query result; the release query result comprises terminal state data of at least one target terminal and node state data of a target service node connected with each target terminal; sending a release query result to the service layer; and the release inquiry result is used for indicating the service layer to send release feedback corresponding to the release request to the at least one target terminal through the target service node in the survival state.

22. The request processing method according to claim 12, wherein the persistence data includes terminal status data of at least one terminal, the terminal status data including a connection relationship and a subscription relationship of the terminal,

the inquiry request comprises an unsubscribe inquiry request sent by the service layer; the unsubscribe query request is generated by the service layer according to the unsubscribe request sent by the terminal;

the generating the query result according to the persistent data includes: acquiring a relationship to be unsubscribed carried in the unsubscribed query request; deleting the relation to be unsubscribed of the terminal in the persistence data, and generating an unsubscribed inquiry result; sending the unsubscribe query result to the service layer; and the unsubscribe query result is used for indicating the service layer to send unsubscribe feedback corresponding to the unsubscribe request to the terminal.

23. A request processing apparatus, comprising:

the first receiving module is used for receiving the function request transmitted by the terminal;

the first sending module is used for sending a query request corresponding to the function request to the persistent layer;

the second receiving module is used for receiving the query result returned by the persistence layer; the query result is generated by the persistence layer according to persistence data; the persistence data includes node state data for each service node;

The execution module is used for executing the function operation corresponding to the function request according to the query result; wherein,

the first sending module is further configured to send a node status request to the persistent layer by each service node according to a preset frequency;

the second receiving module is further configured to receive a node status response generated and returned by the persistence layer according to the node status data of each service node; the node status response includes node status data for a service node in a surviving state of the at least one service node.

24. A request processing apparatus, comprising:

the third receiving module is used for receiving the query request sent by the service layer; the query request is generated by the service layer according to a function request transmitted by the terminal;

the generation module is used for generating a query result according to the persistence data; the persistence data comprises node state data of each service node in the service layer;

the second sending module is used for sending the query result to the service layer; the query result is used for indicating the service layer to execute the function operation corresponding to the function request; wherein,

the third receiving module is further configured to receive a node status request sent by each service node according to a preset frequency;

The generating module is further used for generating node state responses according to the node state data of each service node; the node status response includes node status data for a service node in a surviving state of the at least one service node;

the second sending module is further configured to send the node status response to each service node.

25. A request processing system, comprising: a service layer and a persistence layer; the service layer comprises at least one service node, and each service node is connected to the persistent layer;

the service layer is used for receiving a function request transmitted by a terminal and sending a query request corresponding to the function request to the persistence layer;

the persistence layer is used for generating a query result according to the persistence data and sending the query result to the service layer;

the service layer is further used for executing the function operation corresponding to the function request according to the query result;

the service layer is further configured to send a node status request to the persistent layer by each service node according to a preset frequency;

the persistence layer is further configured to generate a node status response according to the node status data of each service node, and send the node status response to each service node.

26. The request processing system of claim 25, said persistence layer comprising one hosting persistent node and at least one backup persistence node connected to said hosting persistent node; each of the service nodes is connected to the hosting durable node.

27. A request processing apparatus, characterized by comprising:

a memory for storing a computer program;

a processor for implementing the method of any one of claims 1 to 11 when executing a computer program stored in said memory.

28. A request processing apparatus, characterized by comprising:

a memory for storing a computer program;

a processor for implementing the method of any of claims 12 to 22 when executing a computer program stored in said memory.

29. A computer readable storage medium, characterized in that a computer program is stored for implementing the method of any one of claims 1 to 11 when executed by a processor.

30. A computer readable storage medium, characterized in that a computer program is stored for implementing the method of any of claims 12 to 22 when being executed by a processor.