Memory recovery method and device, server and storage medium

Abstract

The application provides a memory recycling method and device, a server and a storage medium. The method comprises the following steps: a recycling node acquires an offset list of a first storage object. The recycling node calculates a deletion ratio of files in the first storage object according to the offset list. A first threshold is preset in the recycling node. When the recycling node determines that the deletion ratio is greater than or equal to the first threshold, the recycling node instructs a management node to create a second storage object. The storage nodes included in the second storage object are located in the same availability zone as the storage nodes in the first storage object. The recycling node determines valid files in the first storage object through the offset list or a file list. The recycling node writes the valid files in the first storage object into the second storage object in an append mode and releases the first storage object. The method improves the idle space recycling efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a memory reclamation method, apparatus, server, and storage medium. Background Technology

[0002] As the system is used, the number of invalid files stored in the system will continue to increase. Garbage collection (GC) nodes can reclaim the storage space occupied by invalid files.

[0003] In existing technology, the reclaimed node can first read the valid files from the old storage node and write them to the memory space of the host where the reclaimed node resides. Then, the reclaimed node can read the valid files and write them to the new storage node.

[0004] However, the recycling speed of recycling nodes is greatly affected by the network during cross-region recycling, resulting in low memory recycling efficiency. Summary of the Invention

[0005] This application provides a memory reclamation method, apparatus, server, and storage medium to solve the technical problem of low memory reclamation efficiency in the prior art.

[0006] Firstly, this application provides a memory reclamation method, including:

[0007] Obtain the offset list of the first storage object, which includes at least the file length of each file written to the first storage object;

[0008] Based on the offset list, calculate the percentage of files deleted from the first storage object;

[0009] When the deletion ratio is greater than or equal to the first threshold, a second storage object is created. The storage space of the second storage object and the storage nodes in the same availability zone are included in the first storage object.

[0010] Based on the offset list of the first storage object, the valid files in the first storage object are appended to the second storage object, and the offset list of the second storage object is obtained.

[0011] Release the first stored object.

[0012] Optionally, based on the offset list, the deletion ratio of files in the first storage object is calculated, specifically including:

[0013] Count the number of files with a length of 0 that have been deleted from the offset list;

[0014] The total number of files written to the first storage object in the offset list;

[0015] The deletion ratio is determined based on the ratio of the number of deletions to the total number.

[0016] Optionally, based on the offset list of the first storage object, the valid files in the first storage object are appended to the second storage object, specifically including:

[0017] The files in the first storage object are remotely copied to the temporary file storage area of ​​the host where the second storage object is located;

[0018] Based on the offset list of the first storage object, determine the file position of the valid file. The valid file is the file whose length in the offset list is not 0.

[0019] Write valid files in batches to the second storage object based on their file locations.

[0020] Optionally, before releasing the first stored object, the method also includes:

[0021] Change the first storage object in the file list to the second storage object.

[0022] Optionally, when the second storage object is not full and the deletion ratio of the third storage object is greater than or equal to the first threshold, the method further includes:

[0023] Write some or all of the files in the third storage object to the second storage object until the second storage object is full.

[0024] Optionally, the method also includes:

[0025] Remove the information corresponding to the target file from the file list based on the target file name;

[0026] Based on the storage object and offset where the target file is located, modify the file length corresponding to the target file in the offset list to 0.

[0027] Optionally, the method also includes:

[0028] Based on the preset erasure coding redundancy ratio, determine the first target number of total storage nodes required.

[0029] Based on the number of availability zones, determine the second target number of storage nodes to be selected from each availability zone;

[0030] Select a second target number of target storage nodes from each availability zone;

[0031] From each target storage node, a storage space is obtained to form a storage object. Secondly, this application provides a memory reclamation device, comprising:

[0032] The acquisition module is used to acquire the offset list of the first storage object, and the offset list includes at least the file length of each file written to the first storage object;

[0033] The processing module is used to calculate the deletion ratio of files in the first storage object based on the offset list; when the deletion ratio is greater than or equal to a first threshold, a second storage object is created, and the storage space of the second storage object and the storage nodes in the same availability zone are included in the first storage object; according to the offset list of the first storage object, the valid files in the first storage object are appended to the second storage object, and the offset list of the second storage object is obtained; the first storage object is released.

[0034] Optionally, the processing module is specifically used for:

[0035] Count the number of files with a length of 0 that have been deleted from the offset list;

[0036] The total number of files written to the first storage object in the offset list;

[0037] The deletion ratio is determined based on the ratio of the number of deletions to the total number.

[0038] Optionally, the processing module is specifically used for:

[0039] The files in the first storage object are remotely copied to the temporary file storage area of ​​the host where the second storage object is located;

[0040] Based on the offset list of the first storage object, determine the file position of the valid file. The valid file is the file whose length in the offset list is not 0.

[0041] Write valid files in batches to the second storage object based on their file locations.

[0042] Optionally, the processing module is also used for:

[0043] Change the first storage object in the file list to the second storage object.

[0044] Optionally, when the second storage object is not full and the deletion ratio of the third storage object is greater than or equal to the first threshold, the processing module is further configured to:

[0045] Write some or all of the files in the third storage object to the second storage object until the second storage object is full.

[0046] Optionally, the processing module is also used for:

[0047] Remove the information corresponding to the target file from the file list based on the target file name;

[0048] Based on the storage object and offset where the target file is located, modify the file length corresponding to the target file in the offset list to 0.

[0049] Optionally, the processing module is also used for:

[0050] Based on the preset erasure coding redundancy ratio, determine the first target number of total storage nodes required.

[0051] Based on the number of availability zones, determine the second target number of storage nodes to be selected from each availability zone;

[0052] Select a second target number of target storage nodes from each availability zone;

[0053] A storage space is obtained from each target storage node to form a storage object.

[0054] Thirdly, this application provides a server, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the first aspect and any possible design of the first aspect.

[0055] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and the method in any possible design of the first aspect.

[0056] The memory reclamation method, apparatus, server, and storage medium provided in this application improve the efficiency of free space reclamation by obtaining an offset list of a first storage object; calculating the deletion ratio of files in the first storage object based on the offset list; setting a first threshold; instructing a management node to create a second storage object when the deletion ratio is greater than or equal to the first threshold, wherein the storage nodes included in the second storage object are located in the same availability zone as the storage nodes in the first storage object; identifying valid files in the first storage object through the offset list or file list; appending the valid files in the first storage object to the second storage object; and releasing the first storage object. Attached Figure Description

[0057] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0058] Figure 1 This application provides a schematic diagram of the structure of a distributed system according to an embodiment of the present application;

[0059] Figure 2 This is a schematic diagram illustrating a node connection method according to an embodiment of this application;

[0060] Figure 3 A flowchart illustrating a memory reclamation method provided in one embodiment of this application;

[0061] Figure 4 A flowchart illustrating the workflow of a recycling node according to an embodiment of this application;

[0062] Figure 5 A flowchart illustrating a memory reclamation method provided in one embodiment of this application;

[0063] Figure 6 A flowchart illustrating the deletion of a file in a storage object is provided in one embodiment of this application.

[0064] Figure 7 A flowchart illustrating the writing process of a file in a storage object is provided in one embodiment of this application;

[0065] Figure 8 This is a schematic diagram of the structure of a memory reclamation device provided in one embodiment of this application;

[0066] Figure 9 This is a schematic diagram of the hardware structure of a server provided in one embodiment of this application.

[0067] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0068] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0069] To improve data throughput and concurrency, business systems typically employ distributed systems. Distributed storage systems usually consist of multiple servers. Each server can correspond to at least one distributed node. This distributed node can function as a recycling node, storage node, management node, or other different roles. Typically, the server used for storage can be a single storage node. Currently, server storage engines often use append-only writes to write target data into the storage node. As older data is deleted, the proportion of garbage data in the storage node continuously increases. The presence of this garbage data directly leads to low memory utilization.

[0070] Garbage collection (GC) helps the system reclaim memory space occupied by garbage data. Garbage collection is typically implemented through garbage collection nodes, which are garbage collection processes running in the distributed system. These processes can run on any server in the distributed system that stores their code. In existing technologies, distributed systems typically deploy one or more availability zones. Garbage collection nodes can read valid files from old storage nodes and write them to the memory space corresponding to the garbage collection node. Subsequently, the garbage collection node can read these valid files from the memory space corresponding to the garbage collection node and write them to a new storage node. Afterward, the garbage collection node changes the location information pointed to by the metadata of these files. Simultaneously, the garbage collection node also deletes files from the old storage node and releases the memory space of the old storage node. In this distributed system, the old storage node, the new storage node, and the garbage collection node may be located in different availability zones and / or on different servers. Therefore, the reading of valid files from the old storage node and the writing of valid files to the new storage node by the garbage collection node may generate cross-availability zone network traffic. This network traffic consumes a significant amount of network bandwidth and increases the system's operating costs. Meanwhile, when implementing garbage collection across availability zones, its speed is significantly affected by network conditions. If network latency occurs, garbage collection efficiency will be greatly reduced. Furthermore, since the valid files in the old storage nodes are no longer contiguous, the recycling node needs to read the valid files from the old storage nodes one by one. This process generates a large amount of discontinuous disk read I / O time, affecting normal business operations' access to valid files in the old storage nodes.

[0071] To address the aforementioned issues, this application proposes a memory reclamation method that implements garbage collection within an availability zone. This method can largely avoid cross-availability zone dedicated line traffic while improving garbage collection efficiency. In this application, the management node of the distributed system can determine the number of storage nodes included in a storage object based on erasure coding redundancy ratio. The management node can also select and create storage nodes corresponding to the storage object based on the amount of data in each storage node. The allocation method of storage nodes in the storage object can improve load balancing among the storage nodes. Each storage object can include storage space from multiple storage nodes. The size of the storage space is a preset size. The multiple storage nodes in the storage object can be evenly distributed across different availability zones. Files can be written to the storage space via append-only operations.

