Implementation method and architecture of distributed system based on distributed embedded storage engine

Abstract

This application provides a method and architecture for implementing a distributed system based on a distributed embedded storage engine. In this method, priority service nodes are assigned to players using the distributed embedded storage engine as a foundation. This method not only overcomes the single-node approach used by stateful service architectures for certain service functions, but also enables the entire distributed system to inherit the high concurrency and high availability advantages of traditional stateless service architectures, while also solving the cumbersome distributed transaction development issues inherent in stateless service architectures.

Description

Technical Field

[0001] The present application relates to the technical field of distributed systems, and in particular to an implementation method and architecture of a distributed system based on a distributed embedded storage engine. Background Art

[0002] The business logic of games is often characterized by high frequency and strong coupling. Using the traditional internet-based stateless server architecture, whether it's a MySQL cluster, a TiDB distributed database, or a Redis cache database, none of them can meet the high-performance business processing requirements at a low cost. Furthermore, mainstream cache databases don't support distributed transactions, requiring developers to resolve distributed transactional issues themselves, which places a heavy development burden. While stateful service architectures offer good performance, they struggle to achieve real-time persistence, and unexpected server crashes can lead to data loss. When dealing with businesses involving multiple data points, such as social media, stateful service frameworks often lack distributed transactional support. For some business modules, a single-node, unified solution is often preferred, which can easily create a single point of failure and limit the system's high concurrency and high availability capabilities. Summary of the Invention

[0003] In view of this, an embodiment of the present application provides an implementation method and architecture of a distributed system based on a distributed embedded storage engine to solve the technical defects existing in the prior art.

[0004] According to a first aspect of an embodiment of the present application, a method for implementing a distributed system based on a distributed embedded storage engine is provided, including:

[0005] Allocating a first priority service node to the first player according to a login request of the first player;

[0006] executing, on the first priority service node based on the storage engine, a data locality service actor request sent by the first player;

[0007] After the request is successfully executed, a success message is returned to the first player.

[0008] According to a second aspect of an embodiment of the present application, a distributed system architecture based on a distributed embedded storage engine is provided, including:

[0009] A plurality of distributed service nodes are configured to provide a priority service node according to the allocation result of the first player's login request; and execute other data locality service actor requests of the first player on the priority service node based on the storage engine;

[0010] Multiple consistent storage servers are used to obtain and return target data according to the needs of distributed business nodes and manage the status of the target data.

[0011] According to a third aspect of an embodiment of the present application, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and the computer program is executed by a processor to implement a method for a distributed system based on a distributed embedded storage engine.

[0012] In an embodiment of the present application, each business node of the distributed system is embedded with an embedded database. When processing business logic, the business node can obtain data directly from the embedded database in all cases except for the first access which requires obtaining data from the consistency storage server. This avoids IO overhead and data delay between servers and greatly improves performance. At the same time, under the data status management of the consistency storage server, when data competition and modification occur between multiple business nodes, there will be no data consistency issues between the business nodes.

[0013] Furthermore, by using a distributed embedded storage engine that achieves data consistency as its foundation, it overcomes the single-node approach used by stateful service architectures for certain business functions, allowing the entire distributed system to inherit the high concurrency and high availability advantages of traditional stateless service architectures while simultaneously resolving the cumbersome distributed transaction development issues inherent in stateless service architectures. The data consistency characteristics of this storage engine are highly compatible with the data locality characteristics of most gaming system functions. By assigning a priority business node to each business entity and routing related requests to that node as much as possible for execution, the target data in most requests is matched to the local database, resolving the issue of poor stateless server efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 It is a structural block diagram of a traditional distributed system in the prior art;

[0015] Figure 2 This is a working diagram of a distributed embedded storage engine that achieves data consistency, provided by an embodiment of the present application;

[0016] Figure 3 This is a schematic diagram of the architecture of a distributed system based on a distributed embedded storage engine provided in an embodiment of the present application;

