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

Abstract

The invention provides a multi-platform data real-time synchronization method and device, electronic equipment and a storage medium. The method comprises the following steps: acquiring an event generated by user operation and platform data change; analyzing the event and forming event information; classifying the event information, generating a synchronization task based on a classification result, and establishing a task queue by using the synchronization task; acquiring a synchronization task related to user access from the task queue, and deploying a prediction model at an edge node close to a user according to user behavior characteristics and historical access data in the synchronization task; acquiring a synchronization task related to the key data change from the task queue, and executing a distributed consensus protocol on the key data change, so that a plurality of platform nodes are consistent with the update state of the key data; and distributing the updating state after the consensus confirmation to a plurality of platform nodes. According to the invention, the delay can be reduced, the accuracy of data synchronization can be improved, the load can be reduced, and the real-time performance and consistency of data synchronization can be improved.

Description

Technical Field

[0001] This application relates to the technical field of data processing, and particularly to a multi-platform data real-time synchronization method, device, electronic device, and storage medium. Background Art

[0002] In multi-platform application scenarios, users usually use the same application or service on mobile devices, PC devices, and other terminal devices simultaneously. To ensure that the user experience on different platforms remains consistent, it is necessary to synchronize data scattered across multiple platforms in real time. However, due to the high frequency of user access and intensive data updates in a multi-platform environment, and involving various network and server environments, it is difficult to balance the real-time performance and consistency of data synchronization. There is an urgent need for an efficient and reliable multi-platform data real-time synchronization technology.

[0003] The prior art usually adopts the following synchronization methods: First, periodic pulling or pushing: the client or server updates data at fixed time intervals; Second, passive triggering or manual refreshing: immediate synchronization is performed when the user initiates an operation; Third, centralized consistency management: maintaining data consistency through a centralized database or a single-point service.

[0004] The above methods generally have the following disadvantages in multi-platform high-concurrency scenarios: Periodic synchronization is prone to update delays or excessive server pressure; Passive synchronization methods lack the ability to perceive data changes and are prone to missing key updates; Centralized management methods are difficult to adapt to distributed multi-node deployment environments, and it is relatively difficult to recover in case of failures; When the frequency of multi-platform data access and updates increases sharply, traditional synchronization means are prone to data inconsistency or high error rates. Summary of the Invention

[0005] In view of this, embodiments of this application provide a multi-platform data real-time synchronization method, device, electronic device, and storage medium to solve the problems in the prior art, such as large delays, high error rates, uneven server loads, resulting in inconsistent data synchronization and high error rates.

[0006] In the first aspect of the embodiments of the present application, a multi-platform data real-time synchronization method is provided, including: respectively configuring event listening modules at the user side and the platform side, where the event listening modules are used to obtain events generated by user operations and platform data changes; sending the events to the event management center so that the event management center parses the events and forms event information; classifying the event information, 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, and deploying a prediction model at an edge node close to the user according to the user behavior characteristics and historical access data included in the synchronization tasks; using the prediction model to obtain target data related to the synchronization tasks, storing the target data in the edge cache, and updating and maintaining the target data using a differential update and cache management method; obtaining synchronization tasks related to critical data changes from the task queue, and executing a distributed consensus protocol for the critical data changes so that multiple platform nodes reach an agreement on the update status of the critical data; distributing the update status confirmed by the consensus to multiple platform nodes to complete the multi-node synchronization of the critical data.

[0007] In the second aspect of the embodiments of the present application, a multi-platform data real-time synchronization device is provided, including: an acquisition module for respectively configuring event listening modules at the user side and the platform side, where the event listening modules are used to obtain events generated by user operations and platform data changes; a sending module for sending the events to the event management center so that the event management center parses the events and forms event information; a classification module for classifying the event information, generating corresponding synchronization tasks based on the classification results, and establishing a task queue using the synchronization tasks; a deployment module for obtaining synchronization tasks related to user access from the task queue, and deploying a prediction model at an edge node close to the user according to the user behavior characteristics and historical access data included in the synchronization tasks; a storage module for using the prediction model to obtain target data related to the synchronization tasks, storing the target data in the edge cache, and updating and maintaining the target data using a differential update and cache management method; a consensus module for obtaining synchronization tasks related to critical data changes from the task queue, and executing a distributed consensus protocol for the critical data changes so that multiple platform nodes reach an agreement on the update status of the critical data; a distribution module for distributing the update status confirmed by the consensus to multiple platform nodes to complete the multi-node synchronization of the critical data.

[0008] In the third aspect of the embodiments of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and the steps of the above method are implemented when the processor executes the computer program.

