Multi-platform data real-time synchronization method and device, electronic equipment and storage medium

Abstract

The application provides a multi-platform data real-time synchronization method and device, electronic equipment and storage medium. The method comprises: obtaining events generated by user operations and platform data changes; analyzing the events and forming event information; classifying the event information, generating a synchronization task based on the classification result, and establishing a task queue using the synchronization task; obtaining a synchronization task related to user access from the task queue, deploying a prediction model on an edge node close to the user according to user behavior characteristics and historical access data in the synchronization task; obtaining a synchronization task related to key data changes from the task queue, executing a distributed consensus protocol on the key data changes, and reaching an agreement on the update status of the key data among multiple platform nodes; and distributing the update status confirmed by the consensus to multiple platform nodes. The application can reduce delay, improve data synchronization accuracy, reduce load, and improve real-time and consistency of data synchronization.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, electronic device and storage medium for real-time data synchronization across multiple platforms. Background Technology

[0002] In multi-platform application scenarios, users typically use the same application or service simultaneously on mobile devices, PCs, and other terminal devices. To ensure a consistent user experience across different platforms, real-time synchronization of data distributed across multiple platforms is necessary. However, due to the high frequency of user access, intensive data updates, and diverse network and server environments involved in multi-platform environments, achieving both real-time performance and consistency in data synchronization is challenging, necessitating an efficient and reliable real-time data synchronization technology across multiple platforms.

[0003] Existing technologies typically employ the following synchronization methods: 1. Periodic pull or push: The client or server updates data at fixed time intervals; 2. Passive trigger or manual refresh: Real-time synchronization is performed when a user initiates an operation; 3. Centralized consistency management: Data consistency is maintained through a centralized database or single-point service.

[0004] The above methods generally have the following drawbacks in multi-platform high-concurrency scenarios: periodic synchronization is prone to update delays or excessive server pressure; passive synchronization methods lack the ability to detect data changes and are prone to missing critical updates; centralized management methods are difficult to adapt to distributed multi-node deployment environments, and recovery is difficult once a failure occurs; when the frequency of data access and updates on multiple platforms increases dramatically, traditional synchronization methods are prone to data inconsistency or high error rates. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, apparatus, electronic device and storage medium for real-time data synchronization across multiple platforms, in order to solve the problems of high latency, high error rate and uneven server load in the prior art, which lead to inconsistent data synchronization and high error rate.

[0006] A first aspect of this application provides a method for real-time data synchronization across multiple platforms, comprising: configuring event listening modules on both the user end and the platform end, wherein the event listening modules are used to acquire events generated by user operations and platform data changes; sending the events to an event management center so that the event management center can parse the events and form event information; classifying the event information and generating corresponding synchronization tasks based on the classification results, and establishing a task queue using the synchronization tasks; acquiring synchronization tasks related to user access from the task queue, and deploying a prediction model on edge nodes close to the user based on user behavior characteristics and historical access data contained in the synchronization tasks; acquiring target data related to the synchronization tasks using the prediction model, storing the target data in an edge cache, and updating and maintaining the target data using a differential update and cache management method; acquiring synchronization tasks related to key data changes from the task queue, executing a distributed consensus protocol on the key data changes so that multiple platform nodes can reach a consensus on the update status of the key data; and distributing the consensus-confirmed update status to multiple platform nodes to complete multi-node synchronization of the key data.

[0007] A second aspect of this application provides a multi-platform real-time data synchronization device, comprising: an acquisition module, configured to acquire events generated by user operations and platform data changes by configuring event listening modules on both the user end and the platform end; a sending module, configured to send events to an event management center, so that the event management center can parse the events and form event information; a classification module, configured to classify the event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue using the synchronization tasks; a deployment module, configured to acquire synchronization tasks related to user access from the task queue, and deploy a prediction model on edge nodes close to the user based on user behavior characteristics and historical access data contained in the synchronization tasks; a storage module, configured to acquire target data related to the synchronization tasks using the prediction model, store the target data in an edge cache, and update and maintain the target data using differential update and cache management methods; a consensus module, configured to acquire synchronization tasks related to key data changes from the task queue, execute a distributed consensus protocol on the key data changes, so that multiple platform nodes can reach a consensus on the update status of the key data; and a distribution module, configured to distribute the consensus-confirmed update status to multiple platform nodes to complete multi-node synchronization of key data.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0011] By configuring event listening modules on both the user end and the platform end, these modules acquire events generated by user operations and platform data changes. These events are then sent to an event management center for parsing and information generation. The event information is categorized, and corresponding synchronization tasks are generated based on the categorization results. A task queue is established using these synchronization tasks. Synchronization tasks related to user access are retrieved from the task queue. Based on user behavior characteristics and historical access data contained in these tasks, a prediction model is deployed on edge nodes close to the user. The prediction model is used to acquire target data related to the synchronization tasks. This target data is stored in an edge cache and updated and maintained using differential updates and cache management. Synchronization tasks related to critical data changes are retrieved from the task queue. A distributed consensus protocol is executed on these critical data changes to ensure consistency among multiple platform nodes regarding the updated status of the critical data. The consensus-confirmed update status is then distributed to multiple platform nodes to complete multi-node synchronization of the critical data. This application reduces latency, improves the accuracy of data synchronization, reduces load, and enhances the real-time performance and consistency of data synchronization. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the multi-platform real-time data synchronization method provided in an embodiment of this application;

