CN114500660A

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

Info

Publication number: CN114500660A
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: 2022-05-13
Anticipated expiration: 2040-10-23
Also published as: CN114500660B

Abstract

The application provides a request method, a request device, 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 persistent layer; receiving a query result returned by the persistence layer; the query result is generated by the persistence layer according to persistent data; and executing the function operation corresponding to the function request according to the query result. By the method and the device, the bandwidth can be saved, and the service performance of each service node in a service layer is 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 request processing method, apparatus, device, and computer readable storage medium.

Background

The Internet of Things (The Internet of Things) means that any object or process needing monitoring, connection and interaction is collected in real time through various devices and technologies such as various information sensors, radio frequency identification technologies, global positioning systems, infrared sensors, laser scanners and The like, various required information such as sound, light, heat, electricity, mechanics, chemistry, biology, positions and The like is collected, ubiquitous connection between objects and between objects and people is realized through various possible network accesses, and intelligent sensing, identification and management of The objects and The processes are realized. The internet of things digitalizes the real world, draws the scattered information and integrates the digital information of objects, the application is very wide, and the application field mainly comprises the following aspects: the fields of transportation and logistics, industrial manufacturing, health care, intelligent environment (home, office, factory), personal and social, etc., and has a very broad market and application scenario.

Under a cluster 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 routing problem of the message between different service nodes. Namely, the terminal to be pushed needs to be found according to the subscription relationship 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 a connection/connection closing/subscription subscribing/subscription canceling request of a terminal, the request is broadcast to other service nodes, and therefore, each service node needs to store subscription relationship data of all terminals in the current local area network. 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 broadcast mode, 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 cannot be 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 and device and a computer readable storage medium.

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

an embodiment of the present application provides a method, including:

a request processing method, applied to a service layer comprising 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 persistent layer; receiving a query result returned by the persistence layer; the query result is generated by the persistence layer according to persistent data; and executing the function operation corresponding to the function request according to the query result.

An embodiment of the present application provides an apparatus, including:

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.

Embodiments of the present application provide a computer-readable storage medium, which stores executable instructions for causing a processor to implement the method provided by the embodiments of the present application when the processor executes the executable instructions.

The embodiment of the application has the following beneficial effects:

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

Drawings

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

FIG. 2 is a schematic flow chart diagram illustrating an alternative request processing method according to an embodiment of the present disclosure;

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

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

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

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

FIG. 7 is an alternative flow chart of a request processing method provided by an embodiment of the present application;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FIG. 24 is a block diagram of an overall design framework provided by an embodiment of the present application;

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

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

fig. 26 is a schematic view illustrating an interaction flow between a service layer and a persistent layer when processing a CONNECT message according to an embodiment of the present application;

fig. 27 is a schematic view of an interaction flow between a service layer and a persistent layer when the service layer processes a SUBSCRIBE message according to an embodiment of the present application;

fig. 28 is a schematic view illustrating an interaction flow between a service layer and a persistent layer when a PUBLISH packet is processed in the service layer according to an embodiment of the present application;

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

fig. 30 is a schematic view illustrating an interaction flow between a service layer and a persistent layer when a DISCONNECT message is processed by the service layer according to the embodiment of the present application;

fig. 31 is a schematic flowchart illustrating interaction between a Broker and a persistent layer when the Broker handles abnormal disconnection of an internet of things device terminal according to an embodiment of the present disclosure;

fig. 32 is a schematic structural diagram illustrating a request processing apparatus according to an embodiment of the present application;

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

fig. 34 is a hardware entity diagram of an apparatus according to an embodiment of the present disclosure.

Detailed Description

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

Referring to fig. 1, fig. 1 is an alternative architecture diagram of a request processing system 100 provided in the embodiment of the present application, in which a terminal 200 (exemplary shown are a terminal 200-1, a terminal 200-2, and a terminal 200-3) is connected to a service layer 300 for supporting a request processing application. At least one service node (illustratively, service node 300-1, service node 300-2, and service node 300-3) is included in the service layer 300, 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 a persistence layer 400, wherein the persistence layer 400 includes a primary persistence node and at least one backup persistence node connected to the primary persistence node (the primary persistence node 400-1, the backup persistence node 400-2, and the backup persistence node 400-3 are shown as examples). Each service node in the service layer 300 establishes a connection with the persistent layer 400 by establishing a connection with the host node 400-1.

The service layer is used for receiving a function request transmitted by the terminal and sending a query request corresponding to the function request to the persistent layer; the persistent layer generates a query result according to the persistent 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 an alternative flowchart of a request processing method provided in 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 can establish a connection with at least one terminal. The communication Protocol between The service node and The terminal may be one of an internet of things communication Protocol such as a hypertext transfer Protocol (HTTP), a websocket, an Extensible Messaging and Presence Protocol (XMPP), a CoAP (CoAP), a Message Queue Telemetry Transport (MQTT), which is not limited in this Application.

In this embodiment, taking MQTT protocol as an example of a communication protocol between a terminal and any service node in a service layer, the terminal may send function requests such as a connection request, a disconnection request, a subscription request, and a subscription cancellation request 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 receiving the function request transmitted by the terminal through the service node establishing 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 relationship and subscription relationship of each terminal in the request processing system are not stored in each service node of the service layer, but in the persistence layer. After receiving the function request sent by the terminal, the service layer determines the data to be queried according to the request type of the function request, and sends the corresponding query request to the persistent layer according to the data to be queried. Taking the function request as an example of a publishing request, after receiving a publishing request of a terminal on a target topic, a service node P in a service layer may determine, according to the type of the request, that data to be queried includes a target terminal subscribed to the target topic, a target service node connected to the target terminal, and a state of the target service node, and send a corresponding querying 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 persistent layer performs a query operation in the persistent data according to the query request and sends a query result to the service node connected to the terminal, and the service layer receives the query result returned by the persistent layer through the service node connected to the terminal. On the basis of the above example that the function request is an issue request, the service layer receives the query result through the service node P.

In step 208, the service layer executes the 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 an example of the release request, after receiving the target terminal subscribed to the target subject, the target service node connected with the target terminal and the state of the target service node, the service layer determines routing information according to the state, and sends the function feedback corresponding to the release request to the target terminal according to the routing information.

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

In some embodiments, referring to fig. 3, fig. 3 is an optional flowchart of a request processing method provided in an embodiment of the present application, and based on fig. 2, before step 202, step 302 to step 304 are further included.

In step 302, each service node sends a heartbeat message to the persistent layer according to a preset frequency.

In some embodiments, the persistent data stored in the persistent layer further includes node status data of each service node in the service layer, wherein the node status data may include a node Internet Protocol address (IP) and a node survival status of the service node, and the like.

In this embodiment, each service node in the service layer sends a heartbeat message to the persistent layer according to the preset frequency, the heartbeat message may carry a current node IP of the service node, and the persistent layer may update the node state data of the service node in the persistent data after receiving the heartbeat message sent by the service node according to the preset frequency, that is, update the node IP of the service node, and set the node survival state as the survival state. The persistent layer may also update the node state data of the service node in the persistent data, that is, set the node survival state to the failure state, in the case that the heartbeat message sent by the service node is not received within a preset period of time.

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 persistent layer.

