State data synchronization method, and electronic device, storage medium and program product

Abstract

A state data synchronization method, which provides a pure in-memory state data management mechanism. By means of optimizing the processing of a state change event and a log synchronization process, the consistency of state data of a plurality of nodes in a state data management system is ensured, and it is ensured that there is always a master node available in the state data management system to provide state data without service interruption, thereby achieving zero-downtime for the state data management system.

Description

Status data synchronization methods, electronic devices, storage media and program products Cross-reference to related applications

[0001] This disclosure claims priority to Chinese patent application No. 202510487379.1, filed on April 17, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of computer technology, and in particular to a state data synchronization method, electronic device, storage medium, and program product. Background Technology

[0003] The state data management system is a crucial component of the application service system. It is responsible for maintaining various state data generated during the operation of the application service system, such as user session information, cached data, or instance status. Currently, upgrading, maintaining, or recovering from a fault in the state data management system typically requires shutting down the system and migrating the state data. This can easily lead to service interruptions, impacting user experience and potentially negatively affecting service continuity. Summary of the Invention

[0004] This disclosure provides a state data synchronization method, electronic device, storage medium, and program product to ensure the consistency of state data across multiple nodes in a state data management system, enabling the state data management system to operate without downtime, ensuring high availability and service continuity, and improving user experience.

[0005] This disclosure provides a state data synchronization method applied to a master node of a state data management system. The state data management system includes a master node and multiple slave nodes, with the master node being elected by the multiple slave nodes. The method includes: triggering a first state change event during the execution of an access request from a client, and performing a change operation on the state data of a first data object in the local memory of the master node according to the first state change event; adding a log entry of the first data object to first log data stored in the local memory of the master node, wherein the log entry of the first data object is used to indicate that a change operation has been performed on the state data of the first data object according to the first state change event and the corresponding state change time; in response to the current synchronization operation triggered every other synchronization window, obtaining the incremental log data to be synchronized in this current time from the first log data, wherein the incremental log data to be synchronized in this current time includes at least one log entry whose state change time is within the current synchronization window; synchronizing the incremental log data to be synchronized in this current time to the multiple slave nodes, so that the slave nodes add the incremental log data to be synchronized in this current time to second log data stored in the local memory of the slave nodes, and performing a change operation on the state data of the second data object in the local memory of the slave nodes according to the incremental log data in the second log data.

[0006] This disclosure provides a state data synchronization device applied to the master node of a state data management system with a master-slave architecture. The state data management system is used to maintain and manage state data generated during the operation of an application service system. The state data management system includes the master node and multiple slave nodes, and the master node is elected by the multiple slave nodes. The device includes: a change unit, used to trigger a first state change event during the execution of an access request from a client, and to perform a change operation on the state data of a first data object in the local memory of the master node according to the first state change event; A log update unit is configured to add log entries of the first data object to the first log data stored in the local memory of the master node, wherein the log entries of the first data object are used to indicate that a change operation has been performed on the state data of the first data object according to the first state change event and the corresponding state change time; and a synchronization unit is configured to, in response to the current synchronization operation triggered every other synchronization window, obtain the incremental log data to be synchronized in this current time from the first log data, wherein the incremental log data to be synchronized in this current time includes at least one log entry whose state change time is within the current synchronization window; synchronize the incremental log data to be synchronized in this current time to the plurality of slave nodes respectively, so that the slave nodes add the incremental log data to be synchronized in this current time to the second log data stored in the local memory of the slave nodes, and perform a change operation on the state data of the second data object in the local memory of the slave nodes according to the incremental log data in the second log data.

[0007] This disclosure provides an application service system, including a state data management system. The state data management system maintains and manages state data generated during the operation of the application service system. The state data management system has a master-slave architecture, including a master node and multiple slave nodes. The master node is elected from the slave nodes. The master node is used to: trigger a first state change event during the execution of an access request from a client, and perform a change operation on the state data of a first data object in the master node's local memory according to the first state change event; and add log entries of the first data object to first log data stored in the master node's local memory, wherein the log entries of the first data object are used to indicate... The state data of the first data object has been modified according to the first state change event, and the corresponding state change time has been recorded. In response to the current synchronization operation triggered every other synchronization window, the incremental log data to be synchronized this time is obtained from the first log data. The incremental log data to be synchronized this time includes at least one log entry whose state change time is within the current synchronization window. The incremental log data to be synchronized this time is synchronized to multiple slave nodes. The slave nodes are used to: add the incremental log data to be synchronized this time to the second log data stored in the slave node's local memory, and perform a modification operation on the state data of the second data object in the slave node's local memory according to the incremental log data in the second log data.

[0008] This disclosure also provides an electronic device, including: a memory and a processor; the memory for storing a computer program; and the processor coupled to the memory for executing the computer program to perform steps in a state data synchronization method.

[0009] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, enables the processor to implement the steps in the state data synchronization method.

[0010] This disclosure also provides a computer program product, including a computer program / instructions that, when executed by a processor, enable the processor to implement the steps in the state data synchronization method.

[0011] The technical solution provided in this disclosure maintains the application service system's state data in both the master node's local memory and the slave node's local memory in a master-slave architecture state data management system. The master node is allowed to interact with clients, triggering state change events during the execution of access requests from clients. Based on these events, the master node performs change operations on the state data in its local memory and synchronously updates the log data in its local memory. The master node asynchronously synchronizes incremental log data to the slave node. The slave node first updates its local log data based on the incremental log data synchronized by the master node, and then performs change operations on the state data in its local memory based on the log data in its local memory. This provides a pure in-memory state data management mechanism. By optimizing the handling of state change events and the log synchronization process, it ensures the consistency of state data across multiple nodes in the state data management system. This guarantees that the state data management system always has a master node providing state data, eliminating service interruptions and ensuring high availability and service continuity, thus improving user experience. Furthermore, batch synchronization of incremental log data in memory reduces synchronization overhead and achieves high performance for the state data management system. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0013] Figure 1 is a schematic diagram of the structure of an exemplary application service system provided in an embodiment of this disclosure;