[0014] Figure 2 This is a schematic diagram of the structure of the multi-platform real-time data synchronization device provided in the embodiments of this application;

[0015] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0016] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0017] In today's internet and mobile application environment, users often use the same application or service simultaneously on multiple platforms (such as mobile phones, PCs, tablets, or other smart devices). To provide users with a consistent user experience, data synchronization across multiple platforms is necessary. For example, in gaming applications, a player's game progress on the mobile device needs to be consistent with the web or client version; or in shopping platforms, shopping cart information added by users on their mobile devices needs to be updated in real time on the web version and other platforms.

[0018] However, with the continuous increase in user scale and data access frequency, multi-platform data synchronization often faces the following challenges:

[0019] Large data volume and frequent updates: User actions are diverse, such as logging in, logging out, purchasing, and points changes. As the data volume and request frequency increase, traditional data synchronization methods are prone to problems such as high latency, data conflicts, and even data loss.

[0020] High real-time requirements: Users need to see the latest data status on multiple platforms in a timely manner. In scenarios with high real-time requirements, such as gaming, finance, and social networking, data synchronization delays will directly affect the user experience.

[0021] Complex network conditions: Due to limitations in network bandwidth and server capabilities, improper synchronization strategies can lead to not only delays and errors but also overload the server.

[0022] In conclusion, efficient, reliable, and real-time data synchronization is of great significance in a multi-platform environment.

[0023] Existing data synchronization mechanisms often employ the following approaches:

[0024] 1. Periodic pull or push

[0025] Data can be retrieved from the server periodically by the client, or pushed to the client by the server at fixed intervals. However, when data updates occur suddenly, the periodic synchronization mechanism may not be triggered in time, causing delays. In addition, if the interval is too short, a large number of synchronization requests will increase the server load.

[0026] 2. Passive triggering or manual synchronization

[0027] Synchronization can be triggered by users themselves (such as manual refresh) or by monitoring user activity. However, this model lacks the ability to detect data changes and is prone to missing key updates; if users do not trigger synchronization or their activity is not significant, data synchronization will be delayed or missed.

[0028] 3. Centralized Consistency Management

[0029] Consistency management is achieved in the backend using a centralized database or middleware, and data consistency is maintained through locking mechanisms or version control. However, centralized solutions can easily become performance bottlenecks in high-concurrency, multi-node scenarios; they also have poor scalability, and recovery is difficult once a failure occurs.

[0030] The above traditional methods are prone to problems such as high latency, high error rate and uneven server load in massive, multi-platform data synchronization scenarios, making it difficult to meet users' needs for real-time performance and consistency.

[0031] Therefore, to address the issues of latency and errors in real-time data synchronization across multiple platforms in existing technologies, this application proposes a real-time data synchronization method for multiple platforms. The technical solution of this application completely solves the problems of latency, errors, and high server load inherent in traditional synchronization methods through an event-driven data synchronization mechanism, an edge-side predictive caching strategy, and a distributed state consensus management mechanism. The main technical points of this solution include the following:

[0032] 1. Event-driven data synchronization mechanism

[0033] Instead of relying solely on user activity characteristics or manual triggers, it abstracts user behavior, data changes, and server status changes into events, using these events as the core to drive the creation and scheduling of synchronous tasks, thus achieving fine-grained control.

[0034] 2. Edge-side predictive caching strategy

[0035] Deploy intelligent predictive caching modules on the user end or edge nodes close to the user end. Through local caching and data pre-fetching mechanisms, predict and synchronize the data that the user is about to access in advance, greatly improving the real-time performance of data access.

[0036] 3. Distributed state consensus management mechanism

[0037] By leveraging a lightweight distributed consensus algorithm, fast, reliable, and consistent confirmation and propagation of state can be achieved across multiple platform nodes, improving data consistency and reducing synchronization error rates.

[0038] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0039] Figure 1 This is a flowchart illustrating the multi-platform real-time data synchronization method provided in an embodiment of this application. Figure 1 As shown, this multi-platform real-time data synchronization method may specifically include:

[0040] S101, configure event listening modules on both the user end and the platform end. The event listening modules are used to acquire events generated by user operations and platform data changes.

[0041] S102, the event is sent to the event management center so that the event management center can parse the event and generate event information;

[0042] S103, classify the event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue using the synchronization tasks;

[0043] S104: Obtain synchronous tasks related to user access from the task queue, and deploy a prediction model on edge nodes close to the user based on user behavior characteristics and historical access data contained in the synchronous tasks.

[0044] S105: Use a prediction model to obtain target data related to the synchronization task, store the target data in the edge cache, and use differential update and cache management to update and maintain the target data;

[0045] S106: Obtain synchronization tasks related to key data changes from the task queue, execute a distributed consensus protocol on the key data changes, so that multiple platform nodes can reach a consensus on the updated status of the key data.

[0046] S107 distributes the updated state after consensus confirmation to multiple platform nodes to complete the multi-node synchronization of key data.

[0047] In some embodiments, to promptly detect player actions and key data changes on the game platform within a game application, event listening modules can be deployed on both the user terminal (e.g., mobile game client, PC game client, etc.) and the server platform (e.g., game backend service, leaderboard service, etc.), and high-performance message middleware can be used to quickly distribute these event messages. An example of this implementation process is as follows:

[0048] User actions and platform data updates are abstracted into events that can trigger data synchronization.

[0049] User actions include: logging in, logging out, and key in-game actions (such as character leveling, skill unlocking, and task completion).

[0050] Platform-side data updates include: ranking changes, battle record changes, item purchases, and item gifts.

[0051] Each event is assigned a corresponding priority (such as high, normal, or low) and a corresponding synchronization strategy during definition, so as to enable fine-grained management later. For example, events triggered by a player's key actions can be marked as high priority, while ordinary background statistics updates can be marked as normal or low priority.

[0052] Furthermore, a dedicated listening proxy or event triggering component is embedded in the game client on mobile or PC. This component will capture the player's actions in real time when it detects actions such as logging in, logging out, or completing important levels.

[0053] The listening agent packages the captured operations into event messages, along with the corresponding event identifier, user information, priority, etc.

[0054] Then, the listening broker uses a high-performance message middleware (such as Kafka, RocketMQ, etc.) to send this event message to the event management center or other receiving units on the platform.

[0055] Furthermore, a monitoring module capable of real-time monitoring of data changes is deployed on the game platform backend or related service nodes. When the backend service detects actions such as updates to leaderboard rankings, changes in player performance, or updates to item purchase records, the monitoring module will abstract the data changes into corresponding events.

[0056] Similar to the user side, the platform's listening module also uses message middleware to send unified event messages, packaging information such as event type, data change content, timestamp, and priority together and transmitting it to the event management center.

[0057] In some examples, high-performance message middleware handles the flow and routing of event messages. Specifically, event messages generated by either the client-side or platform-side listening modules are sent to messaging systems such as Kafka or RocketMQ.

[0058] The messaging system categorizes and stores messages based on pre-configured topics or partitions; the event management center or subsequent processing modules subscribe to the corresponding message topics to obtain various event messages in real time, ensuring that data synchronization needs can be triggered promptly based on different priorities.

[0059] In some examples, the listening module uses a synchronization strategy with different priority tags for different types of events. For example, ranking change events might be defined as normal priority, while data connection events when players switch platforms might be defined as high priority.

[0060] After receiving an event, the event management center can filter and queue event messages according to priority, and use corresponding synchronization strategies to schedule subsequent data synchronization tasks, such as triggering synchronization tasks immediately or temporarily delaying processing.

[0061] Through the above methods, the listening modules on both the user end and the platform end can effectively capture and generate event messages, thereby ensuring timely detection and reporting of user operations and platform data updates in game application scenarios. This provides fundamental support for subsequent data synchronization or state management operations. This embodiment is limited to illustrating how to specifically deploy the event listening module and message middleware within the technical framework of this application to achieve real-time perception of user operations and platform data changes in a multi-platform environment.

[0062] In some embodiments, the event is sent to an event management center so that the event management center can parse the event and generate event information, including:

[0063] After acquiring events generated by user actions or platform data changes, the events are encapsulated along with associated user identifiers, platform identifiers, timestamps, event types, and priority information.

[0064] The encapsulated event is sent to the event management center through the message transmission channel, so that the event management center can parse the event to extract event attributes and related information, and generate event information based on the event attributes and related information.

[0065] Specifically, to achieve unified management of user operations or platform data changes during real-time data synchronization across multiple platforms, it is necessary to send acquired events to an event management center, which then parses the events and generates event information. Taking an online music entertainment platform as an example, the specific implementation process may include the following steps:

[0066] When a user performs a key action on a mobile or web device (such as playing a song, liking, or adding it to their favorites), or when platform data (such as rankings, song information, or comment activity) is updated, the corresponding event listening module will receive the event.

[0067] After capturing this event, the listening module will combine it with associated metadata such as user identifier, platform identifier, timestamp, event type, and priority information to form a preliminary event encapsulation.

[0068] For example, when a user "favorites" a song, the event might be defined as "SongFavorEvent," with the user ID, platform ID (e.g., mobile / web), timestamp, and priority appended to the event.

[0069] The encapsulated event is sent to the event management center through a pre-configured message transmission channel. This message transmission channel can be a high-performance message queue (such as Kafka, RabbitMQ, or RocketMQ), or other distributed messaging mechanisms that conform to network communication specifications such as REST / WebSocket.

[0070] In some examples, to cope with high concurrency and improve transmission efficiency, distributed message queues can be used to establish a stable and high-speed communication path between each platform and the event management center.

[0071] After receiving a packaged event, the event management center parses the event to extract its internal event attributes and related information. This process typically includes the following operations:

[0072] Unpack the event to obtain the user identifier, platform identifier, and timestamp;

[0073] Determine the event type (such as collection, comment, leaderboard update, etc.) and read the priority information;

[0074] The key attributes after unpacking are temporarily stored in an in-memory data structure or written to a dedicated database for use in subsequent classification or task generation.

[0075] Through this analysis process, the event management center can manage different events in a refined manner and provide basic data support for subsequent data synchronization or distributed consensus processes.

[0076] Furthermore, based on event attributes and associated information (such as user ID, event type, priority, etc.), the event management center assembles the parsed results into an "event information" object.

[0077] The "Event Information" object can contain key fields required for cross-platform data synchronization, such as the type of data update triggered by the event, potential target nodes, and applicable synchronization strategies.