[0009] In the fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0010] The above at least one technical solution adopted in the embodiments of the present application can achieve the following beneficial effects: By respectively configuring event listening modules at the user side and the platform side, the event listening modules are used to obtain events generated by user operations and platform data changes; send the events to the event management center so that the event management center can parse the events and form event information; classify the event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue using the synchronization tasks; obtain synchronization tasks related to user access from the task queue, and deploy a prediction model at an edge node close to the user according to the user behavior characteristics and historical access data included in the synchronization tasks; use the prediction model to obtain target data related to the synchronization tasks, store the target data in the edge cache, and update and maintain the target data using a differential update and cache management method; obtain synchronization tasks related to critical data changes from the task queue, execute a distributed consensus protocol for critical data changes so that multiple platform nodes can reach an agreement on the update status of the critical data; distribute the updated status after consensus confirmation to multiple platform nodes to complete multi-node synchronization of critical data. The present application can reduce latency, improve the accuracy of data synchronization, reduce load, and improve the real-time performance and consistency of data synchronization. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0012] Figure 1 It is a flowchart of a multi-platform data real-time synchronization method provided by an embodiment of the present application; Figure 2 It is a structural schematic diagram of a multi-platform data real-time synchronization device provided by an embodiment of the present application; Figure 3 It is a structural schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0013] In the following description, specific details such as specific system architectures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. However, those skilled in the art should understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0014] In today's Internet and mobile application environment, users often use the same application or service on multiple platforms (such as mobile phones, PCs, tablets, or other intelligent device terminals) simultaneously. In order to provide users with a consistent usage experience, data synchronization needs to be carried out among multiple platforms. For example, in a game application, the game progress of players on the mobile side needs to be consistent with the web version or the client version; or in a shopping platform, the shopping cart information added by users on the mobile phone side needs to be updated in real time to the web version and other ports.

[0015] However, with the continuous increase in the user scale and data access frequency, multi-platform data synchronization often faces the following challenges: Large amount of data and frequent updates: User operation behaviors are diverse, such as logging in, logging out, purchasing, and points changes. As the amount of data and the frequency of requests increase, traditional data synchronization methods are prone to problems such as high latency, data conflicts, and even data loss.

[0016] 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 games, finance, and social networking, data synchronization latency will directly affect the user experience.

[0017] Complex network conditions: Due to the limitations of network bandwidth and server capabilities, if the synchronization strategy is inappropriate, not only will there be delays and errors, but there will also be a risk of overloading the server.

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

[0019] Existing data synchronization mechanisms often adopt the following practices: 1. Periodic pulling or pushing The client periodically pulls data from the server, or the server pushes data to the client at fixed intervals. However, when data updates suddenly, the periodic synchronization mechanism cannot be triggered in a timely manner, which is likely to cause delays; in addition, if the period is too short, a large number of synchronization requests will cause the server load to increase.

[0020] 2. Passive triggering or manual synchronization Synchronization is actively triggered by the user (such as manual refresh), or a certain degree of synchronization is triggered based on the monitoring of user activity. However, this mode lacks the ability to perceive data changes and is prone to missing key updates; once the user does not trigger or the activity is not obvious, data synchronization will be lagged or omitted.

[0021] 3. Centralized Consistency Management Consistency management is carried out in the backend in the form of a centralized database or centralized middleware, and data consistency is maintained through a lock mechanism or version control. However, in high-concurrency and multi-node scenarios, the centralized solution is prone to becoming a performance bottleneck; it has poor scalability and is relatively difficult to recover once a failure occurs.

[0022] The above traditional practices are prone to problems such as large delays, high error rates, and uneven server loads in data synchronization scenarios with a large amount of data and multiple platforms, and it is difficult to meet users' requirements for real-time and consistency.

[0023] Therefore, in order to solve the problems of multi-platform data real-time synchronization delay and errors in the prior art. This application proposes a multi-platform data real-time synchronization method. The technical solution of this application completely solves the problems of delay, error, and high server load existing in traditional synchronization methods through an event-driven data synchronization mechanism, an edge-side prediction caching strategy, and a distributed state consensus management mechanism. The main technical points of this technical solution include the following: 1. Event-driven Data Synchronization Mechanism No longer relying solely on user activity characteristics or manual triggering, but abstracting user behavior, data changes, and server state changes into events, and using events as the core to drive the creation and scheduling of synchronization tasks to achieve fine-grained control.

[0024] 2. Edge-side Prediction Caching Strategy Deploy an intelligent prediction caching module on the user side or an edge node close to the user terminal, and through the local caching and data prefetching mechanism, predict and synchronize the data that the user is about to access in advance, greatly improving the real-time performance of data access.

[0025] 3. Distributed State Consensus Management Mechanism With the help of a lightweight distributed consensus algorithm, achieve fast, reliable, and consistent confirmation and propagation of states among multiple platform nodes, improve data consistency, and reduce the synchronization error rate.