[0072] When a file is deleted, it becomes invalid data. When the number of deleted files in a storage object reaches a certain proportion, the storage object becomes an old storage object. A reclaim node can trigger garbage collection for this old storage object. This garbage collection operation specifically reclaims the storage space within the old storage object. A reclaim node can create a new storage object through a management node. The storage nodes in this new storage object are in the same availability zone as those in the old storage object. The reclaim node can transfer valid files from each storage node in the old storage object to storage nodes in the same availability zone in the new storage object. This method saves cross-availability zone traffic. Simultaneously, since the storage nodes in the old and new storage objects are in the same availability zone, files in the old storage object's storage nodes can be written in batches to the local solid-state drives (SSDs) of the new storage object's storage nodes. Subsequently, the new storage object's storage nodes can write files from the SSDs to the corresponding storage space of the new storage object. This storage space is the hard disk drive (HDD) of the storage node. This batch write method can effectively improve the efficiency of memory reclamation. At the same time, the operation of batch writing files from old storage objects to the SSD can reduce the I / O time of old storage objects, thereby avoiding impact on normal business operations and preventing a large amount of random I / O.

[0073] Figure 1This is a schematic diagram of a distributed system provided in one embodiment of this application. This application can be applied to any business system that uses a distributed system for its layout. This business system may further include a client for user interaction. The client can be a webpage for terminal devices such as mobile phones, computers, and tablets. Alternatively, the client can be an application for mobile phones, computers, and tablets. Alternatively, the client can be a business-related teller machine, such as a teller machine for handling banking services, broadband services, or ticket dispensing services. The client can connect to the distributed system via a network or data cable.

[0074] The distributed system of this application may include multiple servers. Each server may include at least one node. The distributed system of this application may include multiple storage nodes, a management node, and a recycling node. The management node may run on the master server of the distributed system and is used to manage the storage nodes in each sub-server. For example, the management node can create and release storage objects. Storage objects are used to store files. Each file can be a piece of data. For example, in a business system, a business node can generate a document from the data of a single business transaction. Similarly, in a user system, a user management node can generate a document from the data of a user. The recycling node is used to reclaim the storage space of invalid data in the storage objects. The recycling node can be set up on any server in the distributed system. The recycling node can communicate with the management node. When the recycling node determines that a storage object needs garbage collection, it performs a garbage collection operation on the storage object.

[0075] In this application, the connection method between the client and each node in the distributed system can be as follows: Figure 2 As shown.

[0076] The client can append an initial file to a storage object based on user instructions. The appended file is divided into multiple data fragments according to a specified erasure coding redundancy ratio, and a corresponding number of checksum data are generated. These data fragments and checksum data are then written to the storage space of the storage node within the storage object via append operations. Specifically, the client requests a writable storage object from the management node before writing the file. This storage object only supports append operations. After each successful write, the storage object sends an internal offset to the client. When reading the file, the client can retrieve the file based on the storage object's extension_id and the offset.

[0077] Storage objects are created by the management node. A storage object can include the storage space of multiple storage nodes. For example, when the erasure coding redundancy ratio is 2:1, a storage object can include the storage space of three storage nodes. The size of this storage space can be a preset size. For example, the preset size can be 1GB. The KV storage records the correspondence between a storage object and the storage space in multiple storage nodes. When an append operation is performed on a storage object, it actually appends file fragments to the storage space of each storage node. Simultaneously, after completing the file writing, the storage object returns a value from its internal storage.<offset,length> Here, offset indicates the file's offset within the storage object. Length indicates the file's length.

[0078] The storage node provides an interface for clients to call, allowing clients to manipulate files stored within it. These operations can include append, read, truncate, and delete. The storage node typically uses a single-machine storage engine. This engine appends received data to the storage space of a specified storage node. The storage space of a storage node is essentially a large file. The file to be written can be appended to this large file as data, thus achieving the writing and storage of the file.

[0079] The key-value (KV) storage is a fixed storage space used to record information about stored objects. Optionally, the data in this KV storage can be global parameters of the system. Specifically, the KV storage can include which storage nodes and disks the content of the stored object will be mapped to, and the sealed length (sealed_length) of the stored object after a sealing operation is performed when the object is full. This KV storage can also record the index information of the file being written and store it in a file list. The key in this file list can be the file name (object_name), and the value can be...<extent_id,offset,length> Each filename uniquely corresponds to a file. Here, `extent_id` is the storage object code, `offset` is the file's internal offset within that storage object, and `length` is the file's length. For each storage object, this KV storage may also include an offset list to record information within that storage object. The key value in this offset list can be `extent_id` and / or `offset`, and the value can be...<object_name,length> Where length is the length of a file's fragments.

[0080] The management node is responsible for creating and encapsulating storage objects. During the creation of a storage object, the management node also needs to consider which storage nodes are included in the storage object, taking into account load balancing.

[0081] The garbage collection node is used to perform garbage collection tasks. This node periodically scans the metadata of all stored objects to calculate the deletion rate of each object. When the deletion rate exceeds a first threshold, the garbage collection node can perform garbage collection on that object. The metadata information must include at least a list of offsets from the key-value store.

[0082] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0083] Figure 3 This is a flowchart illustrating a memory reclamation method provided in one embodiment of this application. Figure 1 and Figure 2 Based on the illustrated embodiments, as Figure 3 As shown, the method in this embodiment may include the following steps:

[0084] S101. Obtain the offset list of the first storage object. The offset list shall include at least the file length of each file written to the first storage object.

[0085] In this embodiment, during the periodic scanning of metadata information of all storage objects by the recycling node, taking the first storage object as an example, the recycling node can obtain the offset list of the first storage object. This offset list is a component of the metadata information. The metadata information may also include information such as the storage node corresponding to the first storage object and the storage space of the storage node. The offset list may include data such as extent_id / offset, object_name, and length. Where extent_id / offset are the key values ​​in the offset list, and object_name and length are the value values ​​in the offset list. Specifically, extent_id is the storage object code of the first storage object, offset is the file's offset within the storage object, object_name is the file name, and length is the file length.

[0086] In this offset list, the data corresponding to a key and a value can be considered as a single row. Each row of data can correspond to a file written to this first storage object. Because the data in this first storage object is stored append-only, the files stored in this first storage object are arranged sequentially.

[0087] In this embodiment, the primary data used is the length in the key-value pair. When a file is written to the first storage object, this length records the file's length. When a file is deleted from the first storage object, it becomes an invalid file, and the length value is changed to 0. Therefore, the recycling node can determine whether a file is valid based on its length.

[0088] S102. Based on the offset list, calculate the deletion ratio of files in the first storage object.

[0089] In this embodiment, the recycling node can perform statistics on the offset list obtained in step S101 to obtain the deletion ratio of files in the first storage object. Specifically, the recycling node can count the total number of rows to obtain the total number of files in the first storage object. The recycling node can also count the number of rows with a file length of 0 to obtain the number of deleted files in the first storage object. The recycling node can determine the deletion ratio based on the ratio of the number of deleted files to the total number of files.

[0090] S103. When the deletion ratio is greater than or equal to the first threshold, a second storage object is created. The storage space of the second storage object and the storage nodes in the same availability zone are included in the first storage object.

[0091] In this embodiment, a first threshold can be preset in the recycling node. This first threshold is used to indicate when to perform garbage collection on the storage object. The first threshold can be an empirical value set by technicians based on actual needs. For example, the first threshold can be 0.1, 0.3, 0.6, 0.8, etc. When the first threshold is small, garbage collection is required after deleting a small number of files in the storage object. When the first threshold is large, garbage collection may be required after deleting most files. Therefore, technicians typically set the first threshold based on memory usage requirements. When memory is scarce, technicians can set a smaller first threshold to reduce the idle time of free storage space in the storage object and improve the utilization rate of free storage space. When memory is plentiful, technicians can set a larger first threshold to reduce the frequency of garbage collection, allowing more server computing resources to be utilized by business services and improving service efficiency.

[0092] When a reclaiming node determines that the deletion ratio is greater than or equal to the first threshold, it can determine that the first storage object needs to undergo garbage collection. At this point, the reclaiming node can instruct the management node to create a second storage object. The storage nodes included in this second storage object are located in the same availability zone as the storage nodes of the first storage object. For example, when the first storage object includes storage space from the first storage node in the first availability zone, the second storage node in the second availability zone, and the third storage node in the third availability zone, the second storage object can include storage space from the fourth storage node in the first availability zone, the fifth storage node in the second availability zone, and the sixth storage node in the third availability zone.

[0093] Optionally, the storage space can be a fixed size. The size of the storage space can be set by technical personnel according to actual needs. For example, the storage space size can be 1GB, 5GB, 1TB, etc. The setting of the storage space size is mainly related to the file size and quantity. For example, when the file size of the business system is generally small, such as 10KB, 2MB, etc., the storage space size can be 1GB, 3GB, etc. Conversely, when the file size of the business system is generally large, such as 500MB, 1GB, etc., the storage space size can be 500GB, 1TB, etc.

[0094] S104. Based on the offset list of the first storage object, append the valid files in the first storage object to the second storage object, and obtain the offset list of the second storage object.

[0095] In this embodiment, the reclaim node can determine the valid files in the first storage object through an offset list. The valid files are those that have not been deleted. The valid files are those whose length in the offset list is not zero. The reclaim node can then append the valid files from the first storage object to the second storage object. Since the first and second storage objects can include multiple storage nodes, the writing process will be described using the first storage node in the first storage object and the fourth storage node in the second storage object as examples. The first and fourth storage nodes can be located in the same availability zone.

[0096] The reclaimed node can append valid files from the storage space of the first storage node to the storage space of the fourth storage node. Optionally, the reclaimed node can send information corresponding to the first storage node to the fourth storage node, so that the fourth storage node can complete the reading and appending of the valid file. The process of other storage nodes in the first storage object writing to the storage node of the second storage object is the same as the process of writing valid files from the first storage node to the fourth storage node.

[0097] In one example, the append-to-write process for this valid file may specifically include:

[0098] Step 1: The recycling node instructs each storage node in the second storage object to remotely copy all files in the first storage object to the temporary file storage area of ​​the host where the second storage object is located.