[0078] In some examples, when a high-priority event is detected (such as a user using an account on multiple devices simultaneously, and the event may affect playlist synchronization in a short period of time), the event management center can mark it as "requires urgent handling" or "real-time synchronization" when creating the event information, providing a basis for prioritizing subsequent processes.

[0079] Through the above methods, events acquired by this application at the user end and platform end can be quickly transmitted to the event management center, where they are uniformly parsed and encapsulated. This provides accurate and detailed basic data support for subsequent processes of real-time data synchronization across multiple platforms (such as event classification, synchronization task generation and scheduling). This embodiment only provides an exemplary description of the event sending and parsing stage, aiming to demonstrate how to achieve centralized management of distributed events with high performance and scalability in a real-world environment.

[0080] In some embodiments, event information is classified, corresponding synchronization tasks are generated based on the classification results, and a task queue is established using the synchronization tasks, including:

[0081] Event information is read from the data structure that stores event information, and the event information is classified according to event type, priority, and platform load status;

[0082] Based on the classification results, determine the synchronization strategy to be executed and generate the corresponding synchronization tasks, create a task queue, and insert the synchronization tasks into the task queue.

[0083] Specifically, to effectively manage event information from different user terminals and platform terminals, an "event management center" and a "task scheduling module" are typically deployed on a server or central system to centrally process and classify events, and generate synchronous tasks based on the classification results. The following example uses an online education platform:

[0084] In online education platforms, the event listening module captures events generated by user login, video playback, question submission, homework grading, and other operations.

[0085] After these events are sent to the event management center, they are parsed and corresponding "event information" is generated and stored in a dedicated data structure (such as a database table or distributed cache).

[0086] Furthermore, the classification module of the event management center will periodically or in real time read unclassified event information from this data structure.

[0087] Based on the event type (such as user viewing time, test submission, course progress update, grading result generation, etc.), combined with the event priority (such as high, normal, low) and the current platform load status (such as server busyness, message queue backlog, etc.), these event information are finely classified.

[0088] For example, in some cases, events involving the synchronization of course progress or real-time feedback of grading results can be classified as "high-priority events," while statistical or log events can be defined as "normal or low-priority events" to facilitate resource allocation for different strategies later.

[0089] Furthermore, after classifying the event information, the classification module, in conjunction with the pre-configured synchronization strategy rules, determines the synchronization strategy to be adopted for each type of event.

[0090] For example, for high-priority grading result update events, a real-time synchronization task can be generated immediately to update all relevant teachers' or students' terminals in a timely manner; while for ordinary or low-priority statistical data update events, a batch or delayed synchronization strategy may be adopted to make reasonable use of system resources.

[0091] Based on the above strategy, the classification module creates a corresponding synchronization task for each event information to be processed, records it in memory or database, and attaches the required parameters (such as target platform node, synchronization method, deadline, etc.).

[0092] Furthermore, in order to enable subsequent processing modules to acquire and execute synchronous tasks in an orderly manner, the system usually maintains one or more task queues (such as high-priority task queues, normal-priority task queues, etc.) to meet the scheduling needs of different scenarios.

[0093] The synchronous tasks generated based on the classification results are written into the corresponding task queues, and necessary task attributes (such as task number, execution priority, creation time, etc.) are recorded.

[0094] In the example of the aforementioned online education platform, high-priority tasks are inserted into a high-priority queue to ensure that they are scheduled for execution within a short period of time; while ordinary or low-priority tasks are placed in the corresponding queues for later or batch processing.

[0095] Through the above process, the online education platform can effectively classify event information under various user operation and data update scenarios, and generate synchronization tasks and establish task queues based on the classification results. This enables subsequent synchronization operations, state consensus, or edge prediction caching to be completed efficiently and accurately. This embodiment only provides an exemplary description of the event classification and synchronization task generation part, aiming to illustrate how to achieve fine-grained management and scheduling of various events in a real business environment.

[0096] In some embodiments, a predictive model is deployed on edge nodes close to the user based on user behavior characteristics and historical access data included in the synchronization task, including:

[0097] Extract synchronous tasks related to user access from the task queue, and read user behavior characteristics and historical access data carried in the synchronous tasks.

[0098] Based on user behavior characteristics and historical access data, select and load model instances that can perform predictive calculations;

[0099] Deploy model instances to edge nodes close to users, and configure and initialize the model instances so that the configured and initialized prediction model can make predictions on data that users may access based on newly received synchronization tasks at the edge nodes.

[0100] Specifically, to improve the real-time responsiveness of product recommendations and page loading on e-commerce platforms, lightweight predictive models can be deployed on edge nodes to pre-cache and synchronize product and page resources that users may access. The implementation steps can be illustrated as follows:

[0101] The e-commerce platform's task scheduling system retrieves synchronous tasks related to user access from the task queue, such as product information that the user recently browsed or searched.

[0102] This synchronization task typically includes users' historical access data (such as browsing history and shopping cart behavior) and user behavior characteristics (such as preference type, purchasing habits, geographical location, and access time period).

[0103] Based on the acquired user behavior characteristics and historical access data, the system selects and loads a lightweight predictive model instance suitable for the current scenario from the model library or model version management system.