As can be seen from the above exemplary implementation of fig. 3 in the embodiment of the present application, the heartbeat message is sent to the persistent layer by each service node, and persistent data stored in the persistent layer can be updated in real time, that is, the accuracy of node state data of each service node in the persistent 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 an optional flowchart of a request processing method provided in an embodiment of the present application, and based on fig. 2, before step 202, step 402 to step 404 are further included.

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

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

In some embodiments, the persistent data stored in the persistent layer also includes node state data for each service node in the service layer, where the node state data may include node IP and node survival status, etc. of the service node.

In some embodiments, each service node in the service layer sends a node status request to the persistent layer according to a preset frequency, wherein the node status request is used for requesting node status data of all service nodes in the current service layer. After receiving a node state request sent by any service node, the persistent layer traverses node state data of all service nodes in persistent data and determines the service node in a survival state. And the persistent layer sends the node state data of all the service nodes in the survival 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 serving node sends the node status request according to the preset frequency, the heartbeat message does not need to be sent again, because when the serving node sends the node status request according to the preset frequency, it already indicates that the serving node is in the alive 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 in the embodiment of the present application, each service node sends a node state request to the persistent layer, so that each service node can obtain node state data of each service node in the current service layer. Meanwhile, node state data of the service nodes are stored in the persistent layer, when the node state of the service nodes changes, the node state data of the service nodes 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 the service nodes through node state requests.

In some embodiments, referring to fig. 5, fig. 5 is an optional flowchart of the request processing method provided in this embodiment, based on fig. 2, when the function request sent by the terminal is a connection request, step 202 shown in fig. 2 may be updated to step 500, step 204 may be implemented by 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 with reference to the steps shown in fig. 5.

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

In some embodiments, the terminal may also send a connection request to a 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 of the service nodes to request a connection to the service node. The service layer may receive the connection request through the service node.

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

In some embodiments, the connection request may carry a Packet Identifier (Packet Identifier), a terminal Identifier (Client Identifier), a clear Session Identifier (clear Session) Identifier, a willingness Message (willmessage), and a connection relationship of the request Packet. Wherein, the connection relation includes the node identification of the service node to which the terminal needs to connect; the subscription relationship includes a clearing session identifier and a will data of the terminal.

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

In some embodiments, in response to the received connection request, the service layer may obtain a connection relationship and a subscription relationship of the terminal carried therein, where the connection relationship may include a correspondence between the terminal identifier and the service node, and the subscription relationship may include the will data of the terminal. The service layer sends a connection query request carrying the connection relation and the subscription relation of the terminal to the persistent layer. After receiving the connection query request, the persistent layer obtains the terminal state data of the terminal from the persistent 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 query request.

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

In some embodiments, after receiving the connection query request, the persistent layer obtains the connection relationship and the 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 the terminal state data of the terminal in the persistent 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. For the connection relation, the persistence layer updates the connection relation to the terminal state data of the terminal; for the subscription relationship, namely for the testimonial data of the terminal, the persistence layer stores the testimonial data into the terminal state data of the terminal.

In step 508, the service layer sends a 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 persistent layer sends a connection relationship storage result and a subscription relationship storage result thereof 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 the service node P1 requesting to establish a connection with the terminal C1, and obtains the subscription relationship (the purge session identifier and the will data of C1) and the connection relationship (the connection request of C1 to P1) of the terminal 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 P1, the persistent layer obtains the 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 (C1 requests to be connected to P1) carried in the connection request, so that the updating and the storage of the C1 connection relation are realized; the persistent layer can replace the historical subscription relationship with the subscription relationship (the clearing session identifier and the will data of C1) of C1 carried in the connection request, so as to update and store the subscription relationship of C1; the persistent layer can also add the subscription relationship (the clear session identifier and the will data of C1) of C1 carried in the connection request to the history subscription relationship, so as to implement the reserved storage of the C1 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 connection query result. The connection query result may include a connection relationship storage result and a subscription relationship storage result. After receiving the connection query result, the service layer sends the connection relationship storage result and the subscription relationship storage result to the terminal C1 in a connection feedback manner.

As can be seen from the foregoing exemplary implementation of fig. 5 in the embodiment of the present application, after receiving a connection request sent by a terminal, the embodiment of the present application may update terminal state data of the terminal in a persistent layer in time, so that a publishing message of a target topic in the connection request may be obtained in time. Meanwhile, because the terminal state data of the terminal is stored in the persistent layer, when the subscription relationship and/or the connection relationship needs to be updated, the update of the terminal state data can be completed only by sending a subscription query request to the persistent layer.

In some embodiments, referring to fig. 6, fig. 6 is an optional flowchart of a request processing method provided in an embodiment of the present application, and based on fig. 5, between any step after step 500, step 602 to step 606 are further included, which will be described with reference to the steps shown in fig. 6.

In step 602, the service layer obtains the will data of the terminal carried in the connection request.

In some embodiments, after receiving the connection request, the service layer queries whether there is any order data of the terminal in the connection request. Under the condition that the connection request carries the will data, the service layer acquires the will data.

In step 604, the service layer sends a will update request carrying the will data to the persistent layer.

In step 606, under the condition that the persistent layer updates the persistent data according to the testament data and generates a testament update result, the service layer receives the testament update result returned by the persistent layer.

In some embodiments, the historical will be stored when the persistent layer queries that the terminal does not have the historical will data, and the historical will data of the terminal is replaced by the update of the will data when the persistent layer queries that the terminal does not have the historical will data. Meanwhile, the persistent layer stores the behavior record in the process of storing the testament data and sends the behavior record as the testament update result to the service layer. The service layer receives the testament update result, the testament update result can be used for representing whether testament data is stored in persistent data, and the testament update result can also be used for representing the update mode of the testament data.

As can be seen from the foregoing exemplary implementation of fig. 6 in the embodiment of the present application, when the service layer receives the connection request, the service layer in the embodiment of the present application further obtains the guidance data therein, and stores the guidance data of the terminal in the persistent layer in time, and when the terminal is disconnected, the latest guidance data can be sent to the target terminal subscribing to the guidance data in time. Meanwhile, because the testament data of the terminal is stored in the persistent layer, when the testament data needs to be updated, the testament data can be updated only by sending a testament updating request to the persistent layer, and compared with the testament data updated in a broadcast mode in the prior art, the testament data does not need to be synchronized to other service nodes in the service layer in the embodiment of the application, so that the processing efficiency of the subscription request can be improved, the bandwidth is saved, and the service performance of each service node in the service layer is improved.

In some embodiments, referring to fig. 7, fig. 7 is an optional flowchart of a request processing method provided in an embodiment of the present application, and based on the above embodiments, the method further includes step 702 to step 706, which will be described with reference to the steps shown in fig. 7.

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

In some embodiments, the terminal also sends a disconnect request to the service layer, where the terminal has established a communication connection with a service node in the service layer, through which the terminal can send the disconnect request to the service layer.

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