[0026] The content of the technical solution of this application will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0027] Figure 1 is a schematic flowchart of the multi-platform data real-time synchronization method provided by the embodiment of this application. As Figure 1 shown, the multi-platform data real-time synchronization method may specifically include: S101, configure an event listening module at the user side and the platform side respectively. The event listening module is used to obtain events generated by user operations and platform data changes; S102, send the events to the event management center so that the event management center can parse the events and form event information; S103, classify the event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue using the synchronization tasks; S104, obtain the synchronization tasks related to user access from the task queue, and deploy a prediction model at the edge node close to the user according to the user behavior characteristics and historical access data included in the synchronization tasks; S105, use the prediction model to obtain the target data related to the synchronization task, store the target data in the edge cache, and update and maintain the target data using differential update and cache management methods; S106, obtain the synchronization tasks related to critical data changes from the task queue, and execute a distributed consensus protocol for critical data changes so that multiple platform nodes can reach an agreement on the update status of the critical data; S107, distribute the updated status after consensus confirmation to multiple platform nodes to complete the multi-node synchronization of critical data.

[0028] In some embodiments, in order to timely sense the operation behavior of players and the changes of critical data on the game platform in a game application, an event listening module can be deployed at the user terminal (such as a mobile game client, a PC game client, etc.) and the server platform side (such as a game background service, a leaderboard service, etc.) respectively, and a high-performance message middleware is used to quickly distribute these event messages. The implementation process can be exemplified as follows: Abstract the operation behavior of the user side and the data update of the platform side into events that can trigger data synchronization.

[0029] User operation behaviors include: login, logout, key actions in the game (such as character level up, skill unlock, task completion), etc.

[0030] Platform side data updates include: ranking changes, record changes, item purchases, item gifts, etc.

[0031] Each type of event is assigned a corresponding priority (such as high, normal, low) and a corresponding synchronization policy when defined for subsequent refined management. For example, the event triggered by a player's key action can be marked as high priority, while the update of ordinary background statistical data can be marked as normal or low priority.

[0032] Further, embed a dedicated listening proxy or event trigger component in the game client on the mobile or PC side. When this component detects operations such as player login, logout, and completion of important levels, it will immediately capture the operation behavior; The listening proxy packages the captured operation behavior into an event message, and attaches corresponding event identifiers, user information, priority, etc.; Then, the listening proxy 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 side.

[0033] Further, deploy a listening module on the game platform background or related service nodes that can monitor data changes in real time; when the background service detects actions such as leaderboard ranking updates, player achievement changes, or prop purchase record updates, this listening module will abstract the data changes into corresponding events.

[0034] Similar to the user side, the listening module on the platform side will also use message middleware to send event messages uniformly, and package and transfer information such as event type, data change content, timestamp, and priority to the event management center.

[0035] In some examples, the high-performance message middleware undertakes the responsibility of event message transfer and routing. Specifically, event messages generated by either the user-side or platform-side listening module will be sent to a message system such as Kafka or RocketMQ.

[0036] The message system classifies and stores messages according to 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 requirements can be triggered in a timely manner based on different priorities.

[0037] In some examples, for different types of events, the listening module will attach synchronization strategies with different priority tags. For example, the ranking change event can be defined as a normal priority, while the data connection event when a player switches across platforms can be defined as a high priority.

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

[0039] In the above manner, the listening modules on the client side and the platform side can effectively capture and generate event messages, thereby ensuring that in the game application scenario, the operations on the client side and the data updates on the platform side are detected and reported in a timely manner, providing a basic support for subsequent data synchronization or status management operations. This embodiment is only limited to illustrate how to specifically deploy the event listening module and the message middleware within the technical framework of this application, so as to achieve real-time perception of user operations and platform data changes in a multi-platform environment.

[0040] In some embodiments, the event is sent to the event management center so that the event management center can parse the event and form event information, including: After obtaining the event generated by the user operation or the platform data change, the event is encapsulated with the associated user identifier, platform identifier, timestamp, event type, and priority information. 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 the event attributes and associated information, and generate event information based on the event attributes and associated information.

[0041] Specifically, in order to achieve unified management of user operations or platform data changes during the real-time synchronization of multi-platform data, the obtained event needs to be sent to the event management center, and the event management center is required to parse the event and form event information. Taking an online music entertainment platform as an example, the specific implementation process may include the following steps: When the user performs key operations (such as song playing, liking, and favoriting) on the mobile terminal or the web terminal, or when the platform data (such as the ranking, song information, and comment dynamics) is updated, the corresponding event listening module will obtain the event.

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

[0043] For example, when the user performs a "favoriting" operation on a song, the event may be defined as "SongFavorEvent", and the user identifier (UserID), platform identifier (PlatformID, such as mobile terminal / web terminal), timestamp (Timestamp), and priority (Priority) are attached to the event.

[0044] 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 message mechanisms that conform to network communication specifications such as REST / WebSocket.

[0045] In some examples, to handle a high concurrency volume and improve transmission efficiency, a distributed message queue can be adopted to establish a stable and high-speed communication path between each platform end and the event management center.

[0046] After receiving the encapsulated event, the event management center parses the event to extract the internal event attributes and associated information. This process typically includes the following operations: Unpack the event to obtain the user identifier, platform identifier, and timestamp; Determine the event type (such as a favorite operation, comment operation, leaderboard update, etc.), and read the priority information; Temporarily store the unpacked key attributes in a memory data structure or write them to a dedicated database for subsequent classification or task generation.