[0104] For example, for common product browsing and recommendation tasks, deep learning models or collaborative filtering models that consume fewer resources but have higher prediction accuracy can be selected to ensure rapid deployment and efficient execution on edge nodes.

[0105] Furthermore, the model instance is deployed to the edge node (e.g., CDN node or local user client) closest to the user, and configuration and initialization are performed to ensure that the model can function properly on that node.

[0106] During the initialization phase, some parameters of the model or the data dictionary can be updated in real time based on newly received synchronization tasks and user behavior characteristics, enabling the model to more accurately identify the product categories or page resources that the user is about to visit.

[0107] Furthermore, once deployed, the predictive model will continuously analyze user access logs and new synchronization tasks in the task queue at the edge nodes, automatically identifying possible access data types related to the user (such as lists of best-selling products, personalized product recommendations, etc.).

[0108] Once it is predicted that a specific product or page resource is likely to be clicked and accessed by a user, an advance synchronization operation is immediately triggered to pre-fetch and cache the corresponding product details, images, inventory information, and other content in the edge node.

[0109] The cached data is dynamically maintained by using differential updates to minimize duplicate downloads or unnecessary network transmissions.

[0110] Through the deployment methods described in the above embodiments, e-commerce platforms can fully leverage user behavior characteristics and historical access data at edge nodes to predict access trends, and perform data synchronization and caching in advance based on the prediction results, thereby improving the response speed for users accessing goods and services on multiple platforms (such as mobile devices and web pages). This embodiment only provides an exemplary description of the technical solution for "deploying prediction models and performing data prediction and synchronization at edge nodes close to users," aiming to demonstrate the feasibility and applicability of this solution in actual business scenarios.

[0111] In some embodiments, a predictive model is used to obtain target data related to the synchronization task, the target data is stored in an edge cache, and differential update and cache management methods are used to update and maintain the target data, including:

[0112] Receive target data identified by the predictive model based on user behavior characteristics and historical access data;

[0113] When the target data is not present in the edge cache, the target data is retrieved from the specified platform node.

[0114] The acquired target data is written to the edge cache, and version and timestamp information are configured for the target data for subsequent updates;

[0115] When a change in the target data is detected, a differential update is performed on the target data in the edge cache;

[0116] Based on the usage of target data on the user end and the cache occupancy status, cache management strategies are used to replace or evict target data, so that the edge cache always maintains valid data related to the synchronization task.

[0117] Specifically, massively multiplayer online games (MMOs) often possess a vast amount of game items, scene resources, and player data. To provide players with a low-latency, highly consistent gaming experience across multiple devices (such as mobile and PC), the system can deploy predictive models on edge nodes close to the players, and then use the prediction results to pre-acquire and cache the target data that players might need. The following is an exemplary illustration of this process:

[0118] The predictive model in the game's backend or edge analyzes the player's past behavioral characteristics (such as frequently used characters) and historical access data (such as recently used skills and items) to generate a list of "target data". In this example, "target data" may include equipment skins or key item information that the player is about to use.

[0119] After receiving the list, the system will perform subsequent processing on the data of each target according to the needs of the synchronization task.

[0120] If certain target data identified by the prediction model is not yet present in the edge cache, the system will send a pull request to the game server or other storage nodes.

[0121] The acquired target data (such as high-resolution models, character decoration files, etc.) is written to the edge cache, and version information and timestamp information are configured for the data when writing.

[0122] In this way, the system can quickly read the required resources directly from the edge cache when the player actually enters the scene or uses the corresponding equipment, reducing the latency of cross-network transmission.

[0123] Furthermore, in order to reduce the network burden caused by large-scale data duplication, when changes to target data are detected (such as character skin hot patching), the system only performs differential transmission and updates on the changed parts.

[0124] For example, if a terrain texture file only updates a small portion of the area, the edge nodes only need to pull the new texture difference package and integrate it into the existing cached data, without having to retransmit the entire file. In this way, the game can ensure that players can quickly obtain the latest version of the resources without consuming a lot of bandwidth to download the complete data package.

[0125] In the game, different terrains or props have different usage frequencies, space occupancy and validity periods. In order to ensure that the edge cache always retains the data that players need most, this embodiment uses a cache management strategy to dynamically adjust and optimize the cache content.

[0126] If a prop or scene resource is detected to have not been accessed for a long time or if system space is limited, the system can replace or clean it up according to a cache eviction algorithm (such as LRU, LFU or a custom strategy) to make room for other high-priority resources.

[0127] When players frequently switch between multiple game scenes, this cache management strategy will also combine the latest results of the prediction model to update the cache priority in a timely manner, ensuring that the data that players may need at any time can always be retrieved quickly.

[0128] Through the above process, the game system deploys a predictive model at edge nodes close to the player and actively retrieves target data based on the model results. It then maintains the target data using differential updates and cache management, thereby ensuring reliable updates of game resources while effectively reducing network traffic and improving the player experience. This embodiment mainly demonstrates the specific implementation details of using predictive models for target data determination, differential updates, and cache management. In actual system deployments, other synchronization strategies or distributed consensus mechanisms can be combined to further improve the overall real-time data synchronization effect across multiple platforms.

[0129] In some embodiments, synchronization tasks related to critical data changes are retrieved from a task queue, and a distributed consensus protocol is executed on the critical data changes to enable multiple platform nodes to reach a consensus on the updated state of the critical data, including:

[0130] Extract synchronization tasks from the task queue that are identified as having critical data changes;

[0131] Select a set of nodes to participate in consensus from multiple platform nodes, and propose changes to key data;

[0132] Each node exchanges voting information according to a pre-defined distributed consensus protocol to determine the update status of key data;

[0133] Once a consensus is reached, the updated state is written to the local storage structure of multiple platform nodes to complete the distributed synchronization of critical data.

[0134] Specifically, massively multiplayer online games (MMORPGs) typically require maintaining the consistency of critical data across multiple platform nodes (such as different game server clusters or regional nodes). For example, player leaderboards, cross-server battle records, and item trading are all critical data affecting game balance and player experience. Inconsistencies in this data across different nodes can lead to player confusion or vulnerabilities in the economic system. Therefore, this embodiment employs a distributed consensus protocol to ensure that the updated state of critical data remains consistent across all relevant nodes. The implementation process can be illustrated as follows:

[0135] After classifying various types of event information, the game's event management center or task scheduling system will generate multiple synchronous tasks and write them into the task queue.

[0136] When a synchronization task is marked as "critical data change" (such as player performance settlement or large-scale item distribution), it means that this synchronization task involves core game data and requires a higher level of consistency assurance.

[0137] In some examples, the system will first retrieve the "critical data change" task from the task queue, preparing to execute the distributed consensus process.

[0138] To ensure data consistency across platforms and regions, the system will select a number of nodes that can participate in consensus (such as a server cluster that mainly stores leaderboards or battle results information) based on pre-configured node roles or physical distribution.

[0139] The key data change (e.g., "Player A wins the championship in the cross-server battle and is rewarded with several rare items") is encapsulated into a consensus proposal and broadcast or sent to the set of nodes. This proposal will contain necessary metadata, such as the change type (battle results settlement), the player IDs involved, and the expected final update status.

[0140] Furthermore, when each node in the node set receives a proposal, it will process it according to a pre-set distributed consensus protocol (such as an improved algorithm of Raft, Paxos, or PBFT).

[0141] Specifically, each node will first check its own status and stored player information to confirm whether there are any conflicts or incompleteness between the proposal and the current data, and then vote on the proposal.

[0142] If a majority or more than a certain threshold of nodes confirm that the change is acceptable, it means that a consensus has been reached, and the key data change enters the "can be committed" state.

[0143] Furthermore, after consensus is reached, the system writes the final update status of this key data change to the local storage structure (such as a database, memory hash, or distributed cache) of each participating node to ensure that the battle results information of all relevant nodes remains completely consistent.

[0144] For other nodes that did not directly participate in this consensus, the latest key data status can be distributed to them through subsequent message broadcasts or periodic synchronization to ensure data consistency throughout the game ecosystem.

[0145] Taking "Player A wins the championship" as an example in this embodiment, once the multi-node writing is completed, the trophy, item and ranking information that Player A sees in each server and on each leaderboard will be synchronized immediately to avoid cross-server status conflicts.

[0146] Through the above process, executing a distributed consensus protocol on critical data in large-scale multiplayer online games can effectively ensure reliable and consistent updates of core business data in high-concurrency, multi-node environments. This embodiment focuses on how to combine task queue mechanisms, consensus proposals, and node voting processes to achieve distributed consistency. In actual system deployment, more optimization methods (such as log compression, batch updates, etc.) can be selected according to the actual scale of the game and business needs to further improve the stability and performance of the system.

[0147] In some embodiments, after completing the multi-node synchronization of critical data, the method further includes:

[0148] The system performs integrity and consistency checks on the key data that has been synchronized. When inconsistencies in key data or synchronization failures are detected, the system triggers an error repair process and restores the state of abnormal nodes according to the distributed consensus protocol.

[0149] Specifically, large-scale multiplayer online games require multi-node synchronization of key data such as leaderboards, cross-server battle records, and player items. Any anomalies in this data synchronization will severely impact player fairness and game balance. Therefore, this embodiment, after completing multi-node synchronization, also performs integrity and consistency checks on the synchronization results and triggers an error repair process upon detecting inconsistencies or synchronization failures. An example of its implementation is as follows:

[0150] Once the distributed consensus protocol completes a consistent update of key data, the system will record and mark the completion time or version number of this round of consensus operation on each node.

[0151] The system's built-in or external verification module will then listen to the tag information and initiate the integrity and consistency verification process to check whether the key data stored on each node is consistent with the consensus result.

[0152] In this example, integrity verification can be performed based on hash digests, data length, or version number comparisons. For example, hash calculations can be performed on key fields such as player items and battle records to compare whether the digests between nodes or in the central verification database are the same. If all nodes have the same hash result for the same data segment, it means that the data is complete and has not been tampered with.

[0153] Consistency checks primarily focus on the logical consistency of key data across multiple nodes: for example, whether the leaderboard rankings are the same, whether the player's battle record status is synchronized, and whether the number of items in the game's economic system matches. Once a node is detected to have a difference in ranking or number of items compared to most nodes, it is marked as "inconsistent".

[0154] Furthermore, when data inconsistency or synchronization failure is detected (e.g., a node experiences a network failure or write anomaly during the consensus process), the system immediately triggers an error recovery process, which typically includes the following operations:

[0155] Record and analyze inconsistent nodes and their corresponding data versions;