In step 704, the service layer sends a request for deletion of a will order corresponding to the request for disconnection to the persistence layer.

In some embodiments, in response to the received disconnection request, the service layer may send a request for deletion of a will order carrying the terminal identification of the terminal to the persistence layer. After receiving the request for deleting the testament advice, the persistent layer queries testament advice data corresponding to the terminal identification in the persistent data, deletes the testament advice data under the condition that the testament advice data is found, generates a deletion result, and sends the testament advice deletion result carrying the deletion result to the service layer.

In step 706, the service layer receives the delete result of the will order sent by the persistence layer.

As can be seen from the foregoing exemplary implementation of fig. 7 in the embodiment of the present application, after a disconnection request sent by a terminal is received, the last data of the terminal in the persistent layer can be deleted in time in the embodiment of the present application. Meanwhile, because the testament data of the terminal is stored in the persistent layer, when the testament data needs to be deleted, the testament data can be deleted only by sending a testament deletion request to the persistent layer, and compared with the testament data deleted in a broadcast mode in the prior art, the testament data deleting method and the testament data deleting device do not need to synchronize the testament data to other service nodes in the service layer, so that the processing efficiency of subscription requests can be improved, the bandwidth is saved, and the service performance of each service node in the service layer is improved.

In some embodiments, referring to fig. 8, fig. 8 is an optional flowchart of a request processing method provided in an embodiment of the present application, and based on the above embodiments, the method further includes steps 802 to 804, which will be described with reference to the steps shown in fig. 8.

In step 802, in case of abnormal disconnection of the terminal, the service layer sends a request for a will order query to the persistent layer.

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

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

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

As can be seen from the above exemplary implementation of fig. 8, in the embodiment of the present application, under the condition that the terminal is abnormally disconnected, a corresponding will query result can be timely queried and obtained in the persistent layer.

In some embodiments, referring to fig. 9, fig. 9 is an optional flowchart of a request processing method provided in this embodiment of the application, and based on fig. 8, after step 804, step 902 to step 906 may be further included, which will be described with reference to the steps shown in fig. 9.

In step 902, the service layer sends a query request of the will order subscription terminal to the persistent layer when the query result of the will order carries the data of the will order of the terminal.

In some embodiments, after step 804, after the service layer queries the carried will-data of the terminal according to the will-query result, the service layer sends a query request of the will-subscribe terminal to the persistent layer, so as to obtain terminal state data of the will-subscribe terminal subscribing to the will-subscribe data and node state data of a target service node connected to each will-subscribe terminal.

In step 904, the service layer receives the inquiry result of the testimony subscription terminal returned by the persistent layer; the inquiry result of the testament subscription terminal comprises terminal state data of at least one testament subscription terminal subscribing the testament data and node state data of a target service node connected with each testament subscription terminal.

In some embodiments, after receiving a query request of a will order subscription terminal sent by a service layer, a persistent layer queries at least one will order subscription terminal subscribing to the will order data in persistent data, terminal state data of each will order subscription terminal can be obtained according to terminal state data of each terminal stored in the persistent data, a target terminal connected to each will order subscription terminal can be obtained according to a connection relationship of each will order subscription terminal, and node state data of a target service node connected to each will order subscription terminal can be obtained by combining node state data of each service node stored in the persistent data. And sending a terminal state data of a testament subscription terminal carrying at least one subscription testament data and a testament subscription terminal inquiry result of node state data of a target service node connected with each testament subscription terminal to a service layer.

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

In some embodiments, after receiving the terminal state data of the at least one will subscription terminal and the node state data of the target service node, the service layer sends the will data to the at least one will subscription terminal through the target service node in the alive state among the at least one target service node.

As can be seen from the above exemplary implementation of fig. 9, in the embodiment of the present application, under the condition that the result of the query of the will advice carries the data of the terminal, the terminal state data of at least one of the subscription terminals subscribing to the data of the will advice and the node state data of the target service node can be obtained in the persistent layer in time, so that the request processing efficiency is improved.

In some embodiments, referring to fig. 10, fig. 10 is an optional flowchart of the request processing method provided in this embodiment of the application, based on fig. 2, when the function request sent by the terminal is a subscription request, step 202 shown in fig. 2 may be updated to step 1000, step 204 may be implemented by 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 with reference to the steps shown in fig. 10.

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

In some embodiments, the terminal also sends a subscription request to the service layer, where the terminal has established a communication connection with a service node in the service layer, through which the terminal can send the subscription request to the service layer.

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

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

In some embodiments, the subscription request may carry a Packet Identifier (Packet Identifier), a subscription relationship, and a connection relationship of the request Packet. Wherein, the subscription relationship includes at least one target topic to which the terminal needs to subscribe, and a Quality of Service Level (QoS) corresponding to each target topic; the connection relationship includes a node identifier of a service node to which the terminal is currently connected.

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

In some embodiments, in response to the received subscription request, the service layer may send a subscription query request carrying the connection relationship and the subscription relationship of the terminal to the persistent layer. After receiving the subscription query request, the persistent layer obtains the terminal state data of the terminal from the persistent 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 query request.

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

In some embodiments, after receiving the subscription query request, the persistent layer obtains the connection relationship and the 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 the terminal state data of the terminal in the persistent data. Meanwhile, the persistent layer also generates a subscription 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 subscription query result to the service layer. The service layer receives the subscription query result.

In some embodiments, the persistent layer further queries, according to the subscription relationship carried in the subscription query request, a reservation message matching the subscription relationship. After the persistent layer queries the reservation message matched with the subscription relationship, the reservation message is carried in the subscription query result and is sent to the service layer. Correspondingly, under the condition that the persistent layer queries the reservation message of the target topic, the subscription query result received by the service layer also carries the reservation 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 persistent layer sends a connection relationship storage result and a subscription relationship storage result thereof to the terminal in a subscription feedback manner.

For example, for a subscription request sent by the terminal C2, the service layer receives the subscription request through the service node P2 connected to the terminal C2, and obtains the subscription relationship (C2 subscribes to the T2 topic) and the connection relationship (C2 is connected to the P2) of the terminal C2 carried in the subscription request; the service layer sends a subscription query request carrying the subscription relationship and the connection relationship of the C2 to the persistent layer through the P2, the persistent layer obtains the terminal state data of the C2, namely the historical connection relationship and the historical subscription relationship of the C2, and the persistent layer can replace the historical connection relationship by using the connection relationship (C2 is connected to the P2) of the C2 carried in the subscription request, so that the updating and the storage of the connection relationship of the C2 are realized; the persistent layer can replace the historical subscription relationship with the subscription relationship of C2 (the C2 subscribes to the T2 topic) carried in the subscription request, so as to update and store the C2 subscription relationship; the persistent layer can also add the subscription relationship of the C2 (the C2 subscribes to the T2 topic) carried in the subscription request to the historical subscription relationship, so as to implement the reserved 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 storage result and a subscription relationship storage result. After receiving the subscription query result, the service layer sends the connection relationship storage result and the subscription relationship storage result to the terminal C2 in a subscription feedback manner.

