Game account data collecting, sharing and recovering method under distributed cluster

Abstract

The invention discloses a method for collecting, sharing and recovering game account data under a distributed cluster. The method comprises the following steps of: deploying a ZooKeeper central registration server, registering a node IP (Internet Protocol) and a port to the ZooKeeper server when a game server process of a team member is started, subscribing a node IP change event at the same time, and dynamically monitoring an online machine node in a team; the game server process runs in the respective development environment of the team members, and when a preset condition is met, the game server process automatically stores the staged account data to a local database and the like. According to the method, a distributed cluster architecture concept is applied to machine nodes of a local area network, a game server supports the functions of local account data collection, sharing, recovery, serialization, import and export and the like, the method can be applied to the local area network and can also be applied to cross-network and off-line environments, extremely convenient account data operation services are provided for game development teams, and the game development teams are more convenient to use. And the convenience and efficiency of account data use in the program development and test process are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data collection, sharing and recovery, and in particular to a method for collecting, sharing and recovering game account data in a distributed cluster. Background Art

[0002] The process in which developers play games to find bugs in game testing is often referred to as "game testing" or "game quality assurance testing" (QA Testing for short). This process is an important part of the software development life cycle, and its purpose is to ensure that the game has no major defects before release and provide a smooth and pleasant user experience. Game testing steps may include but are not limited to: Functional testing: Check whether all functions of the game work as expected. Performance testing: Ensure that the game runs smoothly on different hardware and there are no performance bottlenecks. Compatibility testing: Test the compatibility of the game on different operating systems, devices or browsers. User interface testing: Evaluate whether the game's user interface is intuitive and easy to use. Regression testing: Test after each update or fix to ensure that new changes have not introduced new problems. Stress testing: Test the performance of the game under high load or extreme conditions. Security testing: Ensure that the game has no security vulnerabilities and protects the security of player data. Localization testing: If the game supports multiple languages, ensure the translation accuracy and cultural adaptability of all language versions. Game testing is an iterative process that may require multiple iterations until the game reaches the release standard. Based on this, staged games are often used to store game data so that after subsequent bug fixes, they can quickly switch to the game stage required for testing. However, the existing methods have certain limitations, including:

[0003] 1. The efficiency of manual account operation is limited: When developers need to quickly advance to a certain stage of the game or transition to a specific state, manual account operation will consume a lot of time and cause inefficiency problems.

[0004] 2. Backing up other team members' account data is frequent and cumbersome: When developers want to use other team members' account data, they must perform the following steps: back up the other party's database, copy the database backup to the local computer, import the database, and restart the game server process. All of these steps are time-consuming and cumbersome, and have a significant impact on efficiency.

[0005] 3. Game GM development consumes too much effort: If developers decide to implement the GM menu through programming to quickly reach a specific stage, they will need to write data conversion code for different business modules. For games with fast demand iteration and many business modules, this approach will expose high code maintenance costs because it requires continuous maintenance of GM code.

[0006] 4. It is inconvenient to share different LAN network isolation: Since the game server will be built in the intranet environment under different environments, there is no data intercommunication due to security considerations, which makes it inconvenient for account data sharing. Although the database can be backed up, the method of backing up the database is not efficient and the database size is uncontrollable. Summary of the invention

[0007] In view of this, the purpose of the present invention is to propose a method for collecting, sharing and recovering game account data in a distributed cluster, which can solve at least one technical problem mentioned in the background technology.

[0008] According to one aspect of the present invention, a method for collecting, sharing and restoring game account data in a distributed cluster is provided, the method comprising:

[0009] Deploy a ZooKeeper central registration server. When the game server process of the team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to the node IP change event to dynamically monitor the online machine nodes in the team.

[0010] The game server process running in the development environment of each team member will automatically save the phased account data to the local database when the preset conditions are met;

[0011] Team members access the account data in other team members' local databases through node IP and port from their respective development environments, and query and download other team members' account data to the local database.