[0047] Through this parsing process, the event management center can perform refined management of different events and provide basic data support for subsequent data synchronization or distributed consensus processes.

[0048] Furthermore, based on the event attributes and associated information (such as user identifier, event type, priority, etc.), the event management center assembles the parsing result into an "event information" object.

[0049] This "event information" object can contain the key fields required for cross-platform data synchronization, such as the type of data update triggered by the event, potential target nodes, applicable synchronization strategies, etc.

[0050] In some examples, when detecting a high-priority event (such as a user using an account on multiple terminals simultaneously, and this event may affect playlist synchronization in a short period), the event management center can mark "urgent handling required" or "real-time synchronization" when creating the event information, providing a basis for priority scheduling in subsequent processes.

[0051] Through the above method, the events obtained at the user end and the platform end in this application can be quickly transmitted to the event management center, and be uniformly parsed and encapsulated at the center, providing accurate and detailed basic data support for subsequent processes of multi-platform data real-time synchronization (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 show how to achieve centralized management of scattered events with high performance and scalability in an actual environment.

[0052] In some embodiments, classify the event information, generate corresponding synchronization tasks based on the classification results, and establish a task queue using the synchronization tasks, including: Read event information from the data structure storing event information, and classify the event information according to the event type, priority, and platform load status; Determine the synchronization policy to be executed based on the classification result and generate the corresponding synchronization task, create a task queue, and insert the synchronization task into the task queue.

[0053] Specifically, in order to effectively manage event information from different client and platform sides, an "Event Management Center" and a "Task Scheduling Module" are usually deployed on the server or central system to centrally process and classify events, and generate synchronization tasks according to the classification result. The following takes an online education platform as an example for exemplary illustration: In an online education platform, an event listening module captures events formed by operations such as user login, video playback, question submission, and homework grading.

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

[0055] Furthermore, the classification module in the Event Management Center reads the unclassified event information from this data structure periodically or in real time.

[0056] According to the event type (such as user viewing duration, test question 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 classified in a refined manner.

[0057] For example, in some examples, events related to course progress synchronization 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" for subsequent resource allocation with different strategies.

[0058] Furthermore, after completing the classification of the event information, the classification module combines the pre-configured synchronization policy rules to determine the synchronization policy to be adopted for each type of event.

[0059] For example, for high-priority grading result update events, real-time synchronization tasks can be generated immediately to update to all relevant teachers' or students' terminals in a timely manner; while for normal or low-priority statistical data update events, batch or delayed synchronization strategies may be adopted to reasonably utilize system resources; According to the above strategy, the classification module creates corresponding synchronization tasks for each piece of event information to be processed, records them in memory or the database, and attaches the required parameters (such as target platform nodes, synchronization methods, deadline, etc.).

[0060] Furthermore, to enable subsequent processing modules to orderly obtain and execute synchronization tasks, the system usually maintains one or more task queues (such as high-priority task queues, normal-priority task queues, etc.) to handle scheduling requirements in different scenarios.

[0061] Write the synchronization tasks generated according to the classification results into the corresponding task queues, and record necessary task attributes (such as task numbers, execution priorities, creation times, etc.).

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

[0063] Through the above process, the online education platform can effectively classify event information in various user operation and data update scenarios, generate synchronization tasks based on the classification results, and establish task queues, so that subsequent synchronization operations, state consensus, or edge prediction caching and other links can be completed efficiently and accurately. This embodiment only gives an exemplary description of the event classification and synchronization task generation part, aiming to illustrate how to achieve refined management and scheduling of various events in the actual business environment.

[0064] In some embodiments, according to the user behavior characteristics and historical access data included in the synchronization tasks, a prediction model is deployed at edge nodes close to the users, including: Extract the synchronization tasks related to user access from the task queue, and read the user behavior characteristics and historical access data carried in the synchronization tasks; Based on the user behavior characteristics and historical access data, select and load a model instance that can perform prediction calculations; Deploy the model instance to an edge node close to the user, and configure and initialize the model instance, so that the configured and initialized prediction model can predict the data that the user may access at the edge node according to the newly received synchronization tasks.

[0065] Specifically, to improve the real-time response capabilities of product recommendations and page loading in an e-commerce platform, lightweight prediction models can be deployed at edge nodes to pre-cache and synchronize the products and page resources that the user may access. The implementation steps can be exemplified as follows: The task scheduling system of the e-commerce platform retrieves synchronization tasks related to user access from the task queue, such as the product information that the user has browsed or searched recently.

[0066] This synchronization task usually contains user historical access data (such as browsing records, shopping cart behaviors) and user behavior characteristics (such as preference types, purchase habits, geographical locations, and access time periods).

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

[0068] For example, for common product browsing and recommendation tasks, a deep learning model or a collaborative filtering model that occupies less resources but has high prediction accuracy can be selected to ensure fast deployment and efficient execution on edge nodes.

[0069] Furthermore, the model instance is deployed to the edge node closest to the user (such as a CDN node or a local user client), and through configuration and initialization, it is ensured that the model can run normally on this node.

[0070] In the initialization stage, some parameters or data dictionaries of the model can be updated in real time according to the newly received synchronization tasks and user behavior characteristics, so that the model can more accurately identify the product categories or page resources that the user is about to access.

[0071] Furthermore, the deployed prediction model will continuously analyze the user access logs and new synchronization tasks in the task queue at the edge node, and automatically identify the possible access data types related to the user (such as a list of best-selling products, personalized recommended products, etc.).

[0072] Once it is predicted that a specific product or page resource is likely to be clicked and accessed by the user, an early synchronization operation is immediately triggered, and the corresponding product details, pictures, inventory information, etc. are pre-pulled and cached at the edge node.

[0073] The cached data is dynamically maintained by means of differential update to minimize repeated downloads or unnecessary network transmissions.

[0074] Through the deployment method of the above embodiments, the e-commerce platform can fully utilize the user behavior characteristics and historical access data at the edge node to predict the access trend, and based on the prediction results, perform data synchronization and caching in advance, thereby improving the response speed of users when accessing products and services on multiple platforms (such as mobile terminals and web terminals). This embodiment only exemplarily illustrates the technical solution of "deploying a prediction model at the edge node close to the user and performing data prediction and synchronization", aiming to demonstrate the feasibility and applicability of this solution in actual business scenarios.

[0075] In some embodiments, a prediction model is used to obtain target data related to synchronization tasks, the target data is stored in the edge cache, and a differential update and cache management method is adopted to update and maintain the target data, including: Receiving the target data identified by the prediction model according to the user behavior characteristics and historical access data; When the target data does not exist in the edge cache, pull the target data from the specified platform node; Write the obtained target data into the edge cache, and configure version information and timestamp information for the target data for subsequent updates; When it is detected that the target data has changed, perform differential update on the target data in the edge cache; Based on the usage situation and cache occupancy status of the target data at the user side, use the cache management strategy to replace or eliminate the target data, so that the edge cache always maintains valid data related to the synchronization task.

[0076] Specifically, a massively multiplayer online game (MMO) often has a huge amount of game props, scene resources, and player data. In order to provide players with a low-latency and high-consistency gaming experience across multiple terminals (such as mobile and PC), the system can deploy a prediction model on edge nodes close to players, and then use the prediction results to prefetch and cache the target data that players may need. The following is an exemplary description of this process: The prediction model on the game backend or the edge side analyzes the player's past behavioral characteristics (such as commonly used characters) and historical access data (such as skills and props frequently used recently) to generate a list of "target data"; in this example, the "target data" may include equipment skins or key prop information that the player is about to use.

[0077] After receiving this list, the system processes each piece of target data according to the requirements of the synchronization task.

[0078] If some of the target data identified by the prediction model does not yet exist in the edge cache, the system sends a pull request to the game server or other storage nodes.

[0079] Write the obtained target data (such as high-resolution models, character decoration files, etc.) into the edge cache, and configure version information and timestamp information for this data when writing.

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

[0081] Furthermore, in order to reduce the network burden caused by large-scale data repeated transmission, when it is detected that the target data has changed (such as character skin hot patching, etc.), the system only performs differential transmission and update on the changed part.

[0082] For example, if only a small part of a terrain texture file is updated, the edge node only needs to pull the new texture differential package and integrate it into the existing cached data, rather than retransmitting the entire file. In this way, the game can ensure that players can quickly obtain the latest version of the resources without consuming a large amount of bandwidth to download the complete data packet.

[0083] In the game, the usage frequencies, space occupancies, and expiration periods of different terrains or items vary. To ensure that the edge cache always retains the data most needed by players, in this embodiment, a cache management strategy is used to dynamically adjust and optimize the cache content.

[0084] If it is detected that a certain item or scene resource has not been accessed for a long time or the system space is limited, the system can replace or clean it according to the cache eviction algorithm (such as LRU, LFU, or a custom policy) to make room for other high-priority resources.

[0085] 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.

[0086] Through the above process, the game system deploys a prediction model at the edge node close to the player and actively pulls the target data based on the model results, and uses differential update and cache management methods to maintain the target data, thereby effectively reducing the network transmission volume and improving the player experience while ensuring the reliable update of game resources. This embodiment mainly reflects the specific implementation details of using the prediction model for target data determination, differential update, and cache management. In actual system deployment, other synchronization strategies or distributed consensus mechanisms can also be combined to further improve the overall real-time data synchronization effect of multiple platforms.

[0087] In some embodiments, obtain synchronization tasks related to critical data changes from the task queue, and execute a distributed consensus protocol for critical data changes to enable multiple platform nodes to reach an agreement on the update status of critical data, including: Extract the synchronization task with the task identifier of critical data change from the task queue; Select a set of nodes participating in the consensus among multiple platform nodes and propose a critical data change; Each node exchanges voting information according to the preset distributed consensus protocol to determine the update status of critical data; When consensus is reached, write the update status into the local storage structure of multiple platform nodes to complete the distributed synchronization of critical data.

[0088] Specifically, large-scale multiplayer online games usually need to maintain the consistency of key data among multiple platform nodes (such as different game server clusters or regional nodes). For example, player leaderboards, cross-server battle records, item trading, etc. all belong to the key data that affects game balance and player experience. Once the data is inconsistent among different nodes, it will lead to chaos among players or vulnerabilities in the economic system. Therefore, this embodiment adopts a distributed consensus protocol to ensure that the updated status of key data is consistent on all relevant nodes, and its implementation process can be exemplified as follows: After the event management center or task scheduling system of the game finishes classifying various event information, it will generate multiple synchronization tasks and write them into the task queue.

[0089] When a synchronization task is marked as "key data change" (such as player battle record settlement or large-scale item distribution, etc.), it means that this synchronization task involves the core data of the game and requires a higher level of consistency guarantee.

[0090] In some examples, the system will first extract the "key data change" task from the task queue and prepare to execute the distributed consensus process.

[0091] To ensure the consistency of cross-platform and cross-server data, the system will select a number of nodes that can participate in the consensus according to the pre-configured node roles or physical distributions (such as server clusters that mainly store leaderboard or battle record information).

[0092] Package the current key data change (such as "Player A won the championship in the cross-server battle and was rewarded with several rare items") into a consensus proposal, and broadcast or send this proposal to the node set; in this proposal, necessary metadata will be included, such as change type (battle record settlement), player ID involved, expected final update status, etc.

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

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

[0095] If the majority or more than a certain threshold of nodes confirm that the change can be accepted, it means that consensus has been reached, marking that the key data change enters the "submittable" state.

[0096] Furthermore, after consensus is reached, the system writes the final updated status of this critical data change to the local storage structures (such as databases, in-memory hashes, or distributed caches) of each participating node, so that the achievement information of all relevant nodes remains completely consistent.

[0097] For other nodes that did not directly participate in this consensus, the latest critical data status can also be distributed to them through subsequent message broadcasts or regular synchronizations to ensure data consistency throughout the game ecosystem.

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

[0099] Through the above process, executing a distributed consensus protocol for critical data in a massively multiplayer online game can effectively ensure reliable and consistent updates of core business data in a high-concurrency, multi-node environment. This embodiment focuses on demonstrating how to achieve distributed consistency by combining a task queue mechanism, a consensus proposal, and a node voting process. In actual system deployment, more optimization means (such as log compression, batch updates, etc.) can also be selected according to the actual scale of the game and business requirements to further improve the stability and performance of the system.

[0100] In some embodiments, after multi-node synchronization of critical data is completed, the method further includes: Performing integrity and consistency checks on the synchronized critical data; when it is detected that the critical data is inconsistent or the synchronization fails, triggering an error repair process operation and restoring the status of abnormal nodes according to the distributed consensus protocol.

[0101] Specifically, in a massively multiplayer online game, critical data such as leaderboards, cross-server achievements, and player items and props needs to be multi-node synchronized. Once the synchronization of this data is abnormal, it will seriously affect the fairness of players and the game balance. Therefore, in this embodiment, after multi-node synchronization is completed, the synchronization result will also be subjected to integrity and consistency checks, and an error repair process will be triggered when inconsistency or synchronization failure is detected. The implementation method can be exemplified as follows: When the distributed consensus protocol completes the consistent update of critical data, the system will record and mark the completion time or version number of this round of consensus operation on each node.

[0102] The built-in or external verification module in the system will then detect this marked information and start the integrity and consistency verification process to check whether the critical data stored on each node is consistent with the consensus result.

[0103] In this example, the integrity check can be performed based on methods such as hash digest, data length, or version number comparison: for example, calculating the hash of key fields such as player items and battle records, and comparing whether the digests between each node or with the central verification library are the same; if the hash results of the same data segment by all nodes are consistent, it indicates that this part of the data is complete and has not been tampered with.

[0104] The consistency check mainly focuses on the logical consistency of key data on multiple nodes: for example, whether the leaderboard rankings are the same, whether the player battle records are synchronized, whether the item quantities in the game economy system match, etc.; once it is detected that a certain node has a difference in rankings or item quantities compared with most nodes, it is marked as an "inconsistent" state.

[0105] Furthermore, when data inconsistency or synchronization failure is detected (for example, a network failure or write exception occurs in a node during the consensus process), the system will immediately trigger an error repair process, which usually includes the following operations: Record and analyze the inconsistent nodes and the corresponding data versions; According to the preset distributed consensus protocol or conflict resolution strategy, determine the correct data version that takes the "majority nodes" or "central node" as the standard when conflicts occur; Initiate supplementary updates or rewrites to the abnormal node until the key data of this node is consistent with other nodes.

[0106] Furthermore, to shorten the possible impact on players during the period of key data inconsistency, the system will perform parallel or accelerated processing on the repair process. For example: When cross-server battle records of players are detected as abnormal in the game, by broadcasting the consistency proposal again, the abnormal node is resynchronized with the majority nodes; if the problem comes from a temporarily offline server, a secondary verification process is triggered when the server comes back online until the hashes or version numbers of each node are consistent with the latest data.

[0107] Once the repair is completed, the system will update the verification mark 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 continues to maintain high consistency across multiple platforms.

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

[0109] The following is an embodiment of the apparatus of the present application, which can be used to execute the method embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the method embodiment of the present application.

[0110] Figure 2 It is a schematic structural diagram of a multi-platform data real-time synchronization device provided by an embodiment of the present application. As Figure 2 shown, the multi-platform data real-time synchronization device includes: An acquisition module 201, configured to respectively configure event listening modules at the user side and the platform side, and the event listening modules are used to acquire events generated by user operations and platform data changes; A sending module 202, configured to send the event to the event management center, so that the event management center parses the event and forms event information; A classification module 203, 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; A deployment module 204, configured to obtain synchronization tasks related to user access from the task queue, and deploy a prediction model at an edge node close to the user according to the user behavior characteristics and historical access data included in the synchronization tasks; A storage module 205, configured to use the prediction model to obtain target data related to the synchronization task, store the target data in the edge cache, and update and maintain the target data by using differential update and cache management methods; A consensus module 206, configured to obtain synchronization tasks related to critical data changes from the task queue, and execute a distributed consensus protocol on the critical data changes, so that multiple platform nodes reach an agreement on the update status of the critical data; A distribution module 207, configured to distribute the updated status after consensus confirmation to multiple platform nodes to complete multi-node synchronization of critical data.

[0111] In some embodiments, Figure 2 After the sending module 202 obtains the event generated by the user operation or the platform data change, it encapsulates the event with the associated user identifier, platform identifier, timestamp, event type, and priority information; and sends the encapsulated event to the event management center through the message transmission channel, so that the event management center parses the event to extract event attributes and associated information, and generates event information based on the event attributes and associated information.

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

[0113] In some embodiments, Figure 2 The deployment module 204 extracts the synchronization tasks related to user access from the task queue, reads the user behavior characteristics and historical access data carried in the synchronization tasks; based on the user behavior characteristics and historical access data, selects and loads a model instance capable of performing prediction calculations; deploys the model instance to an edge node close to the user, and configures and initializes the model instance, so that the configured and initialized prediction model can predict the data that the user may access at the edge node according to the newly received synchronization tasks.

[0114] In some embodiments, Figure 2 The storage module 205 receives the target data identified by the prediction model according to the user behavior characteristics and historical access data; when the target data does not exist in the edge cache, pulls the target data from the specified platform node; writes the obtained target data into the edge cache, and configures version information and timestamp information for the target data for subsequent updates; when it is detected that the target data has changed, performs differential updates on the target data in the edge cache; based on the usage situation and cache occupancy status of the target data at the user end, applies a cache management policy to replace or eliminate the target data, so that the edge cache always maintains valid data related to the synchronization tasks.

[0115] In some embodiments, Figure 2 The consensus module 206 extracts the synchronization tasks with the task identifier of critical data change from the task queue; selects a set of nodes participating in the consensus among multiple platform nodes, and proposes the critical data change; each node exchanges voting information according to the preset distributed consensus protocol to determine the update status of the critical data; when consensus is reached, writes the update status into the local storage structure of multiple platform nodes to complete the distributed synchronization of the critical data.

[0116] In some embodiments, Figure 2 The distribution module 207 performs integrity and consistency verification on the synchronized critical data after completing the multi-node synchronization of the critical data; when it is detected that the critical data is inconsistent or the synchronization fails, triggers an error repair process operation and restores the status of the abnormal nodes according to the distributed consensus protocol.

[0117] It should be understood that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The order of execution of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0118] Figure 3 is a schematic structural diagram of the electronic device 3 provided by an embodiment of the present application. As Figure 3 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, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of each module / unit in the above-mentioned device embodiments are implemented.

[0119] Exemplarily, the computer program 303 can be divided into one or more modules / units. The one or more modules / units are stored in the memory 302 and executed by the processor 301 to complete the present application. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program 303 in the electronic device 3.

[0120] The electronic device 3 can be a desktop computer, a notebook, a palm computer, a cloud server, and other electronic devices. The electronic device 3 can include, but is not limited to, the processor 301 and the memory 302. Those skilled in the art can understand that Figure 3 merely examples of the electronic device 3 do not constitute a limitation to the electronic device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, the electronic device may further include input / output devices, network access devices, a bus, etc.

[0121] The 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. The general-purpose processor can be a microprocessor, or the processor can also be any conventional processor, etc.

[0122] The memory 302 may be an internal storage unit of the electronic device 3, for example, the hard disk or memory of the electronic device 3. The memory 302 may also be an external storage device of the electronic device 3, for example, a plug-in hard disk equipped on the electronic device 3, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Further, the memory 302 may also include both the internal storage unit of the electronic device 3 and the external storage device. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 may also be used to temporarily store the data that has been output or will be output.

[0123] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be assigned to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of the present application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiment and will not be elaborated here.

[0124] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0125] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or by a combination of computer software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0126] In the embodiments provided in the present application, it should be understood that the disclosed device / computer equipment and method can be implemented in other ways. For example, the device / computer equipment embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. Multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of devices or units can be in electrical, mechanical or other forms.

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

