Methods and devices for acquiring partition locks, storage media, electronic devices and programs.

Abstract

This application discloses a method, apparatus, storage medium, electronic device, and program for acquiring partition locks, relating to the field of distributed storage systems. The method includes: upon receiving multiple operation requests from one or more clients, pre-screening the multiple operation requests using a root path filter, a directory filter, and a lock type filter to filter out first operation requests that do not require locking and / or do not cause lock contention, thus obtaining second operation requests that cause lock contention; calculating the number of lock contentions corresponding to the second operation request, and determining the target lock region corresponding to the second operation request based on the number of lock contentions, thereby reducing the number of lock contentions in hotspot regions. This application solves the problem of severe lock contention in lock management mechanisms such as global lock mechanisms and fixed partition locks in related technologies, thereby reducing lock contention in hotspot regions.

Description

Technical Field

[0001] This application relates to the field of distributed storage systems, and in particular to methods and apparatus for acquiring partition locks, storage media, electronic devices, and programs. Background Technology

[0002] In related technologies, the lock management mechanisms of distributed storage metadata servers (MDS) include: 1) Global lock mechanism: A global read-write lock is set for metadata operations. Read operations can share the lock resource, while write operations have exclusive locks. When a client performs a write operation and acquires an exclusive lock, other clients' read and write requests must wait until the lock is released. This method is simple, direct, and easy to implement and manage. However, in high-concurrency scenarios, all requests in the global lock mechanism compete for the same lock, resulting in a large number of requests queuing and waiting, extremely low system throughput, and severely limiting the system's concurrent processing capabilities; 2) Fixed partition lock: Based on rules such as directory hierarchy and file hash, the lock space is divided into multiple fixed regions, and each region is locked independently. For example, according to the directory tree hierarchy, directories at different levels are assigned to different lock regions, so that operations in different regions can be performed concurrently, reducing the scope of lock contention. However, the granularity of fixed partition locks cannot be dynamically adjusted. Once the partition is determined, it is difficult to change, and it cannot adapt to the dynamic changes in load under different time periods and business scenarios. In some cases, there may be intense contention for some partition locks while other partition locks remain idle.

[0003] Therefore, lock management mechanisms such as global locks and fixed partition locks in related technologies suffer from severe lock contention.

[0004] Therefore, the problem of severe lock contention in lock management mechanisms such as global locks and fixed partition locks in related technologies has not yet been effectively resolved. Summary of the Invention

[0005] This application provides a method and apparatus for acquiring partition locks, a storage medium, an electronic device, and a program to at least solve the problem of severe lock contention in lock management mechanisms such as global lock mechanisms and fixed partition locks in related technologies.

[0006] This application provides a method for obtaining a partition lock, comprising: upon receiving multiple operation requests sent by one or more clients, performing a pre-examination on the multiple operation requests using a filter index to filter a first operation request among the multiple operation requests to obtain a second operation request, wherein the filter index includes at least one of the following: a root path filter, a directory filter, and a lock type filter; the first operation request is an operation request that does not require locking and / or does not cause lock contention; the second operation request is an operation request that causes lock contention; calculating the number of lock contention attempts corresponding to the second operation request, and determining a target lock region corresponding to the second operation request based on the number of lock contention attempts; and obtaining the partition lock corresponding to the second operation request based on the target lock region.

[0007] This application also provides a partition lock acquisition device, comprising: a pre-inspection module, configured to, upon receiving multiple operation requests sent by one or more clients, pre-inspect the multiple operation requests using a filter index to filter a first operation request among the multiple operation requests and obtain a second operation request, wherein the filter index includes at least one of the following: root path filter, directory filter, lock type filter, the first operation request being an operation request that does not require locking and / or does not cause lock contention, and the second operation request being an operation request that causes lock contention; a calculation module, configured to calculate the number of lock contention attempts corresponding to the second operation request and determine the target lock region corresponding to the second operation request based on the number of lock contention attempts; and an acquisition module, configured to acquire the partition lock corresponding to the second operation request based on the target lock region.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the partition lock acquisition methods described above.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the partition lock acquisition methods described above.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for acquiring a partition lock.

[0011] This application addresses the issue of severe lock contention in related technologies, such as global locking and fixed partition locking, by pre-screening multiple operation requests received from one or more clients using root path filters, directory filters, and lock type filters. This filters out first operation requests that do not require locking and / or do not cause lock contention, resulting in second operation requests that do cause lock contention. The number of lock contention attempts corresponding to the second operation request is calculated, and the target lock region corresponding to the second operation request is determined based on this number, thereby reducing the number of lock contention attempts in hotspot areas. This application resolves the problem of severe lock contention in global locking mechanisms and fixed partition locking mechanisms in related technologies, thus reducing lock contention in hotspot areas. Attached Figure Description

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

[0013] Figure 1 This is a hardware structure block diagram of a computer terminal for a partition lock acquisition method according to an embodiment of this application;

[0014] Figure 2 This is a flowchart of a method for acquiring a partition lock according to an embodiment of this application;

[0015] Figure 3 This is a distributed storage system architecture diagram according to an optional embodiment of this application;

[0016] Figure 4 This is a flowchart of a distributed storage metadata lock optimization method based on a multi-level Bloom filter, according to an optional embodiment of this application;

[0017] Figure 5 This is a frame diagram of a partition lock acquisition device according to an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0019] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] The specific application environment architecture or specific hardware architecture on which the partition lock acquisition method depends is described here.

[0022] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure block diagram of a computer terminal for a partition lock acquisition method according to an embodiment of this application. Figure 1 As shown, a computer terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor (MPU) or programmable logic device (PLD)) and a memory 104 for storing data are also shown. The computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0023] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the method for determining the interaction state in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0024] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0025] Figure 2 This is a flowchart of a method for acquiring a partition lock according to an embodiment of this application, which can be applied to... Figure 1 In computer terminals, such as Figure 2 As shown, the process includes the following steps:

[0026] Step S202: Upon receiving multiple operation requests from one or more clients, a pre-examination is performed on the multiple operation requests using a filter index to filter out the first operation request among the multiple operation requests and obtain the second operation request. The filter index includes at least one of the following: root path filter, directory filter, lock type filter. The first operation request is an operation request that does not require locking and / or does not cause lock contention. The second operation request is an operation request that causes lock contention.

[0027] The aforementioned operation request refers to a request sent by the client to the distributed storage system to perform a specific file system operation (e.g., read, write, create, or delete a file).

[0028] The root path filter is used to check if the top-level path prefix of the operation request exists in the active lock record;

[0029] Directory filters are used to check whether target files in a specific directory pointed to by an operation request have been locked;

[0030] Lock type filters are used to check whether the type of operation request (read or write) might conflict with other existing locks of the same type.

[0031] Step S204: Calculate the number of lock contention attempts corresponding to the second operation request, and determine the target lock region corresponding to the second operation request based on the number of lock contention attempts;

[0032] Among them, the number of lock contention times refers to the number of times a lock resource in a certain target lock region is requested and competed for by multiple clients within a certain period of time.

[0033] Step S206: Obtain the partition lock corresponding to the second operation request based on the target lock region.

[0034] Partition locks are a locking mechanism used in distributed storage systems to control access to resources within a target lock region. Each partition lock can operate independently of other partition locks, allowing concurrent access to different partitions at the same time, reducing global lock wait time and lock contention, thereby improving the overall concurrency performance of the system. Partition locks typically support two types: read locks and write locks. Read locks allow multiple clients to access the resource simultaneously, while write locks require exclusive access.

[0035] The partition lock acquisition method of this application, upon receiving multiple operation requests from one or more clients, pre-screens the multiple operation requests using a root path filter, a directory filter, and a lock type filter. This filters out first operation requests that do not require locking and / or do not cause lock contention, resulting in second operation requests that do cause lock contention. The number of lock contention attempts corresponding to the second operation request is calculated, and the target lock region corresponding to the second operation request is determined based on the number of lock contention attempts, thereby reducing the number of lock contention attempts in hotspot regions. This application solves the problem of severe lock contention in lock management mechanisms such as global lock mechanisms and fixed partition locks in related technologies, thus reducing lock contention in hotspot regions.

[0036] Optionally, the pre-screening of the multiple operation requests by filter index in step S202 above includes the following steps one through three:

[0037] Step 1: Parse the multiple operation requests to obtain the first request path corresponding to each operation request;

[0038] Step 2: Extract the top-level directory prefix contained in each first request path, and perform a first-level pre-check on each operation request based on the root path filter to determine whether a first active lock operation exists under each top-level directory prefix. The top-level directory prefix indicates the highest-level directory in the first request directory corresponding to each first request path. The specific steps of the first-level pre-check may include:

[0039] Obtain the first number of top-level directories expected to be stored by the root path filter and the first false positive rate corresponding to the root path filter; calculate the first group size of the first digit group included in the root path filter and the second number of the first hash functions used to map the top-level directory prefix to the first digit group according to the first formula and the second formula, wherein the first formula is: The second formula is: p1 is the first false positive rate, k1 is the second quantity, m1 is the size of the first digit group, and n1 is the first quantity; a first hash value corresponding to each top-level directory prefix is ​​calculated based on a first hash function of the second quantity; a first index value corresponding to the first hash value is determined according to a first digit group of the first digit group size; a first bit identifier of the first index position corresponding to the first index value is determined in the root path filter; and the existence of the active lock operation under each top-level directory prefix is ​​determined according to the first bit identifier.

[0040] Understandably, by calculating the size of the bit array and the number of hash functions in the Bloom filter, effective pre-detection of active lock operations on the top-level directory prefix can be achieved, thereby filtering out the first operation request that does not require locking or cause lock contention. Specifically:

[0041] 1) Obtain the first number (n1) of top-level directories expected to be stored by the root path Bloom filter (i.e., the root path filter) and the first false positive rate (p1) corresponding to the root path filter. Assume that the number of top-level directory prefixes expected to be managed in the system is 10,000, and set the first false positive rate p1 of the root path Bloom filter to no more than 0.001 (i.e. 0.1%) to ensure efficient filtering while maintaining high accuracy.

[0042] 2) Calculate the size m1 of the root path Bloom filter bit array and the number k1 of the root path Bloom filter hash functions based on the first and second formulas.

[0043] 3) Calculate the first hash value: For each top-level directory prefix, calculate its corresponding first hash value using the first hash function of the second quantity (k1).

[0044] 4) Determine the first index value: Perform a modulo operation between the first hash value and the size of the first digit group (m1) to obtain the corresponding first index value.

[0045] 5) Set bit flag: In the first bit group of the root path Bloom filter, set the bit flag of the first index position obtained by hash value mapping to 1, indicating that there may be an active lock operation in the top-level directory prefix.

[0046] 6) Active Lock Pre-check: When a client sends an operation request, MDS uses a root path Bloom filter to check the bit flags of the top-level directory prefix in the request. If all bit flags at all mapping positions are 1, it is considered that there may be an active lock operation, and further detection is required; if any bit flag at any mapping position is 0, it can be determined that there is no active lock operation under that top-level directory prefix, and the request is the first operation request, which can be allowed directly.

[0047] Based on the above technical solution, by finely configuring the Bloom filter parameters, rapid pre-screening of operation requests can be achieved. Especially in high-concurrency scenarios, this reduces the lock resource management burden on the MDS and improves system response speed. Furthermore, the root path filter can quickly filter out requests without active lock operations under the top-level directory prefix, reducing the overhead of subsequent lock contention detection and waiting.

[0048] Step 3: If it is determined that the first active lock operation exists under the top-level directory prefix corresponding to the third operation request among the plurality of operation requests, the third operation request is filtered, and the fourth operation request other than the third operation request among the plurality of operation requests is pre-checked through the directory filter and / or the lock type filter, wherein the first operation request includes: the third operation request.

[0049] The pre-screening of the fourth operation request (excluding the third operation request) among the plurality of operation requests, using the directory filter and / or the lock type filter, includes the following steps 1-3:

[0050] Step 1: Parse each fourth operation request to determine the second request path corresponding to the fourth operation request;

[0051] Step 2: Determine the second request directory corresponding to each second request path, and perform a secondary pre-check on the first files contained in each second request directory based on each directory filter corresponding to each second request directory, to determine whether a second active lock record exists under each first file; wherein, the steps of the secondary pre-check are as follows:

[0052] Obtain the third number of files expected to be stored in each second request directory corresponding to each directory filter and the second false positive rate corresponding to each directory filter; calculate the second group size of the second group contained in each directory filter and the fourth number of the second hash function used to map the first file information corresponding to each first file to the second group according to the third formula and the fourth formula, wherein the third formula is: The fourth formula is: p2 is the second false positive rate, k2 is the fourth quantity, m2 is the size of the second digit group, and n2 is the third quantity; a hash calculation is performed on each first file information based on the second hash function of the fourth quantity to obtain the second hash value corresponding to each first file information, wherein the first file information includes at least one of the following: the first file name of the first file, the first file identifier of the first file, and the first metadata corresponding to the first file; a second index value corresponding to the second hash value is determined according to the second digit group size of the second digit group; a second bit identifier corresponding to the second index position of each second index value is determined in each directory filter; and the existence of the active lock operation under each first file is determined according to the second bit identifier.

[0053] Understandably, the directory Bloom filter (directory filter) is the second layer in a multi-level Bloom filter system, used to detect more fine-grained file operation requests as to whether lock contention is likely involved. Specifically:

[0054] 1) Directory Bloom Filter Parameter Calculation: For each directory, MDS needs to obtain the third number of files (n2) expected to be stored by the directory filter and the second false positive rate (p2) corresponding to that directory filter. Assuming that a directory is expected to store 5000 files, and setting the second false positive rate p2 of the directory Bloom filter to no more than 0.002 (i.e. 0.2%), to ensure that the filter maintains high accuracy while being efficient.

[0055] 2) Calculate the size m2 of the directory Bloom filter bit array and the number k2 of the directory Bloom filter hash functions based on the third and fourth formulas above.

[0056] The directory Bloom filter is constructed similarly to the root path Bloom filter, but it focuses more on file-level active lock detection.

[0057] 3) Calculate the second hash value: For each piece of first file information in the directory (e.g., file name, file identifier, metadata), calculate its corresponding second hash value using the second hash function of the fourth quantity (k2).

[0058] 4) Determine the second index value: Perform bitwise operations on the calculated second hash value and the size of the second digit group (m2) to obtain the corresponding second index value.

[0059] 5) Set bit flag: In the second bit group of each directory Bloom filter, set the bit flag of the second index position obtained by mapping the second hash value to 1, indicating that the file may have active lock operations.

[0060] 6) Active Lock Pre-check: When a request passing through the root path filter enters the directory filter check phase, MDS uses a directory Bloom filter to check the bit flags of the target file (i.e., the first file) in the request. If all mapped positions have a bit flag of 1, it is considered that there may be an active lock operation, and further detection is required; if any mapped position has a bit flag of 0, it can be determined that there is no active lock operation under that file, and the request can be allowed directly or the lock acquisition can be skipped and the operation can be performed directly.

[0061] Understandably, by using the directory Bloom filter, MDS can perform a fast pre-detection of lock requests at the file level, further filtering out requests for which there are no active lock operations under the target file. The pre-detection process reduces the overhead of subsequent lock acquisition and improves processing efficiency.

[0062] Step 3: If it is determined that there is a second active lock record in the first file corresponding to the fifth operation request among the multiple fourth operation requests, filter the fifth operation request, and perform a pre-check on the sixth operation request other than the fifth operation request among the multiple fourth operation requests through the lock type filter, wherein the first operation request includes: the fifth operation request.

[0063] The process of pre-checking the sixth operation request (excluding the fifth operation request) among the plurality of fourth operation requests through the lock type filter includes the following steps (1)-(3):

[0064] Step (1) parse the sixth operation request to determine the request type corresponding to the sixth operation request;

[0065] Step (2) Determine the target type of the lock type filter corresponding to each sixth operation request based on the request type, and perform a three-level pre-check on each sixth operation request based on the lock type filter of the target type to determine whether there is a lock conflict of the same type for the sixth operation requests of each request type. The lock type filter of the target type includes at least one of the following: write lock type filter and read lock type filter. The lock conflict of the same type is used to indicate that the lock operations corresponding to multiple sixth operation requests of any request type are operations that request to acquire the same type of lock at the same time. The three-level pre-check process specifically includes:

[0066] Obtain the expected number of lock operations of the target type per second from the lock type filter of the target type and the third false positive rate corresponding to the lock type filter of the target type; calculate the size of the third digit group contained in the lock type filter of the target type and the fifth number of the third hash function used to map the request type to the third digit group according to the fifth formula and the sixth formula, wherein the fifth formula is: The sixth formula is: p3 is the third false positive rate, k3 is the fifth quantity, m2 is the third digit group size, and n3 is the number of times. A hash calculation is performed on the request type of each sixth operation request based on the third hash function of the fifth quantity to obtain the third hash value corresponding to each request type. The third index value corresponding to the third hash value is determined according to the third digit group size. The third bit identifier of the third index position corresponding to the third index value is determined in the lock type filter of the target type. The existence of lock conflicts of the same type in the sixth operation requests of each request type is determined according to the third bit identifier.

[0067] Understandably, the lock type Bloom filter (i.e., the lock type filter) is the last layer in the Bloom filter hierarchy, used to accelerate the detection of conflicts between locks of the same type and further optimize the lock request processing flow. Specifically:

[0068] 1) Parameter Acquisition: Acquire the expected number of lock operations of the target type per second (n3) and the corresponding third false positive rate (p3) of the lock type filter. Assume that in a specific directory, the average number of read lock (or write lock) operations per second is 2000, and set the third false positive rate p3 to not exceed 0.008 (i.e. 0.8%) to maintain a good balance between filtering accuracy and efficiency.

[0069] 2) Calculation parameters: Calculate the size of the Bloom filter bit array (m3) and the number of hash functions (k3) using the fifth and sixth formulas above.

[0070] 3) Calculate the third hash value: For each lock request type (such as read lock or write lock), calculate its corresponding third hash value using the fifth number (k3) of the third hash function.

[0071] 4) Determine the third index value: Perform bitwise operations on the calculated third hash value and the size of the third bit array (m3) to obtain the corresponding third index value.

[0072] 5) Set the third bit flag: In the third bit group of the lock type filter of the target type, set the third bit flag of the third index position obtained by mapping the third hash value to 1, indicating that there may be lock conflicts of the same type.

[0073] 6) Active Lock Conflict Pre-detection: When an operation request sent by a client enters the lock type filter check phase, MDS uses the lock type filter to check the bit identifier of the request type (read or write). If the third bit identifier of all mapping positions is 1, it is considered that there may be a lock conflict of the same type, and further detection is required; if the third bit identifier of any mapping position is 0, it can be preliminarily determined that there is no conflict of this lock type, simplifying subsequent processing.

[0074] Understandably, lock-type Bloom filters can further limit the scope of conflict detection, optimizing the conflict detection step that originally required traversing all lock records into detecting only the conflicts of records hit by the Bloom filter, reducing the time complexity of conflict detection from O(n) to O(1), and improving the system response speed.

[0075] The time complexity is O(n): the execution time or resource requirements of an algorithm are a linear function of the input data size (n). Specifically, as the size of the input data increases, the algorithm's running time or resource requirements also increase linearly. For example, traversing an array or list typically has a time complexity of O(n) because each element needs to be accessed once. If the list has 100 elements, it requires 100 operations; if it has 1000 elements, it requires 1000 operations, and so on.

[0076] Time complexity O(1): The execution time or resource consumption of the algorithm does not increase with the increase of the input data size (n), but remains constant in time or space. That is, no matter how large the amount of input data is, the running time or required resources of the algorithm is fixed and will not increase. O(1) complexity operations can include: accessing any position in an array, accessing key-value pairs in a hash table, etc. These operations can be completed immediately through direct addressing or hash function calculation without traversing the entire data structure.

[0077] Step (3) If it is determined that there is a lock conflict of the same type among the multiple seventh operation requests in the multiple sixth operation requests, filter the multiple seventh operation requests to obtain the second operation request, wherein the first operation request includes: the multiple seventh operation requests.

[0078] Optionally, before or after performing pre-checking on the plurality of operation requests through the filter index in step S202 above, the method further includes: upon receiving a first lock request corresponding to a first top-level directory stored in the root path filter, counting based on a first counter in the root path filter to increment the value of the first counter by a first value, wherein the first counter is a counter corresponding to the first top-level directory; upon determining that a second lock request corresponding to a second top-level directory stored in the root path filter has been deleted, counting based on a second counter in the root path filter to decrease the value of the second counter to a second value, wherein the second counter is a counter corresponding to the second top-level directory; upon determining that a first file lock request under the request directory corresponding to the first directory filter has been received, counting based on a third counter in the first directory filter to increment the value of the third counter by a third value, wherein the third counter... The system uses a counter corresponding to the file indicated by the first file lock request. If it is determined that the second file lock request under the request directory corresponding to the second directory filter has been deleted, a count is performed based on the fourth counter in the second directory filter to increase the value of the fourth counter to a fourth value. The fourth counter is the counter corresponding to the file indicated by the second file lock request. The directory filter includes the first directory filter and the second directory filter. If it is determined that a first lock request of a first request type has been received, a count is performed based on the fifth counter in the lock type filter corresponding to the first request type to increase the value of the fifth counter to a fifth value. If it is determined that a second lock request of a second request type has been deleted, a count is performed based on the sixth counter in the lock type filter corresponding to the second request type to decrease the value of the sixth counter to a sixth value. Both the first request type and the second request type are read lock requests or write lock requests.

[0079] Understandably, this application also limits the counter update operation, specifically:

[0080] (1) Root path Bloom filter counter operation, including:

[0081] 1) Increment the first value: When a first lock request is received for the first top-level directory (e.g., / data (data directory)), MDS updates its corresponding first counter in the root path Bloom filter. For example, if a file under the / data directory is requested to be locked, MDS increments the first counter value mapped to that directory prefix by the first value, for example, increasing the first counter value from 5 to 6 (i.e., the first value).

[0082] 2) Reduce to the second value: When it is determined that the second lock request corresponding to the second top-level directory (e.g., / non_active) has been deleted, MDS updates its second counter in the root path Bloom filter. For example, if the lock under the / non_active directory is released, MDS reduces the value of the second counter mapped to that directory prefix to the second value, for example, reducing the value of the second counter from 14 to 13 (i.e., the second value).

[0083] (2) Catalog Bloom filter counter operation, including:

[0084] 1) Incrementing the third value: When a lock request for the first file in the requested directory corresponding to the first directory filter (e.g., / data / active_files (active files in the data directory)) is received, MDS updates its corresponding third counter in the first directory filter. For example, if the lock request is for / data / active_files / file1.txt (file 1, a text file in the list of active files in the data directory), then MDS increments the third counter value mapped to that file to the third value.

[0085] 2) Reduce to the fourth value: When it is determined that the second file lock request in the request directory corresponding to the second directory filter (e.g., / data / inactive_files (inactive files under the data directory)) has been deleted, MDS updates its fourth counter in the second directory filter, reducing the fourth counter value of the file mapping to the fourth value.

[0086] (3) Lock-type Bloom filter counter operation, including:

[0087] 1) Increment the fifth value: Upon receiving a first lock request of the first request type (such as a read lock request), MDS updates its corresponding fifth counter in the lock type filter. For example, if the request is a read lock, MDS increments the fifth counter value of the read lock type filter to the fifth value.

[0088] 2) Reduce to the sixth value: When it is determined that the second lock request of the second request type (such as a write lock request) has been deleted, MDS updates its sixth counter in the lock type filter, reducing the sixth counter value corresponding to the lock type to the sixth value.

