Message processing method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a message processing method and device, electronic equipment, a storage medium and a program product. The method comprises the steps that a first synchronization message is received, the state of the first synchronization message is updated to be a message generation state, and the first synchronization message carries a client identifier; a second synchronization message is pushed to a client corresponding to the client identifier, the state of the second synchronization message is updated to a message pushing state, the second synchronization message carries a first identifier configured by the server for the first synchronization message, and the client is used for performing service processing based on the second synchronization message; first confirmation information is received, the state of the second synchronization message is updated to be a message receiving state according to a first identifier in the first confirmation information, and the first confirmation information is used for indicating that the client has received the second synchronization message; when it is confirmed that the state of the second synchronization message is the preset state, the state of the second synchronization message is updated to be the message synchronization state, and the message processing reliability is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a message processing method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of business scenarios such as instant messaging, business notifications, and multi-terminal collaboration, real-time message synchronization and status management have become core requirements for various client-server interaction systems.

[0003] In related technologies, message synchronization is usually achieved through long-lived connections and centralized push. This means that all messages need to be routed and forwarded uniformly through a central server, and the client and server maintain a persistent connection. The server actively pushes messages to the client to achieve real-time message delivery.

[0004] However, in the above process, while the server can confirm whether the message has been sent or whether the push has been completed, it is difficult to know in a timely manner whether the message has been actually received, displayed, or processed by the client, resulting in low reliability of message processing. Summary of the Invention

[0005] This application provides a message processing method, apparatus, electronic device, storage medium, and program product to solve the technical problem of low reliability in message processing.

[0006] Firstly, this application provides a message processing method, including:

[0007] Receive the first synchronization message and update the status of the first synchronization message to the message generation status. The first synchronization message carries a client identifier.

[0008] The second synchronization message is pushed to the client corresponding to the client identifier, and the status of the second synchronization message is updated to the message push status. The second synchronization message carries the first identifier configured by the server for the first synchronization message. The client is used to perform business processing based on the second synchronization message.

[0009] Receive the first confirmation message, and update the status of the second synchronization message to the message receiving status according to the first identifier in the first confirmation message. The first confirmation message is used to indicate that the client has received the second synchronization message.

[0010] When the status of the second synchronization message is confirmed to be the preset status, the status of the second synchronization message is updated to the message synchronization status.

[0011] In this embodiment, the server receives a first synchronization message and initializes it to a message generation state. It then pushes a second synchronization message carrying a first identifier to the client and updates it to a message push state. After receiving a first confirmation message from the client, the server updates the second synchronization message to a message receiving state. Finally, it updates the second synchronization message to a message synchronization state upon confirming that the second synchronization message has reached a preset state. In this method, the server can generate a second synchronization message by configuring a first identifier for the first synchronization message, achieving unified management and state tracking of message entities. Furthermore, by pushing the second synchronization message to trigger client business processing and driving server state evolution based on the first confirmation message returned by the client, a two-way confirmation mechanism between the server and client is established. Moreover, through a phased, progressively evolving state model, the server can accurately perceive the complete processing progress of the message from generation, push, and reception to final synchronization completion. This solves the problem in related technologies where the server can only confirm whether a message has been sent but cannot perceive the client's actual reception and processing status, significantly improving the accuracy and traceability of message synchronization and enhancing the reliability of message processing.

[0012] Optionally, in the method described above, when it is confirmed that the state of the second synchronization message is a preset state, updating the state of the second synchronization message to a message synchronization state includes:

[0013] Receive a second confirmation message, which indicates that the client has completed the business processing based on the second synchronization message. The second confirmation message includes the first identifier and status of the second synchronization message.

[0014] The first identifier and status are verified to obtain the verification result. When the verification result is that the verification is successful, the status of the second synchronization message is updated to the message processing status.

[0015] When the status of the second synchronization message is confirmed to be in message processing status, the status of the second synchronization message is updated to message synchronization status.

[0016] In this embodiment of the application, by receiving the second confirmation information and verifying the first identifier and status, the message processing status and synchronization status are updated, thereby achieving accurate confirmation of message processing completion and improving the reliability of message synchronization.

[0017] Optionally, in the method described above, after updating the status of the second synchronization message to the message push status, the method further includes:

[0018] Receive message retrieval request. The message retrieval request includes a client identifier and a second identifier. The second identifier is used to indicate the synchronization messages that the client has received at the current time.

[0019] Based on the client identifier and the second identifier, the third synchronization message is determined in the second synchronization message;

[0020] Push the encrypted third synchronous message to the client and update the status of the second synchronous message to message fetch status.

[0021] In this embodiment, by receiving a message retrieval request and determining the third synchronization message based on the client identifier and the second identifier, the precise push of incremental messages is achieved, avoiding the full transmission of invalid data, effectively saving network bandwidth and local resources, and improving the efficiency and targeting of message retrieval.

[0022] Optionally, using the method described above, a second synchronization message is pushed to the client corresponding to the client identifier, including:

[0023] Based on the client identifier, the corresponding message push strategy is determined. The message push strategy is used to instruct the execution of message push processing to the client.

[0024] Determine the corresponding message push channel based on the message push strategy;

[0025] A second synchronized message is pushed to the client via a message push channel.

[0026] In this embodiment of the application, by determining the push strategy and channel based on the client identifier and pushing the second synchronous message, it is possible to adapt to different push channels for different clients, thereby improving the adaptability and stability of message push.

[0027] Secondly, this application provides a message processing method, including:

[0028] Receive a second synchronization message sent by the server. The second synchronization message includes a first identifier configured by the server. The second synchronization message is used to trigger the client to perform message retrieval processing.

[0029] Retrieve the third synchronization message. The second synchronization message includes the third synchronization message, which is a synchronization message that is not stored on the client.

[0030] Send the first confirmation message to the server.

[0031] In this embodiment, the client receives a second synchronization message carrying a first identifier sent by the server. Responding to this second synchronization message, the client triggers message retrieval processing to obtain a third synchronization message not stored by the client and sends a first confirmation message to the server. In this method, the client can accurately obtain incremental synchronization messages not stored by itself through the triggering of the second synchronization message, without passively waiting for message pushes or performing a full message retrieval. This effectively avoids the problems of client message omission, low retrieval efficiency, or resource waste in related technologies. Furthermore, the first confirmation message provides feedback on the message reception status to the server, providing a reliable basis for updating the message status on the server side, forming a two-way interactive closed loop between the client and the server. This method fundamentally solves the problem in related technologies where the client cannot obtain incremental messages in a timely manner and cannot provide feedback on the true reception status to the server, resulting in low reliability of message processing. It significantly improves the accuracy, timeliness, and efficiency of client message synchronization, reduces the client's message processing load, and is adaptable to various message synchronization scenarios such as multi-terminal collaboration and business notifications. While ensuring the traceability of the entire message synchronization process, it further improves the stability and reliability of message synchronization and interaction.

[0032] Optionally, obtaining the third synchronization message using the method described above includes:

[0033] Determine the second identifier of the synchronized message corresponding to the current moment;

[0034] Send a message retrieval request to the server. The message retrieval request is used to request the retrieval of incremental messages. The message retrieval request includes a second identifier and a client identifier.

[0035] Receive the encrypted third synchronization message, and decrypt the encrypted third synchronization message to obtain the decrypted third synchronization message.

[0036] In this embodiment of the application, by determining the second identifier of the synchronized message, sending a pull request, and decrypting the third synchronized message, the secure acquisition of incremental messages is achieved, thereby improving the security and accuracy of message retrieval.

[0037] Optionally, after sending the first confirmation message to the server, the method described above further includes:

[0038] Determine the business processing status, which can be either processing status or completion status. The business processing status is used to indicate the progress of business processing based on third-party synchronization messages.

[0039] When the business processing status is complete, a second confirmation message is sent to the server. The second confirmation message is used to indicate that the business processing status based on the third synchronization message is complete.

[0040] In this embodiment of the application, by determining the business processing status and sending a second confirmation message upon completion, the client's proactive feedback on the message processing progress enables the server to accurately know the business processing completion status, ensuring the traceability of the entire message synchronization process.

[0041] Thirdly, this application provides a message processing apparatus, comprising:

[0042] The receiving module is used to receive the first synchronization message and update the status of the first synchronization message to the message generation status. The first synchronization message carries a client identifier.

[0043] The push module is used to push the second synchronization message to the client corresponding to the client identifier, and update the status of the second synchronization message to the message push status. The second synchronization message carries the first identifier configured by the server for the first synchronization message. The client is used to perform business processing based on the second synchronization message.

[0044] The update module is used to receive the first confirmation information and update the status of the second synchronization message to the message receiving status according to the first identifier in the first confirmation information. The first confirmation information is used to indicate that the client has received the second synchronization message.

[0045] The update module is also used to update the status of the second synchronization message to the message synchronization status when it is confirmed that the status of the second synchronization message is the preset status.

[0046] Optionally, in the apparatus described above, when the state of the second synchronization message is confirmed to be a preset state, the state of the second synchronization message is updated to a message synchronization state. The update module is specifically used for:

[0047] Receive a second confirmation message, which indicates that the client has completed the business processing based on the second synchronization message. The second confirmation message includes the first identifier and status of the second synchronization message.

[0048] The first identifier and status are verified to obtain the verification result. When the verification result is that the verification is successful, the status of the second synchronization message is updated to the message processing status.

[0049] When the status of the second synchronization message is confirmed to be in message processing status, the status of the second synchronization message is updated to message synchronization status.

[0050] Optionally, in the apparatus described above, after updating the status of the second synchronization message to a message push status, the apparatus further includes a processing module, which is specifically used for:

[0051] Receive message retrieval request. The message retrieval request includes a client identifier and a second identifier. The second identifier is used to indicate the synchronization messages that the client has received at the current time.

[0052] Based on the client identifier and the second identifier, the third synchronization message is determined in the second synchronization message;

[0053] Push the encrypted third synchronous message to the client and update the status of the second synchronous message to message fetch status.

[0054] Optionally, the apparatus described above pushes a second synchronization message to the client corresponding to the client identifier, wherein the push module is specifically used for:

[0055] Based on the client identifier, the corresponding message push strategy is determined. The message push strategy is used to instruct the execution of message push processing to the client.

[0056] Determine the corresponding message push channel based on the message push strategy;

[0057] A second synchronized message is pushed to the client via a message push channel.

[0058] Fourthly, this application provides a message processing apparatus, comprising:

[0059] The receiving module is used to receive a second synchronization message sent by the server. The second synchronization message includes a first identifier configured by the server and is used to trigger the client to perform message retrieval processing.

[0060] The acquisition module is used to acquire the third synchronization message. The second synchronization message includes the third synchronization message, which is a synchronization message that is not stored by the client.

[0061] The sending module is used to send the first confirmation message to the server.

[0062] Optionally, in the apparatus described above, the acquisition module is specifically used to acquire the third synchronization message.

[0063] Determine the second identifier of the synchronized message corresponding to the current moment;

[0064] Send a message retrieval request to the server. The message retrieval request is used to request the retrieval of incremental messages. The message retrieval request includes a second identifier and a client identifier.

[0065] Receive the encrypted third synchronization message, and decrypt the encrypted third synchronization message to obtain the decrypted third synchronization message.

[0066] Optionally, in the apparatus described above, after sending the first confirmation information to the server, the apparatus includes a processing module, which is further configured to:

[0067] Determine the business processing status, which can be either processing status or completion status. The business processing status is used to indicate the progress of business processing based on third-party synchronization messages.

[0068] When the business processing status is complete, a second confirmation message is sent to the server. The second confirmation message is used to indicate that the business processing status based on the third synchronization message is complete.

[0069] Fifthly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0070] The memory stores the instructions that the computer executes;

[0071] The processor executes computer-executable instructions stored in memory to implement the method described in the first aspect.

[0072] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the method described in the first aspect.

[0073] The computer-readable storage medium provided in this application embodiment can execute the technical solutions in the above method embodiments, and its beneficial effects are similar, so they will not be described again here.

[0074] Fifthly, this application provides a computer program product, including a computer program, which, when executed by a computer, is used to implement the method of the first aspect.

[0075] The computer program product provided in this application embodiment can execute the technical solutions in the above method embodiments, and its beneficial effects are similar, so they will not be described again here.

[0076] The message processing method, apparatus, electronic device, storage medium, and program product provided in this application involve a server receiving a first synchronization message and initializing it to a message generation state, pushing a second synchronization message carrying a first identifier to the client and updating it to a message push state, receiving a first confirmation message from the client, updating the second synchronization message to a message receiving state, and updating it to a message synchronization state when the second synchronization message reaches a preset state. In this method, the server can generate a second synchronization message by configuring a first identifier for the first synchronization message, achieving unified management and state tracking of message entities. Furthermore, by pushing the second synchronization message to trigger client business processing and driving server state evolution based on the first confirmation message returned by the client, a two-way confirmation mechanism between the server and client is established. Moreover, through a phased, progressively evolving state model, the server can accurately perceive the complete processing progress of the message from generation, push, and reception to final synchronization completion, solving the problem in related technologies where the server can only confirm whether a message has been sent but cannot perceive the client's actual reception and processing status. In addition, this method is applicable to various application scenarios requiring reliable message reception, such as instant messaging, business notifications, and multi-terminal collaboration, significantly improving the accuracy and traceability of message synchronization while enhancing the reliability of message processing. Attached Figure Description

[0077] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0078] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0079] Figure 2 A flowchart illustrating a message processing method provided in an embodiment of this application;

[0080] Figure 3 A flowchart illustrating another message processing method provided in an embodiment of this application;

[0081] Figure 4 Another system architecture diagram provided for an embodiment of this application;

[0082] Figure 5 A flowchart illustrating another message processing method provided in an embodiment of this application;

[0083] Figure 6 A flowchart illustrating another message processing method provided in an embodiment of this application;

[0084] Figure 7 This is a schematic diagram of the structure of a message processing device provided in an embodiment of this application;

[0085] Figure 8 This is a schematic diagram of another message processing device provided in an embodiment of this application;

[0086] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0087] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0088] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0089] With the rapid development of business scenarios such as instant messaging, business notifications, and multi-terminal collaboration, the demand for real-time message synchronization and state management is constantly increasing. The limitations of long-connection, centralized push-based methods in handling the entire message lifecycle state monitoring are becoming increasingly apparent. The characteristics of related technologies include: push-centricity, reliance on connection state judgment, and a single acknowledgment mechanism. This typically leads to the server being unable to perceive the actual processing progress of messages on the client side, placing higher demands on the reliability and state traceability of message processing. Because state imperceptibility directly affects the consistency of messages across multiple terminals, the introduction of compensation mechanisms further increases system complexity.

[0090] In related technologies, message synchronization is usually achieved through long-lived connections and centralized push. All messages are routed and forwarded uniformly through a central server. The client and the server maintain a persistent connection, with the server actively pushing messages to the client, and the connection ending once the client receives the message.

