A message subscription notification method and system supporting delivery confirmation

Abstract

The present invention relates to a message subscription notification method and system supporting delivery confirmation, the method comprising: setting key fields for subscription and message publishing communications between a subscription client Watch_Client, a publishing client Notify_Client and a server Server; establishing a subscription channel management mechanism supporting delivery confirmation for the Client and the Server respectively according to the key fields; and performing subscription and message publishing between Watch_Client, Notify_Client and the Server based on the subscription channel management mechanism. The present invention supports delivery confirmation of message publishing, supports concurrent publishing, concurrent waiting for delivery confirmation, adopts a highly available WatchChannel mechanism, supports successful message publishing in temporary fault scenarios, has high fault tolerance, and supports timeout reconnection waiting in fault scenarios.

Description

Technical Field

[0001] The present invention relates to the field of cloud sharing technology, and in particular to a message subscription notification method and system supporting delivery confirmation. Background Art

[0002] In the shared cloud hard disk scenario, since there are multiple cloud hosts mounting the same cloud hard disk, the metadata management of the cloud hard disk needs to be consistent between cloud host clients. Any modification of the cloud hard disk metadata by any client needs to be synchronized to all cloud hosts mounting the cloud hard disk, such as snapshot and QOS modification.

[0003] If the modification of cloud disk metadata is not synchronized to all cloud hosts in time, cloud hosts will read and write cloud disks based on expired metadata, making the cloud disk status unpredictable. Therefore, a reliable message notification mechanism is needed to confirm that all modifications are delivered to the host that mounts the cloud disk in time.

[0004] In some application scenarios, the host or cloud disk management client that initiates the modification needs to confirm that the modification is accepted by all cloud hosts before executing the subsequent management logic. Therefore, a message notification mechanism that supports delivery confirmation is needed to provide support for shared cloud disks.

[0005] The existing subscription notification solutions mainly include the following categories: redis message subscription solution only supports real-time publishing, but does not support persistent storage; etcd watch solution supports persistence, but does not support delivery confirmation; other subscription solutions based on message queues are mostly passive consumption mode, rather than active delivery, and do not support delivery confirmation. The above subscription notification solutions have their own advantages, but none of them support delivery confirmation and cannot meet the needs of cloud hard disk management. Summary of the invention

[0006] In order to solve the above-mentioned problems in the prior art, the present invention provides a message subscription notification method and system that supports delivery confirmation, supports high reliability and high availability subscription notification, and realizes metadata management in a shared cloud hard disk scenario.

[0007] The present invention proposes a message subscription notification method supporting delivery confirmation, comprising:

[0008] Step 1: Set the key fields for subscription and message publishing communication between the subscription client Watch_Client, the publishing client Notify_Client and the server Server;

[0009] Step 2: Establish a subscription channel management mechanism supporting delivery confirmation for the client and server respectively based on the key fields;

[0010] Step 3: Subscription and message publishing between Watch_Client, Notify_Client and Server are performed based on the subscription channel management mechanism.

[0011] Preferably, the key fields set in step 1 include:

[0012] watch_id: the unique subscription channel identifier within the client;

[0013] WatchStream: associates the subscription callback function WatchCallback with the subscription keyword key, which has a unique watch_id inside the client;

[0014] WatchKey: used to send subscription requests, carrying watch_id, cookie, and key, where the cookie is a globally unique identifier for the client;

[0015] NotifyCallback: message confirmation function;

[0016] WatchChannel: used by the server to manage all subscribing clients Watch_Client for a subscription keyword Key and manage the publishing event Notify_Handler;

[0017] WatchClient: used by the server to manage a client's subscription status for a keyword;

[0018] NotifyMessage: It is a message sent to all subscribers in the WatchChannel after the Server receives the published message. It carries key, cookie, seq, and value, where seq is the marker of a message publishing event.

[0019] NotifyHandler: used to record a publishing event and collect delivery confirmation. It is generated when the server receives a Notify request and released after the publishing is completed.