As can be seen from the foregoing exemplary implementation of fig. 10 in the embodiment of the present application, after receiving a subscription request sent by a terminal, the embodiment of the present application may update terminal state data of the terminal in a persistent layer in time, so that a publication message of a target topic in the subscription request may be obtained in time. Meanwhile, because the terminal state data of the terminal is stored in the persistent layer, when the subscription relationship and/or the connection relationship needs to be updated, the update of the terminal state data can be completed only by sending a subscription query request to the persistent layer.

In some embodiments, referring to fig. 11, fig. 11 is an optional flowchart of the request processing method provided in this embodiment, based on fig. 2, when the function request sent by the terminal is an issue request, step 202 shown in fig. 2 may be updated to step 1100, step 204 may be implemented by 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 with reference to the steps shown in fig. 11.

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

In some embodiments, the terminal also sends a publish request to the service layer, where the terminal has established a communication connection with a service node in the service layer through which the terminal can send the publish request to the service layer.

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

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

In some embodiments, the issue request may carry a Packet Identifier (Packet Identifier) of the request Packet, a target topic, a Quality of Service (QoS) Level corresponding to the target topic, a Payload (Payload), and the like, where the Payload is content actually issued in the issue request, and it is possible to send a picture, any encoded text, and encrypted data.

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

In some embodiments, in response to the received publication request, the service layer may send a publication query request carrying the target topic to the persistence layer. After receiving the query request, the persistent layer queries at least one target terminal subscribed to the target topic in persistent data, obtains terminal state data of the at least one target terminal, and obtains a target service node connected with the at least one target terminal according to a connection relationship of the terminal state data terminals of the at least one target terminal, so as to obtain node state data of each target service node.

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

In some embodiments, after receiving the query issuing request, the persistent layer may obtain a target topic carried in the query issuing request, and obtain the terminal state data of the at least one target terminal and the node state data of the at least one target service node in persistent data through the target topic. Meanwhile, the persistent layer generates a publishing query result comprising the terminal state data of at least one target terminal and the node state data of at least one target service node, and sends the publishing query result to the service layer. The service layer receives the published 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 alive 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 the at least one target terminal and the node state data of the at least one target service node, the service layer sends, to the at least one target terminal, a publishing feedback corresponding to the publishing request through a target service node in an alive state among the at least one target service node, that is, sends, to the at least one target terminal, a payload in the publishing request through the target service node in the alive state among the at least one target service node.

For example, for a publishing request sent by the terminal C3, the service layer receives the publishing request through the service node P3 connected to the terminal C3, and obtains a target topic T3 carried in the publishing request; the service layer sends a publishing query request carrying a target topic T3 to the persistent layer through P3, the persistent layer obtains terminal state data of at least one target terminal subscribing to the target topic T3, namely the connection relation and the subscription relation of the at least one target terminal, and according to the connection relation of the at least one target terminal, a target service node connected with the at least one target terminal can be obtained, so that node state data of each target service node can be obtained. The persistence layer may send 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 issuing the query. After receiving the publishing query result, the service layer determines a target service node in a survival state in the at least one target service node, and sends a publishing feedback corresponding to the publishing request to each target terminal through the target service node in the survival state corresponding to each target terminal according to the connection relationship of each target terminal, where the publishing feedback may be a payload in the publishing request.

As can be seen from the foregoing exemplary implementation of fig. 11 in 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 persistent 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 a release feedback corresponding to the release request can be sent to the target terminal in time. Meanwhile, because the terminal state data of each terminal and the node state data of each service node are stored in the persistent layer, when the message needs to be issued, the acquisition of the target terminal and the routing information can be completed only by sending the issuing query request to the persistent layer.

In some embodiments, referring to fig. 12, fig. 12 is an optional flowchart of the request processing method provided in this embodiment of the application, based on fig. 2, when the function request sent by the terminal is a request to cancel subscription, step 202 shown in fig. 2 may be updated to step 1200, step 204 may be implemented by steps 1202 to 1204, step 206 may be updated to step 1206, step 208 may be updated to step 1208, which will be described with reference to the steps shown in fig. 12.

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

In some embodiments, the terminal also sends a unsubscribe request to the service layer, wherein the terminal has established a communication connection with a service node in the service layer, and the terminal can send the unsubscribe request to the service layer through the communication connection.

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 the relation to cancel subscription of the terminal carried in the request to cancel subscription.

In some embodiments, the subscription request may carry a Packet Identifier (Packet Identifier) of the request Packet and a to-be-unsubscribed relationship. The relation to cancel subscription includes at least one target topic that the terminal needs to cancel subscription.

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

In some embodiments, in response to the received unsubscribe request, the service layer may send an unsubscribe query request carrying a to-be-unsubscribed relationship of the terminal to the persistent layer. After receiving the request for canceling subscription inquiry, the persistent layer obtains the terminal state data of the terminal from the persistent data, and updates the terminal state data of the terminal according to the relation of canceling subscription of the terminal carried in the request for subscribing inquiry.

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

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

In step 1208, the service layer sends a 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 persistent layer sends the deletion record therein to the terminal in a unsubscribe feedback manner.

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 the to-be-unsubscribe relationship of the C4 carried in the unsubscribe request (the C4 unsubscribes from the T4 topic); the service layer sends a request for canceling subscription inquiry carrying the subscription relationship to be canceled of the C4 to the persistent layer through the P4, the persistent layer obtains the terminal state data of the C4, that is, the historical subscription relationship of the C4, and the persistent layer can delete the subscription relationship corresponding to the subscription relationship to be canceled in the historical subscription relationship. The persistent layer may store 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 deleted record to the terminal C4 in a unsubscribe feedback manner.

As can be seen from the foregoing exemplary implementation of fig. 12 in the embodiment of the present application, after receiving a request to cancel subscription sent by a terminal, the embodiment of the present application may update terminal state data of the terminal in a persistent layer in time. Meanwhile, because the terminal state data of the terminal is stored in the persistent layer, when the subscription relationship and/or the connection relationship needs to be updated, the update of the terminal state data can be completed only by sending a subscription query request to the persistent layer.

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

In step 1302, the persistent layer receives a query request sent by the 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 comprises a main persistent node and at least one backup persistent node, wherein the host persistent node and the backup persistent node are designed by adopting a Raft algorithm, so that the reliability and the disaster tolerance capability of the persistent layer can be ensured.

In the embodiment, in the persistent layer, a plurality of persistent nodes form a Raft group, only one host persistent node (Leader node) is in one group, the rest are backup persistent nodes (Follower nodes), the host persistent nodes provide data service for the service layer, persistent data of the host persistent nodes are consistent with the backup persistent nodes, when the host persistent nodes fail, the backup persistent nodes start to compete to generate new host persistent nodes to continue providing service, and high availability of the persistent layer is ensured. Meanwhile, the persistent layer adopts a Multi-Raft-Group architecture, so that fragmented storage of state data such as subscription relation and the like is realized, the problem of read-write performance bottleneck of a single Raft Leader node is solved, and the high performance of the persistent layer is ensured.

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