[0089] In summary, by using a counter, the Bloom filter can more accurately reflect the real-time status of the lock operation, avoid the accumulation of false positives caused by the dynamic changes in the lock operation, and improve the accuracy and effectiveness of the Bloom filter.

[0090] Optionally, the calculation of the lock contention count corresponding to the second operation request in step S204 above includes: parsing the second operation request to determine the third request path corresponding to the second operation request; performing a hash operation on the third request path to determine the fourth hash value corresponding to the third request path; performing a modulo operation on the fourth hash value to determine the first region index corresponding to the fourth hash value, and determining the first initial lock region corresponding to the third request path based on the first region index; counting the number of lock contention counts contained in the first initial lock region based on a preset time interval, and determining the number of lock contention counts contained in the first initial lock region as the lock contention count corresponding to the second operation request.

[0091] Understandably, this application also specifies a dynamic partition locking strategy, which optimizes lock contention management by adjusting the lock region size in real time. Specifically:

[0092] 1) Parsing and Hash Calculation: When MDS receives a second operation request from a client, it parses the request to determine the actual third request path. For example, if a client sends a write operation request with the path: / user / profiles / user1000 / settings.json (where / user represents the user directory, / profiles represents the configuration folder, / user1000 represents a subdirectory of a specific user, and settings.json is a settings file stored in JSON (Lightweight Data Interchange) format), MDS can parse the specific file path to: / user / profiles / user1000 / settings.json.

[0093] Furthermore, MDS performs a hash operation on the parsed third request path. Any suitable hash function can be used, such as Message-Digest Algorithm 5 (MD5) or Secure Hash Algorithm 256 (SHA256), to convert the path into a fourth hash value. For example, the hash value of / user / profiles / user1000 / settings.json is 123456.

[0094] 2) Determining the Lock Region: MDS performs a modulo operation on the fourth hash value to determine the index of the first region corresponding to the fourth hash value. Assuming the number of lock regions is N, and the initial size of each region is S, initially each region contains S files or directories. By taking the modulo of 123456 with N, a number between 0 and N-1 can be obtained as the index of the first region.

[0095] 3) Lock Contention Count Statistics: The Dynamic Partition Lock strategy also includes real-time statistics of lock contention counts. MDS counts the number of lock contentions for each first initial lock region at preset time intervals (e.g., every 100ms) and uses this value as the lock contention count for the second operation request. The lock contention count reflects the busyness of the lock resources in a certain region, that is, the number of clients attempting to acquire the lock in that region at the same time.

[0096] The above technical solution can dynamically adjust the lock region size based on the number of lock contention attempts. When the number of lock contention attempts in a certain region is too high, the strategy will automatically reduce the region size and segment hot spots, thereby reducing lock contention and improving concurrent processing capabilities. Conversely, when the number of lock contention attempts is low, the strategy will merge cold spots, increase the region size, reduce lock management overhead, and improve resource utilization.

[0097] Optionally, the step S204 above, which determines the target lock region corresponding to the second operation request based on the number of lock contention attempts, includes the following methods:

[0098] Method 1:

[0099] Determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within the target time period prior to the current time; adjust the size of the first region corresponding to the first initial lock region based on the lock contention attempts and the historical maximum number of lock contention attempts; specifically: adjust the size of the first region using a seventh formula, wherein the seventh formula is: S is the size of the second region obtained after adjusting the size of the first region, S0 is the size of the first region, and C max Let C be the historical maximum number of lock contention attempts, α be the number of lock contention attempts, and α be an adjustment coefficient. The adjusted first initial lock region is then determined as the target lock region.

[0100] Understandably, Method 1 achieves this by monitoring and analyzing historical contention for lock requests. Specifically:

[0101] 1) Determine the historical maximum lock contention count: MDS needs to determine the historical maximum lock contention count in the first initial lock region (i.e., the lock region located by hash operation) corresponding to a specific operation request (e.g., the second operation request, i.e., the write operation request to / user / profiles / user1000 / settings.json) within a target time period before the current time (e.g., within ten minutes before the current time).

[0102] 2) Adjust the lock region size based on the number of lock contentions: MDS adjusts the lock region size based on the current number of lock contentions (C) and the historical maximum number of lock contentions (C). max Combined with the adjustment coefficient (α), the size (S0) of the first initial locking region is adjusted using the seventh formula mentioned above.

[0103] Where the current lock contention count C is close to the historical maximum lock contention count C max This means that the locked region faces high competition pressure. In the seventh formula (C... max -C) / C max The value will be smaller, and multiplying by S0 after adding the adjustment factor α will decrease S, thereby splitting the region, reducing the number of files in each sub-region, and ultimately reducing the range of lock contention; if the current lock contention count C is much lower than the historical maximum lock contention count C max In the seventh formula (C) max -C) / C max When the value is large, adding the adjustment coefficient α and multiplying by S0 will increase S, thereby merging adjacent low-competition regions, increasing the number of files in the locked region, improving resource utilization and reducing management overhead.

[0104] 3) Determine the target lock area: The adjusted lock area is then determined as the target lock area.

[0105] By using the above technical solutions, adjusting the lock area size enables the system to reduce lock management overhead under low load, while effectively dispersing lock contention and improving resource utilization under high load.

[0106] Method 2:

[0107] The process involves determining the historical maximum lock contention count in the first initial lock region corresponding to the second operation request within a target time period prior to the current time; determining a first size relationship between the lock contention count and the historical maximum lock contention count; if the first size relationship indicates that among the multiple lock contention counts corresponding to multiple second operation requests, there exists a first lock contention count that is less than or equal to the historical maximum lock contention count, then the second initial lock region corresponding to the first lock contention count is determined as a first low contention region; the first low contention regions are merged based on preset rules to generate a target lock region corresponding to the first lock contention count. If the first size relationship indicates that among the multiple lock contention counts corresponding to multiple second operation requests, there exists a third lock contention count that is greater than the historical maximum lock contention count, then the fourth initial lock region corresponding to the third lock contention count is determined as a first high contention region, and receiving lock requests for the first high contention region is suspended; the lock records contained in the first high contention region are allocated to multiple first sub-lock regions, wherein the target lock region corresponding to the third lock contention count includes: any one of the first sub-lock regions.

[0108] Understandably, dynamic lock region adjustment also includes the identification and merging of low-contention regions, specifically:

[0109] 1) Determine the historical maximum number of lock contention attempts: When MDS receives a second operation request, in addition to evaluating the number of lock contention attempts in the current lock region, it also needs to determine the historical maximum number of lock contention attempts in the first initial lock region (i.e., the lock region allocated to this request) corresponding to the second operation request within a target time period (e.g., 10 minutes) before the current time.

[0110] 2) Determine the lock contention levels: Compare the current lock contention count C with the historical maximum lock contention count C. max The first size relationship between them.

[0111] 3) Determination and Merging of the First Low-Content Region: Once the first size relationship between the number of lock contentions and the historical maximum number of lock contentions indicates that there are contention counts lower than the historical maximum, the second initial lock region with a contention count lower than or equal to the historical maximum number of lock contentions is marked as the first low-contention region. Subsequently, these first low-contention regions are merged based on preset rules to generate the target lock region.

[0112] The merged target lock regions will have a wider range of files and greater lock management granularity. For example, the size of each region, which originally contained 128 files, will be adjusted to 256 or more, thereby reducing the number of locks in the system and reducing the additional overhead of lock management.

[0113] 4) Determine the first high contention region: Once the first size relationship between the number of lock contentions and the historical maximum number of lock contentions is determined, indicating that there is a contention number higher than the historical maximum, mark the second initial lock region with the contention number higher than the historical maximum number of lock contentions as the first high contention region.

[0114] 5) Pause Lock Request Reception: Once the first highly contentious region is identified, pause receiving lock requests for that region. This prevents new lock requests from interfering with the splitting process, ensuring the correctness of the splitting operation and data consistency.

[0115] 6) Lock record reallocation: All lock records in the first highly contested region are distributed to multiple first sub-lock regions. Each first sub-region will independently manage its own lock resources, thereby distributing lock contention. Specifically, the original region can be remapped according to the hash value of the file path, dividing it into two or more sub-regions, each assigned an independent read-write lock.

[0116] By employing the above technical solutions, under low-contention conditions, merging the first low-contention region can effectively reduce the number of locks, lower lock management overhead, and free up more resources for data transmission and processing, thereby improving overall system efficiency. Simultaneously, automatically splitting the first high-contention region can disperse hotspots, reduce the concentration of lock contention, and thus increase the throughput of concurrent operations.

[0117] Method 3:

[0118] A second size relationship is determined between the number of lock contention attempts and a first preset threshold. If the second size relationship indicates that among the multiple lock contention attempts corresponding to multiple second operation requests, there is a second lock contention attempt that is less than or equal to the first preset threshold, the third initial lock region corresponding to the second lock contention attempt is determined as the second low contention region. The second low contention region is merged based on a preset rule to generate the target lock region corresponding to the second lock contention attempt.

[0119] A third size relationship is determined between the number of lock contentions and the second preset threshold; if the third size relationship indicates that there is a fourth lock contention number greater than the second preset threshold among the multiple lock contention numbers corresponding to multiple second operation requests, the fifth initial lock region corresponding to the fourth lock contention number is determined as the second high contention region, and the reception of lock requests to the second high contention region is suspended; the lock records contained in the second high contention region are allocated to multiple second sub-lock regions, wherein the target lock region corresponding to the fourth lock contention number includes: any second sub-lock region.

[0120] Understandably, by monitoring the relationship between the number of lock contention attempts and a preset threshold, dynamic adjustment of the lock region can also be achieved, that is, merging low-contention lock regions and splitting high-contention lock regions. Specifically:

[0121] 1) Determine the second relationship between the number of lock contentions and the preset threshold: Determine the second relationship between the number of lock contentions corresponding to multiple second operation requests (i.e., multiple read and write operation requests to the file system) and the first preset threshold within the target time period before the current time. For example: Assuming that the first preset threshold T1 is set to 50 times / second, if the number of lock contentions C2 in a certain region is less than or equal to T1 (i.e., C2≤T1), then that region is determined as the second low contention region.

[0122] 2) Merge the second lowest competition region: Once a region is identified as the second lowest competition region, it is merged based on preset rules to generate the target lock region.

[0123] The purpose of merging operations is to reduce the number of lock regions, thereby reducing lock management overhead and improving resource utilization.

[0124] For example, if the number of lock contention events in lock regions 56 and 57 is lower than or equal to the first preset threshold T1 within the same time period, these two regions are considered the second lowest contention regions. They can be merged into a new region, such as region 56A, and the target lock region is this merged region 56A.

[0125] 3) Determine the third relationship between the number of lock contentions and the second preset threshold: Determine the third relationship between the number of lock contentions corresponding to multiple second operation requests and the second preset threshold within the target time period before the current time. For example, assuming the second preset threshold T2 is set to 150 times / second, if the number of lock contentions C4 in a certain area is greater than T2 (i.e., C4>T2), then that area is determined as the second high contention area.

[0126] 4) Splitting the Second Highest Contention Region: Once a region is identified as the second highest contention region, suspend receiving lock requests for that region to avoid unnecessary lock contention during the splitting operation. Then, distribute the lock records of the original region to multiple second sub-lock regions, ensuring that each sub-region has sufficient resources to handle its operation requests.

[0127] For example, if the number of lock contention attempts in lock region 58 suddenly jumps to 200 times per second, exceeding the second preset threshold T2, the MDS will suspend receiving new lock requests for region 58 and redistribute the lock records contained in that region to two second sub-lock regions, namely 58A and 58B. In this way, lock contention that was originally concentrated in region 58 is distributed to the two sub-regions.

[0128] In summary, merging the second least contested region reduces the number of locks, lowers lock management overhead, and improves system resource utilization. Splitting the second most contested region disperses hotspot contention, reduces the likelihood of lock conflicts, and thus improves concurrency performance.