[0017] Figure 4 This is a schematic diagram of the structure of an embedded database on a service node provided in an embodiment of the present application;

[0018] Figure 5 This is a schematic diagram of the structure of a service node based on a distributed embedded storage engine provided in an embodiment of the present application;

[0019] Figure 6 Schematic diagram of the structure of a consistent storage server based on a distributed embedded storage engine provided in an embodiment of the present application; DETAILED DESCRIPTION

[0020] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of the present application. Therefore, the present application is not limited to the specific implementations disclosed below.

[0021] The terms used in one or more embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of the present application. The singular forms "a", "the" and "the" used in one or more embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of the present application refers to and includes any or all possible combinations of one or more associated listed items.

[0022] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of the present application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of the present application, first may also be referred to as second, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "in response to determining."

[0023] In the existing technology, in order to achieve high concurrency and high availability systems, a stateless server design architecture is generally adopted, such as Figure 1 As shown, this traditional distributed system consists of multiple stateless business servers and distributed databases. This architecture supports only remote access, resulting in poor average performance and prohibitively high hardware costs for medium- to large-scale projects. While caching solutions like Redis can be incorporated into the architecture, ensuring the correctness of distributed transaction processing is difficult, and using distributed locks places a significant mental burden on developers.

[0024] Another existing technology uses a stateful server design architecture. Although performance is improved, its disadvantages are that the state of system functions is maintained by developers, there is a lack of support for distributed transactions and real-time data persistence, and the server is not rigorous enough when scaling horizontally, making it difficult to balance high availability, data reliability, and consistency.

[0025] In this application, in order to solve the above problems, an implementation method and architecture of a distributed system based on a distributed embedded storage engine are provided, which will be described in detail one by one in the following embodiments.

[0026] Figure 2 A working diagram of a distributed embedded storage engine that achieves data consistency in an embodiment of the present application is shown. The storage engine is implemented based on multiple business nodes and multiple consistent storage servers.

[0027] When the business logic of the business node needs to access data, a data access request is initiated to the embedded database of the business node. Specifically, the embedded database includes a consistent storage client node.

[0028] In a specific implementation, if the target data exists in the embedded database, the target data is directly returned to the business logic.

[0029] In this embodiment, the database is embedded in the business node, and the business logic can directly obtain data from the embedded database without accessing other remote data servers, avoiding IO overhead, greatly improving performance, and eliminating additional delays in data queries.

[0030] In another specific embodiment, if the target data does not exist in the embedded database, the first service node initiates a request to the consistency storage server to occupy the target data. The first service node is any service node in the distributed system. For example, when the service logic is first executed, the target data may not yet exist in the embedded database of the first service node.

[0031] Furthermore, the data occupation request includes a data sharing right request or a data exclusivity right request.

[0032] The consistent storage server stores a data status record S, which stores the occupation status information of the data. The occupation status information includes the occupation right type of the data and which business nodes currently occupy the data.

[0033] Furthermore, when the target data is not occupied by any business node, the consistency storage server updates the data status record S: the target data is occupied by the first business node; and returns the target data and the data occupation right information obtained according to the target data occupation request - data sharing rights or data exclusive rights, to the first business node.

[0034] In this embodiment, the target data may exist on the consistent storage server, or may be obtained by the consistent storage server through a request from other servers, which is not particularly limited here.

[0035] After the first business node receives the target data and status information of the current target data returned by the consistency storage server, it stores the target data in the embedded database and updates its own data status record C. That is, the business node also has a data status record. The data status record C of the business node saves the data status of the target data obtained by the current business node.

[0036] In another specific embodiment, when the target data occupation request initiated by the first business node is a data sharing right request, and the target data is currently occupied by other business nodes, the consistency storage server updates the data status record S after receiving the request: adds the first business node to the target data sharing right list; and returns the target data and the target data occupation right information - data sharing rights to the first business node.