[0091] However, in the above process, while the server can confirm whether a message has been sent or pushed, it is difficult to know in a timely manner whether the message has been actually received, displayed, or processed by the client. Although the message has been delivered at the transmission level, due to the lack of a mechanism to confirm the client's processing progress, discrepancies can easily arise between the message state maintained by the server and the actual processing state. If only push status signals are used as the basis for determining synchronization completion, it will lead to problems such as unreliable status and high complexity of system compensation.

[0092] For example, the technical problem of traditional push methods can be understood as the inability to achieve fine-grained evolution and closed-loop management of the status in scenarios that require monitoring the complete processing progress of messages. For instance, it is impossible to avoid problems such as relying on full re-pull or complex compensation due to unknown client processing status.

[0093] During message synchronization, it is typically necessary to determine whether a message was successfully sent based on the status of the push channel. Specifically, after the server pushes a message via a persistent connection, it updates the message status to "sent" based on the connection layer acknowledgment signal.

[0094] However, due to the inherent defects of the traditional push mode: First, its architecture is centered on the push behavior, and the server can only sense whether the message has been pushed, but cannot sense whether the client has actually received it; Second, its confirmation mechanism is a one-time delivery confirmation, so even if the client has received the message, the server still cannot know whether the message has been processed, making it difficult to monitor the status of the entire message lifecycle, resulting in low reliability and status traceability of message processing.

[0095] In addition, in multi-terminal, high-concurrency scenarios, when it is necessary to maintain the consistency of message status across multiple terminals, the lack of a feedback mechanism for client processing progress often necessitates relying on full retransmission or compensation mechanisms for correction. Since the actual processing status of the client cannot be predicted, and the fixed push process cannot confirm the client's processing completion status, the state synchronization process generates a large amount of invalid retransmission and compensation overhead.

[0096] Therefore, this application provides a data processing method in which the server receives a first synchronization message and initializes itself to a message generation state, pushes a second synchronization message carrying a first identifier to the client and updates itself to a push state, receives a first confirmation message from the client and updates itself to a receiving state, and finally updates itself to a message synchronization state when the confirmation reaches a preset state. Based on this state evolution mechanism, unified management and tracking of message entities are achieved through the first identifier, and the server-side state evolution is driven by the client's confirmation information, establishing a two-way confirmation closed loop between the server and the client. This method realizes complete lifecycle state tracking of messages from generation, push, and reception to final synchronization completion, effectively avoiding the problem that the server cannot perceive the client's processing progress in the traditional push mode, realizing fine-grained evolution and closed-loop management of message states, ensuring the reliability and traceability of message processing, and significantly improving the accuracy of message synchronization and system stability.

[0097] Figure 1 Please refer to the system architecture diagram provided for an embodiment of this application. Figure 1This includes a server and a client. The server and client can communicate with each other. The server can send messages to be synchronized to the client, the client can perform business processing on the received messages, and the client can send confirmation messages to the server, which can then process the messages based on the confirmation messages sent by the client.

[0098] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0099] Figure 2 This is a flowchart illustrating a message processing method provided in an embodiment of this application. Specifically, as shown... Figure 2 As shown, the method includes the following steps:

[0100] S201. Receive the first synchronization message and update the status of the first synchronization message to the message generation status.

[0101] The execution entity in this application embodiment can be a server or a message processing device set in the server. The message processing device can be implemented by software or by a combination of software and hardware.

[0102] The first synchronization message carries a client identifier.

[0103] The server can be a server-side device that needs to push messages to clients and perform status monitoring. That is, in this embodiment of the application, the server can be used to implement the full lifecycle management of messages, and can be deployed as a standalone server or a distributed server cluster to adapt to high-concurrency message synchronization scenarios.

[0104] The client can be a terminal device that establishes a communication connection with the server and needs to receive messages pushed by the server. That is, in this embodiment of the application, the client can be used to receive and process messages, as well as provide confirmation feedback.

[0105] The first synchronization message can be a business message to be synchronized. In this embodiment, the first synchronization message can be understood as the original synchronization message for which the server has not performed identifier allocation or push processing. That is, the first synchronization message carries the business data or instructions to be synchronized, providing basic support for subsequent message synchronization on the client. For example, in a business notification scenario, the first synchronization message can be a message such as an order status notification that needs to be synchronized between the server and the client.

[0106] The message generation state can be considered the initialization state of the first synchronization message in the server's state machine, indicating that the server has successfully received the first synchronization message and completed the initial message registration and initialization. This state is the starting point for tracking the entire message lifecycle and can be denoted as S0.

[0107] The client identifier is used to indicate the target client corresponding to the first synchronization message. It is a unique identifier for a client and can be pre-configured. For example, the client identifier can include one or more combinations of the client's device ID, user account, application instance ID, etc. In this way, the server can accurately match the corresponding client and complete subsequent message push, status update and other operations, avoiding message push errors.

[0108] In some embodiments, the server receives the first synchronization message through a preset message receiving interface. For example, in an instant messaging scenario, the first synchronization message to be synchronized can be sent to the server's message receiving interface via a communication protocol; the server's message receiving interface performs integrity verification on the received first synchronization message (e.g., verifying the message format, whether the client identifier is valid, etc.), and after the verification passes, confirms the receipt of the first synchronization message, completing the initial message reception registration; if the verification fails (e.g., incorrect message format, invalid client identifier), a reception failure response is returned, prompting the server to resend the first synchronization message.

[0109] In some embodiments, the server associates and stores the first synchronization message and the client identifier in a local message storage module (e.g., a relational database or a distributed cache) to complete the persistent registration of the message. The server then calls the message state machine module to create a corresponding state record for the first synchronization message in the state machine, sets the initial state to the message generation state S0, and records the state update timestamp to complete the initialization update of the state.

[0110] S202. Push the second synchronization message to the client corresponding to the client identifier, and update the status of the second synchronization message to the message push status.

[0111] The second synchronization message carries a first identifier configured by the server for the first synchronization message.

[0112] The second synchronization message can be a message entity generated by the server after encapsulating the received first synchronization message. In other words, it can be understood as a synchronization message generated by the server after configuring the identifier (assigning the first identifier) ​​of the first synchronization message and pushing it to the client.

[0113] In some scenarios, the second synchronous message can be a lightweight notification containing only the first identifier, used to trigger the client to fetch subsequent messages; in other scenarios, the second synchronous message can also contain the complete message content, depending on the configuration of the push strategy.

[0114] The message push status can be a state in the server's state machine indicating that the message push operation has been successfully triggered. This status indicates that the server has delivered the second synchronization message to the push channel according to the client identifier, but has not yet received the client's acceptance confirmation. Therefore, it only represents that the push behavior has been executed, not that the client has actually received it. In this embodiment, the message push status can be recorded as S1.

[0115] The first identifier can be a message identifier, that is, a unique number or index assigned by the server to the first synchronization message. For example, the first identifier can be message A. This ensures that the server can accurately match the corresponding message and avoid message confusion or incorrect state update.

[0116] The client is used to perform business processing based on the second synchronization message. That is, after receiving the second synchronization message, the client associates the corresponding business data or instructions with the first identifier and executes the specific business operation corresponding to the message.

[0117] For example, if the second synchronization message is a lightweight notification message, in an instant messaging scenario, after receiving the second synchronization message, the client can retrieve the chat content based on the first identifier and display it to the user in the chat interface; in an order status synchronization scenario, the client can obtain the latest order status based on the first identifier and update the local order list or trigger a corresponding prompt.

[0118] In some embodiments, the server may push a second synchronization message to a client corresponding to the client identifier based on the following implementation: determining the corresponding message push strategy based on the client identifier; determining the corresponding message push channel based on the message push strategy; and pushing the second synchronization message to the client through the message push channel.