In step 1306, the persistence layer sends the query results to the service layer; and 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 foregoing exemplary implementation of fig. 13 in the embodiment of the present application, by setting one main persistent node and at least one backup persistent node in a persistent layer, the read-write performance of the persistent layer can be improved, and the availability of the persistent layer is improved. In addition, in the embodiment of the application, the service layer stores the subscription relationship and/or the connection relationship required by the function request in persistent data of the persistent layer, and when the service node receives the function request of the terminal and needs to update the subscription relationship and/or the connection relationship, the service layer can update the subscription relationship and/or the connection relationship only by sending a query request to the persistent layer.

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

In step 1402, the persistent layer receives heartbeat messages sent by each serving node according to a preset frequency.

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

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

In some embodiments, referring to fig. 15, fig. 15 is an alternative flowchart of a request processing method provided in 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 state response from the node state data of each service node; the node status response includes node status data of a serving node of the at least one serving node that is in an alive state.

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 an optional flowchart of a request processing method provided in this embodiment of the application, and based on fig. 13, in a case that the query request sent by the 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 with reference to the steps shown in fig. 16.

In step 1602, the persistent 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 persistent layer obtains the connection relationship and subscription relationship of the terminal carried in the connection query request.

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

In step 1608, the persistence layer sends the connection query result to the service layer; and 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 an optional flowchart of a request processing method provided in the embodiments of the present application, and based on fig. 16, between any steps, step 1702 to step 1706 are further included, which will be described with reference to the steps shown in fig. 17.

In step 1702, the persistent layer receives an order update request sent by the service layer; the will order renewal request is generated by the service layer according to the terminal's will order data carried in the connection request.

In step 1704, the persistence layer updates the persistence data according to the testament data and generates a testament update result.

In step 1706, the persistence layer sends the result of the order update to the service layer.

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

In step 1802, the persistent layer receives a request for deleting the testament sent by the service layer; the request for deleting the will order is generated by the service layer according to the disconnection request sent by the terminal.

In step 1804, the persistent layer deletes the will order data of the terminal and generates a result of the deletion of the will order.

In step 1806, the persistence layer sends the delete result of the will order to the service layer.

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

In step 1902, the persistent layer receives a request for a testimony of advice that the service layer sends in case of an abnormal disconnection of the terminal.

In step 1904, the persistent layer queries the will data of the terminal in the persistent data to generate a query result of the will; the testament inquiry result is used for representing whether testament data of the terminal exist in the persistent data or not; and under the condition that the testament data of the terminal exists in the persistent data, the testament inquiry result also carries the testament data of the terminal.

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

In step 2002, the persistent layer receives a query request of the will subscribe terminal sent by the service layer.

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

In step 2006, the persistent layer generates a query result of the testimonial advice subscription terminal according to the persistent data; the inquiry result of the testament subscription terminal comprises terminal state data of at least one testament subscription terminal and node state data of a target service node connected with each testament subscription terminal.

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

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

In step 2102, the persistent layer receives 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.

In step 2104, the persistent layer obtains the connection relationship and the 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; and the connection inquiry 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 the target topic, and in the case of querying a reservation message of the target topic, the subscription query result also carries the reservation message.

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

In step 2202, the persistent layer receives a request for issuing a query 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 persistent layer obtains the target topic carried in the request to issue the query.

In step 2206, the persistent layer queries at least one target terminal subscribed to the target topic according to the persistent data and generates a published query result; the issuing inquiry 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.

In step 2208, the persistence layer sends the publish query result to the service layer; and 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 an optional flowchart of a request processing method provided in the embodiments of the present application, and will be described with reference to the steps shown in fig. 23.

In step 2302, the persistent layer receives a unsubscribe query request sent by the service layer; the request for requesting to cancel the subscription inquiry is generated by the service layer according to the request for canceling the subscription sent by the terminal.

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

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

In step 2308, the persistence layer sends 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.

Next, 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 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 internet of things is called as the third wave of development of the world information industry after computers and the internet through the fusion application of intelligent perception, identification technology, pervasive computing and ubiquitous networks. The internet of things digitalizes the real world, draws the scattered information and integrates the digital information of objects, the application is very wide, and the application field mainly comprises the following aspects: the fields of transportation and logistics, industrial manufacturing, health care, intelligent environment (home, office, factory), personal and social, etc., and has a very broad market and application scenario.

The internet of things with all things interconnected is realized, and most importantly, the communication between equipment in the internet is realized. Communication protocols of the internet of things, which are relatively common in communication in the internet, include: HTTP, websocket, XMPP, COAP, MQTT. Compared with several other communication protocols, MQTT is a "lightweight" communication protocol based on publish/subscribe (publish/subscribe) mode, which is built on TCP/IP protocol and published by IBM in 1999. The MQTT takes into account the difference of the computing performance of different devices in the protocol design, so all protocols adopt binary format coding and decoding, and the coding and decoding formats are very easy to develop and implement. The minimum data packet only has 2 bytes, and the method has good adaptability to low-power-consumption and low-speed networks. There is a very perfect QoS mechanism, and at most once, at least once, and exactly once three message delivery modes can be selected according to service scenarios. The method runs on a TCP protocol, and simultaneously supports a TLS (TCP + SSL) protocol, so that the safety is better ensured.

The method has the advantages that the method is interconnection of everything, the devices are numerous, the performance of a single MQTT server is limited, the connection requirements of numerous devices are difficult to meet, and the high-availability cluster of the MQTT server is particularly important in the application of the Internet of things. At present, the open-source MQTT proxy server (including the message queue supporting the MQTT protocol) supporting the cluster mode mainly comprises an EMQ and an Apache ActiveMQ. No clustering solution is given by the Mosquitto authority. In the cluster mode, millions of terminals are connected to different nodes, and the terminals can publish messages at any node and publish messages. After a message is published, the message needs to be pushed to a corresponding subscription terminal as required, which needs to solve the routing problem of the message between different nodes. That is, the terminal to be pushed needs to be found according to the subscription relationship of each terminal, and then the message is forwarded to the node to which the terminal is connected. Solutions to this problem by ActiveMQ, Mosquitto, and EMQ are as follows:

and broadcasting to other nodes after receiving a connection/connection closing/subscription subscribing/unsubscription request of the terminal, and storing the full amount of subscription relation data in each node. Considering that network problems occur at any time among nodes and data inconsistency occurs among the nodes due to downtime and recovery of the nodes, the cluster provides a retry mechanism after broadcast failure. In addition, when a node is detached from the cluster due to downtime and the like, after the node is rejoined to the cluster, other nodes send all the subscription data of the node to prevent the subscription data of the node from being lost.

It can be seen that the conventional techniques have the following disadvantages:

(1) large-scale clustering cannot be supported.

Assume that there are N service nodes in the cluster, each service node needs to maintain a long connection with N-1 other service nodes, and each connect/close connect/subscribe/unsubscribe request generates N-1 RPC calls. When the size of the service node is increased, the PRC requests occupy a large amount of bandwidth, and the performance is sharply reduced due to geometric growth. If a broadcasting mode is adopted, a host which does not need to receive information can also receive the information, the safety of the information cannot be guaranteed, the information in the same network segment is inundated, and a large amount of bandwidth can be wasted.

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