[0014] Figure 2 is a signaling interaction diagram of a state data synchronization method provided in an embodiment of this disclosure;

[0015] Figure 3 is a schematic diagram of a status data synchronization device provided in an embodiment of this disclosure;

[0016] Figure 4 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0018] In the embodiments of this disclosure, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the access relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. In the textual description of this disclosure, the character " / " generally indicates that the preceding and following associated objects have an "or" relationship. Furthermore, in the embodiments of this disclosure, "first," "second," "third," etc., are only used to distinguish the content of different objects and have no other special meaning.

[0019] It should be noted that, in the cases involving user information in the embodiments of this disclosure, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with relevant laws, regulations, and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards.

[0020] The technical solutions of this disclosure and how they solve the aforementioned 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 repeated in some embodiments. The technical solutions provided by each embodiment of this disclosure are described in detail below with reference to the accompanying drawings.

[0021] Figure 1 is a schematic diagram of an exemplary application service system provided in an embodiment of this disclosure. Specifically, the application service system may include various components. The state data management system is an important component of the application service system, responsible for maintaining various state data generated during the operation of the application service system. The state data differs for different application service systems. Of course, the state data management system is not limited to managing state data; for example, it can also manage configuration data, metadata, log data, etc. Application service systems include, but are not limited to, e-commerce service systems, cloud service systems, social media platforms, and function computing service clusters. In an e-commerce service system, the state data management system can maintain various state data such as the user's shopping cart, order status, and payment process status. In a cloud service system, the state data management system can maintain state data such as virtual machines, containers, or function instances. In a social media platform, the state data management system can maintain session state to support real-time chat functionality. In a function computing service cluster, the state data management system can maintain the container state of function computing containers, ensuring efficient container operation, effective resource utilization, and rapid fault recovery. In practical applications, the state data management system has shown good implementation results in function computing service clusters, continuously monitoring the status of each function computing container (such as running, paused, error, etc.) and updating this status information in a timely manner. State data management systems typically employ a master-slave architecture to achieve high availability, fault tolerance, and load balancing. To ensure the consistency of state data, the state data management system dynamically selects a master node through an election mechanism. Referring to Figure 1, a state data management system has a master-slave architecture, which can include a master node and multiple slave nodes.

[0022] In this embodiment, the master node interacts with the client, allowing the execution of access requests sent by the client, and triggering a state change event during the execution of the access request from the client. The master node performs change operations on the state data in its local memory based on the state change event, and synchronously updates the log data in its local memory. The master node can also asynchronously obtain incremental log data within the current synchronization window and perform cross-node data synchronization. During cross-node data synchronization, the master node synchronizes the incremental log data within the current synchronization window to each slave node.

[0023] In this embodiment, slave nodes are prohibited from interacting with the client. The state data and log data in the slave node's local memory can only be updated based on the incremental log data synchronized by the master node. Specifically, the slave node updates the log data in its local memory based on the incremental log data received from the master node within the current synchronization window. The slave node can periodically retrieve incremental log data from its local memory asynchronously and perform change operations on the state data in its local memory based on the incremental log data, achieving the effect of maintaining consistency of state data across multiple nodes.

[0024] In practical applications, the master node can also utilize exception handling mechanisms to ensure uninterrupted service and maintain consistency of state data across multiple nodes. These exception handling mechanisms include, but are not limited to: re-electing a new master node when its heartbeat signal is not detected; resynchronizing when log data between the master and slave nodes is inconsistent; recovering state data from memory from persistent storage in extreme cases; and a joint consensus mechanism when state data management system members change.

[0025] It is important to note that the state data management system shown in Figure 1 is merely an example, and the embodiments disclosed herein do not limit the number of nodes in the state data management system.

[0026] To better understand the technical solutions provided by the embodiments of this disclosure, the following description is provided in conjunction with the signaling interaction diagram shown in Figure 2. Figure 2 is a signaling interaction diagram of a state data synchronization method provided by an embodiment of this disclosure. Referring to Figure 2, the method may include the following steps 201 to 206.

[0027] Step 201: During the execution of the access request from the client, the master node triggers the first state change event and performs a change operation on the state data of the first data object in the local memory of the master node according to the first state change event.

[0028] In practical applications, a state data management system needs to maintain the state data of various data objects involved in the application service system. A data object can be understood as an object that the application service system needs to focus on; data objects are often understood as Business Entities (BEs). Different application service systems have different data objects.

[0029] For example, data objects in an e-commerce service system include, but are not limited to, order objects and product objects. Order object status data includes, but is not limited to, various order statuses such as pending payment, paid, in transit, and completed. Product object status data includes, but is not limited to, inventory quantity, listing status, or promotional status.

[0030] For example, data objects in a cloud service system include, but are not limited to, virtual machines, containers, or function instances. Virtual machine status data includes, but is not limited to, health status, CPU utilization, and memory utilization; container status data includes, but is not limited to, running, restarting, and exited. Function instance status includes, but is not limited to, current concurrency, CPU (Central Processing Unit) utilization, and memory utilization.

[0031] Specifically, the client sends an access request to the master node, and the master node executes the access request according to its service logic. During the execution of the client's access request, the master node typically triggers state change events. For ease of understanding and distinction, the state change event currently triggered by the master node is referred to as the first state change event, and the data object whose state data needs to be changed in the first state change event is referred to as the first data object. The first state change event is used to instruct the execution of a change operation on the state data of the first data object in the master node's local memory. For example, the first state change event instructs the change of the order status from unpaid to paid. The master node's local memory refers to the memory space located locally on the master node, used to store the state data and log data of the data objects. The master node performs change operations on the state data of the first data object in its local memory based on the first state change event, for example, changing the order status from unpaid to paid; or updating the CPU or memory usage of a virtual machine instance.