[0129] Optionally, after performing a pre-screening of the plurality of operation requests through the filter index in step S202 above to filter out the first operation request among the plurality of operation requests and obtain the second operation request, the method further includes: if it is determined based on the root path filter, directory filter and lock type filter that the first operation request does not exist among the plurality of operation requests, prohibiting the calculation of the lock contention count corresponding to the second operation request, and determining that the one or more clients are allowed to execute the plurality of operation requests.

[0130] Understandably, this application also specifies a fast request pre-screening mechanism utilizing multi-level Bloom filters (root path filter, directory filter, and lock type filter). Specifically, a three-level Bloom filter is used to pre-screen operation requests to determine whether there is a need to acquire a lock. If the root path filter, directory filter, and lock type filter determine that there is no lock contention related to the first operation request among multiple operation requests (i.e., the path prefix, target file, or lock type of the first operation request is not marked in the Bloom filter), it can be quickly determined that these operation requests do not require lock contention calculation, thus allowing the client to execute directly. Through the above pre-screening, if all three-level filters do not detect the existence of a lock related to the first operation request, then the client can be directly allowed to execute the second operation request without further calculating the lock contention count for the second operation request. This is because the Bloom filter pre-screening mechanism can effectively filter out operation requests that will not cause lock contention.

[0131] To better understand the process of acquiring the partition lock described above, the implementation flow of the method will be further explained below with reference to optional embodiments, but this is not intended to limit the technical solution of the embodiments of this application.

[0132] Distributed storage systems aim to solve the bottlenecks of traditional storage architectures in terms of scalability, reliability, and performance. Their core architecture integrates the functions of object storage, block storage, and file systems. They use a reliable and autonomous distributed hashing algorithm (Controlled Replication Under Scalable Hashing, or CRUSH algorithm) to achieve automatic data distribution and management without a central node. Through decentralized design, dynamic expansion mechanisms, and multi-replica and erasure coding fault tolerance strategies, they balance high performance and high availability and are widely used in fields such as cloud computing, big data, and artificial intelligence (AI).

[0133] MDS originated from the need for efficient metadata management in distributed file systems, aiming to solve the performance bottlenecks and scalability issues of traditional centralized metadata servers. Its core technical architecture is based on the Reliable Autonomic Distributed Object Store (RADOS) underlying storage, using the CRUSH algorithm to achieve distributed storage and automatic management of metadata. It supports master-slave or multi-active deployment modes with multiple MDS nodes to improve the concurrent processing capabilities of metadata operations. MDS employs a layered caching mechanism (e.g., memory caching, solid-state drive (SSD) caching) to accelerate metadata access, and optimizes the efficiency of metadata operations in scenarios with a large number of small files through technologies such as directory sharding and transaction logs. Simultaneously, it leverages consensus protocols such as the Paxos / Raft Consensus Algorithm (Paxos / Raft) to ensure strong consistency of metadata replicas. This gives it dynamic scalability, high availability, and low latency metadata management capabilities in massive file storage scenarios (e.g., AI training data, scientific research datasets), making it a key component for achieving high-performance file storage in distributed storage file systems.

[0134] In distributed storage file systems, under multi-threaded concurrent operation environments, existing technologies achieve concurrency control through POSIX read-write locks or hardware atomic operations (e.g., the x86 architecture's LOCK ADD Instruction, or simply x86 LOCK ADD). However, these technologies lack a dynamic adaptation mechanism in distributed storage metadata lock management.

[0135] The following lock management mechanisms also exist in related technologies:

[0136] Fixed partition locks: However, the fixed partition lock scheme still has the problem that when the operation involves multiple partitions, it is necessary to acquire locks for multiple partitions, which increases the probability of deadlock and complicates the operation process, reducing the efficiency of the system.

[0137] State machine-based lock management: Locks are managed by constructing a state machine that defines various lock states (e.g., read lock, write lock, exclusive lock) and state transition rules. When a client requests a lock, the MDS (Multi-Threading System) determines whether locking is allowed and performs state transitions based on the state machine rules, thus handling complex concurrent request scenarios. However, state machine-based lock management suffers from several drawbacks: high state transition overhead; as concurrent requests increase, state machine judgments and transitions consume significant system resources, leading to increased latency and impacting system performance; and difficulty in managing the waiter queue: after lock waiting requests enter the waiter queue, the wake-up mechanism may trigger the "thundering herd effect," where multiple waiting threads are woken up but only one can acquire the lock, resulting in resource waste and performance degradation.

[0138] Locking strategies tied to metadata structures: Different types of locks are set for different metadata structures (e.g., index nodes (Inodes) and directory entries (Dentries)). For example, Dentry uses Device Node Name (DN) and Directory Version (DVERSION) locks, while Inodes use various other types of locks. The appropriate type of lock is applied to the relevant metadata structure based on the specific operation type (create, delete, modify, etc.). However, the above technical solution suffers from high locking strategy coupling: the locking strategy is tightly dependent on the metadata structure, making complex operations (such as batch file deletion, directory movement, etc.) require acquiring multiple different types of locks simultaneously, resulting in cumbersome operation processes and a high risk of lock conflicts; it also lacks overall optimization: locks for different metadata structures are managed independently, making it difficult to optimize at the system-wide level, leading to low efficiency when handling complex operations involving multiple metadata structures.

[0139] Furthermore, in traditional architectures, file I / O requests initiated by clients require complex metadata processing, specifically:

[0140] 1) The file system client sends a path resolution request to MDS, and MDS locates the Inode metadata corresponding to the file by traversing the directory tree (Dentry);

[0141] 2) The client requests lock resources from the MDS based on the operation type (read / write). The MDS determines whether to grant lock permissions based on the global lock or fixed partition lock policy. If the lock is successfully acquired, the client obtains the data location information and directly interacts with the OSD.

[0142] However, this process exposes significant bottlenecks in high-concurrency scenarios: global locks cause request serialization, fixed partition locks cannot dynamically adapt to the load, and each lock request requires traversing the lock record to detect conflicts (time complexity O(n)), making MDS a key bottleneck for system performance.

[0143] Based on the above problems, this application proposes an optional embodiment of a method for dynamically partitioning lock requests in a distributed storage metadata server (MDS) using multi-level Bloom filters. This method relates to the field of distributed storage technology and aims to improve the concurrency performance and stability of distributed storage systems. Specifically, by constructing a three-level Bloom filter index (root path, directory, lock type) in the MDS metadata lock management module, multi-level fast pre-checking of lock requests is achieved. Combined with a dynamic partitioning lock mechanism and cross-architecture atomic update technology, the problem of low concurrency performance and severe lock contention in traditional lock strategies is solved. The main method flow is as follows: First, a three-level Bloom filter is constructed: the root path filter (m1=65536, k1=4) filters invalid path prefixes, the directory filter (m2=32768, k2=3) detects active locks on target files, and the lock type filter (m3=8192, k3=2) filters for lock conflicts of the same type. These three pre-checks can filter more than 30% of invalid requests. Second, a dynamic partitioning lock mechanism is adopted, initially dividing the system into N regions (S=128 files / region) according to path hashes. An algorithm is then used to... ( Adjusting the area size in real time, especially during periods of high competition. The lock request processing flow was reduced to 32, and expanded to 1024 under low contention conditions. After splitting hotspot regions, the number of contention events decreased by 85%. Finally, the lock request processing flow was optimized. Partition locks were located through path hashing, and the counter was atomically updated using the LOCK ADD instruction (a lock addition instruction provided by x86 architecture processors) on the x86 platform. The latency was reduced from 200ns to 80ns. Other architectures were compatible and adapted using pthread_rwlock (thread read-write lock). This solution improved lock request processing throughput by 200% and reduced average latency by 74%, effectively solving the performance bottleneck of distributed storage metadata lock management.

[0144] Among them, the Bloom filter addresses the space and efficiency bottlenecks in processing large-scale data using set structures in related technologies. It combines hash functions with bit arrays to achieve efficient data filtering through probabilistic judgment, achieving a space complexity as low as zero. Its core applications include database cache penetration protection, spam interception, Uniform Resource Locator (URL) deduplication in search engines, and blockchain transaction verification. It can store 100 million elements in 20MB of memory and perform fast queries. With its advantages in space and time efficiency, it has become a key technology for filtering massive amounts of data in the era of big data.

[0145] The core value of applying Bloom filters to MDS locks lies in: quickly filtering invalid lock requests, reducing lock table query overhead, and decreasing distributed synchronization costs. Despite limitations on false positives and deletions, performance and accuracy can be balanced in real-world scenarios through parameter tuning and periodic reconstruction mechanisms, making it a key optimization technique for metadata management in large-scale distributed file systems.

[0146] Figure 3 This is a distributed storage system architecture diagram according to an optional embodiment of this application, such as... Figure 3 As shown:

[0147] The distributed storage system adopts a decentralized, distributed architecture. Its core components include: clients, monitors, MDS (metadata server), and object storage devices (OSDs). These modules collaborate via high-speed networks (e.g., Ethernet, InfiniBand) to achieve data storage and management. The architecture layers are explained below:

[0148] 1. Client layer (i.e., Figure 3 Distributed storage client):

[0149] position:

[0150] The entry point for users to interact with distributed storage provides three interfaces: block, object, and file.

[0151] Core components:

[0152] The librados library (RADOS client library) encapsulates the underlying Application Programming Interface (API) and is responsible for interacting with the cluster.

[0153] The CRUSH client module uses a local cache CRUSH Map to calculate data storage locations. Input options include: object name, storage pool rules (e.g., number of replicas, fault domain level). Processing steps: Generate random numbers based on object name hashes. Iterate through the CRUSH bucket hierarchy (e.g., host → rack → data center) according to storage pool rules, selecting OSDs based on weights. Ensure balanced data distribution and meet redundancy policies (e.g., deploying replicas across racks).

[0154] 2. Distributed storage system:

[0155] This includes: object gateway services that interact with objects, block device services that interact with blocks, and file system services that interact with files.

[0156] 3. Control Plane (Monitor / MDS):

[0157] Monitor (e.g.) Figure 3 The monitoring service cluster 1…n): maintains cluster metadata (OSD Map, CRUSH Map, authentication information) and ensures consistency among multiple nodes through the Paxos algorithm.

[0158] Interaction with the client: When the client connects for the first time, it pulls the latest cluster map and updates it synchronously via heartbeat.

[0159] MDS (File Scenario, such as) Figure 3 MDS metadata cluster 1…n): manages file system metadata (directory tree, permissions), and caches hot metadata to accelerate access.

[0160] In this optional embodiment, the distributed storage system is optimized for MDS file lock requests. Specifically, the optimization of MDS file lock requests is achieved through the following structure:

[0161] The MDS metadata lock management module, the three-level Bloom filter index module (including: root path filter, directory filter and lock type filter), the dynamic partition lock management module and the atomic operation adaptation module work together to execute the lock request processing flow.

[0162] 4. Data plane (OSD cluster): MDS metadata cluster 1…n.

[0163] OSD Node: Hardware Components: Central Processing Unit (CPU), memory, disks (Hard Disk Drive (HDD) / Solid State Drive (SSD)), and network interface (Gigabit / 10 Gigabit Ethernet). It is responsible for data storage, replication, erasure coding, consistency maintenance, and understands the cluster topology through the OSD Map.

[0164] 5. A storage pool that, together with MDS metadata clusters 1…n and monitoring service clusters 1…n, forms a unified, self-controlled, and scalable distributed storage consistency management system, including:

[0165] 1) Storage pool 1, storage pool 2, ..., storage pool n;

[0166] 2) Controllable and scalable distributed data leveling algorithm (CRUSH): ensures that data is evenly distributed throughout the cluster, while taking into account data redundancy and fault domain.

[0167] 3) Group 1, Group 2, Group 3, ..., Group n: This indicates that the physical storage device is divided into multiple groups, and each group can contain multiple storage nodes, which facilitates management and optimization of data distribution.