The problem of data inconsistency among the service nodes caused by network instability and downtime/recovery of the service nodes is difficult to solve. Even though ActiveMQ, mosquitto-cluster or EMQ propose respective solutions, the problems of logic complexity, influence on performance and the like exist.

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

The Mosquitto-cluster supports horizontal extension, but when the cluster size is large and a new terminal (Client) subscribes/unsubscribes, all other cookies need to be informed, and when the network between the Client and the cluster of the cookies is unstable, so that the Client and the cluster of the cookies are frequently reconnected to send subscription/unsubscribe messages, a large number of requests can be generated among clusters of the cookies, and the performance is influenced.

The EMQ message server cluster is designed based on Erlang/OTP distribution, all nodes of the same cluster of the EMQ message server can copy a routing table mapped by a theme (Topic) and a Broker node, and when a plurality of terminals and a plurality of subscription themes exist, the memory occupied by the routing table is not small and varies, so that the sufficient memory of the server is ensured; in addition, when the cross-endpoint persistent session is processed, if the node maintaining the persistent session fails, the service is abnormal.

The embodiment of the application adopts a calculation and storage separation architecture design, a connection relation and subscription relation data persistence layer is designed based on a Raft algorithm, a calculation service layer is stateless, the persistence layer has the function of a registration center, and a high-performance, elastic expansion and contraction and high-availability message queue system facing the Internet of things is realized.

As shown in fig. 24, which is a schematic diagram of a general design framework provided by the embodiment of the present application, MQTT Broker starts and saves its own information to the persistent layer, and the Broker can obtain other Broker information from the persistent layer to form a Broker cluster with each other. The Internet of things equipment is connected to the Broker cluster through the load balancing server, and the Broker cluster enables the connection relation and subscription relation data of the Internet of things equipment to be persistent to a persistent layer. The service layer does not hold the state data of the connection relation and the subscription relation, so that the Broker node is stateless and can support unlimited horizontal extension. 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 Follower in a competitive way to provide service for a Broker cluster. Meanwhile, the persistent layer is designed by a Multi-Soft-Group architecture, the stored state data is stored in a fragmentation mode when necessary, the problem of performance bottleneck of a single-Soft cluster Leader node is solved, and overall high availability and horizontal expansion of the persistent layer are achieved. According to the scheme of the invention, a Broker service providing layer and a subscription relationship persistent layer are defined not to be tightly coupled, the Broker does not hold subscription relationship data, and each request for connecting/closing connection/subscribing/unsubscribing the Internet of things equipment only generates one call of the service layer to the subscription relationship persistent layer. The persistent layer maintains subscription relationship data, so that even if a Broker providing service fails, the Internet of things equipment is reconnected to other brokers, and MQTT messages can be normally received and sent without sending unnecessary subscription messages. The scheme of the invention supports the elastic expansion and contraction of the Broker and the durable layer, and is suitable for large-scale clustering. The data consistency is ensured by the aid of the persistence layer designed based on the Raft algorithm, and the high availability performance of the system is integrally improved.

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

(1) a persistent layer: and the method is designed based on a Raft algorithm and is used for ensuring the reliability and disaster tolerance capability of the persistence layer. The method is responsible for maintaining connection relation data and subscription relation data of the internet of things device connected to the Broker, such as an address of the Broker to which an MQTT terminal of the internet of things device is connected, a Will Message (willmessage), a reservation Message (RetainMessage), an offline Message, a subscribed Topic (Topic), a Message quality of service (QoS) of the subscribed Topic, a clear session flag (clearsession) and the like. In addition, the persistent layer also maintains relevant information of the Broker nodes, such as the IP (Internet protocol) and the survival state of the Broker nodes, has the functions of a registry and is realized by referring 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, and the rest are Follower nodes, the Leader node provides data service for the Broker layer, the data of the Follower nodes is consistent with the Leader node, when the failure of the Leader node is down, the Follower nodes start to race, a new Leader node is generated to continue providing service, and the high availability of the persistent layer is ensured. Meanwhile, the persistent layer adopts a Multi-Raft-Group architecture, so that fragmented storage of state data such as subscription relation and the like is realized, the problem of read-write performance bottleneck of a single Raft Leader node is solved, and the high performance of the persistent layer is ensured.

For example, please refer to fig. 25A for a schematic diagram of a persistent node failure. Before a fault occurs, a persistent node 1, a persistent node 2, a persistent node 3, a persistent node 4 and a persistent node 5 exist in a persistent layer, wherein the persistent node 1 is a master persistent node, the rest nodes are backup persistent nodes, after the fault occurs, the master persistent node 1 and the backup master persistent node 2 fail, the persistent node 3, the persistent node 4 and the persistent node 5 compete again for removing a new master persistent node, and the persistent node 3 shown in the figure becomes a master persistent node and continues to provide services.

(2) And (3) a service layer: each Broker needs to dynamically sense the currently alive Broker in the cluster, and here, if a third-party component (such as zookeeper or etcd) is used to save the current online state of each Broker, the complexity of the whole scheme design is increased, and a lot of burden is also caused to the 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, in which a lightweight registry is implemented by means of the persistence layer, and functions of service registration and service discovery are provided. When each Broker instance is started, self information is stored in the persistent layer, and heartbeat packets are sent regularly to maintain the online state of the Broker instance. Other brokers can dynamically perceive other brokers in the cluster in near real time by accessing the persistence layer. No matter a new Broker is added into the cluster or the cluster is down due to the fault of the Broker, other normally working Brokers can dynamically sense the state information and complete the routing of messages among the cluster Brokers. A plurality of Broker form a cluster to provide service for the MQTT terminal of the Internet of things equipment.

In some embodiments, the present application also provides an interaction scenario between the service layer and the persistent layer. In the proposal, the service layer and the persistent layer have more interactive scenes, and the interactive scenes are classified and explained according to the message types sent by the equipment terminal of the Internet of things. In the following flow, some descriptions such as message inspection of the service layer are omitted, and the interaction between the service layer and the persistent layer is mainly described.

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

In step 2602, after receiving a heartbeat packet of a Broker and a request for sensing a cluster alive Broker, the persistent layer updates state information of the current Broker, queries the state of the alive Broker, and returns the state information to the Broker, so as to perform message routing between the cluster brokers in the subsequent processing of the PUBLISH message;

in step 2604, if the CONNECT Message includes a testament Message (wil Message), the service layer calls the persistent layer to store the testament Message;

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

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

In step 2702, the persistence layer handles heartbeat of the Broker and sensing requests as above;

in step 2704, the persistent layer performs storage persistence after receiving the connection relationship and subscription relationship data sent by the Broker; the persistent layer queries the reservation message matching the subscription relationship and returns the reservation message 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 interactive flow with the persistent layer when the service layer processes the PUBLISH message (issue request).

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