[0032] Step 202: The master node adds the log entry of the first data object to the first log data stored in the local memory of the master node. The log entry of the first data object is used to indicate that the state data of the first data object has been changed according to the first state change event and the corresponding state change time.

[0033] In this embodiment, after the master node performs a change operation on the state data of the first data object in its local memory based on the first state change event, it also generates a log entry for the first data object. The log entry records key information about the state change, such as the specific content of the state change, the time of the state change, and the data object identifier. For example, a log entry might record "Order ID: 12345, State Change: From Unpaid to Paid, Time: 2025-03-31 16:30:00". Another example is a log entry recording "Virtual Machine ID: vm-001, State Change: From Stopped to Running, Time: 2025-03-31 16:30:00".

[0034] In this embodiment, the log entry for the first data object is used to indicate that a change operation has been performed on the state data of the first data object according to the first state change event, and the corresponding state change time. The master node adds the log entry for the first data object to the first log data stored in the master node's local memory. The first log data is the log data stored in the master node's local memory. As time goes on, the number of log entries in the first log data in the master node's local memory increases.

[0035] Step 203: In response to the synchronization operation triggered every synchronization window, the master node obtains the incremental log data to be synchronized in this session from the first log data. The incremental log data to be synchronized in this session includes at least one log entry whose state change time is within the current synchronization window.

[0036] In practical applications, to ensure consistency of status data across all nodes, the master node periodically performs cross-node data synchronization for incremental log data. Incremental log data refers to the set of all newly added or modified log entries since the last synchronization operation. The synchronization window is the time interval between two consecutive synchronization operations. Assuming the synchronization window is set to 5 minutes, the master node will trigger a synchronization operation at the end of each 5-minute interval. In response to the synchronization operation triggered every other synchronization window, the master node can calculate the time range of the current synchronization window based on the current time and the end time of the last synchronization. For example, if the end time of the last synchronization was 2025-03-31 16:00:00, and the current time is 2025-03-31 16:05:00, the time range of the current synchronization window is from 2025-03-31 16:00:00 to 2025-03-31 16:05:00. The master node selects at least one log entry whose status change time falls within the current synchronization window from the first log data based on the status change time of each log entry in the first log data, and uses it as the incremental log data to be synchronized this time.

[0037] In practical applications, the master node can directly retrieve the incremental log data required for this synchronization from the primary log data and synchronize it to the slave nodes. Optionally, the incremental log data to be synchronized can be compressed to reduce the amount of data to be synchronized, thereby reducing synchronization overhead.

[0038] Based on the above, the implementation method for obtaining the incremental log data to be synchronized in this time from the first log data is as follows: obtain the original incremental log data whose state change time is within the synchronization window in this time from the first log data; merge multiple log entries belonging to the same data object from the original incremental log data to obtain a new log entry corresponding to the same data object; generate the incremental log data to be synchronized in this time based on the new state change logs corresponding to each data object.

[0039] Specifically, raw incremental log data can be understood as incremental log data whose state change time is within the current synchronization window, directly obtained from the first log data; that is, incremental log data that has not yet undergone data compression. When compressing raw incremental log data, multiple log entries belonging to the same data object can be merged to obtain a new log entry corresponding to the same data object.

[0040] In practical applications, log entry merging rules can be set as needed without restriction. For example, when merging, the log entry with the latest state change time can be selected from multiple log entries under the same data object as a new log entry corresponding to that data object, ignoring other log entries.

[0041] Suppose that in an e-commerce system, a product with order ID 12345 undergoes the following status changes within a single synchronization window: at 16:01, it changes from unpaid to paid; at 16:03, it changes from paid to "delivering"; and at 16:04, it changes from "delivering" to "completed." Although the product with order ID 12345 undergoes three status changes within the synchronization window, only the last status change, i.e., the change from "delivering" to "completed," needs to be synchronized.

[0042] The original incremental log data before the merge is as follows: [{order_id:12345,status:Paid,change_time:2025-03-31 16:01:00}, {order_id:12345,status:Delivering,change_time:2025-03-31 16:03:00}, {order_id:12345,status:Completed,change_time:2025-03-31 16:04:00}].

[0043] The merged incremental log data is as follows: [{order_id:12345,status:Completed,change_time:2025-03-31 16:04:00}].

[0044] For example, during the merging process, all intermediate states are linked together in chronological order to form a complete state change path. The merged log entries not only record the final state but also the state change path. Taking the original incremental log data before merging as an example, the merged incremental log data is as follows: [Order ID: 12345, Status Path: [Paid -> In Delivery -> Completed], Time Range: [16:01-16:04]].

[0045] For example, during the merge process, aggregated values ​​(such as total counts, cumulative values, average values, etc.) are calculated and used as the merge result. The merged log entries contain certain aggregated values, rather than specific intermediate states. Assume the original incremental log data before the merge is as follows: [Virtual Machine ID: vm-001, CPU Utilization: 50%, Time: 16:01] [Virtual Machine ID: vm-001, CPU Utilization: 70%, Time: 16:03] [Virtual Machine ID: vm-001, CPU Utilization: 60%, Time: 16:04]

[0046] The merged incremental log data is as follows: [Virtual Machine ID: vm-001, Average CPU Utilization: 60%, Time Range: [16:01-16:04]].

[0047] 204. The master node will synchronize the incremental log data required for this synchronization to multiple slave nodes.

[0048] In this embodiment, every other synchronization window, the master node synchronizes the incremental log data to be synchronized to multiple slave nodes, so that the slave nodes can update the log data and status data in their local memory, ensuring that the status data on all nodes remains consistent.

[0049] In some optional embodiments, after synchronizing the incremental log data to be synchronized to multiple slave nodes, it is also possible to: add an outdated flag to the incremental log data to be synchronized in the first log data in the local memory of the master node, the outdated flag indicating that the corresponding incremental log data has already undergone synchronization.