[0020] Preferably, in step 2, the subscription channel management mechanism of the client side includes:

[0021] 1) Each Client applies for a globally unique cookie to mark the client;

[0022] 2) The client applies for a watch_id to mark a subscription channel for each key it initiates a subscription to, and constructs a WatchStream to associate WatchCallback with the key. WatchStream has a unique watch_id inside the client. When the Client receives a NotifyMessage, it finds the WatchStream through the watch_id carried in the message and executes the WatchCallback in it;

[0023] 3) When unsubscribing, delete the WatchStream to release the watch_id.

[0024] Preferably, in step 2, the subscription channel management mechanism on the server side includes the following concurrent publishing mechanism:

[0025] The server uses WatchChannel to manage the subscription of each key. All Clients subscribing to the same key are associated with the corresponding WatchChannel. The WatchChannel uses a self-incrementing seq to mark each message release, and uses seq to query all releases in progress. The handler corresponding to seq is released after the release is completed or timed out. Each time a message is released, WatchChannel traverses all WatchClients associated with it, sends NotifyMessage to all avariable Clients, and marks the idle Client as waiting, and deletes the WatchClient that has timed out.

[0026] Preferably, in step 2, the subscription channel management mechanism on the server side includes the following automatic reconnection mechanism for the subscription channel:

[0027] The server generates a WatchClient for all subscribed clients Watch_Client, records a watch channel of Client and key, and adds the WatchClient to the WatchChannel to which the key belongs; WatchClient uses key|cookie as key, records the Client's publishing record, and uses seq to mark the seq header that the Client has completed consuming as the starting message for resending when reconnecting due to a failure; WatchClient uses status to mark the status of the subscription channel. When the Client heartbeat is lost or times out without responding to NotifyAck, the Client is marked as idle, and reset to avariable after the Client successfully reconnects; After successfully reconnecting, WatchClient will resend the NotifyMessage that is still being processed, and add it to the NotifyHandler after receiving ack; WatchClient records the watch_id sent by the Client, associates it with the subscription channel with an available status, and carries the watch_id in the NotifyMessage when publishing the message; in the event of a communication failure or the Client loses connection, the watch_id will become invalid, and will be updated to a new watch_id after successfully reconnecting.

[0028] Preferably, in step 2, the subscription channel management mechanism on the server side includes the following delivery confirmation mechanism:

[0029] Each time the Server receives a Notify request, it generates a new NotifyHandler and uses the curr_seq in the WatchChannel as the seq for this release. The WatchChannel adds each watch_id in the avarible or idle state to the NotifyHandler, expecting to receive a response from the WatchClient. When the number of waiting and acks is consistent, it means that the Notify is successfully completed. If some WatchClients have not received acks, they will be considered to have timed out after 3 seconds. The NotifyHandler is released after the release is completed.

[0030] Preferably, in step 2, the subscription channel management mechanism on the server side includes the following subscription information persistent storage mechanism with timeout:

[0031] The server stores each publish in the db persistently and uses seq as the version number to mark this version; each new release deletes the completed or timed-out version; when a new subscription request arrives or reconnection succeeds, the message version that has not been consumed is queried through seq; the server records each subscribed client and uses the watch prefix + key + cookie as the key to mark a subscription. When the status of the channel changes, the server updates the db and uses idle_time:last_seq as the value to record the failure time of the subscription channel and the consumed message seq; when the failure reconnection succeeds, all releases after last_seq are sent to the client; when the next release arrives, if it is determined that idle_time has timed out, the subscription is considered invalid and deleted from the corresponding WatchChannel and the db.

[0032] Preferably, in step 3, the subscription and message publishing process is:

[0033] 1) Watch_Client initiates a subscription request, applies for watch_id, and creates WatchStream;

[0034] 2) Watch_Client sends WatchKey message to Server;

[0035] 3) After receiving the WatchKey request, the Server searches or creates a WatchChannel, creates a WatchClient, joins it to the WatchChannel, and sends the most recent release of the channel;