[0168] 4) Storage backend engine;

[0169] 5) Nodes 1, 2, ..., n in OSD1...n.

[0170] Figure 4 This is a flowchart of a distributed storage metadata lock optimization method based on a multi-level Bloom filter according to an optional embodiment of this application, which can be applied to... Figure 3 In the system, specifically, such as Figure 4 As shown:

[0171] Step S401: Receive client requests (e.g., a lock request for / data / file.txt (i.e., requesting the lock resource for / data / file.txt)).

[0172] Clients in a distributed storage system send file operation requests to the MDS;

[0173] Step S402, MDS path resolution → top-level directory prefix / data;

[0174] Extract the top-level directory prefix from the request path (e.g., / data in / data / file.txt).

[0175] In the distributed storage I / O process, the file path requested by the client (such as / data / file.txt) needs to be parsed first, along with the top-level directory prefix (such as / data).

[0176] After parsing the top-level directory prefix, optional embodiments of this application construct a three-level Bloom filter index for root path, directory, and lock type to achieve multi-layered fast pre-detection of lock requests. Specifically, the root path filter quickly locates whether an active lock exists in the request path prefix; the directory filter checks whether the first file has a lock record in the current directory; and the lock type filter further filters for lock conflicts of the same type. That is, in the distributed storage file system read / write I / O chain, the three-level filters form a layer-by-layer filtering mechanism of "path prefix → directory file → operation type". This three-step pre-detection can filter more than 30% of invalid requests, narrowing the conflict detection range from the entire set of lock records to the minimal set hit by the Bloom filter.

[0177] Step S403, root path filter check (m1=65536, k1=4).

[0178] The root path filter stores the top-level directory prefixes corresponding to all active locks.

[0179] Root path Bloom filter: In the distributed storage I / O process, the file path requested by the client (e.g., / cluster / data / file.txt) needs to first parse the top-level directory prefix (e.g., / cluster). The root path Bloom filter stores the top-level directory prefixes corresponding to all active locks. Its parameter setting logic is as follows: Store the top-level directory path prefix, bit array size m1=65536, k1=4, through the formula... The false positive rate p is calculated and controlled to be ≤0.001 to quickly locate whether there is an active lock in the path prefix. The bit array size is set to m1=65536, and k1=4, determined according to the following method: Assuming the MDS metadata service is expected to manage n=10000 top-level directories, the false positive rate formula for the Bloom filter is: (i.e., the first formula) requires controlling the false positive rate p≤0.001, combined with the formula for the optimal number of hash functions: (i.e., the second formula) Solving the simultaneous equations, we get m1≈65536 (2^16) and k1≈4. At this time, p1≈0.00098≤0.001, which meets the requirements of high reliability pre-inspection.

[0180] The invalid paths filtered out by the root path filter are those whose top-level directory prefix does not contain any active lock records in the current MDS metadata lock management context.

[0181] Step S404: Determine if an active lock prefix exists;

[0182] Use a root path Bloom filter (m1=65536, k1=4) to detect whether there are active lock records associated with the top-level directory prefix.

[0183] If the root path filter indicates that there is no active lock (i.e., the first active lock) associated with this top-level directory prefix, it means that there is currently no lock contention for this top-level path prefix, and the path resolution request can be allowed directly without entering the subsequent lock contention check (i.e., executing step S405).

[0184] If the root path filter may have an active lock (i.e., the root path Bloom filter returns "true"), then proceed to the next step of the directory Bloom filter check (i.e., execute step S406).

[0185] In this context, active lock records refer to locks (such as read locks and write locks) currently held by clients in the MDS. The root path filter quickly determines whether a path prefix belongs to the set of "potentially active locks" through the probabilistic mapping of the Bloom filter. For example, a client requests access to / non_exist_dir / file.txt (where / non_exist_dir is a file in a non-existent directory, and / file.txt is the filename to be accessed in that directory path), but the non_exist_dir directory has never been created in the MDS. Therefore, the top-level directory prefix / non_exist_dir has no mapping record in the root path filter. Alternatively, the directory / data has been created, but currently, no clients hold any locks (read locks / write locks) on this directory or its child nodes. In this case, when a client requests the lock on / data / file.txt, the / data prefix has no active lock record in the root path filter.

[0186] In other words, the root path filter is triggered for pre-checking when it first enters the lock processing flow after the MDS completes path resolution.

[0187] The technical logic of the root path filter is as follows: Parse the top-level directory prefix of the path (e.g., / data), and query the root path Bloom filter (m1=65536, k1=4). If no corresponding mapping exists, it is determined to be an invalid path and directly returned to the client (without entering subsequent lock contention), reducing invalid IO requests by more than 30%; Algorithm processing: False positive rate, ensuring that more than 99.9% of invalid paths are correctly filtered.

[0188] Step S405: If the root path filter indicates that there is no active lock associated with this top-level directory prefix, allow the passage directly and process normally.

[0189] Step S406: If the root path filter indicates the existence of an active lock associated with this top-level directory prefix, the directory (Bloom) filter checks (m2=32768, k2=3).

[0190] Once the root path filter passes the check, the path continues to be resolved to the specific directory (e.g., / data).

[0191] Directory Bloom Filter: Dynamic management of filename indexes. When the IO process parses to a specific directory (e.g., / cluster / data), the directory Bloom filter indexes the filenames in that directory. Each directory has an independent filter, m2=32768, k2=3, storing the filename indexes in the directory. A counting Bloom filter is used, with a 16-bit integer counter, supporting deletion operations. The settings m2=32768 and k2=3 are based on the expectation of storing n=5000 files per directory. Calculated using formulas three and four, m2=32768(2^15) and k2=3, where p≈0.0015≤0.002. A 16-bit counter array (counter range 0~65535) is used, supporting counter decrementing during file deletion to avoid false positive accumulation.

[0192] Step S407: Check if there is an active lock (i.e., a second active lock) in the file file.txt (the requested file name).

[0193] Use a Bloom filter (m2=32768, k2=3) for this directory to check if there are any active lock records in the current directory related to the requested filename;

[0194] If the directory Bloom filter indicates that there are no relevant active locks, it means that there is currently no lock contention for the first file. The process of acquiring the directory-level lock can be skipped, and the client can be directly allowed to perform file operations (i.e., execute step S408).

[0195] If the directory filter returns that there may be an active lock (i.e., the directory Bloom filter hits), then continue to check the lock type Bloom filter to further narrow down the scope of conflict detection (i.e., execute step S409).

[0196] In other words, the directory filter is triggered when it checks the root path: after the root path filter passes, it locates the target directory (such as / data);

[0197] The technical logic of the directory filter is as follows: A directory Bloom filter (m2=32768, k2=3) is used to check if an active lock record exists for the first filename (e.g., file.txt). If not, MDS directly allows the operation without acquiring a directory-level lock, saving 20-50μs of lock contention time.

[0198] Step S408, skip lock acquisition;

[0199] Step S409, lock type filter check (m3=8192, k3=2).

[0200] After the directory filter check passes, confirm the type of operation requested by the client (read or write).

[0201] For rapid filtering of read-write lock conflicts, during the IO operation type confirmation stage (e.g., read / write operation), the lock type filter is subdivided by operation type index, specifically by read lock / write lock, with m3=8192 and k3=2, accelerating the detection of conflicts of the same type of lock. In an optional embodiment of this application, for both read and write lock operations, n3=2000 times / second, m3=8192 (2^13), k3=2, and p≈0.008, the requirements for rapid conflict filtering are met.

[0202] Step S410: Determine if there is a conflict between locks of the same type (read lock or write lock);

[0203] Once the directory filter passes, the corresponding lock type filter is queried based on the operation type (read / write). Conflict detection is performed only on the matched lock records, reducing the complexity from O(n) to O(1). Specifically, a dedicated lock type Bloom filter (m3=8192, k3=2) is used to check for conflicts between locks of the same type (read lock or write lock).

[0204] If the lock type filter indicates that there are no lock conflicts of the same type, the scope of conflict detection can be further narrowed, and conflict detection can be performed only on the records hit by the Bloom filter, instead of traversing the entire lock record set (i.e., execute step S411).

[0205] If the lock type filter is hit, it indicates that there may be a conflict between locks of the same type, and it is necessary to enter the lock conflict detection phase (i.e., execute step S412).

[0206] In other words, the timing of the lock type filter is triggered after the operation type (read / write) is determined; the technical logic is to query the corresponding lock type filter (m3=8192, k3=2) according to the operation type (such as write lock), and only perform conflict detection on the hit lock records, reducing the number of lock records to be traversed from n to n×p (p≤0.008), and reducing the conflict detection time from O(n) to O(1).

[0207] Through the above three-level lock filtering mechanism, the lock request processing time is reduced from 300ms in the traditional solution to about 120ms, and the number of hardware bus contention times is reduced by 75%, fundamentally optimizing the metadata lock bottleneck in the distributed storage IO process.

[0208] Step S411, allow operation;

[0209] Step S412, Dynamic partition lock acquisition: Path hash to locate the region;

[0210] The core value of dynamic partition locks lies in upgrading the "static partitioning" of traditional fixed partition locks to "load-adaptive partitioning," thus solving the problem of competition for hot areas during peak IO periods.

[0211] The specific steps for dynamically partitioning lock regions include:

[0212] 1) Initial Partitioning: Balanced partitioning based on path hashing. A hash operation (e.g., MD4) is performed on the file paths under the directory, and the hash value is mapped to N regions using a modulo operation. Each region initially contains S=128 files. For example, when the directory contains 10,000 files, the initial partitioning is N=10000 / 128≈78 regions. Coupling with the I / O process: When a client requests / data / file.txt, MDS calculates the hash value of file.txt, takes the modulo to obtain the region index, and directly locates the corresponding partition lock, avoiding global lock contention. When the client sends a file operation request (e.g., write / data / file.txt) to MDS, MDS completes path resolution and performs a three-level Bloom filter pre-check (root path → directory → lock type). If all matches, it enters the initial partitioning stage. At this time, MDS performs a hash operation (e.g., MD4) on the file paths under the target directory, mapping the hash value to N regions using a modulo operation. Each region initially contains S=128 files, and each region corresponds to an independent read / write lock.

[0213] 2) Dynamic adjustment mechanism: Based on adaptive optimization of the number of contention attempts, the number of lock contention attempts (C) in each region is periodically counted, and the region size is adjusted according to the formula: .

[0214] Where S is the current region size (the number of files contained in each region); The initial region size (128) is set to 128 because it needs to match the CPU L2 cache line size (128 KiB). Each region occupies approximately 128 × 2B (counter) = 256B of memory, and the 64 regions total 16 KiB, which can fully reside in the L1 cache, reducing memory access latency. α = 0.3 is an adjustment coefficient to control the adjustment sensitivity and avoid frequent oscillations. It is set to 0.3 because this coefficient keeps the region size adjustment range within ±30% / time, thus avoiding excessively slow adjustments. Too small an alpha value leads to hotspot accumulation, while too large an alpha value prevents excessive lock structure reconstruction overhead; C is the number of lock contention attempts in the current region (times / second); C max The highest number of competitions in history (peak in the past 10 minutes). When C > 0.8C maxWhen C < 0.2C, it indicates high competition. S is reduced to half its original size (minimum 32) to split the hotspot region and reduce competition. max When there is low competition, S is increased to twice its original size (maximum 1024), and cold areas are merged to reduce lock management overhead.

[0215] Triggering timing in the IO process: Every 100ms, count the number of lock contention times in each region (obtained through the wait_count parameter of pthread_rwlock) to trigger dynamic adjustments and ensure a fast response when the IO load changes suddenly (such as batch file creation).