[0012] In the above technical solution, the method is based on the distributed cluster architecture concept of each machine node in the local area network. The game server supports local account data collection, sharing, recovery, serialization, import and export and other functions. It can be applied not only to the local area network, but also to cross-network and offline environments, providing extremely convenient account data operation services for the game development team, improving the convenience and efficiency of account data use during program development and testing. The server in the local area network adopts the microservice architecture concept and deploys ZooKeeper as the central registration server, so that each machine node registers its IP address and port number with ZooKeeper and subscribes to the node change event. . This setting allows nodes to discover and access each other, build an efficient distributed cluster, and realize seamless data sharing. The cluster design focuses on high availability and scalability, and has load balancing capabilities, ensuring the stability and reliability of the data sharing platform. Furthermore, the most practical benefit of introducing ZooKeeper is that the "service discovery capability" is improved. With the ZooKeeper central registration server, the game server process will register the node IP information when it starts. When the process is closed or offline, ZooKeeper can also sense the node exit and log off the node, thereby maintaining a valid online node list. When team members meet certain specific rules (such as changes in the main task), the game server process will automatically clone and collect relevant account data. Using the concept of distributed cluster architecture, machines in the local area network can achieve mutual discovery, mutual access and data sharing through the service discovery mechanism. These data will be used as a source of information for subsequent sharing in team collaboration.

[0013] In some embodiments, the game server process running in the development environment of each team member automatically saves the phased account data to the local database when the preset conditions are met. Specifically:

[0014] When a team member's character in the game completes the current main task, a "main task change" event is thrown out through the event framework;

[0015] When receiving the "Mainline Task Change" event, the specific execution steps are as follows:

[0016] The game process server automatically clones a copy of the account data for storage; names the account in the format of "_Chapter ID_Mainline Quest Index" and records the current timestamp in the character data;

[0017] If the account data already exists in the local database, it will be overwritten with the latest account data.

[0018] In the above technical solution, for team members, they can automatically collect account data when the main task events of the game change, without the need for user intervention. Specifically: when team members reach certain specific rules (such as changes in the main task), the game server process will automatically clone and collect relevant account data. Using the concept of distributed cluster architecture, machines in the local area network can achieve mutual discovery, mutual access and data sharing through the service discovery mechanism. These data will be used as a source of information for subsequent sharing in team collaboration.

[0019] In some embodiments, team members access account data in other team members' local databases through node IP and port in their respective development environments, specifically:

[0020] Based on the IP and port information provided by the ZooKeeper central registration server, the basic information of all shared accounts in the LAN is queried, including the branch name of the SVN code repository in each machine environment and the key information description of the main task.

[0021] In the above technical solution, team members can conveniently preview and retrieve account data. With the help of key information descriptions of main tasks, they can quickly filter out the required account data.

[0022] In some embodiments, team members access account data in other team members' local databases through node IP and port from their respective development environments, and query and download account data of other team members to the local database. Specifically:

[0023] Based on the node IP and shared account role ID, access the local database of other team members through the HTTP protocol, download the account binary data to the local, and import it into the local database.

[0024] In the above technical solution, based on the node IP, shared account role ID and HTTP protocol, account data can be obtained by simply clicking download, which greatly saves time, improves efficiency and enhances convenience.

[0025] In some embodiments, after importing the local database, the method further includes:

[0026] Generate the latest unique role ID locally, and replace the role ID and account name fields in the downloaded account data with the generated unique role ID;

[0027] If the generated account name already exists locally, the mapping relationship between the account name and the role ID is re-established and the old role data is deleted.

[0028] In the above technical solution, the overwriting of downloaded account data is achieved, and for convenience, the account name is consistent with the role ID.

[0029] In some embodiments, after importing the local database, the method further includes:

[0030] Access the local database through the HTTP protocol, clone the account binary data to the local database, and generate a new role data.

[0031] In the above technical solution, account data is cloned by accessing the local server through the HTTP protocol, cloning the account binary data to the local server, and importing it into the local database to generate a new role data.

[0032] In some embodiments, after importing the local database, the method further includes:

[0033] Use the ProtoBuf protocol to serialize database data into binary format.

[0034] In the above technical solution, the ProtoBuf protocol is used to import and export offline account data. The ProtoBuf protocol is used to serialize the database data into a binary format. The local account data can be exported as a binary file, and the external binary file can be imported into the local database, which is convenient for use across networks or in offline environments.

[0035] According to another aspect of the present invention, a device for collecting, sharing and restoring game account data in a distributed cluster is provided, based on the above method; comprising:

[0036] ZooKeeper module, used to deploy a ZooKeeper central registration server. When the game server process of the team member starts, it registers the node IP and port with the ZooKeeper server, and subscribes to the node IP change event to dynamically monitor the online machine nodes in the team;

[0037] Several local server modules are used to run the game server process in the development environment of each team member. When the preset conditions are met, the game server process will automatically save the phased account data to the local database; and for team members to access the account data in the local database of other team members through the node IP and port from their own development environment, and to query and download the account data of other team members to the local database.