[0036] 4) Notify_Client initiates a publishing request and sends a NotifyKey message to the Server;

[0037] 5) After receiving the message, the Server searches for WatchChannel, creates NotifyKeyHandler, then iterates over all WatchClients, assembles NotifyMessage to send, and adds WatchClient to NotifyKeyHandler;

[0038] 6) After Watch_Client receives NotifyMessage and processes it, it sends NotifyAck to Server;

[0039] 7) After receiving NotifyAck, Server queries NotifyHandler and adds ack to NotifyHandler according to Client_id;

[0040] 8) After Notify_Client publishes the message, it starts the timing thread, queries the publishing results regularly, and executes NotifyCallback after receiving the result in Finish status.

[0041] The present invention also proposes a message subscription notification system supporting delivery confirmation, comprising:

[0042] The key field setting module is used to set the key fields for subscription and message publishing communication between Watch_Client, Notify_Client and Server;

[0043] A management mechanism building module is used to establish a subscription channel management mechanism supporting delivery confirmation for the client and the server respectively according to the key fields;

[0044] The subscription and message publishing module is used to perform subscription and message publishing between Watch_Client, Notify_Client and Server based on the subscription channel management mechanism.

[0045] The present invention also proposes a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps of the method are implemented.

[0046] The beneficial effects of the present invention are embodied in:

[0047] 1. The present invention supports concurrent publishing and concurrent waiting for delivery confirmation. A delivery confirmation scheme is designed for each message publishing. It supports the client to obtain the delivery status of all cloud hosts after publishing, so that the message publisher can obtain the delivery information of each subscriber. After the message is published, it supports asynchronous waiting for delivery confirmation. If there is a host failure that is not confirmed, the cloud host can restore and reconnect within the timeout period, and the message publishing process can still be completed, realizing a highly available message notification mechanism;

[0048] 2. The present invention adopts a highly available WatchChannel mechanism to support the successful release of messages in temporary failure scenarios;

[0049] 3. The present invention supports automatic reconnection of subscription channels, high fault tolerance, supports timeout reconnection waiting in fault scenarios, and designs a timeout waiting scheme for each message release, so that subscribers can automatically rebuild subscription channels in fault recovery scenarios, and no messages are lost during fault recovery within a certain period of time, thereby achieving high reliability of subscription channels;

[0050] 4. The present invention realizes persistent storage of messages with timeout and supports reading of historical messages: based on the storage architecture with separation of storage and computing, the subscription client is persisted in the DB, supporting high availability of the subscription channel, allocating seq for each message release, and using the userdefined timestamp feature to store it in the DB, so that subscribers can query historical messages within a certain period of time. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a flowchart of the execution of a subscription and publishing process provided by the present invention. DETAILED DESCRIPTION

[0052] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0053] Embodiment 1:

[0054] The present invention proposes a message subscription notification method supporting delivery confirmation, wherein the message notification scheme establishes a subscription channel between the client and the server, and the client and the server respectively design a subscription channel management mechanism and formulate a communication protocol, and perform publishing and subscription communication by specifying a message type. Specifically, the method comprises the following steps:

[0055] Step 1: Set the key fields for subscription and message publishing communication between the subscription client Watch_Client, the publishing client Notify_Client and the server Server; the message definition is described in detail below:

[0056] Message definition: The present invention defines several communication formats to implement the subscription notification function. This section describes key messages and key fields.

[0057] watch_id: the unique subscription channel identifier within the client;

[0058] WatchStream: associates WatchCallback with the subscription keyword key, which has a unique watch_id inside the client;

[0059] WatchKey: used to send subscription requests, carrying Client_cookie and key, as well as local watch_id. watch_id marks a subscription channel and is carried when the server sends NotifyMessage. When the client receives NotifyMessage, it can query the corresponding subscription channel through the watch_id in it for information distribution. After a failure, the watch_id becomes invalid, and a new watch_id can be applied for reconnection.