[0099] For example, the fourth storage node in the second storage object can remotely copy files from the first storage node in the first storage object to the SSD of the host where the fourth storage node resides. Optionally, since the first and fourth storage nodes are located in the same availability zone, the copying method can be a batch copy. This batch copying process can reduce the I / O time occupied by the first storage object during the copying process.

[0100] Step 2: The recycling node determines the location of the valid files in the offset list of the first storage object.

[0101] For example, the fourth storage node in the second storage object can determine the location of valid files that have not been deleted in the host SSD that are copied to the fourth storage node after receiving the offset list sent by the recycling node.

[0102] Step 3: The recycling node can write the valid file to the second storage object based on its location. This writing method can be append-only.

[0103] For example, the fourth storage node can write the valid file to the storage space corresponding to the second storage object within the fourth storage node, based on the file's location. This storage space can be the hard drive of the host machine where the fourth storage node resides. This storage step enables long-term storage of the valid file.

[0104] S105. Release the first storage object.

[0105] In this embodiment, the recycling node can release the first storage object after copying all valid files from the first storage object to the second storage object. Releasing the first storage object can specifically include deleting the data in the first storage object and releasing the storage space occupied by the first storage object.

[0106] In one example, before releasing the first storage object, the reclaim node can modify the metadata of the first storage object to point to the second storage object. Specifically, this metadata can include a list of records. The reclaim node can modify the data in the data row of the record list that includes the first storage object, changing the encoding of the first storage object to the encoding of the second storage object, thus making the metadata point to the second storage object. When a client retrieves a file using this metadata, the feedback received by the client includes the storage object encoding of the second storage object.

[0107] The memory reclamation method provided in this application allows the reclamation node to obtain an offset list of the first storage object. This offset list includes at least the file length of each file written to the first storage object. The reclamation node can use this offset list to calculate the deletion ratio of files in the first storage object. A first threshold can be preset in the reclamation node. When the reclamation node determines that the deletion ratio is greater than or equal to the first threshold, it can instruct the management node to create a second storage object. The storage nodes included in the second storage object are located in the same availability zone as the storage nodes in the first storage object. The reclamation node can use the offset list to identify the valid files in the first storage object. The reclamation node can append the valid files from the first storage object to the second storage object and then release the first storage object. In this application, by reclamation nodes reclaiming free space in storage nodes, the efficiency of free space reclamation in storage nodes is improved. Simultaneously, by creating a second storage object in the same availability zone as the first storage object, this application reduces I / O time and improves reclamation efficiency.

[0108] exist Figure 3 Based on the illustrated embodiment, when the deletion ratio of the first storage object (old extent) reaches a first threshold, the garbage collection node (GC node) performs a garbage collection process on the old extent. This GC process is used to reclaim invalid data and release the storage space in the old extent. The workflow of this process can be as follows: Figure 4 As shown, the specific steps include the following:

[0109] Assume the erasure coding redundancy ratio is 2:1. That is, after acquiring a file to be stored, the business system can split it into two data shards. These two shards are the same size. For example, if the file size is 100KB, each shard can be 50KB. The business system can also generate verification data based on the file. The verification data size is the same as the data shard size. For example, if the data shard size is 50KB, the verification data size is also 50KB. Therefore, the manager node can acquire three storage nodes.

[0110] Suppose the business system is deployed across three Availability Zones (AZs). The management node can select a storage node from each AZ. For example, the management node can select storage node 1 on AZ1, storage node 2 on AZ2, and storage node 3 on AZ3.

[0111] like Figure 4 As shown, this old extent can include three files. File 1 is represented by a grid box, File 2 by a horizontal line box, and File 3 by a vertical line box. File 1, represented by the grid box, has been deleted. All three storage nodes have had these three files written to, and File 1 has been deleted in each of them. Taking File 3, represented by the vertical line box, as an example, during the writing process, the data fragments of File 3 represented by the two vertical line boxes and the verification data of File 3 represented by the diamond box can be appended to the three storage nodes respectively.

[0112] S201, Request the allocation of a new extent.

[0113] In this step, the GC node requests a new extent from the manager to write files from the old extent. The new extent has the same number of storage nodes as the old extent, and each storage node in the new extent belongs to the same availability zone as the storage nodes in the old extent. Simultaneously, the manager can preferentially allocate storage nodes with relatively free storage capacity to the new extent. This allocation method can resolve the issue of inconsistent storage capacity between storage nodes while implementing memory reclamation. The old extent is the first storage object in the above embodiment. The new extent is the second storage object in the above embodiment.

[0114] S202, Send a GC request.

[0115] In this step, the GC node can send a GC request to the storage node corresponding to the new extent. The GC request can include the storage node where the old extent is located, the extent_id of the old extent, and the offset list of the remaining valid files within the old extent.

[0116] S203. The extent file is copied remotely to the host SSD where the second storage object is located.

[0117] This step uses storage node 4 in the new extent as an example. In actual execution, storage nodes 5 and 6 in the new extent perform the same operation. Furthermore, storage nodes 4, 5, and 6 execute independently without interfering with each other.

[0118] After receiving a garbage collection (GC) request, storage node 4 in the new extent can remotely copy the complete old extent file from storage node 1 in the same Availability Zone (AZ) to the SSD of the host where the second storage object resides. The files in the old extent on this SSD are stored as temporary files.