[0050] Specifically, by marking synchronized log data, the master node can prevent it from repeatedly sending the same log data to slave nodes in subsequent operations. Over time, some log data can be deleted from the master node's local memory based on the outdated marker, thus reducing excessive memory usage and conserving memory resources.

[0051] In some optional embodiments, the method further includes: in response to not receiving confirmation messages from a specified number of slave nodes, resynchronizing the incremental log data to be synchronized to the multiple slave nodes until the specified number of slave nodes return confirmation messages, wherein the confirmation messages indicate that the slave nodes acknowledge receiving the incremental log data to be synchronized.

[0052] Specifically, the specified number can be flexibly set as needed. This number is typically set to the majority number in the state data management system to ensure consistency is maintained even in the event of a failure. For example, in a state data management system with 5 nodes, the specified number could be set to 3. The retry mechanism ensures that the master node can reliably synchronize incremental log data to the slave nodes even if it hasn't received enough acknowledgment messages. By continuously retrying until the specified number of acknowledgment messages from the slave nodes are received, consistency and reliability between the master and slave nodes are guaranteed.

[0053] In some optional embodiments, the incremental log data to be synchronized to multiple slave nodes is synchronized as follows: the incremental log data to be synchronized and the index position information of the last log entry of the previous synchronization operation are synchronized to multiple slave nodes respectively. This allows the slave nodes to add the incremental log data to be synchronized to the second log data stored in their local memory if the index position information of the last log entry of the previous synchronization operation received in the current synchronization window matches the index position information of the last log entry received in the previous synchronization window. If a matching failure message is received from a slave node, the incremental log data to be synchronized and the incremental log data within the previous synchronization window are sent to the slave nodes so that the slave nodes can add these two data to the second log data stored in their local memory.

[0054] Specifically, the index position information of log entries is used to identify the specific location of log entries within the log data. A synchronization verification mechanism based on the log index position information ensures the consistency of incremental log data synchronization between the master and slave nodes. That is, by including the index position information of the last log entry from the previous synchronization operation in each synchronization operation, it verifies whether the slave node has correctly received all incremental log data from the previous synchronization operation. If the index position information of the last log entry from the previous synchronization operation received by the slave node in the current synchronization window matches the index position information of the last log entry received in the previous synchronization window, it means that the slave node has correctly received all incremental log data from the previous synchronization operation. At this time, the slave node adds the incremental log data to be synchronized in this operation to its second log data in local memory. If the index position information of the last log entry from the previous synchronization operation received by the slave node in the current synchronization window fails to match the index position information of the last log entry received in the previous synchronization window, it means that the slave node has not correctly received all incremental log data from the previous synchronization operation, and there may be log loss or improper processing. After receiving a matching failure message, the master node will resend the incremental log data that needs to be synchronized this time, as well as the incremental log data that is in the previous synchronization window, so that the slave nodes can fill in the missing incremental log data.

[0055] Step 205: The slave node adds the incremental log data to be synchronized this time to the second log data stored in the slave node's local memory.

[0056] In this embodiment, the slave node's local memory refers to the memory space located locally on the slave node, used to store the state data and log data of data objects. When the slave node receives the incremental log data to be synchronized from the master node, it adds this incremental log data to the second log data stored in the slave node's local memory. This second log data is the log data stored in the slave node's local memory. Over time, the number of log entries in the second log data in the slave node's local memory increases. It is understood that by synchronizing incremental log data, it is ensured that the log data on all nodes remains consistent.

[0057] It is worth noting that slave nodes are prohibited from processing access requests from clients. When a slave node receives an access request from a client, it refuses to process the request and returns the master node's access address information to the client. The client then resends the access request to the master node for processing based on the master node's access address information.

[0058] Step 206: The slave node performs a change operation on the state data of the second data object in the slave node's local memory based on the incremental log data in the second log data.

[0059] In this embodiment, the slave node can periodically obtain incremental log data from the second log data and use the incremental log data to perform change operations on the state data of the second data object in the slave node's local memory to ensure that the state data remains consistent across all nodes.

[0060] The technical solution provided in this disclosure maintains the application service system's state data in both the master node's local memory and the slave node's local memory in a master-slave architecture state data management system. The master node is allowed to interact with clients, triggering state change events during the execution of access requests from clients. Based on these events, the master node performs change operations on the state data in its local memory and synchronously updates the log data in its local memory. The master node asynchronously synchronizes incremental log data to the slave node. The slave node first updates its local log data based on the incremental log data synchronized by the master node, and then performs change operations on the state data in its local memory based on the log data in its local memory. This provides a pure in-memory state data management mechanism. By optimizing the handling of state change events and the log synchronization process, it ensures the consistency of state data across multiple nodes in the state data management system. This guarantees that the state data management system always has a master node providing state data, eliminating service interruptions and ensuring high availability and service continuity, thus improving user experience. Furthermore, batch synchronization of incremental log data in memory reduces synchronization overhead and achieves high performance for the state data management system.

[0061] In practical applications, state data management systems can use any protocol for state data synchronization. Preferably, the state data management system can use the Raft protocol for state data synchronization. The Raft protocol is an algorithm for managing the consistency of replicated logs in distributed systems. It coordinates log replication by electing a leader node (which can be understood as the master node), ensuring data consistency across all nodes. The Raft protocol has the following advantages.

[0062] 1. Easy to understand and implement: The Raft protocol is easier to understand and implement than other consensus algorithms. It has an intuitive design concept, which makes it easier for developers to build and maintain distributed systems.

[0063] 2. Automatic master election and timed heartbeat: When the master node needs to be upgraded or fails, the heartbeat between the master node and the slave node stops, and the cluster can automatically elect a master to ensure that the status data management system always has a master node to provide services and ensure that the status data management system does not go down.

[0064] 3. Strong consistency: The Raft protocol can ensure strong consistency in a distributed environment, where all processes can reach a consistent state within a certain period of time, ensuring data consistency and reliability.

[0065] 4. Log Replication: The Raft protocol ensures that all nodes maintain a consistent state by recording and replicating changes in a log, and quickly synchronizes data when a node recovers.