[0037] After receiving the target data and the status information of the current target data returned by the consistency storage server, the first service node stores the target data in the embedded database, updates its own data status record C, and writes the occupation right information of the target data, namely, the data sharing right, into it.

[0038] In another specific embodiment, when the target data occupation request initiated by the first business node is a data sharing right request, and the target data is currently occupied by other business nodes with data exclusive rights, the consistency storage server clears the data exclusive rights record in the data status record S and sends a notification to other business nodes to reduce the possession of the target data to data sharing rights, and then adds the first business node and other business nodes to the sharing rights list of the target data.

[0039] After receiving the notification, other business nodes update their own data status record C and downgrade the target data's occupancy right information from exclusive right to shared right.

[0040] After receiving the target data and the status information of the current target data returned by the consistency storage server, the first service node stores the target data in the embedded database, updates its own data status record C, and writes the occupation right information of the target data, namely, the data sharing right, into it.

[0041] In another specific embodiment, when the target data occupation request initiated by the first business node is a data exclusivity request, at this time, regardless of whether the target data is occupied by other business nodes with data sharing rights or data exclusivity, the consistency storage server will send a notification to other business nodes to mark the target data as invalid, and update the data status record S: the target data is only occupied by the first business node with data exclusivity.

[0042] After receiving the notification, other business nodes update their own data status records C and set the status of the target data to invalid.

[0043] After receiving the target data and the status information of the current target data returned by the consistency storage server, the first service node stores the target data in the embedded database, updates its own data status record C, and writes the occupancy information of the target data - data exclusivity - into it.

[0044] Furthermore, when the first service node modifies the target data, it requests the consistency storage server to obtain the exclusive right of the target data.

[0045] In one possible implementation, when a first service node requests target data from an embedded database, it finds that the target data exists but has been marked as invalid. This occurs because other service nodes in the distributed system need to modify the target data and have requested exclusive data rights from the consistency storage server.

[0046] In this case, the first business node sends a request to the consistency storage server to occupy the target data. After receiving the request, the consistency server queries the data status record S to determine whether the target data is exclusively owned by a certain business node. The consistency server then retrieves the valid target data from the business node that has exclusive rights to the target data and returns it to the first business node. The request to occupy the target data sent by the first business node can be a request for either data sharing rights or exclusive rights. The specific process is described in the previous embodiment and will not be repeated here.

[0047] Those skilled in the art should know that when a consistent storage server pulls target data from a business node that has exclusive rights to the target data, if the target data is in a write lock state, it will wait for the write lock to be released before pulling the data, which will not be elaborated here.

[0048] In another specific implementation, when the first service node executes a distributed transaction and needs to modify the target data, the transaction is executed based on the working mode of the above-mentioned distributed embedded storage engine.

[0049] The first service node includes a distributed transaction processing unit. When the first service node executes a distributed transaction, the distributed transaction processing unit first creates a transaction and then uses the distributed embedded storage engine to request the consistent storage server to obtain the sharing right and / or exclusive right of the target data.

[0050] For example, when executing transaction A, it is necessary to access target data C and modify target data D. If target data C and D exist in the embedded database, the transaction is executed directly, and the data exclusive right is obtained for the target data D that needs to be modified.

[0051] If the target data C and D do not exist in the embedded database or exist in the embedded database but are in an invalid state, the target data is requested from the consistency storage server based on the working mode of the above-mentioned distributed embedded storage engine, which will not be repeated here; among them, the first business node obtains the sharing right of the target data C and the exclusive right of the target data D.

[0052] After a transaction starts executing, when the transaction's operation sequence first accesses a data item in the database table, a corresponding locking operation is performed on the data item. For example, in transaction A, a read lock is added to the target data C, and a write lock is added to the target data D. The object that supports the transaction operation is returned. For example, when the transaction first accesses the target data C and D, the table name of the table where the target data C and D are located is returned.