in step 2804, after receiving the request of Broker to store the reservation Message (Retain Message), the persistent layer persists the reservation Message for the Broker to send to the newly connected terminal subscribed with the Message when processing SUBSCRIBE Message;

after the persistence layer receives the Broker request, in step 2806, the request is: inquiring the state of a terminal subscribed with a PUBLISH message Topic (Topic) and a Broker connected with the terminal, inquiring corresponding information by a persistent layer, and returning the information to the Broker so as to facilitate the Broker to carry out message pushing and message routing.

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

In step 2902, the persistence layer handles the Broker heartbeat and sensing request as above;

in step 2904, after receiving the request of Broker to cancel subscription, the persistent layer updates the subscription relationship data and returns the response so that the Broker can create an unsubsack message.

In some embodiments, as shown in fig. 30, the present application further provides an interactive flow with the persistent layer when the service layer processes the DISCONNECT message (cancel connection request)

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

in step 3004, after receiving a request for deleting a Will order Message (wil Message) sent by the Broker, the persistent layer executes a deletion logic if there is a corresponding Will order Message in the persistent layer, and does not perform any operation if there is no; the persistence layer returns a processing response.

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

At step 3102, the persistence layer processes the heartbeat of the Broker and the sensing request as above;

in step 3104, the persistent layer receives a request of Broker to query a Will order Message (wil Message), queries the Will order Message, and returns a response;

in step 3106, if the will-order message exists, the Broker continues to send a request to query the status of the terminal subscribed with the will-order message and the Broker connected thereto, and the persistent layer receives the request to query and return a response, so that the Broker performs message pushing and message routing; if the will information does not exist, the processing logic ends.

Compared with the prior art, the invention has the following important difference points and key points: an operation storage separation framework of an internet of things message queue system; the service layer and the persistence layer are separated, nodes in the Broker cluster do not hold data of the connection relation and the subscription relation of the equipment end of the Internet of things, the data are maintained by the persistence layer, and the persistence layer provides a data service interface for the Broker cluster. The Broker node is stateless and can support capacity expansion and capacity reduction without limit. The persistent layer has the function of a registration center; the node state data in the Broker cluster is reported to the persistent layer at regular time, the persistent layer has the role of a registration center, the system structure is simplified, and the operation and maintenance cost is reduced. And 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 a quasi-real time manner from the persistence layer.

The embodiment of the application also supports the flexible 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 or even hundreds of millions of internet-of-things equipment is accessed into the cluster, each Broker in the cluster needs to maintain full connection information and subscription information, RPC calls among Broker nodes in the cluster are increased in a geometric level along with the number of Broker nodes, and the performance of large-scale clusters is sharply reduced. In the embodiment of the application, nodes in the Broker cluster do not have a connection relationship and a subscription relationship in a full quantity, but the information is held by the persistent layer, so that the cluster performance is not reduced along with the increase of the number of the Broker nodes, the cluster can be massively clustered, and the requirement of accessing hundreds of millions of levels of equipment of the Internet of things is met. The persistent layer in the technical scheme also has the role of a registration center, provides service for the service layer to dynamically sense state data of other nodes in the cluster, and avoids operation and maintenance cost brought by using third-party components (zookeeper, etcd and the like).