[0128] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0129] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, to implement all or part of the processes in the above method embodiments of the present application, it can also be completed by a computer program instructing relevant hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above method embodiments can be implemented. The computer program can include computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc.

[0130] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the technical solutions of the present application have been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included within the protection scope of the present application.

Claims

1. A multi-platform data real-time synchronization method, characterized in that: include: An event monitoring module is configured on the user side and the platform side respectively, and the event monitoring module is used to obtain events generated by user operations and platform data changes; Sending the event to an event management center so that the event management center analyzes the event and generates event information; Classifying the event information, generating corresponding synchronization tasks based on the classification results, and establishing a task queue using the synchronization tasks; Acquire synchronization tasks related to user access from the task queue, and deploy a prediction model on an edge node close to the user based on user behavior characteristics and historical access data contained in the synchronization tasks; Using the prediction model to obtain target data related to the synchronization task, storing the target data in the edge cache, and updating and maintaining the target data using differential update and cache management methods; Obtain synchronization tasks related to key data changes from the task queue, and 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; Distribute the updated status after consensus confirmation to multiple platform nodes to complete multi-node synchronization of key data.

2. The method according to claim 1, characterized in that The sending the event to an event management center so that the event management center analyzes the event and forms event information includes: After obtaining an event generated by a user operation or a platform data change, encapsulate the event with the associated user ID, platform ID, timestamp, event type, and priority information; The encapsulated event is sent to the event management center through a message transmission channel, so that the event management center parses the event to extract event attributes and associated information, and generates event information based on the event attributes and associated information.