[0156] Based on the preset distributed consensus protocol or conflict resolution strategy, determine the correct data version based on the "majority of nodes" or "central node" when a conflict occurs;

[0157] Initiate supplementary updates or rewrites to the abnormal node until the critical data of that node is consistent with that of other nodes.

[0158] Furthermore, to minimize the impact on players during periods of critical data inconsistency, the system will parallelize or accelerate the repair process. For example:

[0159] When an abnormal cross-server battle record of a player is detected in the game, the abnormal node is re-broadcast with a consensus proposal to resynchronize with the majority of nodes. If the problem comes from a temporarily offline server, a secondary verification process is triggered when the server comes back online until the hash or version number of each node is consistent with the latest data.

[0160] Once the repair is complete, the system will update the verification flags on each node again, indicating that this round of data repair has ended and players can continue to carry out various game activities normally, and the data will continue to maintain high consistency across multiple platforms.

[0161] Through the above process, this embodiment ensures that after the multi-node synchronization of a large-scale multiplayer online game is completed, the integrity and consistency of key data are verified in real time and reliably. Once an anomaly or failure is detected, distributed repair is quickly performed, so that the entire game ecosystem can still maintain accurate synchronization and high availability of key player data in a cross-server environment.

[0162] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0163] Figure 2 This is a schematic diagram of the structure of the multi-platform real-time data synchronization device provided in the embodiments of this application. Figure 2 As shown, the multi-platform real-time data synchronization device includes:

[0164] The acquisition module 201 is used to configure the event listening module on the user end and the platform end respectively. The event listening module is used to acquire events generated by user operations and platform data changes.

[0165] The sending module 202 is used to send events to the event management center so that the event management center can parse the events and form event information;

[0166] The classification module 203 is used to classify event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue using the synchronization tasks.

[0167] Deployment module 204 is used to obtain synchronous tasks related to user access from the task queue, and deploy a prediction model at edge nodes close to the user based on the user behavior characteristics and historical access data contained in the synchronous tasks.

[0168] Storage module 205 is used to obtain target data related to the synchronization task using a prediction model, store the target data in the edge cache, and update and maintain the target data using differential update and cache management methods.

[0169] Consensus module 206 is used to retrieve synchronization tasks related to key data changes from the task queue, execute a distributed consensus protocol on key data changes, so that multiple platform nodes can reach a consensus on the updated status of key data.

[0170] The distribution module 207 is used to distribute the updated status after consensus confirmation to multiple platform nodes in order to complete the multi-node synchronization of key data.

[0171] In some embodiments, Figure 2 After obtaining events generated by user operations or platform data changes, the sending module 202 encapsulates the events along with associated user identifiers, platform identifiers, timestamps, event types, and priority information. The encapsulated events are then sent to the event management center via a message transmission channel, enabling the event management center to parse the events to extract event attributes and associated information, and generate event information based on the event attributes and associated information.

[0172] In some embodiments, Figure 2 The classification module 203 reads event information from the data structure storing event information and classifies the event information according to event type, priority and platform load status; it determines the synchronization strategy to be executed based on the classification results and generates the corresponding synchronization task, creates a task queue and inserts the synchronization task into the task queue.

[0173] In some embodiments, Figure 2 The deployment module 204 extracts synchronous tasks related to user access from the task queue, reads user behavior features and historical access data carried in the synchronous tasks; selects and loads model instances that can perform predictive calculations based on user behavior features and historical access data; deploys the model instances to edge nodes close to the user, and configures and initializes the model instances so that the configured and initialized predictive model can predict the data that the user may access based on the newly received synchronous tasks at the edge nodes.

[0174] In some embodiments, Figure 2The storage module 205 receives target data identified by the prediction model based on user behavior characteristics and historical access data; when the target data is not present in the edge cache, it retrieves the target data from the specified platform node; it writes the retrieved target data into the edge cache and configures version information and timestamp information for the target data for subsequent updates; when a change in the target data is detected, it performs differential updates on the target data in the edge cache; based on the usage of the target data on the user end and the cache occupancy status, it uses a cache management strategy to replace or evict the target data, so that the edge cache always maintains valid data related to the synchronization task.

[0175] In some embodiments, Figure 2 The consensus module 206 extracts synchronization tasks with key data changes identified from the task queue; selects a set of nodes to participate in the consensus among multiple platform nodes and proposes key data changes; each node exchanges voting information according to a preset distributed consensus protocol to determine the update status of the key data; after consensus is reached, the update status is written into the local storage structure of multiple platform nodes to complete the distributed synchronization of key data.

[0176] In some embodiments, Figure 2 After completing the multi-node synchronization of key data, the distribution module 207 performs integrity and consistency verification on the synchronized key data; when inconsistency of key data or synchronization failure is detected, it triggers the error repair process and restores the state of abnormal nodes according to the distributed consensus protocol.

[0177] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0178] Figure 3 This is a schematic diagram of the structure of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0179] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 303 in electronic device 3.