[0038] In the above technical scheme, in order to better use the above method, the present application proposes a device for collecting, sharing and recovering game account data under a distributed cluster. Each module corresponds to each step of the above method. The specific principles have been described above and will not be repeated here.

[0039] According to another aspect of the present invention, a device for collecting, sharing and restoring game account data in a distributed cluster is provided, comprising:

[0040] at least one processor and a memory communicatively coupled to the at least one processor;

[0041] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can perform the above method.

[0042] In the above technical solution, in order to better run and process the method, the above method is stored in a memory, and the stored method is executed by a processor. It should be noted that the principle and effect of each step have been described above and will not be described in detail here.

[0043] According to another aspect of the present invention, a computer-readable storage medium is provided, storing a computer program, wherein the computer program implements the above method when executed by a processor.

[0044] In the above technical solution, in order to better run and use the method, the above method is stored in a computer-readable storage medium, and the above method is implemented using a processor. It should be noted that the principle and effect of each step have been described above and will not be described in detail here. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0046] Figure 1 It is a flow chart of an embodiment of a method for collecting, sharing and restoring game account data in a distributed cluster according to the present invention;

[0047] Figure 2 It is a system framework diagram of an embodiment of a method for collecting, sharing and restoring game account data in a distributed cluster of the present invention;

[0048] Figure 3 It is a structural diagram of an embodiment of a device for collecting, sharing and restoring game account data in a distributed cluster according to the present invention;

[0049] Figure 4 The present invention is a schematic diagram of the local server module structure of an embodiment of a device for collecting, sharing and restoring game account data in a distributed cluster. DETAILED DESCRIPTION

[0050] The present invention will be further described in detail below in conjunction with the accompanying drawings and examples. It is particularly noted that the following examples are only used to illustrate the present invention, but are not intended to limit the scope of the present invention. Similarly, the following examples are only partial embodiments of the present invention rather than all embodiments, and all other embodiments obtained by those of ordinary skill in the art without creative work are within the scope of protection of the present invention.

[0051] The present invention provides a method for collecting, sharing and restoring game account data in a distributed cluster, which can solve at least one technical problem mentioned in the background technology.

[0052] Embodiment 1

[0053] See also Figure 1 , a method for collecting, sharing and restoring game account data in a distributed cluster, the method comprising:

[0054] S1. Deploy a ZooKeeper central registration server. When the game server process of the team member starts, it registers the node IP and port with the ZooKeeper server, and subscribes to the node IP change event to dynamically monitor the online machine nodes in the team.