[0053] During the execution of a transaction, operations on the transaction objects are recorded and a transaction log is generated. For example, when the first service node executes transaction A, the modification process of target data D is recorded in the WAL log and the log is written to the log queue for persistence.

[0054] After the transaction is executed, the changes are submitted to the database on the current business node, the lock on the data item is released, and then the transaction is destroyed.

[0055] In the above embodiment, the data occupancy status of each business node is recorded and managed through a distributed embedded storage engine. For data that is frequently accessed and, in most cases, does not require competitive modification, data access performance is significantly improved while also meeting data consistency requirements. Moreover, through this engine, when a transaction is executed, in most cases, the required data can be directly accessed locally, which is far superior to the performance of traditional distributed database remote access. Because the ownership of the data accessed by the transaction layer is local, distributed transactions can be completed without coordination with other nodes, that is, transactions can be completed independently without a transaction coordination node, which greatly reduces the cost of transaction execution compared to traditional distributed transactions. In the rare case that no data is hit locally, distributed transaction processing can also be achieved through the engine's data storage layer.

[0056] For data changes caused by transaction execution, since traditional transaction coordination points are not required, the transaction execution node itself can submit the change log, achieving real-time data persistence at a low cost.

[0057] Through the above technical means, the distributed transaction processing method based on this engine maintains the execution efficiency of traditional game servers while achieving the high concurrency, high availability, and reliable data persistence characteristics similar to the stateless servers of the traditional Internet.

[0058] In another specific embodiment, based on the distributed embedded storage engine and distributed transaction processing method provided in the embodiments of this application, this application also provides a method for implementing a distributed system based on a distributed embedded storage engine. Specifically, this method is used to implement the system functions of games in large and medium-sized game projects. The system functions of a game are the basic logic modules of the game. The basic logic modules do not directly participate in the core gameplay logic of the game, but record key numerical values, strategies, player relationships, and other aspects of data; for example, systems such as friends, guilds, equipment, and achievements are all system functions, and the corresponding combat system is classified as a gameplay function module.

[0059] The implementation method of the distributed system specifically includes:

[0060] S100: Allocate a first priority service node to the first player according to a login request of the first player.

[0061] Specifically, after receiving a player's login request, unlike the working method of the stateless architecture, the solution in the embodiment of the present application does not randomly assign a business node based on a load balancing situation. Instead, it assigns a priority business node to the request. In subsequent processing, this first priority business node will be used first to handle other basic business logic requests sent by the same player. In the basic logic business of the game, most of the player's requests have data locality and are only related to their own business logic, such as daily check-in, backpack props update, etc. Using a priority business node has better processing efficiency.

[0062] Furthermore, when the first priority service node fails or the service node is horizontally expanded to add a new service node, the priority service node is reassigned to the player.

[0063] Furthermore, priority business nodes are assigned to players based on the consistent hashing algorithm.

[0064] S200: Execute other data locality business actor requests sent by the player based on the above storage engine on the first priority business node.

[0065] In this implementation, actor requests include both regular business processing requests and transactions consisting of multiple operation sequences. When processing actor requests, the priority service node executes the corresponding transaction using the transaction processing method described above. Within the transaction, the node accesses the data involved in the request, such as the player's inventory data, the character's team data, the character's guild data, or data related to interactions with other players. The specific process is not detailed here.

[0066] Furthermore, in traditional stateful service architectures, due to the need to ensure server performance, requests are usually quickly responded to and modifications are completed in memory, without persisting the modified data in real time. The embodiments of the present application implement incremental logging of business data on business nodes, thereby achieving real-time persistence. When business nodes execute business functions, any modification operations on data items in the embedded database will be recorded in the incremental log, thereby achieving real-time data persistence through the incremental log, ensuring that the data submitted by players will not be lost.

[0067] S300: After the request is successfully executed, a success message is returned to the player and the transaction ends.