[0180] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0181] Processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0182] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 302 can include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0183] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0184] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0185] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0186] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0187] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0188] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0189] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0190] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application are described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A multi-platform data real-time synchronization method, characterized in that, The method comprises the following steps: configuring an event listening module at the user end and the platform end respectively, the event listening module being used to obtain events generated by user operations and platform data changes; sending the events to an event management center so that the event management center analyzes the events and forms event information; classifying the event information and generating corresponding synchronization tasks based on the classification results, and establishing a task queue using the synchronization tasks; obtaining synchronization tasks related to user access from the task queue, deploying a prediction model on an edge node close to the user according to user behavior characteristics and historical access data contained in the synchronization tasks; obtaining target data related to the synchronization tasks using the prediction model, storing the target data in an edge cache, and updating and maintaining the target data using a differential update and cache management method; obtaining synchronization tasks related to key data changes from the task queue, and executing a distributed consensus protocol on key data changes to reach an agreement on the update status of the key data among multiple platform nodes; distributing the update status confirmed by the consensus to multiple platform nodes to complete multi-node synchronization of the key data; wherein the use of the prediction model to obtain target data related to the synchronization tasks, the storage of the target data in the edge cache, and the update and maintenance of the target data using a differential update and cache management method comprises: receiving target data identified by the prediction model based on user behavior characteristics and historical access data; pulling the target data from a designated platform node when the target data does not exist in the edge cache; writing the obtained target data into the edge cache and configuring version information and timestamp information for the target data for subsequent updates; performing differential updates on the target data in the edge cache when changes in the target data are detected; based on the usage and cache occupancy status of the target data at the user end, using a cache management strategy to replace or eliminate the target data, so that the edge cache always maintains valid data related to the synchronization tasks; after completing the multi-node synchronization of the key data, the method further comprises: performing integrity and consistency checks on the synchronized key data, and triggering an error repair process when inconsistencies or synchronization failures are detected, and recovering the state of abnormal nodes according to the distributed consensus protocol.

2. The method of claim 1, wherein, The sending of the events to the event management center so that the event management center analyzes the events and forms event information comprises: after obtaining events generated by user operations or platform data changes, encapsulating the events with associated user identifiers, platform identifiers, timestamps, event types, and priority information; sending the encapsulated events to the event management center through a message transmission channel, so that the event management center analyzes the events to extract event attributes and associated information, and generates event information based on the event attributes and associated information.

3. The method of claim 1, wherein, The event information is classified, and corresponding synchronization tasks are generated based on the classification results, and a task queue is established by using the synchronization tasks, including: The event information is read from the data structure storing the event information, and the event information is classified according to the event type, priority and platform load state; According to the classification result, the synchronization strategy to be executed is determined, the corresponding synchronization task is generated, the task queue is created, and the synchronization task is inserted into the task queue.

4. The method of claim 1, wherein, The prediction model is deployed on the edge node close to the user according to the user behavior characteristics and historical access data contained in the synchronization task, including: Extract the synchronization task related to user access from the task queue, read the user behavior characteristics and historical access data carried in the synchronization task; Based on the user behavior characteristics and historical access data, select and load the model instance that can perform prediction calculation; Deploy the model instance to the edge node close to the user, and configure and initialize the model instance, so that the prediction model after configuration and initialization can predict the user's possible access data according to the newly received synchronization task on the edge node.

5. The method of claim 1, wherein, The synchronization task related to the key data change is obtained from the task queue, and the distributed consensus protocol is executed on the key data change, so that the multiple platform nodes reach an agreement on the update state of the key data, including: Extract the synchronization task with the task identification of key data change from the task queue; Select a node set participating in consensus from the multiple platform nodes, and make a proposal for the key data change; Each node exchanges voting information according to the preset distributed consensus protocol to determine the update state of the key data; When consensus is reached, write the update state into the local storage structure of the multiple platform nodes to complete the distributed synchronization of the key data.

6. A multi-platform data real-time synchronization device, characterized in that, Including: The acquisition module is configured to configure an event listening module on the user side and the platform side respectively, and the event listening module is used to obtain events generated by user operation and platform data change; The sending module is configured to send the event to the event management center, so that the event management center analyzes the event and forms event information; The classification module is configured to classify the event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue by using the synchronization tasks; The deployment module is configured to extract the synchronization task related to user access from the task queue, and deploy the prediction model on the edge node close to the user according to the user behavior characteristics and historical access data contained in the synchronization task; The storage module is configured to use the prediction model to obtain target data related to the synchronization task, store the target data into the edge cache, and use the differential update and cache management method to update and maintain the target data; The consensus module is configured to extract the synchronization task related to the key data change from the task queue, and execute the distributed consensus protocol on the key data change, so that the multiple platform nodes reach an agreement on the update state of the key data. A distribution module is configured to distribute the updated state confirmed by the consensus to the platform nodes to complete multi-node synchronization of the key data. The storage module is configured to receive target data identified by the prediction model based on user behavior characteristics and historical access data, pull the target data from a designated platform node when the target data does not exist in the edge cache, write the obtained target data into the edge cache, and configure version information and timestamp information for the target data for subsequent updates; when detecting a change in the target data, perform differential update on the target data in the edge cache; based on the usage of the target data at the user end and the cache occupancy state, use a cache management strategy to replace or eliminate the target data, so that the edge cache always maintains valid data related to the synchronization task; The distribution module is configured to perform integrity and consistency check on the key data after the completion of the multi-node synchronization of the key data; when detecting inconsistency or synchronization failure of the key data, trigger an error repair process operation and perform state recovery on the abnormal node according to the distributed consensus protocol.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, the computer-readable storage medium comprising: The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 5.

Images