[0060] NotifyKeyRequest and Response: When the client publishes a message, it sends a request to the server, carrying the key and value, where the value is the message body. The server will assign a unique seq in the channel to this release and carry it to the client in the Response for subsequent query notification result index.

[0061] NotifyMessage: After receiving a publish message, the Server will assemble a NotifyMessage message and send it to all subscribers in the WatchChannel. The NotifyMessage will carry the seq and watch_id of this message, as well as the published information content.

[0062] NotifyMessageAck: After receiving NotifyMessage, the client calls callback to process and sends Ack message to the server as the response of this release, carrying seq, cookie and ack_result, where seq is the mark of a message release event. After receiving the ack message, the server queries the NotifyHandler through seq and updates the ack_result of the client.

[0063] NotifyResultRequest / Response: NotifyResultRequest carries key, cookie, and seq. After the publisher publishes the message, the client starts a timed query thread and sends NotifyResultRequest to query the publishing result at regular intervals until the response received has a status of Finish. After receiving acks from all clients or timing out, the server puts each client's ack_result into NotifyResult and sends it to the publisher, and returns a publishing status of Finish.

[0064] NotifyCallback: message confirmation mechanism;

[0065] WatchChannel: used by the server to manage all subscribing clients Watch_Client for a subscription keyword Key and manage the publishing event Notify_Handler;

[0066] WatchClient: used by the server to manage a client's subscription status for a keyword;

[0067] NotifyMessage: It is a message sent to all subscribers in the WatchChannel after the Server receives the published message. It carries key, cookie, seq, and value, where seq is the marker of a message publishing event.

[0068] NotifyHandler: used to record a publishing event and collect delivery confirmation. It is generated when the server receives a Notify request and released after the publishing is completed.

[0069] The above Client: subscription or publishing client; Server: subscription server;

[0070] Client_cookie: globally uniquely identifies a client; Watch: indicates a subscription; Notify: indicates a message release.

[0071] Step 2: Establish a subscription channel management mechanism supporting delivery confirmation for the client and server respectively based on the key fields;

[0072] Client management:

[0073] Each client applies for a globally unique cookie to identify the client.

[0074] The client applies for a watch_id to mark a subscription channel for each key it initiates a subscription to, and constructs a WatchStream to associate WatchCallback with the key. WatchStream has a unique watch_id inside the client. When the Client receives a NotifyMessage, it finds the WatchStream through the watch_id carried in the message and executes the WatchCallback in it.

[0075] When canceling a subscription, delete the WatchStream and release the watch_id. A client's watch on the same key is an idempotent operation.

[0076] Server management:

[0077] WatchChannel: The server uses WatchChannel to manage subscriptions for each key, and all Clients subscribing to this key will be associated with this WatchChannel. WatchChannel uses a self-incrementing seq to mark each message release, and uses seq to query all releases in progress. The handler corresponding to this seq is released after the release is completed or times out. Each time the Publisher releases a message, WatchChannel will traverse all WatchClients associated with it, send NotifyMessage to all avariable Clients, mark Clients in the idle state as waiting, and delete WatchClients that have timed out.

[0078] WatchClient: Server generates a WatchClient for all subscribed clients, records a watch channel of Client and key, and adds this WatchClient to the WatchChannel to which this key belongs. WatchClient uses key|cookie as key, and records the publishing record of this Client. It uses seq to mark the seq header that the Client has completed consuming, as the starting message to be resent when reconnecting due to a failure. WatchClient uses status to mark the status of the subscription channel. When the client heartbeat is lost or the NotifyAck is not responded to due to timeout, the Client is marked as idle, and reset to avariable after the Client successfully reconnects. After successfully reconnecting, WatchClient will resend the NotifyMessage that is still being processed, and add it to the NotifyHandler after receiving the ack. WatchClient records the watch_id sent by the Client, associates the subscription channel with an available status, and carries the watch_id in the NotifyMessage when publishing the message. When there is a communication failure or the Client loses connection, the watch_id will become invalid, and will be updated to a new watch_id after successfully reconnecting.