3. The method according to claim 1, characterized in that The classifying the event information, generating corresponding synchronization tasks based on the classification results, and establishing a task queue using the synchronization tasks includes: Reading the event information from a data structure storing the event information, and classifying the event information according to event type, priority, and platform load status; The synchronization strategy to be executed is determined according to the classification result, and a corresponding synchronization task is generated, a task queue is created, and the synchronization task is inserted into the task queue.

4. The method according to claim 1, characterized in that The step of deploying a prediction model at an edge node close to the user according to the user behavior characteristics and historical access data included in the synchronization task includes: Extracting synchronization tasks related to user access from the task queue, and reading user behavior characteristics and historical access data carried in the synchronization tasks; Based on the user behavior characteristics and historical access data, select and load a model instance that can perform predictive calculations; The model instance is deployed to an edge node close to the user, and the model instance is configured and initialized, so that the configured and initialized prediction model predicts the data that the user may access based on the newly received synchronization task at the edge node.

5. The method according to claim 1, characterized in that The method of using the prediction model to obtain target data related to the synchronization task, storing the target data in an edge cache, and updating and maintaining the target data by using a differential update and cache management method includes: Receiving target data identified by the prediction model based on user behavior characteristics and historical access data; When the target data does not exist in the edge cache, the target data is pulled from the designated platform node; Writing the acquired target data into the edge cache, and configuring version information and timestamp information for the target data for subsequent updates; When a change in the target data is detected, performing a 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 status, the target data is replaced or eliminated using a cache management strategy, so that the edge cache always maintains valid data related to the synchronization task.