[0068] In the embodiment of the above-mentioned distributed system implementation method, a distributed embedded storage engine with data consistency is used as the foundation, overcoming the single-node solution used by stateful service architectures for certain business functions. This allows the entire distributed system to inherit the high concurrency and high availability advantages of traditional stateless service architectures while solving the cumbersome distributed transaction development issues of stateless service architectures. The data consistency characteristics of this storage engine are highly compatible with the data locality characteristics of most gaming system functions. By assigning a priority business node to each business entity and routing related requests to this priority business node as much as possible for execution, the target data in most requests can be found in the local database, solving the problem of poor efficiency of stateless servers.

[0069] According to the description of the implementation method of the distributed system based on the distributed embedded storage engine, the present application also provides an implementation architecture of the distributed system, such as Figure 3 As shown, the architecture includes:

[0070] The allocation node is used to allocate the first priority business node to the first client based on the first client's login request. Unlike the working mode of the stateless architecture, the allocation node does not randomly allocate a business node based on a load balancing situation. Instead, it allocates a priority business node to the request. In subsequent processing, the first priority business node will be used first to handle other basic business logic requests sent by the same player.

[0071] Multiple distributed service nodes are used to provide priority service nodes according to the allocation results of player login requests; and execute other data locality service actor requests of the same player on the priority service nodes based on the storage engine;

[0072] Multiple consistent storage servers are used to obtain and return target data according to the needs of distributed business nodes and manage the status of the target data.

[0073] Furthermore, each business node includes, for example Figure 5 As shown:

[0074] A data status recording unit is used to store the occupancy status of business data on the current business node;

[0075] Embedded database: This database includes:

[0076] Consistent storage client nodes, used to store business data;

[0077] Distributed transaction processing unit, used to execute transactions according to business logic and modify target data;

[0078] A logging unit, used to incrementally record operations that modify data;

[0079] a data requesting unit, configured to initiate a target data occupation request to the consistency storage server when the target data does not exist in the consistency storage client node or the occupation state of the target data is invalid;

[0080] The data receiving unit is used to receive the target data and the occupancy status information of the target data returned by the consistency storage server; the data receiving unit also sends the target data to the consistency storage client node, and sends the occupancy status information of the received target data to the data status recording unit.

[0081] Further, such as Figure 6 As shown, each consistent storage server also includes:

[0082] A data acquisition unit, configured to acquire target data according to a data occupation request sent by a distributed service node device;

[0083] A data status recording unit is used to store the current occupancy status of business data;

[0084] A data status updating unit, configured to update a data status record in its own data status recording unit according to a target data occupation request sent by a distributed service node;

[0085] A data status notification unit, configured to notify other service nodes to update their respective data status records according to the target data occupation request;

[0086] The data sending unit is used to return the acquired target data and the occupation status information of the target data to the service node that sent the data occupation request.

[0087] According to the description of the embodiment of the implementation method of the distributed system based on the distributed embedded storage engine mentioned above, the present application also provides a computer-readable storage medium, which stores computer instructions, which, when executed by a processor, implement the steps of the implementation method of the distributed system based on the distributed embedded storage engine as described above.

[0088] The above is a schematic diagram of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the method for implementing a distributed system based on a distributed embedded storage engine described above share the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the method for implementing a distributed system based on a distributed embedded storage engine described above.

[0089] The foregoing description describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0090] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0091] It should be noted that for the aforementioned method embodiments, for ease of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0092] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0093] The preferred embodiments of the present application disclosed above are intended only to help illustrate the present application. The optional embodiments do not describe all details in detail, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of this application. This application selects and describes these embodiments in detail in order to better explain the principles and practical applications of this application, so that those skilled in the art can better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.

Claims