[0119] S204, Read & Append Write.

[0120] In this step, storage node 4 determines the location of valid files based on the offset list in the garbage collection (GC) request. Valid files are those with a length other than zero. Then, storage node 4 sequentially reads all valid files from the temporary file into memory and appends them sequentially to the storage space of the new extent. Storage node 4 can also obtain the offset list of the newly written files within the memory space of the new extent.

[0121] S205, Data GC complete.

[0122] In this step, each storage node of the new extent returns the operation results to the GC node.

[0123] S206. Change the target location of object metadata.

[0124] In this step, after obtaining the operation results from all storage nodes of the new extent, the GC node determines whether all background operations were successful. If the operation is successful, the GC node modifies the metadata of all files involved in this change, making them point to the new extent. If the operation fails, the GC node reports an exception. That is, the GC node can modify the extent_id of the old extent in the data rows of the file list that include the old extent to the extent_id of the new extent.

[0125] S207, Delete the old extent.

[0126] In this step, the GC node can send requests to delete the old extent to the corresponding storage nodes. The corresponding storage nodes then release the corresponding storage space.

[0127] Based on the above embodiments, when a recycling node requests the creation of a storage object, it writes data to the storage object until it is full. Once the storage object is full, the recycling node requests the creation of a new storage object and continues writing data. Optionally, while the second storage object is not full, the write permission for the second storage object will be held by the recycling node, preventing other processes from writing files to it. The read and delete permissions for the second storage object are not held by the recycling node; therefore, other processes can read and delete files in the second storage object.

[0128] Taking the first storage object and the second storage object as examples. After all the data in the first storage object is written to the second storage object, the second storage object is not yet full.

[0129] Assume that the storage nodes in the third storage object are located in the same availability zone as the storage nodes in the first storage object. If the third storage object needs to be reclaimed, the reclamation node will continue writing data from the third storage object into the second storage object until the second storage object is full. Optionally, when the second storage object is full, the reclamation node can request the creation of a fourth storage object. This reclamation node can then continue writing files from the third storage object that have not yet been written to the second storage object into the fourth storage object. The storage nodes of this fourth storage object are located in the same availability zone as the storage nodes of the second storage object.

[0130] Suppose that the storage node of the fifth storage object is located in a different availability zone than the storage node of the first storage object. If the fifth storage object needs to be reclaimed, the reclamation node will create a sixth storage object based on the availability zone corresponding to the fifth storage object's storage node. The sixth storage object's storage node will be located in the same availability zone as the fifth storage object. The reclamation node will write the valid files from the fifth storage node to the sixth storage object. That is, even if the second storage object is not full, the valid files from the fifth storage object will not be written to the second storage object because the storage nodes are in different availability zones.

[0131] Based on the above embodiments, when creating a storage object, the management node can determine the target number of storage nodes to be added to the storage object according to the erasure coding redundancy ratio. For example, when the erasure coding redundancy ratio is 2:1, it means that each target file needs to be split into 2 data fragments and generate one corresponding verification data. Therefore, the target number is 3. As another example, when the erasure coding redundancy ratio is 4:2, it means that each target file needs to be split into 4 fragments and generate 2 verification files. Therefore, the target number is 6.

[0132] The management node can determine the number of storage nodes to select in each availability zone based on the number of availability zones. For example, when there are 3 availability zones, if the target number is 3, the management node needs to select one target storage node in each availability zone. Alternatively, if the target number is 6, the management node needs to select two target storage nodes in each availability zone. Optionally, the management node can select target storage nodes from each availability zone based on load balancing.

[0133] The management node can obtain a storage space from each target storage node. This storage space is equivalent to a large file on that target storage node. The management node can then use the storage space on each target storage node to create this storage object.

[0134] Figure 5 This is a flowchart illustrating a memory reclamation method provided in one embodiment of this application. Figures 1 to 4 Based on the illustrated embodiment, the process by which a user writes data into this distributed system can be as follows: Figure 5 As shown, the method in this embodiment may include the following steps:

[0135] S301. Based on the file name of the target file, delete the information corresponding to the target file from the file list.

[0136] In this embodiment, the management node can obtain a file list of the target storage object. Based on the filename of the target file, the management node can determine the data row corresponding to that target file from the file list. The management node can delete that data row. Once the data row is deleted, the target file will no longer be searchable.

[0137] S302. Based on the storage object and offset where the target file is located, modify the file length corresponding to the target file in the offset list to 0.

[0138] In this embodiment, the management node can obtain an offset list. The management node can determine the data row corresponding to the target file based on the target storage object and the target offset. The target storage object and target offset can be obtained by the management node from the file list in step S301. The management node can modify the file length in the data row to 0. This modification can also maintain the record of files written to the target storage object and use the file length to identify whether the file has been deleted.