[0066] In practical applications, when a network partition occurs, some nodes may be unable to communicate with other nodes in the state data management system, and slave nodes may not be able to receive the master node's heartbeat signal. Alternatively, if the master node crashes or malfunctions, slave nodes may also be unable to receive the master node's heartbeat signal.

[0067] Optionally, to better ensure that the state data management system always has a master node providing services and to ensure that the state data management system does not shut down, each slave node listens for the master node's heartbeat signal, and if it cannot listen for the master node's heartbeat signal, it elects a new node as the master node. Preferably, the master node is determined by the slave nodes through election using the Raft protocol.

[0068] In practical applications, the state data management system may add or remove nodes, resulting in member changes. Optionally, a joint consensus approach can be used to handle these changes, ensuring a smooth transition and avoiding service interruptions. Specifically, the master node receives a member change request, which can instruct the addition of a new node or the removal of an existing one. In response, the master node modifies the old configuration information to obtain new configuration information. The master node then sends this new configuration information to multiple slave nodes for confirmation. Based on confirmations received from at least one slave node, the master node determines whether to accept the member change operation for the state data management system.

[0069] The old configuration information is used to indicate the node composition information of the status data management system before the member change, while the new configuration information is used to indicate the node composition information of the status data management system after the member change. The new configuration information can also indicate member change information, which is used to indicate the addition of new nodes or the removal of existing nodes in the status data management system.

[0070] Suppose that before the membership change, the state data management system consisted of 3 nodes (A, B, C), and now 2 new nodes (D, E) need to be added. The old configuration information was [A, B, C], indicating that the current state data management system consisted of these three nodes. The new configuration information [A, B, C, D, E] indicates that the current state data management system consists of these five nodes.

[0071] Specifically, the master node sends the new configuration information to each slave node for confirmation. If a slave node confirms acceptance of the new configuration information, it returns an acceptance confirmation to the master node; if a slave node does not accept the new configuration information, it returns a rejection confirmation to the master node. If the master node receives confirmation from a majority of nodes, it can proceed with the membership change process. If the master node does not receive confirmation from a majority of nodes, it can refuse to proceed with the membership change process. Based on this, when determining whether to accept a membership change operation for the state data management system based on the acceptance confirmations received from at least one slave node, the master node can determine whether to accept the membership change operation for the state data management system based on whether the number of slave nodes returning acceptance confirmations is greater than a set threshold. If the number of slave nodes returning acceptance confirmations is greater than the set threshold, it is confirmed that the master node has received confirmation from a majority of nodes, and it can proceed with the membership change process; if the number of slave nodes returning acceptance confirmations is not greater than the set threshold, it is confirmed that the master node has not received confirmation from a majority of nodes, and it can refuse to proceed with the membership change process.

[0072] The technical solution provided in this disclosure is a pure memory-based state data management mechanism, which effectively reduces disk I / O (Input / Output) and improves synchronization efficiency. In extreme cases, all nodes in the state data management system may experience downtime, potentially leading to data loss in memory. Optionally, to address this extreme situation, the full state data in the master node's local memory can be periodically retrieved, and the full state data retrieved in the current period can be stored in a persistent storage system. This allows for rapid restoration of data consistency in the state data management system using the full state data in the persistent storage system, enabling the system to quickly resume normal service.

[0073] Specifically, full state data refers to all state data in the master node's local memory at a specific point in time. The full state data acquired in different periods may differ. There are no restrictions on the persistent storage system used to store the full state data acquired in the current period. Optional persistent storage systems include, but are not limited to, disks, cloud disks, object storage services, and other systems with data persistence capabilities.

[0074] Optionally, considering that the full state data in the persistent storage system is mainly for dealing with extreme situations and is not the primary source of state data synchronization, in order to reduce the occupation of storage resources, a small number of full state data periods can be retained in the persistent storage system.

[0075] Optionally, the implementation of storing the full state data acquired in the current period into the persistent storage system is as follows: in response to storing the full state data of a first number of periods in the persistent storage system, storing the full state data acquired in the current period into the persistent storage system, wherein the first number is less than a set number; in response to storing the full state data of a set number of periods in the persistent storage system, deleting the full state data of the period furthest from the current time in the persistent storage system, and storing the full state data acquired in the current period into the persistent storage system.

[0076] Specifically, the quantity can be flexibly set as needed. By setting the quantity, the amount of full state data stored in the persistent storage system can be limited, which can effectively prevent storage space from being occupied by a large amount of historical data, while also ensuring that full state data for the most recent few periods is always available.

[0077] For example, suppose the set quantity is 5 periods. Initially, assume the persistent storage system is empty (stores 0 periods of the first log data). When the first period ends, full state data is generated and stored in the persistent storage system. At this point, the persistent storage system contains full state data for 1 period. At the end of the second to fifth periods, full state data is generated and stored in the persistent storage system respectively. At this point, the persistent storage system stores full state data for periods 1, 2, 3, 4, and 5 sequentially. When the sixth period ends, full state data is generated again. At this point, the persistent storage system contains full state data for 5 periods, reaching the set quantity. The full state data for the period furthest from the current time (i.e., the full state data for period 1) is deleted, and the full state data for period 6 is stored in the persistent storage system. At this point, the persistent storage system stores full state data for periods 2, 3, 4, 5, and 6. At the end of the seventh period, the full state data for period 2 is deleted, and the full state data for period 7 is stored. Similarly, the persistent storage system always maintains the full state data of the most recent 5 periods.

[0078] In practical applications, to handle extreme situations, the master node can also query the status data of each data object in the application service system and load the queried status data of each data object into the master node's local memory to achieve rapid recovery of status data, thus eliminating the need for additional persistent data. For example, if the state data of function instances is stored in memory, when the state data in memory needs to be restored, the latest state of each function instance can be traversed and restored to memory.