[0055] In this embodiment, the ZooKeeper central registration server deployment method is as follows: In a local area network environment, deploy a Windows or Linux server that runs 24 hours a day, download it from the official website (https: / / zookeeper.apache.org / releases.html#download), decompress it, modify the configuration file, and then run it.

[0056] S2. The game server process running in the development environment of each team member will automatically save the phased account data to the local database when the preset conditions are met;

[0057] In this embodiment, the game server process running in the development environment of each team member automatically saves the phased account data to the local database when the preset conditions are met. Specifically: when the team member's character in the game completes the current main task, a "main task change" event is thrown out through the event framework; when the "main task change" event is received, the specific execution steps are as follows: the game process server automatically clones a copy of the account data for storage; the account name is named in the format of "_ chapter ID_ main task index", and the current timestamp is recorded in the character data; if the account data already exists in the local database, it is overwritten with the latest account data. For team members, they can automatically collect account data when the main task event of the game changes, and there is no need for user intervention. Specifically: when a team member reaches a certain specific rule (such as a change in the main task), the game server process will automatically clone and collect relevant account data. Using the concept of distributed cluster architecture, machines in the local area network achieve the purpose of mutual discovery, mutual access and data sharing through the service discovery mechanism, and these data will be used as a data source for subsequent sharing in team collaboration.

[0058] S3. Team members access the account data in other team members' local databases through the node IP and port from their respective development environments, and query and download the account data of other team members to the local database.

[0059] In this embodiment, the ZooKeeper central registration server is not responsible for storing account data, but only plays a role of "service discovery". That is, it is only used to register the IP and port of the machine node, and then provide subscription services for the game server process on each machine, without uploading and downloading. The account data is always stored in the database of each team member's computer.

[0060] In this embodiment, team members access account data in other team members' local databases through node IP and port in their respective development environments. Specifically:

[0061] Based on the IP and port information provided by the ZooKeeper central registration server, the basic information of all shared accounts in the LAN is queried, including the branch name of the SVN code repository in each machine environment and the key information description of the main task. Team members can conveniently preview and retrieve account data, and with the help of the key information description of the main task, they can quickly filter out the required account data.

[0062] In this embodiment, the account data of other team members is queried and downloaded to the local database. Specifically, based on the node IP and the shared account role ID, the local database of other team members is accessed through the HTTP protocol, the account binary data is downloaded locally, and imported into the local database. Based on the node IP, the shared account role ID and the HTTP protocol, the account data can be obtained by simply clicking to download, which greatly saves time, improves efficiency, and enhances convenience.

[0063] In this embodiment, after importing the local database, the following steps are also included:

[0064] Generate the latest unique role ID locally, and replace the role ID and account name fields in the downloaded account data with the generated unique role ID; if the generated account name already exists locally, re-establish the mapping relationship between the account name and the role ID, and delete the old role data. This solution implements overwriting the downloaded account data, and for convenience, the account name is consistent with the role ID.

[0065] In this embodiment, after importing the local database, it also includes: accessing the local database through the HTTP protocol, cloning the account binary data to the local database, and generating a new role data. This solution implements cloning account data, accessing the local server through the HTTP protocol, cloning the account binary data to the local, and importing it into the local database to generate a new role data.

[0066] In this embodiment, after importing the local database, it also includes: using the ProtoBuf protocol to serialize the database data into a binary format. This solution uses the ProtoBuf protocol to import and export offline account data, and uses the ProtoBuf protocol to serialize the database data into a binary format. The local account data can be exported as a binary file, and the external binary file can also be imported into the local database, which is convenient for use across networks or in offline environments.

[0067] In this embodiment, the method is based on the distributed cluster architecture concept used by each machine node in the local area network. The game server supports local account data collection, sharing, recovery, serialization, import and export and other functions. It can be applied not only to the local area network, but also to cross-network and offline environments, providing extremely convenient account data operation services for the game development team, and improving the convenience and efficiency of using account data in the process of program development and testing. The server in the local area network adopts the microservice architecture concept and deploys ZooKeeper as the central registration server, so that each machine node registers its IP address and port number with ZooKeeper and subscribes to the node change event. . This setting allows nodes to discover and access each other, build an efficient distributed cluster, and realize seamless data sharing. The design of the cluster focuses on high availability and scalability, and has load balancing capabilities, ensuring the stability and reliability of the data sharing platform. When team members meet certain specific rules (such as changes in the main task), the game server process will automatically clone and collect relevant account data. Using the concept of distributed cluster architecture, machines within the local area network can discover, access and share data with each other through a service discovery mechanism. These data will be used as a source of information for subsequent sharing in team collaboration.

[0068] In order to better explain the embodiment of the present invention, the embodiment of the present invention will be described in a system module manner as follows:

[0069] The present invention discloses a method for collecting, sharing and restoring game account data under a distributed cluster. The method refers to that each machine node in a local area network uses the concept of a distributed cluster architecture. The game server supports local account data collection, sharing, recovery, serialization, import and export and other functions. It can be applied not only to a local area network, but also to cross-network and offline environments. It provides extremely convenient account data operation services for game development teams, and improves the convenience and efficiency of using account data during program development and testing.

[0070] See also Figure 2, the account data recovery function is divided into five main modules: account data collection module, account data sharing module, account data management module, account sharing web page module and service discovery module. These five modules are integrated into a single game server process, which can be run in a team collaborative LAN environment, and can also export account data for use in a cross-network or offline environment. The server in the LAN adopts the microservice architecture concept and deploys ZooKeeper as the central registration server, so that each machine node registers its IP address and port number with ZooKeeper, and subscribes to node change events. This setting allows nodes to discover and access each other, build an efficient distributed cluster, and realize seamless data sharing. The cluster is designed with high availability and scalability, and has load balancing capabilities to ensure the stability and reliability of the data sharing platform.

[0071] In this system, the account data of team members in their respective development environments can be collected and classified and stored in the local database according to specific rules (for example, by the game's main task ID). Then, through their respective "account data sharing modules", data preview, search and download services are provided to other team members. Through the service discovery module, each machine node in the LAN can discover, access and share valid and diverse game account data in their respective environments. Team members can quickly download online or import offline the finished accounts run by other members, saving the time of running accounts step by step.

[0072] ② The technical solution of the invention (the technical solution shall be described in combination with the schematic diagram, mainly with a detailed description of the innovative points of the technology and the effects brought about by the innovation, etc.):

[0073] The present invention discloses a method for collecting, sharing and restoring game account data under a distributed cluster. The method refers to that each machine node in a local area network uses the concept of a distributed cluster architecture. The game server supports local account data collection, sharing, recovery, serialization, import and export and other functions. It can be applied not only to a local area network, but also to cross-network and offline environments. It provides extremely convenient account data operation services for game development teams, and improves the convenience and efficiency of using account data during program development and testing.

[0074] The account data recovery function is divided into five main modules: account data collection module, account data sharing module, account data management module, account sharing web page module and service discovery module. These five modules are integrated into a single game server process, which can be run in a local area network environment for team collaboration, and can also export account data for use in a cross-network or offline environment.

[0075] The servers in the LAN adopt the concept of microservice architecture and deploy ZooKeeper as the central registration server, so that each machine node registers its IP address and port number with ZooKeeper and subscribes to node change events. This setting allows nodes to discover and access each other, build an efficient distributed cluster, and achieve seamless data sharing. The cluster design focuses on high availability, scalability, and load balancing capabilities, ensuring the stability and reliability of the data sharing platform.

[0076] In this system, the account data of team members in their respective development environments can be collected and classified and stored in the local database according to specific rules (for example, according to the main task ID of the game). Then, through their respective "account data sharing modules", data preview, search and download services are provided to other team members. Through the service discovery module, the machine nodes of the local area network can discover, access and share valid and diverse game account data in their respective environments. Team members can quickly download online or import offline the finished accounts run by other members, saving the time of running accounts step by step. Under this framework, the corresponding functions of each module are as follows:

[0077] 1. Account data collection module, which is responsible for collecting and saving account data in the local environment, collects and classifies account data according to specific rules, such as the game's main task ID, and stores it in the local database. The specific steps are as follows:

[0078] (1) Sending a main task change event. When a character in the game completes the current main task, a "main task change" event will be thrown out through the event framework.

[0079] (2) Listen for mainline task change events. When a "mainline task change" event is received, the specific execution steps are as follows:

[0080] ① Clone a copy of the account data for storage, name the account in the format of "_Chapter ID_Mainline Task Index", and record the current timestamp in the character data to facilitate displaying the generation time of the account data to users through the "Account Sharing Web Page Module".

[0081] ② If the account name already exists in the database, it will be overwritten with the current newer account data to ensure that one account name is mapped to only one copy of data, with the last copy of data taking precedence.

[0082] 2. The account data sharing module is responsible for providing other team members with locally collected shared account data. Only account data named in the format of "_Chapter ID_Mainline Task Index" is allowed to appear in the shared list. The specific steps are as follows:

[0083] (1) Provides an HTTP interface for "Get Shared Account List" to return basic information of all shared accounts in the local environment, including: channel ID, account name, role name, role ID, role level, role creation time, role last login time, role last logout time, account data generation time, main task ID, combat power and other fields. Fields can be expanded according to needs.

[0084] (2) Provides an HTTP interface for "getting code branch name" to return the branch name of the SVN code repository in the local environment, making it easier for other team members to know that the account data comes from a certain code branch version.

[0085] (3) Provide an HTTP interface for "Getting Mainline Mission Information" to return the core key information corresponding to the mainline mission ID. The key information can more easily convey what game data the corresponding account data has unlocked, making it easier for other team members to find matching accounts through text descriptions.

[0086] (4) Provide "Download Account Role Data" and "Clone Account Role Data" HTTP interfaces, and return all binary data information of the account.

[0087] 3. Account data management module, responsible for various management operations of account data, such as downloading other party's account data, cloning local account data, and importing and exporting offline account data.

[0088] (1) Enter the IP address and shared account role ID, access the "Download Account Role Data" interface of other team members through the HTTP protocol, download the account binary data to the local computer, and import it into the local database.

[0089] (2) Support overwriting download account data

[0090] ① Generate the latest unique role ID locally, and replace the role ID and account name fields in the downloaded account data with the newly generated role ID. For convenience, the account name is consistent with the role ID.

[0091] ② If the generated account name already exists locally, the mapping relationship between the account name and the role ID is re-established, and the old role data is deleted to achieve data overwriting.

[0092] (3) Supports cloning of account data, accessing the local server through the HTTP protocol, cloning the account binary data to the local, and importing it into the local database to generate a new role data.

[0093] (4) Supports importing and exporting offline account data. The database data is serialized into binary format using the ProtoBuf protocol. Local account data can be exported as binary files, and external binary files can be imported into the local database, making it convenient to use across networks or in offline environments.

[0094] 4. The account sharing web page module is responsible for providing a web page to facilitate team members to preview and search for account sharing information and download account data in a visual way.

[0095] (1) The web page obtains the accessible LAN machine node IP address and port number and other information through the "service discovery" module, and accesses the "account data sharing module" data of each team member through the HTTP protocol, thereby displaying their externally shared account data and displaying the basic information of the account on the web page. The basic information includes: channel ID, account name, role name, role ID, role level, role creation time, role last login time, role last logout time, account data generation time, main task ID, combat power and other fields.

[0096] (2) The web page provides a text filtering function, which allows you to enter text information to quickly find matching account data entries.

[0097] (3) The web page provides a download button. Find the account entry you need and click "Download". By calling your own "Account Data Management Module", the other party's account data will be downloaded to the local computer. After the download is successful, the account name will be automatically copied to the clipboard for direct pasting into the game client input window.

[0098] (4) The web page provides a clone button. Find your local account entry and click "Clone". By calling your own "Account Data Management Module", a copy of your local account data will be cloned and stored in the local database. After the cloning is successful, the account name will be automatically copied to the clipboard for direct pasting into the game client input window.

[0099] 5. The service discovery module is responsible for interacting with the central registration server ZooKeeper to realize registration, search and management services.

[0100] (1) Register your own information with ZooKeeper, such as IP address, port number, etc.

[0101] (2) Subscribe to ZooKeeper service change events, such as service addition, deletion, and modification events, and promptly update the machine node information cached by the local server.

[0102] (3) Provide an interface for accessing accessible machine nodes, so that the "Account Sharing Web Page Module" can display the account sharing data list and ensure the validity of the page data.

[0103] Based on the above, we can see that the advantages of this case are as follows:

[0104] 1. Automatically collect account data: For team members, they can automatically collect account data when the main task events of the game change, without the need for user intervention. Using the concept of distributed cluster architecture, machines in the local area network can achieve mutual discovery, mutual access and data sharing through the service discovery mechanism. These data will be used as a source of information for subsequent sharing in team collaboration.

[0105] 2. Quickly download finished product accounts: Team members can conveniently preview and retrieve account data. With the help of the key information description of the main task, they can quickly filter out the required account data. At the same time, they can also download a variety of finished product accounts. Simply click to download to obtain account data, which greatly saves time, improves efficiency, and enhances convenience. Account data can also be imported and exported across networks or offline environments. According to personal needs, they can flexibly download each other's account data or finished product accounts, which can enable the characters in the local environment to quickly reach a certain state, thereby greatly improving the development efficiency of R&D personnel.

[0106] 3. Controllable development costs: The development costs of this solution are completely controllable. Once the development is completed, there is no need to adjust it again, and it can be used stably and sustainably, further saving development costs.

[0107] 4. Distributed clusters have high scalability: Team members often turn on and off the computer, or turn on and off the game server, which may cause the other party's server to be inaccessible. Using the service discovery ZooKeeper mechanism, it is possible to dynamically increase and decrease nodes and improve the real-time performance of the account sharing page. Compared with the existing technology, data can only be saved in a single game server, and data sharing of multiple machine nodes in the local area network cannot be achieved. This patent adds a distributed cluster architecture, which can improve the scalability and robustness of data sharing in the local area network.

[0108] 5. Improve the convenience of sharing account data among servers in different LANs: When server clusters built on different LANs cannot communicate with each other, the account data can be exported from the first environment as a binary file, and then shared to the second environment through file sharing, and the binary file can be imported into the server to achieve cross-network sharing of account data. The cross-network and offline import and export functions are added, and are no longer limited to a single LAN. Compared with retrieving files, this patent provides options in multiple environments, and can be used to share account data within a LAN, across LANs, and in offline environments, which is more universal.

[0109] Embodiment 2

[0110] See also Figure 3 , a device for collecting, sharing and restoring game account data in a distributed cluster, based on the above method; including connected:

[0111] ZooKeeper module, used to deploy a ZooKeeper central registration server. When the game server process of the team member starts, it registers the node IP and port with the ZooKeeper server, and subscribes to the node IP change event to dynamically monitor the online machine nodes in the team;

[0112] Several local server modules are used to run the game server process in the development environment of each team member. When the preset conditions are met, the game server process will automatically save the phased account data to the local database; and for team members to access the account data in other team members' local databases through the node IP and port from their own development environment, and query and download other team members' account data to the local database. Please refer to Figure 4 , the local server module includes the following sub-modules:

[0113] 1. Account data collection module, which is responsible for collecting and saving account data in the local environment, collects and classifies account data according to specific rules, such as the game's main task ID, and stores it in the local database. The specific steps are as follows:

[0114] (1) Sending a main task change event. When a character in the game completes the current main task, a "main task change" event will be thrown out through the event framework.

[0115] (2) Listen for mainline task change events. When a "mainline task change" event is received, the specific execution steps are as follows:

[0116] ① Clone a copy of the account data for storage, name the account in the format of "_Chapter ID_Mainline Task Index", and record the current timestamp in the character data to facilitate displaying the generation time of the account data to users through the "Account Sharing Web Page Module".

[0117] ② If the account name already exists in the database, it will be overwritten with the current newer account data to ensure that one account name is mapped to only one copy of data, with the last copy of data taking precedence.

[0118] 2. The account data sharing module is responsible for providing other team members with locally collected shared account data. Only account data named in the format of "_Chapter ID_Mainline Task Index" is allowed to appear in the shared list. The specific steps are as follows:

[0119] (1) Provides an HTTP interface for "Get Shared Account List" to return basic information of all shared accounts in the local environment, including: channel ID, account name, role name, role ID, role level, role creation time, role last login time, role last logout time, account data generation time, main task ID, combat power and other fields. Fields can be expanded according to needs.

[0120] (2) Provides an HTTP interface for "getting code branch name" to return the branch name of the SVN code repository in the local environment, making it easier for other team members to know that the account data comes from a certain code branch version.

[0121] (3) Provide an HTTP interface for "Getting Mainline Mission Information" to return the core key information corresponding to the mainline mission ID. The key information can more easily convey what game data the corresponding account data has unlocked, making it easier for other team members to find matching accounts through text descriptions.

[0122] (4) Provide "Download Account Role Data" and "Clone Account Role Data" HTTP interfaces, and return all binary data information of the account.

[0123] 3. Account data management module, responsible for various management operations of account data, such as downloading other party's account data, cloning local account data, and importing and exporting offline account data.

[0124] (1) Enter the IP address and shared account role ID, access the "Download Account Role Data" interface of other team members through the HTTP protocol, download the account binary data to the local computer, and import it into the local database.

[0125] (2) Support overwriting download account data

[0126] ① Generate the latest unique role ID locally, and replace the role ID and account name fields in the downloaded account data with the newly generated role ID. For convenience, the account name is consistent with the role ID.

[0127] ② If the generated account name already exists locally, the mapping relationship between the account name and the role ID is re-established, and the old role data is deleted to achieve data overwriting.

[0128] (3) Supports cloning of account data, accessing the local server through the HTTP protocol, cloning the account binary data to the local, and importing it into the local database to generate a new role data.

[0129] (4) Supports importing and exporting offline account data. The database data is serialized into binary format using the ProtoBuf protocol. Local account data can be exported as binary files, and external binary files can be imported into the local database, making it convenient to use across networks or in offline environments.

[0130] 4. The account sharing web page module is responsible for providing a web page to facilitate team members to preview and search for account sharing information and download account data in a visual way.

[0131] (1) The web page obtains the accessible LAN machine node IP address and port number and other information through the "service discovery" module, and accesses the "account data sharing module" data of each team member through the HTTP protocol, thereby displaying their externally shared account data and displaying the basic information of the account on the web page. The basic information includes: channel ID, account name, role name, role ID, role level, role creation time, role last login time, role last logout time, account data generation time, main task ID, combat power and other fields.

[0132] (2) The web page provides a text filtering function, which allows you to enter text information to quickly find matching account data entries.

[0133] (3) The web page provides a download button. Find the account entry you need and click "Download". By calling your own "Account Data Management Module", the other party's account data will be downloaded to the local computer. After the download is successful, the account name will be automatically copied to the clipboard for direct pasting into the game client input window.

[0134] (4) The web page provides a clone button. Find your local account entry and click "Clone". By calling your own "Account Data Management Module", a copy of your local account data will be cloned and stored in the local database. After the cloning is successful, the account name will be automatically copied to the clipboard for direct pasting into the game client input window.

[0135] 5. The service discovery module is responsible for interacting with the central registration server ZooKeeper to realize registration, search and management services.

[0136] (1) Register your own information with ZooKeeper, such as IP address, port number, etc.

[0137] (2) Subscribe to ZooKeeper service change events, such as service addition, deletion, and modification events, and promptly update the machine node information cached by the local server.

[0138] (3) Provide an interface for accessing accessible machine nodes, so that the "Account Sharing Web Page Module" can display the account sharing data list and ensure the validity of the page data.

[0139] In this embodiment, in order to better use the method described in one of the embodiments, the present application proposes a device for collecting, sharing and recovering game account data under a distributed cluster. Each module corresponds to each step of the above method. The specific principles have been described above and will not be repeated here.

[0140] Embodiment 3

[0141] A device for collecting, sharing and restoring game account data in a distributed cluster, comprising:

[0142] at least one processor and a memory communicatively coupled to the at least one processor;

[0143] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described in one of the embodiments.

[0144] In this embodiment, in order to better run and process the method described in one of the embodiments, the above method is stored in a memory, and a processor is used to execute the stored method. It should be noted that the principle and effect of each step have been described above and will not be described in detail here.

[0145] Embodiment 4

[0146] A computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the method described in one of the embodiments is implemented.

[0147] In this embodiment, in order to better run and use the method described in one of the embodiments, the method is stored in a computer-readable storage medium and implemented by a processor. It should be noted that the principle and effect of each step have been described above and will not be described in detail here.

[0148] The above descriptions are only some embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Any equivalent device or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for collecting, sharing and restoring game account data in a distributed cluster, characterized in that: The method comprises: Deploy a ZooKeeper central registration server. When the game server process of the team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to the node IP change event to dynamically monitor the online machine nodes in the team. The game server process running in the development environment of each team member will automatically save the phased account data to the local database when the preset conditions are met; Team members access the account data in other team members' local databases through node IP and port in their respective development environments, and query and download other team members' account data to the local database.

2. A method for collecting, sharing and restoring game account data in a distributed cluster as claimed in claim 1, characterized in that: The game server process running in the development environment of each team member will automatically save the phased account data to the local database when the preset conditions are met. Specifically: When a team member's character in the game completes the current main task, a "main task change" event is thrown out through the event framework; When receiving the "Mainline Task Change" event, the specific execution steps are as follows: The game process server automatically clones a copy of the account data for storage; names the account in the format of "_Chapter ID_Mainline Quest Index" and records the current timestamp in the character data; If the account data already exists in the local database, it will be overwritten with the latest account data.

3. The method for collecting, sharing and restoring game account data in a distributed cluster as claimed in claim 1, characterized in that: Team members access account data in other team members' local databases through node IP and port in their respective development environments. Specifically: Based on the IP and port information provided by the ZooKeeper central registration server, the basic information of all shared accounts in the LAN is queried, including the branch name of the SVN code repository in each machine environment and the key information description of the main task.

4. A method for collecting, sharing and restoring game account data in a distributed cluster as claimed in claim 3, characterized in that: Query and download other team members' account data to the local database, specifically: Based on the node IP and shared account role ID, access the local database of other team members through the HTTP protocol, download the account binary data to the local, and import it into the local database.

5. A method for collecting, sharing and restoring game account data in a distributed cluster as claimed in claim 4, characterized in that: After importing the local database, it also includes: Generate the latest unique role ID locally, and replace the role ID and account name fields in the downloaded account data with the generated unique role ID; If the generated account name already exists locally, the mapping relationship between the account name and the role ID is re-established and the old role data is deleted.

6. A method for collecting, sharing and restoring game account data in a distributed cluster as claimed in claim 4, characterized in that: After importing the local database, it also includes: Access the local database through the HTTP protocol, clone the account binary data to the local database, and generate a new role data.

7. The method for collecting, sharing and restoring game account data in a distributed cluster as claimed in claim 1, characterized in that: The method further comprises: Use the ProtoBuf protocol to serialize the data in the local database into binary format.

8. A device for collecting, sharing and restoring game account data in a distributed cluster, characterized in that: A method according to any one of claims 1 to 7; comprising connecting: The ZooKeeper module is used to deploy a ZooKeeper central registration server. When the game server process of the team member starts, it registers the node IP and port with the ZooKeeper server, and subscribes to the node IP change event to dynamically monitor the online machine nodes in the team; Several local server modules are used to run the game server process in the development environment of each team member. When the preset conditions are met, the game server process will automatically save the phased account data to the local database; and for team members to access the account data in the local database of other team members through the node IP and port from their own development environment, and to query and download the account data of other team members to the local database.

9. A device for collecting, sharing and restoring game account data in a distributed cluster, characterized in that: include: at least one processor and a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method as claimed in any one of claims 1 to 7.

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

Images