[0139] The memory reclamation method provided in this application allows the management node to obtain a file list of the target storage object. The management node can determine the corresponding data row of the target file from this file list based on the target file's name. The management node can delete this data row. The management node can also obtain an offset list. Based on the target storage object and target offset of the target file, the management node can determine the corresponding data row of the target file. The management node can modify the file length in this data row to 0. In this application, by modifying the file length in the offset list to 0, the write record of the target file can be stored in this offset list. Simultaneously, the file length indicates that the target file has been deleted. By deleting the data row of the target file from the file list, the target file becomes unsearchable, thus achieving deletion of the target file from the user's perspective.

[0140] exist Figure 5 Based on the illustrated embodiment, the process of a client requesting to delete a file in a storage object can be as follows: Figure 6 As shown, the specific steps include the following:

[0141] S401, The user program calls the client to delete the target object.

[0142] In this step, the user can invoke the client through the user program. The user can generate a command to delete user object data through the client. The client can then send this command to the management node of the business system. The target object may include at least one target file.

[0143] S402. The client queries the info of the target object from the KV store by the object name and obtains extent_id, offset, and length.

[0144] In this step, the client can obtain query results from the KV storage through the management node. The management node can retrieve information (info) about the object from the KV storage based on at least one target file name (object_name) included in the target object. This information may include the storage object where the target file resides, the internal offset of the target file within that storage object, and the file length of the target file.

[0145] S403, The client deletes the target object's okey from the KV storage.

[0146] In this step, the client can delete the object's address from the KV store through the management node. The address is the list of files for that target object. The address for that object is the data row of the target file within that address.

[0147] S404. The client modifies the ekey in the KV store and sets the length field of the value to 0.

[0148] In this step, the client can modify the ekey in the KV store through the management node. This ekey is the offset list. Specifically, the management node can determine the data row of the object in the ekey based on the stored object and its offset within the stored object. The management node can then change the length of the data row of the object in the ekey to 0.

[0149] Based on the above embodiments, the process of client-side data writing can be as follows: Figure 7 As shown. The specific process may include the following steps:

[0150] S501: The client allocates a writable extent from the management node.

[0151] In this step, the client can submit a write request to the management node. The management node can determine whether there is an extent that is not yet full. If it exists, the management node can send the extent's storage object code (extent_ID) back to the client. If it does not exist, the management node can create a new extent and send its extent_ID back to the client.

[0152] S502: When the client appends an object to an extent, it actually writes it to multiple files corresponding to that extent. After a successful write, it returns the offset and length of the files written.<offset,length> .

[0153] In this step, the client can write the object to the extent corresponding to the extent_ID. During the actual writing process, the object is written to the storage space of each storage node included in the extent. Each storage space is equivalent to a file. After the object is successfully written to each storage node of the extent, each storage node will send a write message back to the client. This write message may include...<offset,length> .

[0154] S503, The client records `okey` in the KV store, key: user object name, value:<extent_id,offset,length> .

[0155] In this step, the client can record write information in the key-value store's `okey` through the management node. This `okey` is essentially a list of files. The key value in this file list can be the filename of the object (`object_name`). The value in this `okey` can include...<extent_id,offset,length> .

[0156] S504. The client records the ekey in the KV store, key: extent_id / offset, value:<object_name,length> .

[0157] In this step, the client can record the write information in the ekey of the KV store through the management node. This ekey is the offset list. The key value in this offset list can be extent_id / offset. The value in this ekey can include...<object_name,length> .

[0158] Figure 8 A schematic diagram of a memory reclamation device according to an embodiment of this application is shown, as follows: Figure 8 As shown, the memory reclamation device 10 of this embodiment is used to implement the operation corresponding to the server in any of the above method embodiments. The memory reclamation device 10 of this embodiment includes:

[0159] The acquisition module 11 is used to acquire the offset list of the first storage object, wherein the offset list includes at least the file length of each file written to the first storage object;

[0160] Processing module 12 is used to calculate the deletion ratio of files in the first storage object according to the offset list; when the deletion ratio is greater than or equal to a first threshold, create a second storage object, the second storage object and the first storage object include storage space of storage nodes in the same availability zone; according to the offset list of the first storage object, append valid files in the first storage object to the second storage object and obtain the offset list of the second storage object; release the first storage object.

[0161] Optionally, processing module 12 is specifically used for:

[0162] Count the number of files with a length of 0 that have been deleted from the offset list;

[0163] The total number of files written to the first storage object in the offset list;

[0164] The deletion ratio is determined based on the ratio of the number of deletions to the total number.

[0165] Optionally, processing module 12 is specifically used for:

[0166] The files in the first storage object are remotely copied to the temporary file storage area of ​​the host where the second storage object is located;

[0167] Based on the offset list of the first storage object, determine the file position of the valid file. The valid file is the file whose length in the offset list is not 0.

[0168] Write valid files in batches to the second storage object based on their file locations.

[0169] Optionally, the processing module 12 is also used for:

[0170] Change the first storage object in the file list to the second storage object.

[0171] Optionally, when the second storage object is not full and the deletion ratio of the third storage object is greater than or equal to the first threshold, the processing module 12 is further configured to:

[0172] Write some or all of the files in the third storage object to the second storage object until the second storage object is full.

[0173] Optionally, the processing module 12 is also used for:

[0174] Remove the information corresponding to the target file from the file list based on the target file name;