6. The method according to claim 1, characterized in that The step of obtaining synchronization tasks related to key data changes from the task queue and 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 includes: Extracting a synchronization task with a task identifier of a key data change from the task queue; Select a set of nodes participating in the consensus from the multiple platform nodes, and propose key data changes; Each node exchanges voting information according to a preset distributed consensus protocol to determine the update status of the key data; When consensus is reached, the updated status is written into the local storage structure of the multiple platform nodes to complete the distributed synchronization of the key data.

7. The method according to claim 1, characterized in that After completing the multi-node synchronization of key data, the method further includes: Perform integrity and consistency checks on the key data that has completed synchronization; when it is detected that the key data is inconsistent or the synchronization fails, trigger the error repair process operation and restore the state of the abnormal node according to the distributed consensus protocol.

8. A multi-platform data real-time synchronization device, characterized in that: include: An acquisition module, used to configure event monitoring modules on the user side and the platform side respectively, wherein the event monitoring modules are used to acquire events generated by user operations and platform data changes; A sending module, used for sending the event to an event management center, so that the event management center analyzes the event and generates event information; A classification module, used 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, used to obtain synchronization tasks related to user access from the task queue, and deploy a prediction model on an edge node close to the user according to the user behavior characteristics and historical access data contained in the synchronization task; A storage module, used to obtain target data related to the synchronization task using the prediction model, store the target data in the edge cache, and update and maintain the target data using differential update and cache management methods; A consensus module, used to obtain synchronization tasks related to key data changes from the task queue, and 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; The distribution module is used to distribute the updated status after consensus confirmation to multiple platform nodes to complete multi-node synchronization of key data.

9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images