[0079] NotifyHandler: Every time the Server receives a Notify request, it will generate a new NotifyHandler and use the curr_seq in the WatchChannel as the seq for this release. The WatchChannel will add each watch_id in the avarible or idle state to the NotifyHandler, expecting to receive responses from these WatchClients. When the number of waiting and acks is consistent, it means that this Notify has been successfully completed. If some WatchClients have not received acks, they will be judged to have timed out after 3 seconds. After the release is completed, the NotifyHandler is released.

[0080] Persistent storage of subscription information: The server will persist each publish storage in the db, and use seq as the version number to mark this version. Each new release will delete the completed or timed-out version. When a new subscription request arrives or reconnects successfully, the message version that has not been consumed can be queried through seq. The server will also record each subscribed client, using the watch prefix + key + cookie as the key to mark a subscription. When the status of this channel changes, the server will update the db, using idle_time:last_seq as the value, and record the failure time of this subscription channel and the consumed message seq. When the failure reconnects successfully, all releases after last_seq are sent to the client. When the next release arrives, if it is determined that idle_time has timed out, the subscription is considered invalid, deleted from the corresponding WatchChannel and deleted from the db.

[0081] Step 3: Subscription and message publishing between Watch_Client, Notify_Client and Server are performed based on the subscription channel management mechanism. The specific process is as follows:

[0082] The client initiates a subscription request, applies for a watch_id, creates a WatchStream, and inserts it into the watch_map.

[0083] The client sends a WatchKey message to the server.

[0084] After receiving the WatchKey request, the Server searches for or creates a WatchChannel, creates a WatchClient, adds it to the WatchChannel, and sends the most recent release of this channel.

[0085] The Notify client initiates a publishing request and sends a NotifyKey message to the Server.

[0086] After receiving it, the Server looks for WatchChannel, creates NotifyKeyHandler, then iterates over all WatchClients, assembles NotifyMessage to send, and adds WatchClient to NotifyKeyHandler.

[0087] After receiving the NotifyMessage, the Watch client sends a NotifyAck to the Server.

[0088] After receiving NotifyAck, the Server queries NotifyHandler and adds the ack to NotifyHandler according to the Client_id.

[0089] After the Publisher publishes a message, it starts a timing thread to query the publishing results regularly and executes NotifyCallback after receiving the result in the Finish status.

[0090] The execution process of a subscription and publication process is shown in Figure 1 .

[0091] Take a qos change as an example to illustrate the message subscription notification process:

[0092] When the cloud host mounts the cloud disk, it initiates a WatchKey request, carries the WatchKeyCallback of the received message, and marks its own cookie. The client will first apply for a watch_id, associate this key and cookie, and mark this subscription channel.

[0093] After receiving the WatchKey request, the server checks whether the key already exists in the WatchChannel. If not, a new channel is created. Then a watch_id is requested for this watch request, a WatchClient is created and added to the channel.

[0094] The cloud disk management end needs to modify the QOS, initiate a Notify request, and carry the new QOS value in the Notify message.

[0095] After receiving the Notify message, the Server sends a Notify message to all WatchClients of this channel through the stream_id associated in the WatchClient.

[0096] After receiving the message, the cloud host calls WatchCallback to process it and returns ack to the Server.

[0097] After receiving the ACKs from all cloud hosts, the server sends the ACKs from all cloud hosts to the publisher.

[0098] After the publisher receives all the acks from Notify and confirms that all cloud hosts have been delivered, it calls NotifyCallback to make the QOS modification effective. If there is a cloud host failure or other reasons that do not send acks, the server will wait for 3 seconds and send a timeout result to the publisher, and the publisher will cancel the modification or re-initiate it.

[0099] The present invention also proposes a message subscription notification system supporting delivery confirmation, comprising:

[0100] The key field setting module is used to set the key fields for subscription and message publishing communication between Watch_Client, Notify_Client and Server;

[0101] A management mechanism building module is used to establish a subscription channel management mechanism supporting delivery confirmation for the client and the server respectively according to the key fields;