[0119] The message push strategy is used to instruct the execution of message push processing to the client. The message push strategy can be a pre-defined set of push rules. In other words, the server pre-configures or dynamically determines specific rules based on factors such as client type, network environment, and business needs to push secondary synchronous messages to the client. This adapts to the business needs and network conditions of different clients, ensuring the stability and timeliness of message pushes.

[0120] For example, for online instant messaging clients, a long-connection real-time push strategy can be adopted; for offline or background applications, a system-level push channel strategy can be adopted to save power; for critical business notifications, a multi-channel redundant push strategy can be adopted simultaneously to ensure delivery.

[0121] A message push channel is a communication path that allows a server to push a second synchronous message to a client. It is the carrier for implementing message push and can include one or more of the following: long connection channel, short connection channel, system-level notification channel, and SMS channel.

[0122] In some embodiments, different push channels are adapted to different client types and network scenarios. For example, online instant messaging clients preferentially use long connection channels, offline clients use system notification channels, and IoT terminals use short connection channels. This ensures that the second synchronization message can be accurately and efficiently transmitted to the target client.

[0123] In some embodiments, the server may pre-configure a client identifier-push policy mapping table, which stores the push policy corresponding to each client identifier. Specifically, the server queries the mapping table and matches the push policy corresponding to the client based on the client identifier carried in the first synchronization message in S201. The allocation of the push policy is determined based on the client's service type, real-time requirements, and device type.

[0124] For example, for clients with high real-time requirements such as instant messaging, a push strategy of priority push, 3 retries, and immediate triggering is assigned; for non-real-time clients such as IoT devices and offline notifications, a push strategy of idle push, 1 retry, and delayed triggering is assigned; for clients in high-concurrency scenarios, a push strategy of batch push and time-sharing triggering is assigned. In this way, it can be ensured that the push strategy is accurately matched with the client's business needs.

[0125] In some embodiments, the server can combine a message push strategy to match the corresponding push channel. For example, if the push strategy requires immediate push and the client is online and has a good network, a long connection channel is selected to achieve real-time message transmission; if the push strategy requires delayed push or the client is offline, a system notification channel or SMS channel is selected to ensure that the message can reach the client; for clients with limited resources such as IoT terminals, a short connection channel is selected to reduce client resource consumption; if a channel fails to push, it can automatically switch to a backup push channel according to the push strategy to improve the success rate of message push.

[0126] In some embodiments, the server encapsulates the second synchronization message into a data packet conforming to the push channel protocol and sends it to the target client through the channel. After sending, the server updates the message's push status according to the push result. If the push is successful, the server updates the message status to the message push status and records metadata such as push time and channel information. If the push fails, the server retryes or switches to a backup channel according to the reason for the failure, until the maximum number of retries is reached and a retransmission operation is performed.

[0127] In some embodiments, in a multi-client scenario, the server can pre-assign a priority label to each client. For example, the label for high priority (e.g., clients with high real-time requirements) can be P1, and the label for low priority (e.g., clients with non-real-time requirements such as offline status updates of IoT devices) can be P2.

[0128] During message push, the server employs a priority queue scheduling algorithm, prioritizing push requests from client P1 and placing push requests from client P2 into a low-priority queue to be processed when system resources are available. Furthermore, the server can dynamically adjust priority tags based on real-time status reports from clients (e.g., network quality, device load, service activity).

[0129] In this way, through this dynamic priority scheduling mechanism, the server can ensure the real-time performance of critical business in high-concurrency scenarios, avoid low-priority tasks blocking high-priority tasks, optimize system resource utilization, improve the overall system push throughput, and adapt to the synchronization needs of multiple clients and multiple business scenarios.

[0130] For example, when a low-priority client suddenly enters a high-real-time business scenario (e.g., a device triggers an alarm), its priority can be temporarily increased to P1 to ensure timely delivery of critical messages. When a high-priority client experiences network interruption or enters offline mode, its priority can be temporarily downgraded to P2 to avoid invalid high-priority pushes and optimize server resource utilization.

[0131] In some embodiments, after updating the state of the second synchronization message to the message push state, the server may receive a message retrieval request, which includes a client identifier and a second identifier; determine the third synchronization message in the second synchronization message based on the client identifier and the second identifier; push the encrypted third synchronization message to the client; and update the state of the second synchronization message to the message retrieval state.

[0132] The second identifier indicates the synchronization messages the client has received at the current moment. This can be understood as the client setting a sequence number or timestamp for the synchronized messages locally, recording the latest message position successfully received and stored by the client. When the client initiates a fetch request, it sends this identifier to the server, which uses it to determine which messages the client is missing. For example, the second identifier could be the ID, timestamp, or incrementing sequence number of the client's latest local message. The server can then determine the incremental messages the client needs to synchronize by comparing them with its message database.

[0133] A message fetch request is used to instruct a client to request the server to retrieve outdated incremental messages. Therefore, the message fetch request must contain at least a client identifier and a secondary identifier so that the server can accurately locate the target client and its current synchronization progress.

[0134] In some embodiments, message retrieval requests are typically triggered in the following scenarios: for example, after the client receives a lightweight synchronization notification (second synchronization message) pushed by the server, it confirms that there are new messages to be retrieved based on the first identifier in the notification; or, when the client comes back online or starts the application, it actively synchronizes messages generated during the offline period with the server.

[0135] The third synchronization message can be a set of incremental messages that the client has not yet stored, determined based on the client's pull request. The third synchronization message can be one or more messages, depending on the gap between the client's current progress and the latest message on the server. This ensures that the client completes incremental message synchronization, avoiding the resource waste caused by pulling all messages.

[0136] The message retrieval status indicates that the server has responded to the client's retrieval request and successfully pushed the third synchronization message. This status indicates that the server has completed processing the client's retrieval request and pushed the missing message to the client; it only represents that the retrieval response has been executed, not that the client has successfully stored the message. In this embodiment, the message retrieval status can be denoted as S2.

[0137] In some embodiments, after receiving a message retrieval request, the server may perform validity verification on the client identifier in the message retrieval request (to confirm that the client is a system-registered client) and verify the legality of the format of the second identifier (to confirm that the identifier set is complete and there are no invalid identifiers).

[0138] After the verification is successful, the server queries all second synchronous messages (i.e., synchronous messages that have been pushed to the client) corresponding to the client in the local message storage based on the client identifier. Then, the server compares the first identifier corresponding to the second synchronous message with the second identifier in the message retrieval request (the set of message identifiers that the client has received), filters out the second synchronous messages corresponding to the first identifier that do not appear in the set of second identifiers, and identifies them as third synchronous messages (i.e. incremental messages that the client has not stored).

[0139] Afterwards, the server performs an integrity check on the confirmed third synchronization message (confirming that the message content is complete and the first identifier association is valid). Once the check passes, the confirmation operation of the third synchronization message is completed, preparing for subsequent pushes and ensuring that the incremental push messages are accurate and effective, avoiding duplicate pushes or pushes of invalid messages.

[0140] In some embodiments, the server can encapsulate the third-party synchronization message into a data packet conforming to the transmission protocol and send it to the client through a suitable message push channel. To ensure the reliability of message transmission, the server can encrypt the third-party synchronization message to prevent the message content from being stolen or tampered with during transmission, or it can compress the message to reduce network bandwidth consumption.

[0141] After the push is completed, the server updates the status according to the push result. If the push is successful, the status is updated to message pull status in the status record of the second synchronization message associated with the pull request, and metadata such as pull time and number of messages pulled are recorded.