[0079] In practical applications, the full state data in the local memory of slave nodes is usually the most up-to-date. Therefore, prioritizing recovery from slave nodes can avoid accessing the persistent storage system, thereby significantly improving recovery speed. Optionally, the above method further includes: in response to the loss of full state data in the local memory of the master node, determining whether the full state data in the local memory of all slave nodes is lost; if the full state data in the local memory of at least one slave node is not lost, then obtaining the full state data in the local memory of at least one slave node and loading it into the local memory of the master node; if the full state data in the local memory of all slave nodes is lost, then obtaining the full state data of at least one period most recent from the current time from the persistent storage system and loading it into the local memory of the master node.

[0080] In some optional embodiments, before retrieving the full state data of at least one period most recent to the current time from the persistent storage system and loading it into the local memory of the master node, it can be determined whether it is necessary to query the state data of each data object in the application service system to restore the full state data based on the application scenario requirements; if not, the full state data of at least one period most recent to the current time is retrieved from the persistent storage system and loaded into the local memory of the master node; if so, the state data of each data object in the application service system is queried, and the queried state data of each data object is loaded into the local memory of the master node.

[0081] Specifically, if the application scenario allows for recovery using the most recent historical snapshot (e.g., when real-time requirements are not high, or the system is within a maintenance window), then the full state data for one or more periods most recent than the current time can be directly retrieved from the persistent storage system and loaded into the master node's local memory. If the application scenario has strict requirements for real-time performance and up-to-date state (e.g., financial transaction systems, online payment systems), then it is necessary to query the current state data of each data object in the application service system and load this state data into the master node's local memory to ensure that the recovered state is up-to-date. Therefore, flexibly selecting the most suitable recovery strategy based on the actual application scenario's needs ensures efficient and reliable recovery of the master node's full state data under various circumstances. This flexibility not only improves the system's availability and reliability but also better meets the specific needs of different application scenarios.

[0082] Figure 3 is a schematic diagram of a state data synchronization device provided in an embodiment of this disclosure. The device can be composed of software and / or hardware. The device can be configured into the master node of a state data management system. The state data management system includes a master node and multiple slave nodes. The master node is elected by multiple slave nodes. Referring to Figure 3, the device may include a change unit 31, a log update unit 32, and a synchronization unit 33.

[0083] The change unit 31 is used to trigger a first state change event during the execution of an access request from a client, and to perform a change operation on the state data of the first data object in the local memory of the master node according to the first state change event.

[0084] Log update unit 32 is used to add log entries of the first data object to the first log data stored in the local memory of the master node. The log entries of the first data object are used to indicate that the state data of the first data object has been changed according to the first state change event and the corresponding state change time.

[0085] Synchronization unit 33 is used to respond to the current synchronization operation triggered every other synchronization window, obtain the incremental log data to be synchronized in the current time from the first log data, the incremental log data to be synchronized in the current time includes at least one log entry whose state change time is within the current synchronization window; synchronize the incremental log data to be synchronized in the current time to multiple slave nodes, so that the slave nodes add the incremental log data to be synchronized in the current time to the second log data stored in the local memory of the slave nodes, and perform a change operation on the state data of the second data object in the local memory of the slave nodes according to the incremental log data in the second log data.

[0086] Optionally, when the synchronization unit 33 obtains the incremental log data to be synchronized this time from the first log data, it is specifically used to: obtain the original incremental log data whose state change time is within the current synchronization window from the first log data; merge multiple log entries belonging to the same data object from the original incremental log data to obtain a new log entry corresponding to the same data object; and generate the incremental log data to be synchronized this time based on the new state change logs corresponding to each data object.

[0087] Optionally, after synchronizing the incremental log data to be synchronized to multiple slave nodes, the synchronization unit 33 is further configured to: add an outdated flag to the incremental log data to be synchronized to be synchronized to the first log data in the local memory of the master node, the outdated flag indicating that the corresponding incremental log data has already undergone synchronization operation; and / or, in response to not receiving confirmation messages returned by a specified number of slave nodes, synchronize the incremental log data to be synchronized to the multiple slave nodes again until a specified number of confirmation messages returned by slave nodes are received, wherein the confirmation message indicates that the slave node confirms that it has received the incremental log data to be synchronized to be synchronized.

[0088] Optionally, when the synchronization unit 33 synchronizes the incremental log data to be synchronized to multiple slave nodes, it is specifically used to: synchronize the incremental log data to be synchronized to and the index position information of the last log entry of the previous synchronization operation to multiple slave nodes respectively, so that when the slave node confirms that the index position information of the last log entry of the previous synchronization operation received in the current synchronization window matches the index position information of the last log entry received in the previous synchronization window, it adds the incremental log data to be synchronized to the second log data stored in the local memory of the slave node.

[0089] Optionally, the synchronization unit 33 is also configured to: if a matching failure message is received from the slave node, send the incremental log data to be synchronized this time and the incremental log data in the previous synchronization window to the slave node, so that the slave node can add the incremental log data to be synchronized this time and the incremental log data in the previous synchronization window to the second log data stored in the slave node's local memory.

[0090] Optionally, the master node is elected by the slave nodes using the Raft protocol. Each slave node listens to the master node's heartbeat signal, and if it cannot listen to the master node's heartbeat signal, it selects a new node as the master node.

[0091] Optionally, the above apparatus further includes a member change unit, used to modify the old configuration information in response to a member change request to obtain new configuration information; wherein the old configuration information is used to indicate the node composition information of the state data management system before the member change, and the new configuration information is used to indicate the node composition information of the state data management system after the member change; the new configuration information is sent to multiple slave nodes respectively, so that the slave nodes confirm whether to accept the new configuration information; and the member change operation for the state data management system is determined based on the confirmation information received from at least one slave node.

[0092] Optionally, the synchronization unit 33 is also used to: periodically acquire the full state data in the master node's local memory, and store the full state data acquired in the current period into the persistent storage system.