1. A method for implementing a distributed system based on a distributed embedded storage engine, characterized in that: include: allocating a first priority service node to a first player according to a login request of the first player; Executing the data locality service actor request sent by the first player on the first priority service node based on the distributed embedded storage engine, including: if the target data in the actor request exists on the consistency storage client node of the first priority service node, directly returning the data; if the target data in the actor request does not exist on the consistency storage client node of the first priority service node or the target data is in an invalid state, requesting the target data from the consistency storage server; the data locality service is a service related only to the service logic of the first priority service node; The distributed embedded storage engine is implemented based on multiple business nodes and multiple consistent storage servers; the business node includes an embedded database, and the consistent storage client node is a node in the embedded database for storing business data; After the request is successfully executed, a success message is returned to the first player.

2. The method according to claim 1, executing the data locality service actor request of the first player according to the storage engine on the first priority service node further comprises: If the actor request contains a transaction, for the target data that needs to be modified in the transaction, the distributed transaction processing unit of the first priority service node requests the consistency storage server to obtain exclusive rights to the target data; The consistency storage server manages the occupancy status of the target data.

3. The method according to claim 2, wherein: Acquiring exclusive rights to target data also includes: When the transaction operation sequence first accesses the data item in the consistent storage client node on the first priority service node, the corresponding locking operation is performed on the data item; the operation sequence is executed, and when the transaction is completed, the modification is committed and the lock is released.

4. The method according to claim 1, wherein If the target data is in an invalid state, the request to the consistency storage server to obtain the target data further includes: According to the request, the consistency storage server obtains the target data from the service node having the exclusive right to the target data and returns the target data to the first priority service node.

5. The method according to claim 1, further comprising: When the first-priority business node executes an actor request, any modification operations on the data items in the embedded database of the first-priority business node will be recorded in the incremental log to achieve data persistence.

6. A distributed system based on a distributed embedded storage engine, comprising: an allocation node, configured to allocate a first priority service node to the first client according to a login request of the first client; A plurality of distributed service nodes, configured to provide a priority service node according to the allocation result of the first player login request; Executing other data locality service actor requests of the first player on the priority service node based on the storage engine, including: if the target data in the actor request exists on the consistency storage client node of the first priority service node, directly returning the data; if the target data in the actor request does not exist on the consistency storage client node of the first priority service node or the target data is in an invalid state, requesting the target data from the consistency storage server; the data locality service is a service related only to the service logic of the first priority service node; Multiple consistent storage servers are used to obtain and return target data based on the needs of distributed business nodes and manage the status of the target data; The distributed embedded storage engine is implemented based on multiple distributed business nodes and multiple consistent storage servers. The multiple distributed business nodes include an embedded database; the consistent storage client node is a node in the embedded database for storing business data.

7. The distributed system according to claim 6, wherein the distributed service node comprises: A data status recording unit is used to store the occupancy status of business data on the current business node; Embedded database: The database includes: Consistent storage client nodes, used to store business data; Distributed transaction processing unit, used to execute transactions according to business logic and modify target data; Logging unit, used to incrementally record operations that modify data; a data requesting unit, configured to initiate a target data occupation request to the consistency storage server when the target data does not exist in the consistency storage client node or the occupation state of the target data is invalid; The data receiving unit is used to receive the target data and the occupancy status information of the target data returned by the consistency storage server; the data receiving unit also sends the target data to the consistency storage client node, and sends the occupancy status information of the received target data to the data status recording unit.

8. The distributed system according to claim 7, wherein the consistency storage server comprises: A data acquisition unit, configured to acquire target data according to a data occupation request sent by a distributed service node device; A data status recording unit, used to store the current occupancy status of business data; A data status updating unit, configured to update a data status record in its own data status recording unit according to a target data occupation request sent by a distributed service node; A data status notification unit, configured to notify other service nodes to update their respective data status records according to the target data occupation request; The data sending unit is used to return the acquired target data and the occupation status information of the target data to the service node that sent the data occupation request.

9. 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 5 are implemented.

Images