[0102] The subscription and message publishing module is used to perform subscription and message publishing between Watch_Client, Notify_Client and Server based on the subscription channel management mechanism.

[0103] A computer-readable storage medium stores a computer program, which implements the steps of the above method when executed by a processor.

[0104] In the description of the embodiments of the present invention, it should be understood that the terms "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "center", "top", "bottom", "top", "bottom", "inside", "outside", "inner side", "outer side" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. Among them, "inside" refers to an internal or enclosed area or space. "Periphery" refers to the area surrounding a specific component or a specific area.

[0105] In the description of the embodiments of the present invention, the terms "first", "second", "third", and "fourth" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first", "second", "third", and "fourth" may explicitly or implicitly include one or more of the features. In the description of the present invention, unless otherwise specified, "multiple" means two or more.

[0106] In the description of the embodiments of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "install", "connect", "connect", and "assemble" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a direct connection, or an indirect connection through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0107] In the description of the embodiments of the present invention, specific features, structures, materials or characteristics may be combined in a suitable manner in any one or more embodiments or examples.

[0108] In the description of the embodiments of the present invention, it is to be understood that "-" and "~" represent the range between two values, and the range includes the endpoints. For example: "AB" represents a range greater than or equal to A and less than or equal to B. "A~B" represents a range greater than or equal to A and less than or equal to B.

[0109] In the description of the embodiments of the present invention, the term "and / or" herein is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " herein generally indicates that the associated objects before and after are in an "or" relationship.

[0110] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A message subscription notification method supporting delivery confirmation, characterized in that: include: Step 1: Set the key fields for subscription and message publishing communication between the subscription client Watch_Client, the publishing client Notify_Client and the server Server; Step 2: Establish a subscription channel management mechanism supporting delivery confirmation for the client and server respectively according to the key fields; Step 3: Subscription and message publishing between Watch_Client, Notify_Client and Server are performed based on the subscription channel management mechanism; The key fields set in step 1 include: watch_id: the unique subscription channel identifier within the client; WatchStream: associates the subscription callback function WatchCallback with the subscription keyword Key, which has a unique watch_id inside the client; WatchKey: used to send subscription requests, carrying watch_id, cookie, and Key, where the cookie is a globally unique tag for the client; NotifyCallback: message confirmation function; WatchChannel: used by the server to manage all subscribing clients Watch_Client for a subscription keyword Key and manage the publishing event Notify_Handler; WatchClient: used by the server to manage a client's subscription status for a keyword; NotifyMessage: It is a message sent to all subscribers in the WatchChannel after the Server receives the published message. It carries Key, cookie, seq, and value. Seq is the marker of a message publishing event. NotifyHandler: used to record a publishing event and collect delivery confirmation. It is generated when the server receives a Notify request and is released after the publishing is completed. In step 2, the subscription channel management mechanism on the client side includes: 1) Each Client applies for a globally unique cookie to mark the client; 2) The client applies for a watch_id to mark a subscription channel for each Key it subscribes to, and constructs a WatchStream to associate WatchCallback with the Key. WatchStream has a unique watch_id inside the client. When the Client receives a NotifyMessage, it finds the WatchStream through the watch_id carried in the message and executes the WatchCallback in it; 3) When canceling a subscription, delete WatchStream to release the watch_id; In step 2, the subscription channel management mechanism on the server side includes the following concurrent publishing mechanisms: The server uses WatchChannel to manage the subscription of each Key. All Clients subscribing to the same Key are associated with the corresponding WatchChannel. The WatchChannel uses the self-incrementing seq to mark each message release, and uses seq to query all releases in progress. The handler corresponding to seq is released after the release is completed or timed out. Each time a message is released, WatchChannel traverses all WatchClients associated with it, sends NotifyMessage to all avariable Clients, and marks the idle Client as waiting, and deletes the WatchClient that has timed out. In step 2, the subscription channel management mechanism on the server side includes the following automatic reconnection mechanism for subscription channels: The Server generates a WatchClient for all subscribed clients Watch_Client, records a watch channel of Client and Key, and adds the WatchClient to the WatchChannel to which the Key belongs; WatchClient uses Key|cookie as Key, records the Client's publishing record, and uses seq to mark the seqheader that the Client has completed consuming, as the starting message to be resent when reconnecting due to a failure; WatchClient uses status to mark the status of the subscription channel. When the Client heartbeat is lost or times out without responding to NotifyAck, the Client is marked as idle, and reset to avariable after the Client successfully reconnects; After successfully reconnecting, WatchClient will resend the NotifyMessage that is still being processed, and add it to the NotifyHandler after receiving ack; WatchClient records the watch_id sent by the Client, associates the subscription channel with an available status, and carries the watch_id in the NotifyMessage when publishing the message; in the event of a communication failure or the Client loses connection, the watch_id will become invalid, and will be updated to a new watch_id after successfully reconnecting.