[0142] S203. Receive the first confirmation information, and update the status of the second synchronization message to the message receiving status according to the first identifier in the first confirmation information.

[0143] The first confirmation message indicates that the client has received the second synchronization message. This can be understood as a confirmation feedback sent by the client to the server after successfully receiving the second synchronization message. The first confirmation message carries at least a first identifier so that the server can accurately match and update the status of the corresponding message.

[0144] In some embodiments, the first confirmation information may further include information such as the client identifier and the receiving timestamp to enrich the dimensions of state tracking. The sending of the first confirmation information indicates that the client has reliably delivered the message, meaning that the message is accessible on the client side.

[0145] The message reception status can be represented in the server's state machine as the state that the client has successfully received the message. This status is a key evolution node from "pushed" to "received," indicating that the server has received the client's confirmation of receipt and the message has reliably reached the client. However, this status only indicates that the message has been received and stored by the client, and does not mean that the message has been displayed or completed business processing. In this embodiment, the message reception status can be denoted as S3.

[0146] In some embodiments, the server monitors confirmation messages returned by the client through a pre-established communication channel. Upon receiving the first confirmation message, the server can perform format validation and legality verification to confirm the message's integrity. For high-concurrency scenarios, the server can employ an asynchronous processing mechanism, placing the received first confirmation message into a confirmation message queue for batch consumption by the background processing module to avoid blocking the main business process. Simultaneously, the server can record information such as the receipt time and source client of the confirmation message for subsequent monitoring and analysis.

[0147] In some embodiments, to optimize network overhead, the client can use a lightweight acknowledgment protocol to send the first acknowledgment information. For example, the client can encode the acknowledgment status of multiple messages into a binary bitmap, where each bit represents the reception status of a message (e.g., 1 indicates received, 0 indicates not received), and send it to the server in batches. After receiving the compressed acknowledgment information, the server decodes the acknowledgment information and updates the status of the corresponding messages in batches according to the maintained mapping relationship between message identifiers and bitmap positions. This approach significantly reduces the amount of acknowledgment information transmitted, making it particularly suitable for resource-constrained scenarios such as IoT devices, or for ensuring the reliability of message synchronization in low-bandwidth network environments.

[0148] In some embodiments, the server parses a first identifier from the received first confirmation information and queries the state record of the corresponding second synchronization message in the state machine module based on the first identifier. After confirming that the current state is a message push state (i.e., the state evolution path allows evolution from the push state to the receive state), the server updates the message state to the message receive state. Through the above process, the server achieves accurate perception of the client's receiving behavior, providing key information support for the full lifecycle state tracking of messages.

[0149] S204. When the status of the second synchronization message is confirmed to be the preset status, the status of the second synchronization message is updated to the message synchronization status.

[0150] The preset state can be a state predefined in the server's state machine that triggers the final synchronization of the message. In this embodiment, the preset state can be the message processing state (S4), which is the state reached after the client has completed the business processing of the message. The server continuously monitors the message state, and when it detects that the message has evolved to the preset state, it confirms that the message has completed the entire process synchronization and can mark it as the final state.

[0151] The message synchronization state can be represented in the server's state machine as the state where the message has completed the full synchronization process. This state indicates that the entire lifecycle of the message, from generation and push to receipt and processing, has been closed, and the server will no longer trigger subsequent pushes or state change operations for this message. After a message enters this state, it can be archived as historical data or cleaned up to release system resources; this can be denoted as S5.

[0152] In some embodiments, the server may update the status of the second synchronization message to a message synchronization state when it confirms that the status of the second synchronization message is a preset state, based on the following implementation: receiving second confirmation information, the second confirmation information including a first identifier and status of the second synchronization message; performing verification processing on the first identifier and status to obtain a verification result, and updating the status of the second synchronization message to a message processing state when the verification result is a successful verification; and updating the status of the second synchronization message to a message synchronization state when it confirms that the status of the second synchronization message is a message processing state.

[0153] The second confirmation message indicates that the client has completed the business processing based on the second synchronization message. This can be understood as the final confirmation feedback returned by the client to the server after successfully displaying, consuming, or performing the corresponding business operation on the message. The second confirmation message carries at least a first identifier, used by the server to locate the corresponding message.

[0154] The verification result can be the legality judgment result obtained by the server after verifying the first identifier and status in the second confirmation information. It is used to determine whether the second confirmation information is credible and whether it can be used to trigger message status updates, ensuring that the server performs status update operations based on legal and valid confirmation information, and avoiding status chaos caused by illegal information.

[0155] The message processing status can be the state where the client has completed the business processing. This status is a key evolution point from message received to final completion, indicating that the server has received the client's processing confirmation, and the message has completed the business-related operations on the client side, but has not yet been marked as final completion.

[0156] In some embodiments, the server parses the first identifier and status from the received second confirmation information. Specifically, it verifies the validity of the first identifier by querying the message status database to see if a corresponding message exists. If the message does not exist, it returns a verification failure and records an exception.

[0157] Secondly, the validity of the status is verified, that is, the status value is checked to see if it is a predefined business processing status, and compared with the actual status of the current message to ensure that the status evolution path is valid (for example, only messages in the received state can receive processing confirmation). If all verifications pass, a verification result of "pass" is generated; otherwise, it is considered a failure, and a retransmission can be triggered according to the reason for the failure.

[0158] In some embodiments, after confirming that the verification result is successful, the server extracts the first identifier from the second confirmation information, combines it with the client identifier, queries the state in the local message state machine, accurately locates the second synchronous message corresponding to the first identifier, and reconfirms that the current state of the message is the message receiving state (to ensure the legality of the state evolution and avoid skipping updates).

[0159] Furthermore, the server updates the status of the second synchronization message from the message receiving status to the message processing status, and records the status update timestamp and the basis for the update. Afterward, the server associates and stores the status update record with the second confirmation information, the client identifier, and the first identifier to form a complete status evolution traceability log, providing a clear basis for subsequent updates to the message synchronization status.

[0160] In some embodiments, the server continuously monitors the message status. When it detects that a message has reached the message processing state, it determines whether this state meets the preset final state prerequisite. If so, a final state update operation is triggered, which updates the message status from the message processing state to the message synchronization state. This operation signifies that the message has completed its entire lifecycle synchronization from generation to processing, and the server will no longer push or change the status of this message.

[0161] For example, in the embodiments of this application, the entire process of synchronizing messages includes the updating of multiple states, specifically including message generation state, message push state, message receiving state, message retrieval state, message processing state, and message synchronization state. The relevant markers can be shown in Table 1:

[0162] Table 1

[0163]

[0164] It can be seen that the message states change sequentially and cannot be skipped; they can only move forward and not backward. The state changes, i.e., the message progression, are S0→S1→S2→S3→S4→S5.

[0165] The message processing method, apparatus, electronic device, storage medium, and program product provided in this application involve a server receiving a first synchronization message and initializing it to a message generation state, pushing a second synchronization message carrying a first identifier to the client and updating it to a message push state, receiving a first confirmation message from the client, updating the second synchronization message to a message receiving state, and updating it to a message synchronization state when the second synchronization message reaches a preset state. In this method, the server can generate a second synchronization message by configuring a first identifier for the first synchronization message, achieving unified management and state tracking of message entities. Furthermore, by pushing the second synchronization message to trigger client business processing and driving server state evolution based on the first confirmation message returned by the client, a two-way confirmation mechanism between the server and client is established. Moreover, through a phased, progressively evolving state model, the server can accurately perceive the complete processing progress of the message from generation, push, and reception to final synchronization completion, solving the problem in related technologies where the server can only confirm whether a message has been sent but cannot perceive the client's actual reception and processing status. In addition, this method is applicable to various application scenarios requiring reliable message reception, such as instant messaging, business notifications, and multi-terminal collaboration, significantly improving the accuracy and traceability of message synchronization while enhancing the reliability of message processing.