[0093] Optionally, when the synchronization unit 33 stores the full state data acquired in the current period into the persistent storage system, it is specifically used to: in response to the storage of full state data for a first number of periods in the persistent storage system, store the full state data acquired in the current period into the persistent storage system, wherein the first number is less than a set number; in response to the storage of full state data for a set number of periods in the persistent storage system, delete the full state data of the period furthest from the current time in the persistent storage system, and store the full state data acquired in the current period into the persistent storage system.

[0094] Optionally, the synchronization unit 33 is further configured to: in response to the loss of full state data in the local memory of the master node, determine whether the full state data in the local memory of all slave nodes has been lost; if the full state data in the local memory of at least one slave node has not been lost, then obtain the full state data in the local memory of at least one slave node and load it into the local memory of the master node; if the full state data in the local memory of all slave nodes has been lost, then obtain the full state data of at least one period closest to the current time from the persistent storage system and load it into the local memory of the master node.

[0095] Optionally, before retrieving the full state data of at least one period most recent from the current time from the persistent storage system and loading it into the local memory of the master node, the synchronization unit 33 is also used to: determine whether it is necessary to query the state data of each data object in the application service system to restore the full state data based on the application scenario requirements; if not, perform the step of retrieving the full state data of at least one period most recent from the persistent storage system and loading it into the local memory of the master node; if so, query the state data of each data object in the application service system and load the queried state data of each data object into the local memory of the master node.

[0096] The detailed implementation methods and beneficial effects of each unit in the device provided in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0097] It should be noted that the execution subject of each step in the method provided in the above embodiments can be the same device, or the method can be executed by different devices. Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order; however, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as 201, 202, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0098] Figure 4 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. As shown in Figure 4, the electronic device includes a memory 41 and a processor 42.

[0099] Memory 41 is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0100] Processor 42, coupled to memory 41, is used to execute computer programs in memory 41 for: performing steps in a state data synchronization method.

[0101] Optionally, as shown in Figure 4, the electronic device may also include other components such as a communication component 43, a display 44, a power supply component 45, and an audio component 46. Figure 4 only schematically shows some components and does not imply that the electronic device only includes the components shown in Figure 4. Furthermore, the components within the dashed boxes in Figure 4 are optional, not mandatory, and their specific inclusion depends on the product form of the electronic device. The electronic device of this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device of this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed boxes in Figure 4; if the electronic device of this embodiment is a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed boxes in Figure 4.

[0102] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0103] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G (2nd Generation), 3G (3rd Generation), 4G (4th Generation) / LTE (long Term Evolution), 5G (5th Generation), or combinations thereof. In an exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0104] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0105] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0106] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0107] Accordingly, this disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium may be volatile, non-volatile, or a combination thereof, and may be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, digital video disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium.

[0108] Accordingly, this disclosure also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above-described method embodiments. It should be understood that each step or combination of steps in the above-described method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0109] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0110] The above are merely embodiments of this disclosure and are not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A state data synchronization method, applied to the master node of a state data management system with a master-slave architecture, wherein the state data management system is used to maintain and manage state data generated during the operation of an application service system, the state data management system includes the master node and multiple slave nodes, the master node being elected by the multiple slave nodes, the method comprising: During the execution of an access request from a client, a first state change event is triggered, and a change operation is performed on the state data of the first data object in the local memory of the master node according to the first state change event; The log entry of the first data object is added to the first log data stored in the local memory of the master node, wherein the log entry of the first data object is used to indicate that a change operation has been performed on the state data of the first data object according to the first state change event and the corresponding state change time. In response to the current synchronization operation triggered every other synchronization window, the incremental log data to be synchronized in this current time is obtained from the first log data. The incremental log data to be synchronized in this current time includes at least one log entry whose status change time is within the current synchronization window. The incremental log data to be synchronized this time is synchronized to the multiple slave nodes respectively, so that the slave nodes add the incremental log data to be synchronized this time to the second log data stored in the local memory of the slave nodes, and perform a change operation on the state data of the second data object in the local memory of the slave nodes according to the incremental log data in the second log data.

2. The method according to claim 1, wherein, Obtain the incremental log data to be synchronized this time from the first log data, including: Obtain the original incremental log data whose status change time is within the current synchronization window from the first log data; Multiple log entries belonging to the same data object are merged from the original incremental log data to obtain a new log entry corresponding to the same data object. The incremental log data to be synchronized this time is generated based on the new status change logs corresponding to each data object.

3. The method according to claim 1, wherein, After synchronizing the incremental log data required for this synchronization to the multiple slave nodes, the process also includes: An outdated flag is added to the incremental log data that needs to be synchronized this time in the first log data in the local memory of the master node. The outdated flag indicates that the corresponding incremental log data has already been synchronized.

4. The method according to claim 1, wherein, After synchronizing the incremental log data required for this synchronization to the multiple slave nodes, the process also includes: In response to the failure to receive confirmation messages from a specified number of slave nodes, the incremental log data to be synchronized this time is synchronized to the multiple slave nodes again until the specified number of slave nodes return confirmation messages, wherein the confirmation messages indicate that the slave nodes confirm that they have received the incremental log data to be synchronized this time.

5. The method according to claim 1, wherein, The incremental log data to be synchronized this time will be synchronized to the multiple slave nodes respectively, including: The incremental log data to be synchronized this time and the index position information of the last log entry of the previous synchronization operation are synchronized to the multiple slave nodes respectively, so that the slave nodes can confirm that the index position information of the last log entry of the previous synchronization operation received in the current synchronization window matches the index position information of the last log entry received in the previous synchronization window. The incremental log data required for this synchronization is added to the second log data stored in the local memory of the slave node.

6. The method according to claim 5, further comprising: If a matching failure message is received from the slave node, the incremental log data to be synchronized this time and the incremental log data in the previous synchronization window are sent to the slave node so that the slave node can add the incremental log data to be synchronized this time and the incremental log data in the previous synchronization window to the second log data stored in the local memory of the slave node.