[0216] 3) Hotspot Area Splitting: Fine-grained unlock contention. When the number of contention events in a region exceeds 100 times / second (experiments show that the bus conflict rate exceeds 70% at this threshold), a split operation is triggered. The split process is as follows: suspend new lock requests for the region; remap the lock records of the original region to two sub-regions according to their hash values; allocate independent read-write locks to each sub-region; resume lock requests, and new requests are allocated according to the sub-region hashes. An optional embodiment of this application considers lock compatibility and proposes that during the split process, ongoing IO requests are not affected; only new requests are processed according to the new partitioning rules, avoiding IO interruptions. Specifically, based on an optional embodiment of this application, the threshold is chosen so that when the number of contention events exceeds 100 times / second, it is because the bus arbitration latency increases from 50ns to 200ns; triggering a split can reduce the latency back to within 80ns.

[0217] In summary, the optional embodiments of this application introduce a dynamic partition lock mechanism based on the number of contention attempts, and the optional embodiments of this application propose an algorithm formula. (i.e., the seventh formula) adjusts the size of the locked area in real time, focusing on hotspot areas (C > 0.8C). max Automatic splitting, cold region (C < 0.2C) max Dynamic merging ensures precise matching of lock granularity with load.

[0218] This involves traversing the potentially conflicting lock records filtered by the Bloom filter and checking the actual lock status. The lock region to which the file belongs is determined based on the path hash, and the lock for the corresponding partition is acquired. Read operations use shared locks, while write operations require exclusive locks.

[0219] In other words, partition lock acquisition involves locating the lock region based on the path hash and acquiring the corresponding read-write lock (shared lock for read operations, exclusive lock for write operations).

[0220] The triggering time for partition lock acquisition is: after all three levels of filtering are hit, the actual lock contention phase begins;

[0221] Technical logic: Calculate the target file path hash value and locate the lock region according to the dynamic partitioning rules (current region size S); read operations acquire shared locks (allowing multi-threaded concurrency), and write operations acquire exclusive locks (single-thread exclusive); if lock acquisition fails (conflict), enter the waiter queue to wait, avoiding CPU spinning waste; performance correlation with IO process: dynamic partitioning reduces the number of lock contention times in an 8-thread scenario from 10^6 times / second to 1.5×10^5 times / second, and increases IO throughput by 316% (e.g., from 1200ops / s to 3800ops / s).

[0222] Through the process steps S412 described above, optimizations were made for high-concurrency scenarios. When the IO load suddenly increases (e.g., 100 clients simultaneously operating on the same directory), the dynamic partition lock quickly splits the region size from 128 to 32, reducing lock contention from 800 times / second to 200 times / second, and increasing IO throughput by 210%. Resource utilization is improved: Under low load, the region size expands to 1024, the number of locks decreases from 78 to 10, and lock management overhead decreases from 35% of IO time to 8%, freeing up CPU resources to handle actual data transmission. Hardware affinity optimization: The dynamically adjusted region size is always a power of 2 (32 / 64 / 128 / 1024), matching the memory paging mechanism (4KiB pages), reducing memory fragmentation and cross-page access.

[0223] In summary, by deeply integrating dynamic partition locks into the file I / O process through the above step S412, the optional embodiments of this application realize a closed loop of "load awareness - dynamic adaptation - performance optimization" for metadata lock management, fundamentally solving the problems of hotspot competition and resource waste of fixed partition locks in related technologies.

[0224] Step S413, Conflict detection: Traverse the Bloom filter hit records;

[0225] Conflict detection reduces the time complexity from O(n) to O(1) by filtering potentially conflicting lock records using a Bloom filter and only iterating through records that are hit by the Bloom filter.

[0226] The timing for triggering conflict detection is: after acquiring the partition lock, but before executing any specific operation;

[0227] Technical logic: The lock records hit by the Bloom filter account for only p (≤0.008) of the total number of records, which greatly reduces the traversal range; for the hit records, check whether the lock range (such as byte-level lock) is conflicting, and allow the IO request after confirming that there is no conflict;

[0228] Time consumption comparison: The traditional solution takes 300μs to traverse 1000 lock records, while this solution only traverses 8 records (1000×0.008), reducing the time consumption to 20μs and the IO latency from 359ms to less than 120ms.

[0229] Step S414, atomic operation to update counter (x86: LOCK ADD).

[0230] For the Bloom filter counter update stage, by combining hardware atomic operations (e.g., the x86 platform LOCK ADD instruction) with lock protection mechanisms (ARM platform mutex lock), a cross-architecture compatible and efficient update is achieved, reducing the counter update latency from 200ns to 80ns.

[0231] The specific steps for updating the counter using atomic operations include:

[0232] 1) Architecture adaptation and update logic triggering timing: After successful lock acquisition, before (adding the lock) or after (releasing the lock) the I / O operation is executed. Technical implementation: x86 architecture: Use the LOCK ADD instruction to atomically update the counter of the Bloom filter, such as: LOCK ADD DWORD PTR[counter], 1; atomically increment the counter.

[0233] Single update latency was reduced from 200ns to 80ns, and bus contention was reduced by 60%. Other architecture features: pthread_rwlock protects counter updates, ensuring cross-platform compatibility. Update logic: When adding a lock: the corresponding hash position counter is incremented by 1 to record the active lock state; when releasing a lock: the counter is decremented by 1 (if ≥ 1), to avoid false positive accumulation.

[0234] 2) Technical basis for the parameters in the example: Bloom filter parameters (when n=10000): m=65536, k=4, at which time the false positive rate is... This meets data consistency requirements; the 16-bit counter supports a maximum count of 65535, suitable for high-frequency I / O scenarios (e.g., 100,000 operations per second for 6553 seconds). Dynamic parameter adjustment: C max The maximum number of contention attempts in the past 10 minutes is taken to adapt to the periodic fluctuations of IO load (such as weekday peaks and nighttime troughs); α=0.3 ensures that the area size adjustment range is moderate and avoids IO process jitter caused by frequent partition rebuilding.

[0235] The IO processing flow of the distributed storage system in the optional embodiments of this application can be divided into the following core stages: Client request stage: The client sends a file operation request (such as write / data / file.txt) to the MDS; Path resolution stage: The MDS resolves the path and locates the target directory (such as / data); Metadata lock processing stage: Three-level Bloom filter pre-check; Dynamic partition lock acquisition; Conflict detection and counter update; Data access stage: The MDS returns the data location, and the client interacts with the OSD; Lock release stage: The lock is released after the operation is completed, and the Bloom filter counter is updated.

[0236] In summary, the optional embodiments of this application transform the metadata lock bottleneck in the traditional IO process into a performance acceleration point, which is particularly suitable for high-frequency IO scenarios such as big data analysis and cloud storage, providing core technical support for the large-scale deployment of distributed storage systems. Invalid request filtering chain: Three-level Bloom filtering intercepts 30% of invalid IO requests, reducing MDS computing power consumption; Dynamic lock granularity adaptation: The partition size is adjusted in real time according to the IO load, splitting hot areas under high concurrency and merging cold areas under low load, improving hardware resource utilization by 85%; Atomic update and conflict detection optimization: Counter update latency is reduced by 60%, conflict detection time is shortened by 93%, and end-to-end IO latency is reduced from 359ms to 80-120ms; Cross-architecture compatibility: Automatic adaptation to hardware characteristics through compile-time macro definitions ensures performance consistency under different IO scenarios.

[0237] Optional embodiments of this application can also extend the three-level Bloom filter architecture to edge distributed storage scenarios, combining the lightweight characteristics of edge nodes to optimize parameters (such as reducing the bit array to 8KB) to solve the metadata lock conflict problem of edge devices; combined with AI load prediction algorithms, the model is trained through historical competition data to adjust the lock region division threshold in advance, achieving "prediction-adaptation" dual-drive optimization; the characteristics of new storage media (such as 3DX Point (three-dimensional cross-point memory)) are integrated, and the counter atomic operation logic is reconstructed to take advantage of its low latency, further reducing the update latency to 50ns; extended to cross-cloud storage environments, the cross-region lock synchronization strategy is dynamically adjusted through the Bloom filter hash collision probability to reduce the overhead of cross-data center lock conflicts; a Bloom filter status visualization monitoring module is developed to display the false positive rate and lock region competition heat map of each level in real time, assisting in operation and maintenance optimization.

[0238] Furthermore, optional embodiments of this application also provide a computer-readable storage medium. The methods described above according to optional embodiments of this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded via a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0239] Through the optional embodiments of this application, performance improvements and throughput optimizations are achieved: In tests on the Intel Xeon 8-core platform, the throughput of 8-thread lock operations increased from 1200 ops / s to 3800 ops / s, an improvement of 316%, approaching the 380% speedup of the atomic operation scheme in the paper; latency reduction: The average latency of lock requests decreased from 359ms to 80-120ms, with a 72% reduction in latency from journaled_completion_queued to sub_op_committed (log completion queuing to sub-operation commit confirmation), consistent with the partition lock optimization results in the paper; reduced lock contention: Dynamic partitioning reduces the number of contentions in hot areas by 85%, and the performance degradation is <8% at 128 elements / lock, verifying the relationship between partition lock granularity and performance in the paper; reduced memory footprint: Multi-level Bloom filter compression reduces memory footprint from 1.8GB to 0.65GB in a 10 million file scenario, saving 64% of space. Hardware resource utilization: Atomic operations reduce the counter update latency from 200ns to 80ns (x86 architecture), reducing bus contention, consistent with the conclusion in the paper regarding the impact of shared hardware resources. Anti-blocking capability (first draft): Long transaction locks are automatically migrated to independent threads for processing, avoiding global blocking of the MDS. The dynamic adjustment mechanism completes optimization within 100ms when the load fluctuates by ±50%.

[0240] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0241] This embodiment also provides a partition lock acquisition device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated hereafter. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0242] Figure 5 This is a frame diagram of a partition lock acquisition device according to an embodiment of this application, as shown below. Figure 5 As shown, the device includes:

[0243] The pre-inspection module 52 is used to pre-inspect the multiple operation requests sent by one or more clients by using a filter index to filter the first operation request among the multiple operation requests and obtain the second operation request. The filter index includes at least one of the following: root path filter, directory filter, lock type filter. The first operation request is an operation request that does not require locking and / or does not cause lock contention. The second operation request is an operation request that causes lock contention.

[0244] The calculation module 54 is used to calculate the number of lock contention attempts corresponding to the second operation request, and determine the target lock region corresponding to the second operation request based on the number of lock contention attempts.

[0245] The acquisition module 56 is used to acquire the partition lock corresponding to the second operation request based on the target lock region.

[0246] The partition lock acquisition device of this application, upon receiving multiple operation requests from one or more clients, pre-screens the multiple operation requests using a root path filter, a directory filter, and a lock type filter. This filters out first operation requests that do not require locking and / or do not cause lock contention, resulting in second operation requests that do cause lock contention. The number of lock contention attempts corresponding to the second operation request is calculated, and the target lock region corresponding to the second operation request is determined based on the number of lock contention attempts, thereby reducing the number of lock contention attempts in hotspot areas. This application solves the problem of severe lock contention in lock management mechanisms such as global lock mechanisms and fixed partition locks in related technologies, thus reducing lock contention in hotspot areas.

[0247] In an exemplary embodiment, the pre-detection module 52 is further configured to parse the plurality of operation requests to obtain a first request path corresponding to each operation request; extract the top-level directory prefix contained in each first request path, and perform a first-level pre-detection on each operation request based on the root path filter to determine whether a first active lock operation exists under each top-level directory prefix, wherein the top-level directory prefix is ​​used to indicate the highest-level directory in the first request directory corresponding to each first request path; if it is determined that a first active lock operation exists under the top-level directory prefix corresponding to a third operation request among the plurality of operation requests, the third operation request is filtered, and a fourth operation request other than the third operation request among the plurality of operation requests is pre-detected through the directory filter and / or the lock type filter, wherein the first operation request includes: the third operation request.