[0166] Figure 3 This is a flowchart illustrating another message processing method provided in an embodiment of this application. Please refer to... Figure 3 The method includes the following steps:

[0167] S301, Receive the second synchronization message sent by the server.

[0168] The second synchronization message includes a first identifier configured by the server, and is used to trigger the client to perform message retrieval processing.

[0169] In some embodiments, when the server has messages that need to be synchronized, a second synchronization message is sent to the client via a corresponding push channel. Upon receiving the second synchronization message, the client parses the message format and extracts the first identifier. Furthermore, the client can decide whether to immediately trigger the fetch process based on local policies; for example, if the client is active, it may respond immediately; if it is in the background or low-power mode, processing may be delayed or only processed under specific network conditions. After receiving the message, the client can temporarily store the second synchronization message locally for later processing.

[0170] S302, Send the first confirmation message to the server.

[0171] In some embodiments, after sending a first confirmation message to the server, a business processing status is determined, which is either a processing status or a completed status. When the business processing status is completed, a second confirmation message is sent to the server, which is used to indicate that the business processing status based on the third synchronization message is completed.

[0172] The business processing status is used to indicate the progress of business processing based on third-party synchronization messages.

[0173] The processing status indicates an intermediate state where the client has begun performing business processing based on third-party synchronous messages, but has not yet completed the entire business process.

[0174] The completion status indicates that the client has completed all business processing steps based on the third synchronization message, and that the business data or instructions have been executed without any abnormalities.

[0175] In some embodiments, after completing the business processing of the message, the client can determine whether the current status is a completed status based on the processing result. If so, the client sends a second confirmation message to the server through an acknowledgment channel (which may or may not be the same as the message push channel).

[0176] If a message transmission fails, the client can record the pending transmission queue and return to the initial state (i.e., the message generation state) to re-perform message synchronization. Through this mechanism, the client proactively reports the message's business completion status to the server, enabling the server to accurately perceive the entire message process progress and forming a complete two-way confirmation loop.

[0177] S303, Obtain the third synchronization message.

[0178] The second synchronization message includes the third synchronization message, which is a synchronization message that is not stored by the client.

[0179] In some embodiments, the client may obtain the third synchronization message based on the following implementation: determining the second identifier of the synchronized message corresponding to the current time; sending a message retrieval request to the server, the message retrieval request being used to request the retrieval of incremental messages, the message retrieval request including the second identifier and the client identifier; receiving the encrypted third synchronization message, and decrypting the encrypted third synchronization message to obtain the decrypted third synchronization message.

[0180] In some embodiments, after receiving the second synchronization message and parsing the first identifier, the client determines whether it needs to immediately fetch the message based on the first identifier. If the client has not yet stored the message content corresponding to the first identifier locally, the fetching process is triggered. In addition, the client will also actively initiate a message fetching request when it comes online again, when the application starts, or when synchronizing on a scheduled basis, in order to obtain incremental messages generated during the offline period.

[0181] In some embodiments, the client needs to parse the decrypted third synchronization message and extract fields such as message content. Then, the client associates the parsed message content with the first identifier and stores it in a local database or file system to ensure message persistence and reliability.

[0182] After storage is complete, the client can submit the message to the upper-level business module for display or processing. For example, in an instant messaging scenario, the message can be displayed in the chat interface; in an order status synchronization scenario, the local order list can be updated. Through the above process, the client achieves reliable message storage and business readiness.

[0183] The message processing method, apparatus, electronic device, storage medium, and program product provided in this application trigger the client to perform message retrieval processing by receiving a second synchronization message carrying a first identifier sent by the server, combining the second identifier of the currently synchronized message, sending a message retrieval request containing the second identifier and the client identifier to the server, receiving and decrypting the encrypted third synchronization message to obtain the incremental message, sending a first confirmation message to the server, and sending a second confirmation message after completing the business processing, thereby realizing message synchronization between the client and the server. In the above method, the client can trigger incremental fetching through the second synchronization message to accurately obtain the third synchronization message that it has not stored. It then uses double confirmation information to report the synchronization and processing status to the server. This method can achieve accurate message synchronization even when the client has unsynchronized incremental messages, effectively avoiding synchronization errors and resource waste caused by duplicate or missed message pushes. It eliminates the need for the client to fetch all messages, reducing communication overhead between the client and server and the client's storage pressure, thus improving message synchronization processing efficiency. It accurately achieves message synchronization between the client and server. Furthermore, this method is applicable to message synchronization needs of different types of clients and different network environments, reducing system deployment and maintenance costs. It improves the overall processing efficiency of message synchronization while increasing the accuracy of message synchronization.

[0184] Figure 4 This is a schematic diagram of another system architecture provided for an embodiment of this application. Please refer to [link / reference]. Figure 4 The method is described in detail below:

[0185] This system mainly consists of four core modules: a message production module, a message server (i.e., a push channel module), and a client system. The message production module generates business messages to be synchronized and sends them to the message server. The message server, as the core of the state machine, manages message storage, state evolution, push scheduling, and client confirmation processing, assigning a unique identifier to each message and maintaining its entire lifecycle state from generation to completion. The push channel module pushes the synchronization identifier (i.e., the second synchronization message) generated by the message server to the target client using an adapted push strategy. The client system receives the pushed synchronization identifier, triggers message retrieval processing to obtain the complete message content, and sends reception and processing confirmation information back to the message server, achieving reliable message synchronization and state closure.

[0186] The message processing method, apparatus, electronic device, storage medium, and program product provided in this application employ a message processing method based on push-driven and client-acknowledged state evolution. This method introduces a state evolution mechanism triggered by client acknowledgment, enabling the server to maintain an authoritative and traceable message state, achieving highly reliable, efficient, and low-resource-consumption message synchronization. Specifically, the method uses a combined mechanism of push triggering, client-pull verification, and incremental acknowledgment. In this mechanism, the push only serves as a synchronization trigger signal, the client holds the initiative in synchronization, and the server does not rely on connection state to determine the synchronization result, effectively avoiding problems such as duplicate pushes, message loss, and full compensation.

[0187] Figure 5 This is a flowchart illustrating another message processing method provided in an embodiment of this application. Please refer to... Figure 5 The method includes the following steps:

[0188] After the process starts, the message production module generates the business message to be synchronized (i.e., the first synchronization message) (S501); it determines whether the message needs to push a synchronization signal to the client (S502). If not, the current message synchronization process ends directly (S503); if so, the server pushes a synchronization trigger signal to the target client, where the synchronization push signal can be understood as the second synchronization message (S504); after receiving the synchronization trigger signal, the client performs integrity verification on the signal and completes local verification in conjunction with the status of locally synchronized messages (S505); after successful verification, the client actively initiates an incremental synchronization request (i.e., a message retrieval request) to the message server to retrieve incremental messages that it has not stored (S506); after receiving the request, the server filters out the corresponding incremental message (i.e., the third synchronization message) based on the identification information carried by the client (i.e., the second identifier) ​​and returns it to the client (S507); after successfully receiving the incremental message, the client completes the message confirmation operation and pushes a synchronization cursor (first confirmation information, second confirmation information) to the message server. At this point, the complete message synchronization process ends (S508).

[0189] Figure 6 This is a flowchart illustrating another message processing method provided in an embodiment of this application. Please refer to... Figure 6 The method includes the following steps:

[0190] S601. The server receives the first synchronization message and updates the status of the first synchronization message to the message generation status.

[0191] The first synchronization message carries a client identifier.

[0192] The specific process is as follows: At the start of the message synchronization process, the message production module generates a business message to be synchronized (the first synchronization message) and sends it to the server. Upon receiving the message, the server assigns a unique message identifier (the second synchronization message) to it, associates the message content with the message identifier, and stores them together. Simultaneously, it initializes the corresponding message state in the message state machine, with the initial state being the message generation state. Through these steps, the message is registered and initialized on the server side, enabling it to enter a synchronizeable state.

[0193] S602. The server pushes the second synchronization message to the client corresponding to the client identifier and updates the status of the second synchronization message to the message push status.

[0194] The second synchronization message carries a first identifier configured by the server for the first synchronization message, and the client uses the second synchronization message to perform business processing.

[0195] The specific process is as follows: After message initialization is complete, the server calls the push scheduling module, selects the corresponding message push channel based on the pre-configured target client information (client identifier) ​​and message push strategy, and actively pushes the second synchronization message to the target client. Upon triggering or completion of the push operation, the server updates the status of the second synchronization message to the message push status.

[0196] It should be noted that during this stage, the update of the message status only indicates that the push action has been executed, and does not mean that the client has actually received or processed the message.

[0197] S603, The client sends a message retrieval request to the server.

[0198] The message retrieval request is used to request the retrieval of incremental messages. The message retrieval request includes a second identifier and a client identifier.

[0199] S604. The server determines the third synchronization message in the second synchronization message based on the client identifier and the second identifier.

[0200] S605. The server pushes an encrypted third synchronization message to the client and updates the status of the second synchronization message to the message retrieval status.

[0201] S606. The client receives the encrypted third synchronization message and decrypts it to obtain the decrypted third synchronization message.

[0202] S607, The client sends the first confirmation message to the server.

[0203] The specific process is as follows: After receiving the second synchronization message sent by the server through the message push channel, the client pulls the incremental message, parses the message, and stores the message content and message identifier in the client's local storage module to ensure message reliability. Subsequently, the client sends a reception confirmation message (first confirmation message) to the server to indicate that the client has successfully received the message.

[0204] S608. The server updates the status of the second synchronization message to the message receiving status based on the first identifier in the first confirmation information.

[0205] The first confirmation message is used to indicate that the client has received the second synchronization message.

[0206] The specific process is as follows: After receiving the first confirmation message, the server performs a validity check on the message, including message identifier verification and status validity verification. If the verification passes, the server updates the status of the second synchronization message to the message reception status according to the status evolution rules.

[0207] S609. The client determines the business processing status, which is either processing status or completion status.

[0208] S610. When the business processing status is completed, send a second confirmation message to the server.

[0209] The second confirmation information includes the first identifier and status of the second synchronization message. The second confirmation information is used to indicate that the status of business processing based on the third synchronization message is a completed status.

[0210] The specific process is as follows: After receiving the message, the client displays, processes, or automatically consumes the third synchronous message. Once the client confirms that the corresponding processing flow has been completed, it sends a processing confirmation message (i.e., the second confirmation message) to the server.

[0211] S611. The server performs verification processing on the first identifier and status, obtains the verification result, and updates the status of the second synchronization message to the message processing status when the verification result is successful.

[0212] The specific process is as follows: After receiving the processing confirmation information, the server verifies the confirmation information again, and if the confirmation is valid, updates the message status to message processing status.

[0213] S612. When the server confirms that the status of the second synchronization message is message processing status, it updates the status of the second synchronization message to message synchronization status.

[0214] The specific process is as follows: when the message's state evolves to the preset final state, the server marks the message as synchronized and will no longer trigger subsequent push or state change operations on that message. This completes the entire synchronization process for a message, from generation, push, reception, processing to completion. Through the above phased process design, a closed-loop message synchronization system is achieved, where push triggers synchronization behavior, client confirmation drives state evolution, and the server maintains the authoritative state.

[0215] The message processing method, apparatus, electronic device, storage medium, and program product provided in this application achieve a highly reliable, loosely coupled, traceable, and scalable message synchronization method through push-triggered synchronization, client-side confirmation-driven state evolution, and server-side maintenance of an authoritative state machine. This effectively solves the problems of unreliable state, high resource consumption, and difficulty in guaranteeing consistency in traditional message synchronization. Specifically, this method does not rely on a specific push protocol or implementation method. The push channel can be system notification push, long-connection push, short-connection push, or any other form of message delivery mechanism. This effectively avoids the push channel not being used as a basis for determining the message synchronization result; it is only used to trigger synchronization behavior on the client side and does not directly participate in the final determination of the message state. Furthermore, the confirmation information sent by the client to the server adopts a unified confirmation model, only needing to carry the message identifier and corresponding state information, regardless of the specific client type or operating environment. This allows clients with different operating systems, different terminal forms, or different application instances to use the same confirmation logic. Moreover, the message state machine maintained by the server adopts a phased, progressively evolving state model. The number and meaning of states can be expanded or trimmed according to specific business needs without affecting the basic logic of the overall synchronization process. For example, without changing the overall structure of the synchronization method, intermediate states can be added to adapt to more complex business processing scenarios. Furthermore, this invention abstracts message synchronization into a general mechanism of "push triggering, client confirmation, and state evolution." This method can be reused as a basic capability by different business systems and is applicable to various application scenarios such as instant messaging systems, business notification systems, order status synchronization systems, and message synchronization for IoT devices. Moreover, when the push channel, client type, or business processing logic changes, only the corresponding module needs to be adjusted, without reconstructing the overall message synchronization process or state control logic, significantly reducing the evolution cost and maintenance complexity of the system.

[0216] Figure 7 This is a schematic diagram of the structure of a message processing device provided in an embodiment of this application, as shown below. Figure 7 As shown, the device 70 includes: a receiving module 71, a pushing module 72, and an updating module 73.

[0217] The receiving module 71 is used to receive the first synchronization message and update the status of the first synchronization message to the message generation status. The first synchronization message carries a client identifier.

[0218] The push module 72 is used to push the second synchronization message to the client corresponding to the client identifier, and update the status of the second synchronization message to the message push status. The second synchronization message carries the first identifier configured by the server for the first synchronization message. The client is used to perform business processing based on the second synchronization message.

[0219] The update module 73 is used to receive the first confirmation information and update the status of the second synchronization message to the message receiving status according to the first identifier in the first confirmation information. The first confirmation information is used to indicate that the client has received the second synchronization message.

[0220] The update module 73 is also used to update the status of the second synchronization message to the message synchronization status when it is confirmed that the status of the second synchronization message is the preset status.

[0221] The message processing apparatus provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0222] In one possible implementation, the update module 73 is specifically used for:

[0223] Receive a second confirmation message, which indicates that the client has completed the business processing based on the second synchronization message. The second confirmation message includes the first identifier and status of the second synchronization message.

[0224] The first identifier and status are verified to obtain the verification result. When the verification result is that the verification is successful, the status of the second synchronization message is updated to the message processing status.

[0225] When the status of the second synchronization message is confirmed to be in message processing status, the status of the second synchronization message is updated to message synchronization status.

[0226] In one possible implementation, the apparatus further includes a processing module, which is specifically used for:

[0227] Receive message retrieval request. The message retrieval request includes a client identifier and a second identifier. The second identifier is used to indicate the synchronization messages that the client has received at the current time.

[0228] Based on the client identifier and the second identifier, the third synchronization message is determined in the second synchronization message;