7. The method according to claim 1, wherein, The master node is elected by the slave nodes using the Raft protocol. Each slave node listens to the heartbeat signal of the master node, and if it cannot listen to the heartbeat signal of the master node, it selects a new node as the master node.

8. The method according to claim 1, further comprising: In response to a member change request, the old configuration information is modified to obtain new configuration information; wherein, the old configuration information is used to indicate the node composition information of the status data management system before the member change, and the new configuration information is used to indicate the node composition information of the status data management system after the member change; The new configuration information is sent to multiple slave nodes so that the slave nodes can confirm whether they accept the new configuration information. Whether to accept the member change operation for the state data management system is determined based on the acknowledgment information received from at least one slave node.

9. The method according to claim 1, further comprising: The system periodically retrieves all state data from the master node's local memory and stores the current period's retrieved state data in a persistent storage system.

10. The method according to claim 9, wherein, Store the full state data acquired in the current period to a persistent storage system, including: In response to storing full state data for a first number of periods in the persistent storage system, the full state data acquired in the current period is stored in the persistent storage system, wherein the first number is less than a set number. In response to the persistent storage system storing a set number of full state data periods, the system deletes the full state data of the period furthest from the current time in the persistent storage system and stores the full state data acquired in the current period into the persistent storage system.

11. The method of claim 9, further comprising: In response to the loss of the full state data in the local memory of the master node, determine whether the full state data in the local memory of all slave nodes has been lost; If at least one slave node's local memory has not lost all state data, then at least one slave node's local memory is retrieved and loaded into the master node's local memory. If all state data in the node's local memory is lost, then the full state data of at least one period most recent to the current time is retrieved from the persistent storage system and loaded into the master node's local memory.

12. The method according to claim 11, wherein, Before retrieving full state data from the persistent storage system for at least one period most recent to the current time and loading it into the master node's local memory, the process also includes: Determine whether it is necessary to query the status data of each data object in the application service system to restore the full status data based on the application scenario requirements. If not required, then the step of retrieving the full state data of at least one period most recent to the current time from the persistent storage system and loading it into the local memory of the master node is executed; If necessary, the status data of each data object in the application service system is queried, and the status data of each data object is loaded into the local memory of the master node.

13. A state data synchronization device, applied to the master node of a state data management system with a master-slave architecture, the state data management system being used to maintain and manage state data generated during the operation of an application service system, the state data management system including the master node and multiple slave nodes, the master node being elected by the multiple slave nodes, the device comprising: The change unit is used to trigger a first state change event during the execution of an access request from a client, and to perform a change operation on the state data of the first data object in the local memory of the master node according to the first state change event. The log update unit is used to add the log entry of the first data object to the first log data stored in the local memory of the master node, wherein the log entry of the first data object is used to indicate that the state data of the first data object has been changed according to the first state change event and the corresponding state change time. as well as The synchronization unit is configured to respond to the current synchronization operation triggered every other synchronization window by obtaining the incremental log data to be synchronized in the current time from the first log data, wherein the incremental log data to be synchronized in the current time includes at least one log entry whose state change time is within the current synchronization window; synchronizing the incremental log data to be synchronized in the current time to the plurality of slave nodes respectively, so that the slave nodes add the incremental log data to be synchronized in the current time to the second log data stored in the local memory of the slave nodes, and performing a change operation on the state data of the second data object in the local memory of the slave nodes according to the incremental log data in the second log data.

14. The status data synchronization device according to claim 13, wherein, When the synchronization unit obtains the incremental log data to be synchronized this time from the first log data, it is specifically used for: Obtain the original incremental log data whose status change time is within the current synchronization window from the first log data; Multiple log entries belonging to the same data object are merged from the original incremental log data to obtain a new log entry corresponding to the same data object. The incremental log data to be synchronized this time is generated based on the new status change logs corresponding to each data object.

15. The status data synchronization device according to claim 13, wherein, After synchronizing the incremental log data required for this synchronization to the multiple slave nodes, the synchronization unit is further configured to: An outdated flag is added to the incremental log data that needs to be synchronized this time in the first log data in the local memory of the master node. The outdated flag indicates that the corresponding incremental log data has already been synchronized.

16. The state data synchronization device according to claim 13, wherein, After synchronizing the incremental log data required for this synchronization to the multiple slave nodes, the synchronization unit is further configured to: In response to the failure to receive confirmation messages from a specified number of slave nodes, the incremental log data to be synchronized this time is synchronized to the multiple slave nodes again until the specified number of slave nodes return confirmation messages, wherein the confirmation messages indicate that the slave nodes confirm that they have received the incremental log data to be synchronized this time.

17. An application service system, comprising: A status data management system is provided for maintaining and managing the status data generated during the operation of the application service system. The status data management system has a master-slave architecture, comprising a master node and multiple slave nodes, wherein the master node is elected by the multiple slave nodes. The master node is used to: trigger a first state change event during the execution of an access request from a client, and perform a change operation on the state data of a first data object in the local memory of the master node according to the first state change event; The log entry of the first data object is added to the first log data stored in the local memory of the master node, wherein the log entry of the first data object is used to indicate that a change operation has been performed on the state data of the first data object according to the first state change event and the corresponding state change time. In response to the current synchronization operation triggered every other synchronization window, the incremental log data to be synchronized in this current time is obtained from the first log data. The incremental log data to be synchronized in this current time includes at least one log entry whose status change time is within the current synchronization window. The incremental log data to be synchronized in this current time is then synchronized to the multiple slave nodes respectively. The slave node is used to: add the incremental log data to be synchronized this time to the second log data stored in the local memory of the slave node, and perform a change operation on the status data of the second data object in the local memory of the slave node according to the incremental log data in the second log data.

18. An electronic device comprising: Memory and processor; The memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 1 to 12.

19. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1 to 12.

20. A computer program product comprising a computer program / instructions that, when executed by a processor, cause the processor to perform the steps of the method according to any one of claims 1 to 12.

Images