[0175] Based on the storage object and offset where the target file is located, modify the file length corresponding to the target file in the offset list to 0.

[0176] Optionally, the processing module 12 is also used for:

[0177] Based on the preset erasure coding redundancy ratio, determine the first target number of total storage nodes required.

[0178] Based on the number of availability zones, determine the second target number of storage nodes to be selected from each availability zone;

[0179] Select a second target number of target storage nodes from each availability zone;

[0180] A storage space is obtained from each target storage node to form a storage object.

[0181] The memory recycling device 10 provided in this application embodiment can execute the above method embodiment. Its specific implementation principle and technical effect can be found in the above method embodiment, and will not be repeated here.

[0182] Figure 9 A schematic diagram of the hardware structure of a server provided in an embodiment of this application is shown. Figure 9As shown, the server 20 is used to implement the operations corresponding to the server in any of the above method embodiments. The server 20 in this embodiment may include: a memory 21, a processor 22, and a communication interface 24.

[0183] Memory 21 is used to store computer programs.

[0184] Processor 22 is used to execute computer programs stored in memory to implement the memory reclamation method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0185] Alternatively, the memory 21 can be either standalone or integrated with the processor 22.

[0186] When the memory 21 is a device independent of the processor 22, the server 20 may also include a bus 23. The bus 23 is used to connect the memory 21 and the processor 22.

[0187] Communication interface 24 can be connected to processor 21 via bus 23. Processor 22 can control communication interface 24 to achieve communication with other servers in the business system. The server can also communicate with clients through this communication interface. This business system can be a distributed system.

[0188] The server provided in this embodiment can be used to execute the memory reclamation method described above. Its implementation and technical effects are similar, and will not be repeated here.

[0189] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and the method in any possible design of the first aspect.

[0190] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0191] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0192] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0193] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0194] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0195] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0196] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as these combinations of technical features do not contradict each other, they should be considered within the scope of this specification.

[0197] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0198] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A memory reclamation method, characterized in that, The method includes: Obtain an offset list of the first storage object, wherein the offset list includes at least the file length of each file written to the first storage object; Based on the offset list, calculate the deletion ratio of the files in the first storage object; When the deletion ratio is greater than or equal to the first threshold, a second storage object is created, and the storage space of the second storage object includes the storage nodes in the same availability zone as the first storage object. The files in the first storage object are remotely copied to the temporary file storage area of ​​the host where the second storage object is located; Based on the offset list of the first storage object, the file position of the valid file is determined, wherein the valid file is the file whose length is not 0 in the offset list; The valid files are written in batches to the second storage object according to the file location, and the offset list of the second storage object is obtained; wherein, both the first storage object and the second storage object include storage nodes distributed in multiple availability zones, and the storage node of the second storage object in each availability zone is used to receive the valid files of the first storage object on the storage node in the same availability zone; Release the first storage object.

2. The method according to claim 1, characterized in that, The step of calculating the deletion ratio of the files in the first storage object based on the offset list specifically includes: Count the number of files with a length of 0 that were deleted from the offset list; Count the total number of files written to the first storage object in the offset list; The deletion ratio is determined based on the ratio of the number of deletions to the total number.

3. The method according to claim 1 or 2, characterized in that, Before releasing the first storage object, the method further includes: Change the first storage object in the file list to the second storage object.

4. The method according to claim 1 or 2, characterized in that, When the second storage object is not full and the deletion ratio of the third storage object is greater than or equal to the first threshold, the method further includes: Write some or all of the files in the third storage object into the second storage object until the second storage object is full.

5. The method according to claim 1 or 2, characterized in that, The method further includes: Based on the file name of the target file, remove the information corresponding to the target file from the file list; Based on the storage object and offset where the target file is located, the file length corresponding to the target file in the offset list is modified to 0.

6. The method according to claim 1 or 2, characterized in that, The method further includes: Based on the preset erasure coding redundancy ratio, determine the first target number of the total number of storage nodes required; Based on the number of availability zones, determine a second target number of storage nodes to be selected from each availability zone; Select the second target number of target storage nodes from each of the availability zones; One storage space is obtained from each of the target storage nodes to form the storage object.

7. A memory reclamation device, characterized in that, include: The acquisition module is used to acquire an offset list of the first storage object, wherein the offset list includes at least the file length of each file written to the first storage object; The processing module is used to calculate the deletion ratio of the files in the first storage object according to the offset list; when the deletion ratio is greater than or equal to a first threshold, a second storage object is created, wherein the storage space of the second storage object and the storage nodes in the first storage object include the same availability zone; The files in the first storage object are remotely copied to the temporary file storage area of ​​the host where the second storage object is located; Based on the offset list of the first storage object, the file position of the valid file is determined, wherein the valid file is the file whose length is not 0 in the offset list; The valid files are written in batches to the second storage object according to the file location, and the offset list of the second storage object is obtained; wherein, both the first storage object and the second storage object include storage nodes distributed in multiple availability zones, and the storage node of the second storage object in each availability zone is used to receive the valid files of the first storage object on the storage node in the same availability zone; Release the first storage object.

8. A server, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

Images