[0248] In one exemplary embodiment, the pre-detection module 52 is further configured to obtain a first number of top-level directories expected to be stored by the root path filter and a first false positive rate corresponding to the root path filter; calculate, according to a first formula and a second formula, the size of a first digit group included in the root path filter and a second number of first hash functions used to map the top-level directory prefix to the first digit group, wherein the first formula is: The second formula is: p1 is the first false positive rate, k1 is the second quantity, m1 is the size of the first digit group, and n1 is the first quantity; a first hash value corresponding to each top-level directory prefix is ​​calculated based on a first hash function of the second quantity; a first index value corresponding to the first hash value is determined according to a first digit group of the first digit group size; a first bit identifier of the first index position corresponding to the first index value is determined in the root path filter; and the existence of the active lock operation under each top-level directory prefix is ​​determined according to the first bit identifier.

[0249] In an exemplary embodiment, the pre-inspection module 52 is further configured to parse each fourth operation request to determine the second request path corresponding to the fourth operation request; determine the second request directory corresponding to each second request path, and perform a second-level pre-inspection on the first files contained in each second request directory based on each directory filter corresponding to each second request directory to determine whether there is a second active lock record under each first file; if it is determined that there is a second active lock record under the first file corresponding to the fifth operation request among the plurality of fourth operation requests, filter the fifth operation request, and perform a pre-inspection on the sixth operation request other than the fifth operation request among the plurality of fourth operation requests through the lock type filter, wherein the first operation request includes: the fifth operation request.

[0250] In an exemplary embodiment, the pre-detection module 52 is further configured to obtain a third number of files expected to be stored in each second request directory corresponding to each directory filter and a second false positive rate corresponding to each directory filter; calculate, according to a third formula and a fourth formula, the second number of the second number group contained in each directory filter and a fourth number of the second hash function used to map the first file information corresponding to each first file to the second number group, wherein the third formula is: The fourth formula is: p2 is the second false positive rate, k2 is the fourth quantity, m2 is the size of the second digit group, and n2 is the third quantity; a hash calculation is performed on each first file information based on the second hash function of the fourth quantity to obtain the second hash value corresponding to each first file information, wherein the first file information includes at least one of the following: the first file name of the first file, the first file identifier of the first file, and the first metadata corresponding to the first file; a second index value corresponding to the second hash value is determined according to the second digit group size of the second digit group; a second bit identifier corresponding to the second index position of each second index value is determined in each directory filter; and the existence of the active lock operation under each first file is determined according to the second bit identifier.

[0251] In an exemplary embodiment, the pre-detection module 52 is further configured to parse the sixth operation request to determine the request type corresponding to the sixth operation request; determine the target type corresponding to the lock type filter for each sixth operation request based on the request type, and perform a three-level pre-detection on each sixth operation request based on the lock type filter of the target type to determine whether there is a lock conflict of the same type for the sixth operation request of each request type, wherein the lock type filter of the target type includes at least one of the following: a write lock type filter and a read lock type filter, wherein the lock conflict of the same type is used to indicate that the lock operations corresponding to multiple sixth operation requests of any request type are operations that request to acquire the same type of lock at the same time; if it is determined that multiple seventh operation requests among the multiple sixth operation requests have lock conflicts of the same type, filter the multiple seventh operation requests to obtain the second operation request, wherein the first operation request includes: the multiple seventh operation requests.

[0252] In an exemplary embodiment, the pre-detection module 52 is further configured to obtain the expected number of lock operations of the target type per second for the lock type filter of the target type and the third false positive rate corresponding to the lock type filter of the target type; calculate the size of the third digit group contained in the lock type filter of the target type and the fifth number of the third hash function used to map the request type to the third digit group according to the fifth formula and the sixth formula, wherein the fifth formula is: The sixth formula is: p3 is the third false positive rate, k3 is the fifth quantity, m2 is the third digit group size, and n3 is the number of times. A hash calculation is performed on the request type of each sixth operation request based on the third hash function of the fifth quantity to obtain the third hash value corresponding to each request type. The third index value corresponding to the third hash value is determined according to the third digit group size. The third bit identifier of the third index position corresponding to the third index value is determined in the lock type filter of the target type. The existence of lock conflicts of the same type in the sixth operation requests of each request type is determined according to the third bit identifier.

[0253] In an exemplary embodiment, the pre-detection module 52 is further configured to, upon receiving a first lock request corresponding to a first top-level directory stored in the root path filter, count based on a first counter in the root path filter to increment the value of the first counter by a first value, wherein the first counter is a counter corresponding to the first top-level directory; upon determining that a second lock request corresponding to a second top-level directory stored in the root path filter has been deleted, count based on a second counter in the root path filter to decrease the value of the second counter to a second value, wherein the second counter is a counter corresponding to the second top-level directory; and upon determining that a first file lock request is received under a request directory corresponding to the first directory filter, count based on a third counter in the first directory filter to increment the value of the third counter to a third value, wherein the third counter is an indication of the first file lock request. The counter corresponding to the file; if it is determined that the second file lock request under the request directory corresponding to the second directory filter has been deleted, a count is performed based on the fourth counter in the second directory filter to increase the value of the fourth counter to a fourth value, wherein the fourth counter is the counter corresponding to the file indicated by the second file lock request, and the directory filter includes: the first directory filter and the second directory filter; if it is determined that a first lock request of the first request type has been received, a count is performed based on the fifth counter in the lock type filter corresponding to the first request type to increase the value of the fifth counter to a fifth value; if it is determined that the second lock request of the second request type has been deleted, a count is performed based on the sixth counter in the lock type filter corresponding to the second request type to decrease the value of the sixth counter to a sixth value, wherein the first request type and the second request type are both: read lock request or write lock request.

[0254] In an exemplary embodiment, the calculation module 54 is further configured to parse the second operation request to determine a third request path corresponding to the second operation request; perform a hash operation on the third request path to determine a fourth hash value corresponding to the third request path; perform a modulo operation on the fourth hash value to determine a first region index corresponding to the fourth hash value, and determine a first initial lock region corresponding to the third request path based on the first region index; count the number of lock contentions contained in the first initial lock region based on a preset time interval, and determine the number of lock contentions contained in the first initial lock region as the number of lock contentions corresponding to the second operation request.

[0255] In an exemplary embodiment, the calculation module 54 is further configured to determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within a target time period prior to the current time; adjust the size of the first region corresponding to the first initial lock region based on the number of lock contention attempts and the historical maximum number of lock contention attempts; and determine the adjusted first initial lock region as the target lock region.

[0256] In an exemplary embodiment, the calculation module 54 is further configured to adjust the size of the first region using a seventh formula, wherein the seventh formula is: S is the size of the second region obtained after adjusting the size of the first region, S0 is the size of the first region, and C max The maximum number of lock contention attempts in history is given by C, where C is the number of lock contention attempts and α is an adjustment coefficient.

[0257] In an exemplary embodiment, the calculation module 54 is further configured to: determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within a target time period prior to the current time; determine a first size relationship between the number of lock contention attempts and the historical maximum number of lock contention attempts; if the first size relationship indicates that among the multiple lock contention attempts corresponding to multiple second operation requests, there exists a first lock contention attempt that is less than or equal to the historical maximum number of lock contention attempts, determine the second initial lock region corresponding to the first lock contention attempt as a first low contention region; and perform merging processing on the first low contention region based on a preset rule to generate a target lock region corresponding to the first lock contention attempt.

[0258] In an exemplary embodiment, the calculation module 54 is further configured to determine a second size relationship between the number of lock contention attempts and a first preset threshold; if the second size relationship indicates that among the multiple lock contention attempts corresponding to multiple second operation requests, there exists a second lock contention attempt that is less than or equal to the first preset threshold, the third initial lock region corresponding to the second lock contention attempt is determined as a second low contention region; and the second low contention region is merged based on a preset rule to generate a target lock region corresponding to the second lock contention attempt.

[0259] In an exemplary embodiment, the calculation module 54 is further configured to: determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within a target time period prior to the current time; determine a first size relationship between the number of lock contention attempts and the historical maximum number of lock contention attempts; if the first size relationship indicates that there is a third number of lock contention attempts among the multiple lock contention attempts corresponding to multiple second operation requests that is greater than the historical maximum number of lock contention attempts, determine the fourth initial lock region corresponding to the third number of lock contention attempts as a first high contention region, and suspend receiving lock requests for the first high contention region; allocate the lock records contained in the first high contention region to multiple first sub-lock regions, wherein the target lock region corresponding to the third number of lock contention attempts includes: any one of the first sub-lock regions.

[0260] In an exemplary embodiment, the calculation module 54 is further configured to determine a third size relationship between the number of lock contention attempts and a second preset threshold; if the third size relationship indicates that there is a fourth lock contention attempt greater than the second preset threshold among the multiple lock contention attempts corresponding to multiple second operation requests, the fifth initial lock region corresponding to the fourth lock contention attempt is determined as a second high contention region, and receiving lock requests to the second high contention region is suspended; the lock records contained in the second high contention region are allocated to multiple second sub-lock regions, wherein the target lock region corresponding to the fourth lock contention attempt includes: any second sub-lock region.

[0261] In an exemplary embodiment, the pre-detection module 52 is further configured to, if it is determined based on the root path filter, directory filter and lock type filter that the first operation request does not exist among the plurality of operation requests, prohibit the calculation of the lock contention count corresponding to the second operation request, and determine that the one or more clients are allowed to execute the plurality of operation requests.

[0262] For a description of the features in the embodiment corresponding to the partition lock acquisition device, please refer to the relevant description in the embodiment corresponding to the partition lock acquisition method, which will not be repeated here.

[0263] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the partition lock acquisition method.

[0264] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described partition lock acquisition method embodiments when running.

[0265] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0266] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described partition lock acquisition method embodiments.

[0267] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described partition lock acquisition method embodiments.

[0268] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0269] The acquisition of a partition lock provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for acquiring a partition lock, characterized in that, include: When multiple operation requests are received from one or more clients, a pre-examination is performed on the multiple operation requests using a filter index to filter out the first operation request among the multiple operation requests, thereby obtaining the second operation request. The filter index includes: a root path filter, a directory filter, and a lock type filter. The root path filter is used to check whether the top-level path prefix corresponding to the multiple operation requests exists in the active lock record. The directory filter is used to check whether the target file in the specific directory pointed to by the multiple operation requests has been locked. The lock type filter is used to check whether the type of the multiple operation requests conflicts with other existing locks of the same type. The first operation request is an operation request that does not require locking and / or does not cause lock contention. The second operation request is an operation request that causes lock contention. Calculate the number of lock contention attempts in the first initial lock region corresponding to the second operation request, and determine the target lock region corresponding to the second operation request based on the number of lock contention attempts; Obtain the partition lock corresponding to the second operation request based on the target lock region; Determining the target lock region corresponding to the second operation request based on the number of lock contention attempts includes: Determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within the target time period prior to the current time; Determine a first size relationship between the number of lock contentions and the historical maximum number of lock contentions; If, among the multiple lock contention counts corresponding to the multiple second operation requests indicated by the first size relationship, there exists a first lock contention count that is less than or equal to the historical maximum lock contention count, the second initial lock region corresponding to the first lock contention count is determined as the first low contention region; The first low-competition region is merged based on preset rules to generate the target lock region corresponding to the first number of lock contention attempts.

2. The method for acquiring a partition lock according to claim 1, characterized in that, Pre-screening of the multiple operation requests using a filter index includes: The multiple operation requests are parsed to obtain the first request path corresponding to each operation request; Extract the top-level directory prefix contained in each first request path, and perform a first-level pre-check on each operation request based on the root path filter to determine whether there is a first active lock operation under each top-level directory prefix, wherein the top-level directory prefix is ​​used to indicate the highest-level directory in the first request directory corresponding to each first request path; If it is determined that the first active lock operation exists under the top-level directory prefix corresponding to the third operation request among the plurality of operation requests, the third operation request is filtered, and the fourth operation request other than the third operation request among the plurality of operation requests is pre-checked through the directory filter and / or the lock type filter, wherein the first operation request includes: the third operation request.