The embodiment of the application also ensures data consistency and has strong fault disaster tolerance capability. In the related technical scheme, the problem of data inconsistency among nodes caused by network instability and node downtime/recovery is difficult to solve. Even though mosquitto-cluster or EMQTT, etc. propose respective solutions: all the data of the cluster are held by all the nodes, but the problems of complicated logic, influence on performance and the like exist. In the embodiment of the application, the cluster data is maintained by the persistence layer, the nodes in the Broker cluster acquire the connection relation and subscription relation data from the persistence layer, the problem of data consistency is effectively solved, and the service cannot be influenced by the fault of the Broker node. The consistency guarantee of the persistence layer can be realized 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 included module and each unit included in each module, and may be implemented by a processor in a terminal; of course, the implementation can also be realized through a specific logic circuit; in the implementation process, the Processor may be a Central Processing Unit (CPU), a microprocessor Unit (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.

Fig. 32 is a schematic structural diagram of a request processing apparatus according to an embodiment of the present disclosure, and 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 persistent layer;

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

An executing module 3204, configured to execute a functional operation corresponding to the functional 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, and 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 an inquiry request sent by a service layer; the query request is generated by the service layer according to a function request transmitted by a 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; and the query result is used for indicating the service layer to execute the function operation corresponding to the function request.

Here, it should be noted that: the above description of the apparatus embodiments, similar to the above description of the method embodiments, has similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

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 standalone product, the request processing method may also be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, where the computer software product is stored in a storage medium and includes several instructions to enable a terminal (which may be a smartphone with a camera, a tablet computer, or the like) to execute 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 usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

Correspondingly, the present application provides a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the steps in any of the request processing methods described in the foregoing embodiments.

Correspondingly, in an embodiment of the present application, a chip is further provided, where the chip includes a programmable logic circuit and/or program instructions, and when the chip runs, the chip is configured to implement the steps in any of the request processing methods in the foregoing embodiments.

Correspondingly, in the embodiment of the present application, there is also provided a computer program product, which is used to implement the steps in the request processing method in any of the foregoing embodiments when the computer program product is executed by a processor of a terminal.

Based on the same technical concept, the embodiment of the present application provides an apparatus for implementing the request processing method described in the above method embodiment. Fig. 34 is a hardware entity diagram of an apparatus provided in the embodiment of the present application, as shown in fig. 34, the apparatus 3400 includes a memory 3410 and a processor 3420, the memory 3410 stores a computer program operable on the processor 3420, and the processor 3420 executes the computer program to implement the steps in any request processing method according to the embodiment of the present application.

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

The processor 3420, when executing the program, implements the steps of any of the request processing methods described above. 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 (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understood that the electronic device implementing the above-described processor function may be other electronic devices, and the embodiments of the present application are not limited in particular.

The computer-readable storage medium/Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a magnetic Random Access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical Disc, or a Compact Disc Read-Only Memory (CD-ROM), and the like; 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.

Here, it should be noted that: the above description of the storage medium and terminal embodiments is similar to the description of the method embodiments described above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the storage medium and the terminal of the present application, reference is made to the description of the embodiments of the method 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 the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits 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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In the several embodiments provided in the present application, it should be understood that the disclosed terminal and method can be implemented in other manners. The above-described terminal embodiments are merely illustrative, for example, the division of the unit is only one logical function division, and there may be other division ways 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 implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms. The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units; can be located in one place or distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiments of the present application.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing an automatic test line of a device to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a magnetic or optical disk, or other various media that can store program code.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

The features disclosed in several of the method or terminal embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments or terminal embodiments.

The above description is only for the embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present application, and shall 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 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 persistent layer;

receiving a query result returned by the persistence layer; the query result is generated by the persistence layer according to persistent data;

and executing the function operation corresponding to the function request according to the query result.

2. The request processing method of claim 1, the persistent data comprising node state data for each of the service nodes; the method further comprises the following steps:

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

and receiving the heartbeat confirmation message returned by the persistent layer.

3. The request processing method of claim 2, the method further comprising:

each service node sends a node state request to the persistent layer according to the 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 serving node of the at least one serving node that is in an alive state.

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

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

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

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

acquiring the testament data of the terminal carried in the connection request;

sending a testament update request carrying the testament data to the persistent layer;

and under the condition that the persistent layer updates the persistent data according to the testament data and generates a testament update result, receiving the testament update result returned by the persistent layer.

6. The request processing method of claim 5, the method further comprising:

receiving a disconnection request sent by the terminal;

sending a request for deleting the wisdom corresponding to the disconnection request to the persistent layer;

and receiving a result of deleting the testament order sent by the persistent layer.

7. The request processing method of claim 5, the method further comprising:

sending a testament inquiry request to the persistent layer under the condition that the terminal is abnormally disconnected;

and receiving the testament inquiry result returned by the persistent layer.

8. The request processing method of claim 7, the method further comprising:

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

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

and sending the testament order data to the at least one testament order subscription terminal through the target service node in a survival state according to the terminal state data of the at least one testament order subscription terminal and the node state data of the target service node.

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

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

the receiving of the query result returned by the persistent layer and the execution of the function operation corresponding to the function request according to the query result include: receiving a subscription query result returned by the persistent layer; the subscription query result is generated by the persistence layer when the connection relationship and the subscription relationship of the terminal are stored in the persistent data; and sending subscription feedback corresponding to the subscription request to the terminal according to the subscription query result.

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

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

the function request comprises an issue request; the sending of the query request message corresponding to the function request to the persistent layer includes: acquiring a target theme carried in the release request; sending a publishing query request carrying the target topic to the persistent layer;

the receiving of the query result returned by the persistent layer and the execution of the function operation corresponding to the function request according to the query result include: receiving a release query result returned by the persistent layer; the issuing and inquiring result comprises terminal state data of at least one target terminal subscribing the target subject 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.

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

the function request comprises a unsubscribe request; the sending of the query request message corresponding to the function request to the persistent layer includes: acquiring a relation to be unsubscribed of the terminal carried in the unsubscribe request; sending a request for canceling subscription inquiry carrying the relation of subscription to be canceled to the persistent layer;

the receiving of the query result returned by the persistent layer and the execution of the function operation corresponding to the function request according to the query result include: receiving a unsubscribe query result returned by the persistent layer; the unsubscribe query result is generated when the persistent layer deletes the relation of subscription to be unsubscribed of the terminal in the persistent data; and sending a subscription cancellation feedback corresponding to the subscription cancellation request to the terminal according to the subscription cancellation query result.

13. A method for processing a request, 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 a terminal;

generating a query result according to the persistent data;

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

14. The request processing method of claim 13, the persistent data comprising node state data for each service node in the service layer; the method further comprises the following steps:

receiving heartbeat messages sent by each service node according to a 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.

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

receiving a node state request sent by each service node according to the preset frequency;

generating a node state response according to the node state data of each service node; the node status response comprises node status data of a service node in an alive state among the at least one service node;

and sending the node feedback message to each service node.

16. The request processing method according to claim 15, wherein the persistent data includes terminal status data of at least one terminal, the terminal status data includes 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 query results from the persisted data comprises: acquiring the connection relation and subscription relation of the terminal carried in the connection inquiry request; inquiring and/or updating the connection relation and the subscription relation of the terminal in the persistent data, and generating a connection inquiry result;

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

17. The request processing method of claim 16, the method further comprising:

receiving a testimony updating request sent by the service layer; the will order updating request is generated by the service layer according to the will order data of the terminal carried in the connection request;

updating the persistent data according to the testament data and generating a testament update result;

and sending the testimony updating result to the service layer.

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

receiving a request for deleting the testimony advice sent by the service layer; the request for deleting the will advice is generated by the service layer according to the request for disconnecting the connection sent by the terminal;

deleting the testament data of the terminal and generating a testament deletion result;

and sending the result of deleting the testimony advice to the service layer.

19. The request processing method of claim 17, the method further comprising:

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

querying the testament data of the terminal in the persistent data to generate a testament query result; the testament inquiry result is used for representing whether testament data of the terminal exist in the persistent data or not; and under the condition that the besom data of the terminal exists in the persistent data, the besom inquiry result also carries the besom data of the terminal.

20. The request processing method of claim 19, the method further comprising:

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

inquiring at least one testament subscription terminal for subscribing the testament data;

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

sending the inquiry result of the testimony subscription terminal to the service layer; and the inquiry result of the testament order subscribing terminal is used for indicating the service layer to send the testament order data to the at least one testament order subscribing terminal through the target service node in the survival state.

21. The request processing method according to claim 15, wherein the persistent data includes terminal status data of at least one terminal, the terminal status data includes 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 a subscription request sent by the terminal;

the generating query results from the persisted data comprises: acquiring the connection relation and the subscription relation 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 query result;

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

22. The request processing method of claim 21, wherein the subscription relationship includes a target topic, and the subscription query result further carries a reservation message of the target topic when the reservation message is queried.

23. The request processing method according to claim 15, wherein the persistent data includes terminal status data of at least one terminal, the terminal status data includes a connection relationship and a subscription relationship of the terminal,

the query request comprises a query issuing 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;

the generating query results from the persisted data comprises: acquiring a target theme carried in the query issuing request; inquiring at least one target terminal subscribed to the target theme according to the persistent data and generating a published inquiry result; the issuing inquiry result comprises terminal state data of the at least one target terminal and node state data of a target service node connected with each target terminal; sending the issuing inquiry result to the service layer; and the issuing inquiry result is used for indicating the service layer to send issuing feedback corresponding to the issuing request to the at least one target terminal through the target service node in the survival state.

24. The request processing method according to claim 15, wherein the persistent data includes terminal status data of at least one terminal, the terminal status data includes a connection relationship and a subscription relationship of the terminal,

the query request comprises a unsubscribe query request sent by the service layer; the request for requesting to cancel subscription is generated by the service layer according to the request for canceling subscription sent by the terminal;

the generating query results from the persisted data comprises: acquiring a relation to be unsubscribed carried in the unsubscribe inquiry request; deleting the relation of the terminal to be unsubscribed from the persistent data, and generating an unsubscribe query 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.

25. 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 the 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 persistent data;

and the execution module is used for executing the function operation corresponding to the function request according to the query result.

26. 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 a terminal;

the generating module is used for generating a query result according to the persistent data;

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

27. 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 persistent layer;

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

and the service layer is also used for executing the function operation corresponding to the function request according to the query result.

28. The request processing system of claim 27, the persistence layer comprising a primary persistence node and at least one backup persistence node connected to the host persistent node; each service node is connected with the host node.

29. An apparatus, comprising:

a memory for storing a computer program;

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

30. An apparatus, comprising:

a memory for storing a computer program;

a processor for implementing the method of any one of claims 13 to 24 when executing the computer program stored in the memory.

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

32. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method of any one of claims 13 to 24.