[0229] Push the encrypted third synchronous message to the client and update the status of the second synchronous message to message fetch status.

[0230] In one possible implementation, the push module 72 is specifically used for:

[0231] Based on the client identifier, the corresponding message push strategy is determined. The message push strategy is used to instruct the execution of message push processing to the client.

[0232] Determine the corresponding message push channel based on the message push strategy;

[0233] A second synchronized message is pushed to the client via a message push channel.

[0234] Figure 8 This is a schematic diagram of another message processing device provided in an embodiment of this application, as shown below. Figure 8 As shown, the device 80 includes a receiving module 81, an acquisition module 82, and a sending module 83.

[0235] The receiving module 81 is used to receive a second synchronization message sent by the server. The second synchronization message includes a first identifier configured by the server and is used to trigger the client to perform message retrieval processing.

[0236] The acquisition module 82 is used to acquire the third synchronization message. The second synchronization message includes the third synchronization message, which is a synchronization message that is not stored by the client.

[0237] The sending module 83 is used to send the first confirmation information to the server.

[0238] The message processing apparatus provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0239] In one possible implementation, the acquisition module 82 is specifically used for:

[0240] Determine the second identifier of the synchronized message corresponding to the current moment;

[0241] Send a message retrieval request to the server. The message retrieval request is used to request the retrieval of incremental messages. The message retrieval request includes a second identifier and a client identifier.

[0242] Receive the encrypted third synchronization message, and decrypt the encrypted third synchronization message to obtain the decrypted third synchronization message.

[0243] In one possible implementation, the device includes a processing module, which is further configured to:

[0244] Determine the business processing status, which can be either processing status or completion status. The business processing status is used to indicate the progress of business processing based on third-party synchronization messages.

[0245] When the business processing status is complete, a second confirmation message is sent to the server. The second confirmation message is used to indicate that the business processing status based on the third synchronization message is complete.

[0246] The message processing apparatus provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0247] Figure 9This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the electronic device 90 may include at least one processor 91 and a memory 92.

[0248] Memory 92 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0249] The memory 92 may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0250] The processor 91 is used to execute computer execution instructions stored in the memory 92 to implement the methods described in the foregoing method embodiments. The processor 91 may be a CPU, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0251] Optionally, the electronic device 90 may also include a communication interface 93. In specific implementations, if the communication interface 93, memory 92, and processor 91 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0252] Optionally, in a specific implementation, if the communication interface 93, memory 92, and processor 91 are integrated on a single chip, then the communication interface 93, memory 92, and processor 91 can communicate through an internal interface.

[0253] The electronic device in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be repeated here.

[0254] This application provides a computer-readable storage medium, which may include various media capable of storing computer-executable instructions, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), RAM, a disk, or an optical disk. Specifically, the computer-readable storage medium stores computer-executable instructions, which, when executed by a computer, cause the technical solution shown in the above method embodiment to be executed. The specific implementation and technical effects are similar and will not be repeated here.

[0255] This application provides a computer program product, including a computer program. When the computer program is executed by a computer, the technical solution shown in the above method embodiment is executed. The specific implementation method and technical effect are similar, and will not be repeated here.

[0256] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0257] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0258] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0259] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0260] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0261] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0262] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0263] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A message processing method, characterized in that, Applied to a server, the method includes: Receive the first synchronization message and update the status of the first synchronization message to the message generation status. The first synchronization message carries a client identifier. The client pushes a second synchronization message to the client corresponding to the client identifier and updates the status of the second synchronization message to message push status. The second synchronization message carries the first identifier configured by the server for the first synchronization message. The client is used to perform business processing based on the second synchronization message. The client receives a first confirmation message and updates the status of the second synchronization message to a message receiving status based on the first identifier in the first confirmation message. The first confirmation message is used to indicate that the client has received the second synchronization message. When the status of the second synchronization message is confirmed to be the preset status, the status of the second synchronization message is updated to the message synchronization status.

2. The method according to claim 1, characterized in that, When the status of the second synchronization message is confirmed to be a preset status, the status of the second synchronization message is updated to a message synchronization status, including: Receive a second confirmation message, which indicates that the client has completed the business processing based on the second synchronization message. The second confirmation message includes a first identifier and status of the second synchronization message. The first identifier and the status are verified to obtain a verification result. When the verification result is that the verification is successful, the status of the second synchronization message is updated to the message processing status. When the status of the second synchronization message is confirmed to be message processing status, the status of the second synchronization message is updated to message synchronization status.

3. The method according to claim 1, characterized in that, After updating the status of the second synchronized message to a message push status, the method further includes: Receive a message retrieval request, the message retrieval request including the client identifier and a second identifier, the second identifier being used to indicate the synchronization messages that the client has received at the current time; Based on the client identifier and the second identifier, a third synchronization message is determined in the second synchronization message; The encrypted third synchronization message is pushed to the client, and the status of the second synchronization message is updated to message retrieval status.

4. The method according to claim 1, characterized in that, Push a second synchronization message to the client corresponding to the client identifier, including: Based on the client identifier, a corresponding message push strategy is determined, and the message push strategy is used to instruct the execution of message push processing to the client; Based on the aforementioned message push strategy, determine the corresponding message push channel; The second synchronization message is pushed to the client through the message push channel.

5. A message processing method, characterized in that, Applied to a client, the method includes: The client receives a second synchronization message sent by the server. The second synchronization message includes a first identifier configured by the server. The second synchronization message is used to trigger the client to perform message retrieval processing. Obtain a third synchronization message, wherein the second synchronization message includes the third synchronization message, and the third synchronization message is a synchronization message not stored by the client; Send a first confirmation message to the server.

6. The method according to claim 5, characterized in that, Retrieve third-party synchronization messages, including: Determine the second identifier of the synchronized message corresponding to the current moment; Send a message retrieval request to the server. The message retrieval request is used to request the retrieval of incremental messages. The message retrieval request includes the second identifier and the client identifier. Receive the encrypted third synchronization message and decrypt the encrypted third synchronization message to obtain the decrypted third synchronization message.

7. The method according to claim 5, characterized in that, After sending the first confirmation message to the server, the method further includes: Determine the business processing status, which is either a processing status or a completion status. The business processing status is used to indicate the progress of business processing based on the third synchronization message. When the business processing status is complete, a second confirmation message is sent to the server. The second confirmation message is used to indicate that the business processing status based on the third synchronization message is complete.

8. A message processing device, characterized in that, Applied to servers, including: A receiving module is used to receive a first synchronization message and update the status of the first synchronization message to a message generation status. The first synchronization message carries a client identifier. The push module is used to push a second synchronization message to the client corresponding to the client identifier, and update the status of the second synchronization message to a message push status. The second synchronization message carries a first identifier configured by the server for the first synchronization message. The client is used to perform business processing based on the second synchronization message. An update module is used to receive first confirmation information and update the status of the second synchronization message to a message receiving status according to the first identifier in the first confirmation information. The first confirmation information is used to indicate that the client has received the second synchronization message. The update module is also used to update the status of the second synchronization message to a message synchronization status when it is confirmed that the status of the second synchronization message is a preset status.

9. A message processing device, characterized in that, Applied to the client side, including: The receiving module is used to receive a second synchronization message sent by the server. The second synchronization message includes a first identifier configured by the server. The second synchronization message is used to trigger the client to perform message retrieval processing. The acquisition module is used to acquire a third synchronization message, wherein the second synchronization message includes the third synchronization message, and the third synchronization message is a synchronization message that is not stored by the client; The sending module is used to send the first confirmation information to the server.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images