3. The method for acquiring a partition lock according to claim 2, characterized in that, Based on the root path filter, a first-level pre-check is performed on each operation request to determine whether a first active lock operation exists under each top-level directory prefix, including: Obtain the first number of top-level directories expected to be stored by the root path filter and the first false positive rate corresponding to the root path filter; The size of the first digit group contained in the root path filter and the second number of the first hash function used to map the top-level directory prefix to the first digit group are calculated according to the first formula and the second formula, wherein the first formula is: The second formula is: p1 is the first false positive rate, k1 is the second quantity, m1 is the size of the first digit group, and n1 is the first quantity; The first hash value corresponding to each top-level directory prefix is ​​calculated based on the second number of first hash functions; The first index value corresponding to the first hash value is determined based on the first digit group of the first digit group size. In the root path filter, determine the first bit identifier of the first index position corresponding to the first index value; The presence of the active lock operation is determined based on the first bit identifier under each top-level directory prefix.

4. The method for acquiring a partition lock according to claim 2, characterized in that, Pre-screening of the fourth operation request (excluding the third operation request) among the plurality of operation requests using the directory filter and / or the lock type filter includes: Each fourth operation request is parsed to determine the second request path corresponding to the fourth operation request; Determine the second request directory corresponding to each second request path, and perform a second-level pre-check on the first files contained in each second request directory based on each directory filter corresponding to each second request directory, so as to determine whether there is a second active lock record under each first file; If it is determined that a second active lock record exists in the first file corresponding to the fifth operation request among a plurality of fourth operation requests, the fifth operation request is filtered, and the sixth operation request other than the fifth operation request among the plurality of fourth operation requests is pre-checked through the lock type filter, wherein the first operation request includes: the fifth operation request.

5. The method for acquiring a partition lock according to claim 4, characterized in that, A secondary pre-check is performed on the first files contained in each second request directory based on each directory filter corresponding to each second request directory to determine whether a second active lock record exists under each first file, including: Obtain the third number of files expected to be stored in each second request directory corresponding to each directory filter and the second false positive rate corresponding to each directory filter; The size of the second digit group contained in each directory filter and the fourth quantity of the second hash function used to map the first file information corresponding to each first file to the second digit group are calculated according to the third and fourth formulas, wherein the third formula is: The fourth formula is: p2 is the second false positive rate, k2 is the fourth quantity, m2 is the second digit group size, and n2 is the third quantity; The hash function of the fourth quantity is used to perform a hash calculation on each first file information to obtain the second hash value corresponding to each first file information. The first file information includes at least one of the following: the first file name of the first file, the first file identifier of the first file, and the first metadata corresponding to the first file. The second index value corresponding to the second hash value is determined based on the second digit group of the second digit group size; In each directory filter, determine the second bit identifier of the second index position corresponding to each second index value; The existence of the active lock operation in each first file is determined based on the second bit identifier.

6. The method for acquiring a partition lock according to claim 4, characterized in that, Pre-screening of the sixth operation request (excluding the fifth operation request) among the plurality of fourth operation requests using the lock type filter includes: The sixth operation request is parsed to determine the request type corresponding to the sixth operation request; Based on the request type, the target type corresponding to the lock type filter for each sixth operation request is determined, and a three-level pre-check is performed on each sixth operation request based on the lock type filter of the target type to determine whether there is a lock conflict of the same type for the sixth operation requests of each request type. The lock type filter of the target type includes at least one of the following: write lock type filter and read lock type filter. The lock conflict of the same type is used to indicate that the lock operations corresponding to multiple sixth operation requests of any request type are operations that request to acquire the same type of lock at the same time. If it is determined that multiple seventh operation requests among multiple sixth operation requests have lock conflicts of the same type, the multiple seventh operation requests are filtered to obtain the second operation request, wherein the first operation request includes the multiple seventh operation requests.

7. The method for acquiring a partition lock according to claim 6, characterized in that, A lock type filter based on the target type performs a three-level pre-check on each sixth operation request to determine whether there is a lock conflict of the same type for each request type, including: Obtain the expected number of lock operations of the target type per second from the lock type filter of the target type and the third false positive rate corresponding to the lock type filter of the target type; The fifth formula is used to calculate the size of the third digit group contained in the lock type filter of the target type and the fifth number of the third hash function used to map the request type to the third digit group, according to the fifth and sixth formulas, wherein the fifth formula is: The sixth formula is: p3 is the third false positive rate, k3 is the fifth quantity, m2 is the third digit group size, and n3 is the number of times. The request type of each sixth operation request is hashed using the third hash function based on the fifth number to obtain the third hash value corresponding to each request type; The third index value corresponding to the third hash value is determined based on the third digit group of the third digit group size; In the lock type filter of the target type, determine the third bit identifier of the third index position corresponding to the third index value; The third bit identifier is used to determine whether there is a lock conflict of the same type in the sixth operation request of each request type.

8. The method for acquiring a partition lock according to claim 1, characterized in that, Before or after pre-screening the plurality of operation requests using a filter index, the method further includes: Upon receiving a first lock request corresponding to the first top-level directory stored in the root path filter, a count is performed based on the first counter in the root path filter to increment the value of the first counter by a first value, wherein the first counter is the counter corresponding to the first top-level directory; If it is determined that the second lock request corresponding to the second top-level directory stored in the root path filter has been deleted, a count is performed based on the second counter in the root path filter to reduce the value of the second counter to a second value, wherein the second counter is the counter corresponding to the second top-level directory; If it is determined that a first file lock request has been received in the request directory corresponding to the first directory filter, a count is performed based on the third counter in the first directory filter to increase the value of the third counter to a third value, wherein the third counter is the counter corresponding to the file indicated by the first file lock request; If it is determined that the second file lock request under the request directory corresponding to the second directory filter has been deleted, a count is performed based on the fourth counter in the second directory filter to increase the value of the fourth counter to a fourth value, wherein the fourth counter is the counter corresponding to the file indicated by the second file lock request, and the directory filter includes: the first directory filter and the second directory filter; Upon determining that a first lock request of the first request type has been received, a count is performed based on the fifth counter in the lock type filter corresponding to the first request type, so as to increase the value of the fifth counter to the fifth value; If it is determined that the second lock request of the second request type has been deleted, a count is performed based on the sixth counter in the lock type filter corresponding to the second request type to reduce the value of the sixth counter to the sixth value, wherein both the first request type and the second request type are: read lock request or write lock request.

9. The method for acquiring a partition lock according to claim 1, characterized in that, Calculate the number of lock contention attempts corresponding to the second operation request, including: The second operation request is parsed to determine the third request path corresponding to the second operation request; Perform a hash operation on the third request path to determine the fourth hash value corresponding to the third request path; The fourth hash value is moduloed to determine the first region index corresponding to the fourth hash value, and the first initial lock region corresponding to the third request path is determined based on the first region index. The number of lock contention attempts contained in the first initial lock region is counted based on a preset time interval, and the number of lock contention attempts contained in the first initial lock region is determined as the number of lock contention attempts corresponding to the second operation request.

10. The method for acquiring a partition lock according to claim 1, characterized in that, Determining the target lock region corresponding to the second operation request based on the number of lock contention attempts further includes: Determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within the target time period prior to the current time; The size of the first region corresponding to the first initial lock region is adjusted based on the number of lock contention attempts and the historical maximum number of lock contention attempts, and the adjusted first initial lock region is determined as the target lock region.

11. The method for acquiring a partition lock according to claim 10, characterized in that, Adjusting the size of the first region corresponding to the first initial lock region based on the number of lock contention attempts and the historical maximum number of lock contention attempts includes: The size of the first region is adjusted using a seventh formula, wherein the seventh formula is: S is the size of the second region obtained after adjusting the size of the first region, S0 is the size of the first region, and C max The maximum number of lock contention attempts in history is given by C, where C is the number of lock contention attempts and α is an adjustment coefficient.

12. The method for acquiring a partition lock according to claim 1, characterized in that, Determining the target lock region corresponding to the second operation request based on the number of lock contention attempts further includes: Determine a second relationship between the number of lock contention attempts and a first preset threshold; If, in the case where the second lock contention count is less than or equal to the first preset threshold among the multiple lock contention counts corresponding to the multiple second operation requests indicated by the second size relationship, the third initial lock region corresponding to the second lock contention count is determined as the second low contention region; The second low-contention region is merged based on preset rules to generate the target lock region corresponding to the second lock contention count.

13. The method for acquiring a partition lock according to claim 1, characterized in that, Determining the target lock region corresponding to the second operation request based on the number of lock contention attempts further includes: Determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within the target time period prior to the current time; Determine a first size relationship between the number of lock contentions and the historical maximum number of lock contentions; If, among the multiple lock contention counts corresponding to the multiple second operation requests indicated by the first size relationship, there is a third lock contention count that is greater than the historical maximum lock contention count, the fourth initial lock region corresponding to the third lock contention count is determined as the first high contention region, and the reception of lock requests to the first high contention region is suspended. The lock records contained in the first high-contention region are allocated to multiple first sub-lock regions, wherein the target lock region corresponding to the third lock contention number includes: any first sub-lock region.

14. The method for acquiring a partition lock according to claim 1, characterized in that, Determining the target lock region corresponding to the second operation request based on the number of lock contention attempts further includes: Determine a third relationship between the number of lock contention attempts and the second preset threshold; If, in the case where the fourth lock contention count is greater than the second preset threshold among the multiple lock contention counts corresponding to the multiple second operation requests indicated by the third size relationship, the fifth initial lock region corresponding to the fourth lock contention count is determined as the second high contention region, and the reception of lock requests to the second high contention region is suspended. The lock records contained in the second high-contention region are allocated to multiple second sub-lock regions, wherein the target lock region corresponding to the fourth lock contention number includes any second sub-lock region.

15. The method for acquiring a partition lock according to claim 1, characterized in that, After performing a pre-screening of the plurality of operation requests using a filter index to filter out the first operation request among the plurality of operation requests and obtain the second operation request, the method further includes: If, based on the root path filter, directory filter, and lock type filter, it is determined that the first operation request does not exist among the plurality of operation requests, the calculation of the lock contention count corresponding to the second operation request is prohibited, and it is determined that the one or more clients are allowed to execute the plurality of operation requests.

16. A device for acquiring a partition lock, characterized in that, include: A pre-detection module is used to pre-detect multiple operation requests sent by one or more clients by using a filter index to filter out a first operation request and obtain a second operation request. The filter index includes a root path filter, a directory filter, and a lock type filter. The root path filter checks whether the top-level path prefix corresponding to the multiple operation requests exists in the active lock record. The directory filter checks whether the target file in the specific directory pointed to by the multiple operation requests has been locked. The lock type filter checks whether the type of the multiple operation requests conflicts with other existing locks of the same type. The first operation request is an operation request that does not require locking and / or does not cause lock contention, while the second operation request is an operation request that causes lock contention. The calculation module is used to calculate the number of lock contention attempts in the first initial lock region corresponding to the second operation request, and to determine the target lock region corresponding to the second operation request based on the number of lock contention attempts. The acquisition module is used to acquire the partition lock corresponding to the second operation request based on the target lock region; The calculation module is further configured to: determine the historical maximum number of lock contention attempts in the first initial lock region corresponding to the second operation request within a target time period prior to the current time; determine a first size relationship between the number of lock contention attempts and the historical maximum number of lock contention attempts; if the first size relationship indicates that among the multiple lock contention attempts corresponding to multiple second operation requests, there exists a first lock contention attempt that is less than or equal to the historical maximum number of lock contention attempts, determine the second initial lock region corresponding to the first lock contention attempt as a first low contention region; and perform merging processing on the first low contention region based on preset rules to generate the target lock region corresponding to the first lock contention attempt.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the partition lock acquisition method as described in any one of claims 1 to 15 when executing the computer program.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the partition lock acquisition method as described in any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the partition lock acquisition method as described in any one of claims 1 to 15.

Images