2. A message subscription notification method supporting delivery confirmation according to claim 1, characterized in that: In step 2, the subscription channel management mechanism on the server side includes the following delivery confirmation mechanism: Each time the Server receives a Notify request, it generates a new NotifyHandler and uses the curr_seq in the WatchChannel as the seq for this release. The WatchChannel adds each watch_id in the avarible or idle state to the NotifyHandler, expecting to receive a response from the WatchClient. When the number of waiting and acks is consistent, it means that the Notify is successfully completed. If some WatchClients have not received acks, they will be considered to have timed out after 3 seconds. The NotifyHandler is released after the release is completed.

3. A message subscription notification method supporting delivery confirmation according to claim 2, characterized in that: In step 2, the subscription channel management mechanism on the server side includes the following subscription information persistent storage mechanism with timeout: The server stores each publish in the db persistently and uses seq as the version number to mark this version; each new release deletes the completed or timed-out version; when a new subscription request arrives or reconnection succeeds, the message version that has not been consumed is queried through seq; the server records each subscribed client and uses the watch prefix + key + cookie as the key to mark a subscription. When the status of the channel changes, the server updates the db and uses idle_time:last_seq as the value to record the failure time of the subscription channel and the consumed message seq; when the failure reconnection succeeds, all releases after last_seq are sent to the client; when the next release arrives, if it is determined that idle_time has timed out, the subscription is considered invalid and deleted from the corresponding WatchChannel and the db.

4. A message subscription notification method supporting delivery confirmation according to claim 3, characterized in that: In step 3, the subscription and message publishing process is: 1) Watch_Client initiates a subscription request, applies for watch_id, and creates WatchStream; 2) Watch_Client sends WatchKey message to Server; 3) After receiving the WatchKey request, the Server searches or creates a WatchChannel, creates a WatchClient, joins it to the WatchChannel, and sends the most recent release of the WatchChannel; 4) Notify_Client initiates a publishing request and sends a NotifyKey message to the Server; 5) After receiving the message, the Server searches for WatchChannel, creates NotifyKeyHandler, then iterates over all WatchClients, assembles NotifyMessage to send, and adds WatchClient to NotifyKeyHandler; 6) After Watch_Client receives NotifyMessage and processes it, it sends NotifyAck to Server; 7) After receiving NotifyAck, Server queries NotifyHandler and adds ack to NotifyHandler according to Client_id; 8) After Notify_Client publishes the message, it starts the timing thread, queries the publishing results regularly, and executes NotifyCallback after receiving the result in Finish status.

5. A message subscription notification system supporting delivery confirmation, using the method according to any one of claims 1 to 4, characterized in that: The system comprises: The key field setting module is used to set the key fields for subscription and message publishing communication between Watch_Client, Notify_Client and Server; A management mechanism building module is used to establish a subscription channel management mechanism supporting delivery confirmation for the client and the server respectively according to the key fields; The subscription and message publishing module is used to perform subscription and message publishing between Watch_Client, Notify_Client and Server based on the subscription channel management mechanism.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

Images