Request processing system, method, device, storage medium and program product

Abstract

The embodiment of the invention provides a request processing system, method and equipment, a storage medium and a program product. Wherein the server creates a request list for the successfully updated lease number to store the lease number, the identifier of the access request carrying the lease number and the processing result of the access request. When a server receives an access request, if a processing result of a request carrying the same lease number and having the same identifier is queried in a request list, the processing result stored in the request list is directly used as a response result of the received access request and is returned to a client node; therefore, the same access request is processed once and has the same processing result, and idempotent processing of the access request is realized. And on the other hand, in the distributed system, idempotent processing is realized between the server side and the client side through the lease number, the client side can obtain the lease number from any service node, session maintenance with each service node is not needed, and the pressure of the server side can be reduced.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a request processing system, method, device, storage medium, and program product. Background Technology

[0002] Idempotency means that for the same operation, the final result is consistent no matter how many times it is executed. In distributed systems, due to communication and coordination among multiple nodes, the same operation may be executed multiple times, thus requiring the idempotency of operations in distributed systems to be guaranteed. Summary of the Invention

[0003] This application provides a request processing system, method, apparatus, storage medium, and program product for implementing idempotent request processing.

[0004] This application provides a request processing system, including: a client node and multiple service nodes; the multiple service nodes provide distributed services;

[0005] The multiple service nodes are used to update the lease number; for the first lease number that is successfully updated, a request list corresponding to the first lease number is created; the request list is used to store the first lease number, the identifier of the first access request carrying the first lease number, and the processing result of the first access request;

[0006] The client node is configured to obtain a second lease number from a first service node among the plurality of service nodes; and send a second access request carrying the second lease number to the second service node among the plurality of service nodes.

[0007] The second service node is configured to, if the processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number when the first lease number set currently stored includes the second lease number, use the processing result corresponding to the identifier of the second access request as the response result of the second access request, and return the response result to the client node.

[0008] Furthermore, the lease number increments over time, and the second service node is specifically used for:

[0009] If the first set of lease numbers currently stored includes the second lease number, and the absolute value of the difference between the second lease number and the largest lease number in the first set of lease numbers is greater than a set difference threshold, and no processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, then an error message is output to the client node.

[0010] And / or,

[0011] If the second lease number is less than the smallest lease number in the first lease number set, an error message is output to the client node.

[0012] This application embodiment also provides a request processing method applicable to service nodes providing distributed services, wherein the service node stores a request list corresponding to a first lease number that has been successfully updated; the request list is used to store the first lease number, an identifier of a first access request carrying the first lease number, and the processing result of the first access request;

[0013] The method includes:

[0014] Receive a second access request sent by the client node, carrying the second lease number;

[0015] If the first set of lease numbers currently stored includes the second lease number, and if the processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, then the processing result corresponding to the identifier of the second access request is used as the response result of the second access request.

[0016] The response result is returned to the client node.

[0017] This application embodiment also provides a request processing method, applicable to a client node, the method comprising:

[0018] The second lease number is obtained from the first service node among multiple service nodes; the multiple service nodes provide distributed services and store a request list corresponding to the first lease number that has been successfully updated; the request list corresponding to the first lease number is used to store the first lease number, the identifier of the first access request carrying the first lease number, and the processing result of the first access request;

[0019] Send a second access request carrying the second lease number to the second service node among the plurality of service nodes;

[0020] The second service node receives the response result of the second access request returned by the second service node; wherein, if the first set of lease numbers stored includes the second lease number, and the request list corresponding to the second lease number stores the processing result corresponding to the identifier of the second access request, the second service node uses the processing result corresponding to the identifier of the second access request as the response result.

[0021] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to store computer programs;

[0022] The processor is coupled to the memory and is used to execute the computer program to perform the steps in the above-described request processing methods.

[0023] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps in the above-described request processing methods.

[0024] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the above-described request processing methods.

[0025] In this embodiment, the server creates a request list to store successfully updated lease numbers, the identifier of the access request carrying that lease number, and the processing result of the access request. Thus, when the server receives an access request carrying a lease number, if it finds a processing result for a request with the same lease number and identifier in the stored request list, it considers the received access request to be the same as the access request corresponding to the processing result stored in the request list. The server then directly returns the processing result stored in the request list as the response result to the received access request to the client node, ensuring that the same access request is processed only once and has the same processing result, achieving idempotent processing of access requests. On the other hand, in a distributed system, idempotent processing between the server and client is achieved through lease numbers. The client can obtain a lease number from any service node without needing to maintain a session with each service node, reducing the server's workload. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0027] Figure 1 A schematic diagram of the structure of the request processing system and a schematic diagram of the request processing process provided in the embodiments of this application;

[0028] Figure 2 This is a schematic diagram of another request processing procedure provided for an embodiment of this application;

[0029] Figure 3 and Figure 4 A flowchart illustrating the request processing method provided in an embodiment of this application;

[0030] Figure 5 A schematic diagram illustrating the response flow of a service node to a second access request, provided in an embodiment of this application.

[0031] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0034] In some embodiments of this application, to achieve idempotent processing in a distributed system, the server creates a request list to store successfully updated lease numbers, the identifier of the access request carrying that lease number, and the processing result of the access request. Thus, when the server receives an access request carrying a lease number, if it finds a processing result for a request with the same lease number and identifier in the stored request list, it considers the received access request to be the same as the access request corresponding to the processing result stored in the request list. The server then directly returns the processing result stored in the request list as the response result to the received access request to the client node, ensuring that the same access request is processed only once and has the same processing result, achieving idempotent processing of access requests. On the other hand, in a distributed system, idempotent processing between the server and client is achieved through lease numbers. The client can obtain a lease number from any service node without needing to maintain a session with each service node, reducing the load on the server.

[0035] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0036] It should be noted that the same reference numerals denote the same object in the following figures and embodiments. Therefore, once an object is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0037] Figure 1This is a schematic diagram of the structure of a request processing system provided in an embodiment of this application. Figure 1 As shown, the request processing system includes: client node 10 and multiple service nodes 20. "Multiple" refers to two or more.

[0038] In this embodiment, the service node 20 is a computer device that can respond to service requests from the client node 10 and provide relevant services to the user. It generally possesses the capability to undertake and guarantee services. The service node 20 can be a single server device, a cloud-based server array, or a virtual machine (VM) running within a cloud-based server array. Alternatively, the service node 20 can also refer to other computing devices with corresponding service capabilities, such as computers or other terminal devices (running service programs).

[0039] Client node 10 refers to a computer device used by a user, possessing the computing, internet access, and communication functions required by the user, such as a mobile phone, tablet computer, personal computer, or wearable device. Of course, client node 10 can also be a server device. In this embodiment, client node 10 can run client programs for services provided by service node 20, such as a Software Development Kit (SDK). The SDK can be a full SDK or a lightweight SDK. The full SDK can directly interact with service node 20, for example, by providing read / write interfaces to directly interact with service node 20 to implement data read / write. The lightweight SDK provides lightweight file read / write interfaces and mainly interacts with proxy service node 30, which implements the functions of the full SDK; that is, the proxy service node 30 interacts with service node 20.

[0040] Multiple service nodes 20 provide distributed services. In this embodiment, the specific content of the distributed services provided by the multiple service nodes 20 is not limited. Optionally, the distributed service may be a distributed storage service, a distributed computing service, or a distributed metadata management service, but is not limited to these.

[0041] Distributed storage can improve the efficiency of data storage and management. Most distributed storage systems typically separate metadata from application data, separating control flow from data flow to achieve higher policy scalability and input / output (I / O) concurrency. Therefore, the metadata management method is crucial, directly impacting policy scalability, performance, reliability, and stability.

[0042] Metadata management methods can be divided into centralized and distributed approaches. In a centralized metadata service, each metadata service node operates within a single process, with a central metadata server responsible for storing metadata and handling client query requests. This server provides a unified namespace and handles access control functions such as location resolution and data positioning. In a distributed metadata service, each metadata service node corresponds to an independent process, managing metadata across different dimensions. For distributed metadata management services, such as... Figure 2 As shown, service node 20 may include multiple metadata service nodes 201. "Multiple" means two or more. The multiple metadata service nodes 201 are used to manage metadata of different dimensions. In some embodiments, the metadata service nodes may include a metadata server 201a and a namespace server 201b. There may be one or more metadata servers 201a and namespace servers 201b.

[0043] In this distributed storage system, metadata node 201a is responsible for managing the identification information of application data and ensuring data security; it can be the holder of file session locks. The identification information of application data can be inode (INode) information, a crucial data structure used to store file metadata, including but not limited to: file type, file size, file owner, file permissions, timestamps, and data block pointers. The data block pointers record information about the data server where the data resides. The data server internally records the actual location of the file data on the disk containing the data blocks. Namespace node 201b is responsible for managing the directory tree of the distributed file system.

[0044] For distributed metadata management services, service node 20 may also include a root server 202. The root server 202 is responsible for scheduling and managing metadata service nodes in the cluster, such as metadata nodes and space naming nodes, in the distributed storage system.

[0045] A distributed metadata service refers to a system where the root service node, metadata node, and namespace node each run in separate, independent processes. These different metadata service nodes can interact via Remote Procedure Call (RPC). The metadata service nodes in a distributed metadata service run in separate processes to manage different dimensions of metadata within the distributed storage system.

[0046] In this embodiment, the service provided by service node 20 is idempotent. Idempotency means that for the same operation, the final result is consistent regardless of how many times it is executed. To ensure the idempotency of operations in service node 20, this embodiment proposes a request processing method based on a sequence mechanism to achieve idempotency in request processing. Here, the sequence number is a lease sequence number (referred to as lease number) for both the client and server, and this sequence number has an expiration time, i.e., it has a validity period. In this embodiment, the lease number (Sequence Identity, SeqId) is a sequence number maintained by client node 10 and service node 20, and can be represented by a natural number. Preferably, the lease number increments over time.

[0047] In the embodiments of this application, such as Figure 1 As shown in step 1, service node 20 can update the lease number (SeqId). Each update changes the lease number maintained by service node 20. In this embodiment, the specific implementation of service node 20 updating the lease number is not limited. In some embodiments, service node 20 can periodically update the lease number according to a set period. For example, service node 20 can increase the lease number by a set increment in each period based on the lease number of the previous period. For example, the lease number increases by 1 in each period.

[0048] like Figure 2 As shown in step 1, for the distributed metadata service system, the root service node 202 can periodically and incrementally update the lease number (SeqId) according to the set period T1, and as follows... Figure 2 As shown in step 2, the lease number updated in the current period is provided to multiple metadata service nodes 201. Accordingly, the metadata service node 201 can update its lease number by receiving the lease number provided by the root service node 202, and use the received lease number as the currently updated lease number (SeqId-1). In this embodiment, the specific value of the period T1 is not limited. In some embodiments, the period T1 can be determined according to the heartbeat detection period of the root service node 202, such as the period T1 being equal to the heartbeat detection period of the root service node 202.

[0049] Based on the heartbeat detection mechanism between the root service node 202 and the metadata service node 201, the root service node 202 can carry the lease number updated in the current period in the heartbeat signal and provide the heartbeat signal to the metadata service node 201. The metadata service node 201 can obtain the lease number from the heartbeat signal and update the stored lease number with the obtained lease number, that is, use the lease number obtained from the heartbeat signal as the currently updated lease number (SeqId-1).

[0050] The lease number (SeqId-1) currently updated to by service node 20 is defined as the first lease number (SeqId-1). For example... Figure 1 Step 2 and Figure 2 As shown in step 3, for the first lease number (SeqId-1), service node 20 (or metadata service node 201) can create a request list corresponding to the first lease number (Seq-Id1). This request list is stored in service node 20. Preferably, the request list is persistently stored in service node 20. The request list corresponding to each lease number is used to store the lease number, the identifier of the access request carrying the lease number, and the processing result of the access request. The identifier of the access request refers to information that uniquely identifies a request, which can be a Universally Unique Identifier (UUID). The processing result of the access request is the response result of service node 20 to the access request. The access request can be a read request, write request, or data deletion request for the distributed storage system. For ease of description and distinction, in this embodiment, the access request carrying the first lease number (SeqId-1) stored by service node 20 (such as metadata service node 201) is defined as the first access request. Figure 1 The first access request is represented by its UUID, where UUID-1 represents the identifier of the first access request.

[0051] The lease number stored by service node 20 (such as metadata service node 201) has a set validity period t1. The validity period t1 is greater than the lease number update cycle of the aforementioned root service node 202, i.e., the cycle T1. That is, t1 > T1. If T1 = 1 minute, then t2 can be 5 minutes, etc.

[0052] Service node 20 (such as metadata service node 201) can delete the request list of expired lease numbers after the lease number expires, thereby deleting the expired lease numbers, the identifiers of access requests carrying expired lease numbers, and the processing results of these access requests. In some embodiments, service node 20 can delete the request list of expired lease numbers after a set duration t2 of lease number expiration. The set duration t2 is greater than the aforementioned validity period t1. Alternatively, after a lease number expires, service node 20 can delete the request list corresponding to the smallest lease number among the currently expired lease numbers when updating to a new lease number, thus achieving lease number expiration deletion.

[0053] Client node 10 can obtain the lease number from any service node 20 to update the lease number. In this embodiment, for ease of description and distinction, the service node from which client node 10 obtains the lease number is defined as the first service node. That is, as follows... Figure 1As shown in step 3, client node 10 obtains the lease number from the first service node. The first service node is the service node that successfully responds to client node 10's lease renewal request. Specifically, as... Figure 2 As shown in step 4, client node 10 can send a lease renewal request to any service node 20. Upon receiving the lease renewal request, service node 20 can determine the maximum valid lease number, defined as the second lease number (SeqId-2).

[0054] Specifically, such as Figure 2 As shown in step 5, for the service node 20 that receives the lease update request, it can respond to the lease update request by querying the validity period of the currently stored lease numbers; if there are valid lease numbers in the currently stored lease numbers, the largest lease number is determined from the valid lease numbers as the second lease number (SeqId-2), and the second lease number (SeqId-2) is returned to the client node 10 (corresponding to Figure 2 Step 6.1). Accordingly, as Figure 2 As shown in step 6.2, if all lease numbers currently stored by service node 20 have expired, then based on the largest lease number currently stored by service node 20, the lease number can be periodically and incrementally updated according to a set period T2. The update period T2 for service node 20 to update its lease numbers is defined as the second period T2. In this embodiment, service node 20 can use the lease number updated in the current second period as the second lease number (SeqId-2) and return the second lease number (SeqId-2) to client node 10 (corresponding to...). Figure 2 Step 6.2.1). The current second cycle can be the first cycle of service node 20's self-update.

[0055] Furthermore, such as Figure 2 As shown in step 6.2.2, the service node 20 (or metadata service node) that receives the lease update request sent by the client node 10 performs the self-update for any second period T2. i This allows the creation of the second cycle T2. i The updated request list corresponding to the lease number. This request list can store the corresponding second period T2. i Updated lease number (SeqId) i ), carrying the lease number (SeqId) i Access request and carrying the lease number (SeqId) i The result of processing the access request (T2). i represents the i-th second cycle. i = 1, 2, 3… Preferably, the request list can persistently store the corresponding second cycle T2. i Updated lease number (SeqId) i), carrying the lease number (SeqId) i Access request and carrying the lease number (SeqId) i The result of processing the access request.

[0056] For distributed metadata management systems, such as Figure 2 As shown in step 6.2, when a metadata service node receives a lease update request and all its stored lease numbers have expired, it can periodically and incrementally update the lease numbers based on the maximum lease number currently stored in the metadata service node, according to a set second period T2. For example, a set gradient can be added to the maximum currently stored lease number for each second period T2 to obtain the lease number for each second period T2. The automatic update of lease numbers by the metadata service node when all its stored lease numbers have expired reduces the dependency of the metadata service node's lease number updates on the root service node. Even if the root service node malfunctions, the metadata service node can still update its lease numbers, which helps maintain and improve the idempotency of distributed metadata management.

[0057] Since the lease number of the metadata service node may be obtained through self-update or from access requests, in some cases, the maximum lease number of the metadata service node may be greater than the maximum lease number stored by the root service node. In this case, the root service node 202 can update the lease number stored by the root service node to the maximum lease number stored by the metadata service node, and continue to periodically increment the lease number based on the maximum lease number stored by the metadata service node, according to the aforementioned first period T1.

[0058] To conserve storage resources, service node 20 (such as metadata service node 201) can delete the request list of expired lease numbers after the lease number expires, thereby deleting the expired lease number, the identifier of the access request carrying the expired lease number, and the processing results of these access requests. In some embodiments, service node 20 can delete the request list of expired lease numbers after a set expiration time T3. The set expiration time T3 is longer than the aforementioned validity period T2.

[0059] Alternatively, after a lease number expires, service node 20 can delete the request list corresponding to the smallest lease number among the currently expired lease numbers when updating to a new lease number, thus achieving lease number expiration deletion. Specifically, service node 20 (such as metadata service node 201) that receives a lease update request can delete the second period T2. i The request list corresponding to the smallest expired lease number in the stored lease numbers can be deleted periodically or irregularly to save storage resources.

[0060] In the aforementioned distributed metadata service system, client node 10 can request a lease number from any metadata service node 201 to update the lease number. Specifically, client node 10 can send a lease update request to any metadata service node 201. Upon receiving the lease update request, metadata service node 201 can determine the maximum valid lease number, which is defined as the second lease number (SeqId-2). For the specific implementation of how metadata service node 201 determines the second lease number (SeqId-2), please refer to the relevant content on how service node 20 determines the second lease number (SeqId-2) mentioned above, which will not be repeated here.

[0061] In practical applications, the service node 20 (such as metadata service node 201) that sends the lease update request to client node 10 may malfunction and fail to respond to the lease update request, causing client node 10 to fail to update the lease number. If client node 10 does not receive a response to the lease update request within a set time period, it is determined that the lease number update has failed, meaning it failed to obtain the lease number from the service node (such as the metadata service node). Client node 10 can then request the lease number again from other unrequested metadata service nodes 201 until the lease number update is successful. In this way, client node 10 can obtain the lease number from other service nodes when some metadata service nodes malfunction, improving the lease number update success rate and enhancing system stability.

[0062] Based on the above analysis, when sending a lease update request, client node 10 can determine the target metadata service node from among the metadata service nodes 201 that have not yet sent a lease update request. Optionally, client node 10 can randomly select one metadata service node from among the metadata service nodes 201 that have not yet sent a lease update request as the target metadata service node. Further, client node 10 can periodically send lease update requests to the target metadata service node according to the current update cycle. If obtaining the lease number from the target metadata service node fails, the update cycle is shortened, and a new target metadata service node is determined from the remaining metadata service nodes that have not sent a lease update request. Afterwards, client node 10 can set the shortened update cycle as the current update cycle and return to execute the operation of periodically sending lease update requests to the target metadata service node according to the current update cycle until the lease number is successfully obtained. Using the same method, client node 10 sequentially requests lease number updates from previously unrequested metadata service nodes until a lease number is successfully obtained, i.e., until a metadata service node successfully responds to the lease update request and returns the lease number to client node 10. In this way, client node 10 can obtain lease numbers from other metadata service nodes even when some are malfunctioning, improving the lease number update success rate and enhancing system stability.

[0063] The meta-service data node that responds to the lease update request sent by client node 10 and returns a lease number to client node 10 is the first service node, and the lease number returned by the meta-service data node as the first service node to client node 10 is the aforementioned second lease number (SeqId-2).

[0064] On the other hand, if client node 10 fails to obtain the lease number from the target metadata service node, it can shorten the update cycle and continue to send lease update requests to the new metadata service node, thereby updating the lease number as quickly as possible and improving lease update efficiency.

[0065] Accordingly, if client node 10 fails to obtain a lease number after sending a lease update request to all metadata service nodes, client node 10 will output a lease update failure message. For example, if client node 10 fails to obtain a lease number after sending a lease update request to all metadata service nodes, it will output a lease update failure message within a set time period. This set time period can be freely configured, such as 5 seconds, 10 seconds, or 20 seconds.

[0066] Upon receiving a lease renewal request, the metadata service node can respond to the request and determine the second lease number (SeqId-2) that is currently valid. For details on how the metadata service node responds to the lease renewal request and determines the second lease number (SeqId-2) that is currently valid, please refer to the aforementioned content regarding service node 20 responding to the lease renewal request and determining the second lease number (SeqId-2) that is currently valid; these details will not be repeated here.

[0067] like Figure 1 Step 4 and Figure 2 As shown in step 7, when client node 10 accesses the distributed service, it can send an access request carrying the second lease number (SeqId-2) to the second service node, which is the destination service node of the access request, based on the second lease number (SeqId-2) obtained from the first service node 20. The second service node can be the first service node or any other service node, depending on the access requirements corresponding to the access request. For ease of description and distinction, the access request carrying the second lease number (SeqId-2) sent by client node 10 is defined as the second access request. The second lease number (SeqId-2) may be the aforementioned first lease number (SeqId-1) or any other lease number, depending on the specific lease number obtained by client node 10 from the first service node.

[0068] Specifically, client node 10 can determine the destination service node from multiple service nodes 20 as the second service node based on access request information. The access request information refers to information reflecting the purpose or intent of the access, and may include the data to be operated on and the address information or identifier of the service node corresponding to the data. The service node corresponding to the data to be operated on is the destination service node. For example, in some embodiments, the second access request is a data deletion request, then the access request information may include: the identifier of the data to be deleted and the address information or identifier of the service node where the data to be deleted is located. The service node where the data to be deleted is located is the destination service node.

[0069] For the aforementioned distributed metadata management system, client node 10 can determine the destination service node from multiple metadata service nodes based on the access request information, and use it as the second service node. Specifically, client node 10 can obtain the address information or identifier of the metadata service node corresponding to the data to be operated on from the access request information. The metadata service node specified by the address information or identifier of the metadata service node corresponding to the data to be operated on is the destination service node, which is the second service node.

[0070] like Figure 1 Steps 5 to 6.4.1 and Figure 2As shown in step 8, the second service node 20 (or metadata service node) can receive the second access request and respond to the second access request based on the second lease number (SeqId-2) carried in the second access request and the lease number (SeqId-3) currently stored in the service node 20.

[0071] The lease number (SeqId-3) currently stored by the second service node 20 is the lease number stored during its response to the second access request. For ease of description and distinction, the lease number (SeqId-3) currently stored by the second service node 20 is defined as the first lease number set (SeqId-3). The first lease number set (SeqId-3) can have one or more. Multiple means two or more. Whether the first lease number set (SeqId-3) stored by the second service node 20 during its response to the second access request includes the first lease number (SeqId-1) updated by the aforementioned service node 20 is determined by the order and interval between the second service node 20 receiving the second access request carrying the second lease number (SeqId-2) and updating the first lease number (SeqId-1). If the second service node 20 has updated to the first lease number (SeqId-1) when it receives the second access request, then the first lease number set (SeqId-3) currently stored by the second service node 20 includes the first lease number; if the second service node 20 has not yet updated to the first lease number (SeqId-1) or the second service node 20 has deleted the expired first lease number when it receives the second access request, then the first lease number set (SeqId-3) currently stored by the second service node 20 does not include the first lease number (SeqId-1).

[0072] Of course, whether the first lease number set (SeqId-3) stored by the second service node 20 during the response to the second access request includes the second lease number (SeqId-2) determined by the second service node 20 in response to the lease renewal request is also determined by the time interval between the second service node 20 receiving the second access request and determining the second lease number (SeqId-2) in response to the lease renewal request. If the second lease number (SeqId-2) stored by the second service node 20 has expired and been deleted when the second access request carrying the second lease number (SeqId-2) arrives, then the first lease number set (SeqId-3) currently stored by the second service node 20 does not include the second lease number (SeqId-2). If a second access request carrying the second lease number (SeqId-2) arrives, and the second lease number (SeqId-2) stored in the second service node 20 is valid or expired but not deleted, then the first lease number set (SeqId-3) currently stored in the second service node 20 includes the second lease number (SeqId-2).

[0073] The second service node 20 can respond to the access request based on the second lease number (SeqId-2) carried in the second access request and the first lease number set (SeqId-3) currently stored by the service node 20. Specifically, as follows: Figure 1 As shown in step 5, it can be determined whether the first lease number set (SeqId-3) currently stored by the second service node 20 includes the second lease number (SeqId-2). Further, as shown in step 6.1, if the first lease number set (SeqId-3) currently stored by the second service node 20 includes the second lease number (SeqId-2), then the identifier of the second access request (such as UUID) can be used. Figure 1 and Figure 2 (Illustrated with the identifier of the second access request as UUID-2) The query is performed in the request list stored in the second service node 20; if the processing result corresponding to the identifier of the second access request (such as UUID-2) is found in the request list corresponding to the second lease number (SeqId-2), the processing result corresponding to the identifier of the second access request (such as UUID-2) is used as the response result of the second access request, and the response result is returned to the client node 10.

[0074] In this embodiment, the server creates a request list to store successfully updated lease numbers, the identifier of the access request carrying that lease number, and the processing result of that access request. Thus, when the server receives an access request carrying a lease number, if it finds a processing result for a request with the same lease number and identifier in the stored request list, it considers the received access request to be the same as the access request corresponding to the processing result stored in the request list. The server then directly returns the processing result stored in the request list as the response result to the received access request to the client node, ensuring that the same access request is processed only once and has the same processing result, achieving idempotent processing of access requests. On the other hand, in a distributed system, idempotent processing between the server and client is achieved through lease numbers. The client can obtain a lease number from any service node without needing to maintain a session with each service node, reducing the server's workload.

[0075] In the embodiment where the lease number, access request identifier, and access request processing result are stored in the persistent storage request list of the service node, the request list will not disappear even if the service node or service process restarts. After the service node or service process in the service node restarts, the same access request can still be idempotently processed based on the lease number, access request identifier, and access request processing result in the persistent storage request list.

[0076] However, in some embodiments, when the second service node receives the second access request, the first lease number set (SeqId-3) stored includes the second lease number (SeqId-2), but the processing result of the second access request is not found in the request list corresponding to the second lease number (SeqId-2). The absence of a processing result for the second access request in the request list corresponding to the second lease number (SeqId-2) can be categorized into two cases: first, the request list corresponding to the second lease number (SeqId-2) stores the identifier of the second access request but not the processing result; second, the request list corresponding to the second lease number (SeqId-2) stores neither the identifier nor the processing result of the second access request.

[0077] The request list corresponding to the second lease number (SeqId-2) stores the identifier of the second access request, but does not store the processing result of the second access request. This could be because an identical access request is being processed, or because the processing of the identical access request failed, such as due to an exception occurring on the second service node during the access request processing. For access requests that fail to process, if the client does not receive a response within the specified response time, it will respond with a timeout and resend the same access request. That is, client node 10 has already requested a retry. If the second service node responds to the same access request again, it may cause errors and affect data security. For example, if the access request is a data deletion request, and client node 10 has already sent the same data deletion request when it times out and the service node has already responded to the resent data deletion request and deleted the relevant data, then if the second service node attempts to delete data from the same storage location again, the deletion may fail.

[0078] The inventors of this application have discovered through research and analysis that the timeout retry duration of a typical client node generally does not exceed a certain specific duration. Within this specific duration, the number of update cycles (first cycle T1) experienced by the lease numbers maintained by the service node is fixed. Based on this, a difference threshold L can be set between the lease number carried in the access request and the maximum lease number stored by the service node. This difference threshold L is determined by the update cycle of the service node's lease numbers (such as the first cycle T1), the increment gradient of the lease number in one update cycle, and the timeout retry duration of the client node. For example, if the first cycle T1 is 1 minute, the lease number increases by 1 in one update cycle, and the timeout retry duration of the client node is 10 minutes, then the set difference threshold can be 10, etc.

[0079] like Figure 1As shown in step 6.2, based on the set difference threshold L, if the first lease number set (SeqId-3) stored by the second service node at the time of the second access request includes the second lease number (SeqId-2), but the absolute value of the difference between the second lease number and the largest lease number in the first lease number set is greater than the set difference threshold L, that is... Figure 1 If [Max(SeqId-3)-SeqId-2] > L, and no processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, it indicates that the second access request may be an access request that was previously processed abnormally by the second service node. Therefore, an error message can be returned to client node 10 to indicate that the user server of client node 10 cannot respond to the second access request, thus preventing errors caused by processing the second access request. Here, Max(SeqId-3) represents the maximum lease number in the first lease number set; [Max(SeqId-3)-SeqId-2] represents the difference between the second lease number and the maximum lease number in the first lease number set.

[0080] Accordingly, such as Figure 1 As shown in step 6.4.1, if the first lease number set (SeqId-3) stored by the second service node when receiving the second access request includes the second lease number (SeqId-2), but the absolute value of the difference between the second lease number and the largest lease number in the first lease number set is less than or equal to a set difference threshold, that is... Figure 1 If [Max(SeqId-3)-SeqId-2] ≤ L, and the identifier of the second access request is not found in the request list corresponding to the second lease number, then the second access request is a new access request for the second service node. Therefore, the identifier of the second access request can be stored in the request list corresponding to the second lease number, and the second access request can be processed to obtain the processing result. Afterwards, the processing result of the second access request can be stored in the request list corresponding to the second lease number. And, as shown... Figure 1 As shown in step 6.4.2, the second service node returns the processing result of the second access request to the client node 10.

[0081] In this embodiment, the specific processing method of the second service node for the second access request is not limited. In some embodiments, the second access request is a data deletion request. The second service node determines the storage location of the data to be deleted based on the data deletion request, deletes the corresponding data from that storage location, and uses a data deletion success message as the processing result of the data deletion request. In other embodiments, the second access request is a data query request. The second service node determines the data query conditions from the data query request; queries the data according to the data query conditions to obtain the data query result, and uses the data query result as the processing result of the data query request. In still other embodiments, the second access request is a write request. The second service node determines the data to be written and the storage location to be written from the write request; writes the data to be written to the storage location to be written, and uses a data write success message as the processing result of the write request, and so on.

[0082] Furthermore, such as Figure 1 As shown in step 6.3.1, if the first lease number set (SeqId-3) stored by the second service node when receiving the second access request includes the second lease number (SeqId-2), but the absolute value of the difference between the second lease number and the largest lease number in the first lease number set is less than or equal to the set difference threshold, that is... Figure 1 If [Max(SeqId-3)-SeqId-2] ≤ L, and the identifier of the second access request (e.g., UUID-2) is found in the request list corresponding to the second lease number, but no processing result is found corresponding to the identifier of the second access request, then it means that the second service node is processing other access requests that are the same as the second access request. The second service node 20 can wait for the second service node to complete processing the other identical access requests before writing the processing result of the identical access request into the request list corresponding to the second lease number. Afterwards, as shown... Figure 1 As shown in step 6.3.2, the processing result corresponding to the access request with the same identifier (e.g., UUID-2) is retrieved from the request list corresponding to the second lease number and returned as the response result of the second access request to the client node 10. In other words, when the second service node 20 finds a processing result corresponding to the identifier of the second access request in the request list corresponding to the second lease number, it returns the processing result corresponding to the identifier of the second access request as the response result of the second access request to the client node 10. In this way, the same access request is still processed only once in the distributed system and the processing result is the same, which can realize the idempotency processing of access requests.

[0083] In some embodiments, the first lease number set (SeqId-3) stored by the second service node when receiving the second access request does not include the second lease number (SeqId-2). In this case, if the second lease number (SeqId-2) is less than the smallest lease number in the first lease number set (SeqId-3), that is, SeqId-2 < Min(SeqId-3), where Min(SeqId-3) represents the smallest lease number in the first lease number set (SeqId-3), it means that the second lease number (SeqId-2) has expired and been deleted by the second service node. In this case, the access request carrying the second lease number (SeqId-2) may be a floating request. A floating request refers to a request that, after being sent from the client, does not reach the server within the response time tolerated by the client, but floats in the network for a long time (several minutes, even several hours or longer) before reaching the server. The floating request may be caused by reasons such as the network or switch, resulting in the request not reaching the server within the specified time, causing the request to float.

[0084] Traditional idempotent processing solutions cannot block floating requests. When the client sends a request to the server, a unique request identifier is generated for each request. The server adds a cache (Cache) to cache key-value pairs (Key-Value, KV) with the request identifier as the key (Key) and the processing result (Response) of the processed request as the value (Value) corresponding to the key. The key-value pairs in the cache have a validity period, and the key-value pairs are deleted after they expire. In this way, during the validity period of the KV corresponding to a certain request identifier, when the server receives a request with the same request identifier, it can directly read the processing result of the request from the cache and return it to the client to achieve the idempotency of the request. However, for floating requests, the client node side may have resent the same access request due to response timeout, that is, the client node has requested a retry. If the second service node responds to the floating request again, it may cause errors and affect data security. For example, if the floating request is a data deletion request, when the client node retries due to timeout, it has sent the same data deletion request, and the service node has responded to the resent data deletion request and deleted the relevant data. During the floating period of the floating request, other write requests have written new data to the storage space where the data was deleted. If the second service node 20 processes the floating request when it arrives, the newly written data will be deleted, resulting in incorrect data deletion.

[0085] To solve this problem, in some embodiments of the present application, such as Figure 1As shown in step 6.1, if the second lease number (SeqId-2) carried in the second access request is less than the minimum lease number in the first lease number set (SeqId-3), that is, SeqId-2 < Min(SeqId-3), the second service node can return an error prompt message to the client node 10 to prompt the user of the client node 10 that the server cannot respond to the second access request, which can prevent errors caused by processing free requests.

[0086] In some other embodiments, the first lease number set (SeqId-3) stored by the second service node when receiving the second access request does not include the second lease number (SeqId-2). In this case, if the second lease number (SeqId-2) is greater than the maximum lease number in the first lease number set (SeqId-3), it means that the second service node needs to update the lease number. In this case, for the second service node, the second lease number is the first lease number that has been successfully updated currently. Accordingly, the second service node can update the lease number to the second lease number, that is, create a request list corresponding to the second lease number, and store the second lease number and the identifier of the second access request (such as UUID-2) in the request list corresponding to the second lease number. Further, the second service node can also process the second access request to obtain the processing result of the second access request. After that, the processing result of the second access request is returned to the client node 10, and the processing result of the second access request is stored in the request list corresponding to the second lease number.

[0087] In some embodiments of the present application, the client node 10 can also store the identifier of the processed access request (defined as the third access request) and the lease number carried by the access request. Among them, the third access request may include the second access request and the first access request, or may not include the first access request and the second access request, which is specifically determined by the sending times of the first access request, the second access request, and the third access request. The lease number carried by the third access request can be one or more.

[0088] The number of third access requests sent to a service node (such as a metadata service node) may reach a set threshold, which is greater than or equal to 2 and is an integer. For ease of description, a service node whose number of received third access requests reaches the set threshold is defined as a third service node; and a metadata service node whose number of received third access requests reaches the set threshold is defined as a target metadata service node. Then, if the number of requests sent to the third service node reaches the set threshold, the client node 10 can, based on the identifier of the third access request and the lease number corresponding to the third access request, request the third service node to delete the identifier of the access request and the processing result of the access request from the request list corresponding to the lease number of the access request. This saves storage resources for the third service node, and when the number of completed access requests for the same lease number reaches the set threshold, requesting the third service node to delete the identifier and processing result of the access requests for that lease number simultaneously reduces the number of accesses from the client node to the service node, thus reducing the access pressure on the service node.

[0089] The foregoing embodiments only illustrate the request processing method provided in this application by taking the request processing system supporting idempotent processing as an example. Of course, the request processing system provided in this application can also provide a selection interface, allowing the user to choose whether to use the idempotent scheme provided by the request processing system. For example, in some embodiments, the service node can provide a user interface, which may include a selection control for the user to choose whether to use the idempotent scheme provided in this application (i.e., a scheme that strongly depends on idempotency) or not to use the idempotent scheme provided in this application (i.e., a scheme that does not depend on idempotency). For access requests sent by client nodes that choose not to use the idempotent scheme provided in this application, the service node can directly process the access request, obtain the processing result, and return the processing result to the client node. The process by which the service node processes the access request can be found in the relevant content of the foregoing embodiments, and will not be repeated here.

[0090] In addition to providing a request processing system, this application also provides a request processing method. The request processing method provided in this application is described below from the perspectives of client nodes and service nodes providing distributed services.

[0091] Figure 3 This is a flowchart illustrating a request processing method provided in an embodiment of this application. This method is applicable to service nodes providing distributed services. Figure 3 As shown, the request processing method mainly includes:

[0092] 301. Receive a second access request sent by the client node, carrying the second lease number.

[0093] 302. If the first set of lease numbers currently stored includes the second lease number, and if the processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, then the processing result corresponding to the identifier of the second access request shall be used as the response result of the second access request.

[0094] 303. Return the response result to the client node.

[0095] Figure 4 This is a flowchart illustrating another request processing method provided in an embodiment of this application. This method is applicable to client nodes. For example... Figure 4 As shown, the request processing method mainly includes:

[0096] 401. Obtain the second lease number from the first service node among multiple service nodes; multiple service nodes provide distributed services and store a request list corresponding to the successfully updated first lease number; the request list corresponding to the first lease number is used to store the first lease number, the identifier of the first access request carrying the first lease number, and the processing result of the first access request.

[0097] 402. Send a second access request carrying the second lease number to the second service node among multiple service nodes.

[0098] 403. Receive the response result of the second access request returned by the second service node; wherein, if the second service node stores the processing result corresponding to the identifier of the second access request in the first set of lease numbers, which includes the second lease number, and the request list corresponding to the second lease number stores the processing result corresponding to the identifier of the second access request, the second service node shall take the processing result corresponding to the identifier of the second access request as the response result.

[0099] In this embodiment, the service node can update the lease number (SeqId). The lease number can increment over time. This embodiment does not limit the specific implementation of how the service node updates the lease number. In some embodiments, the lease number can be updated periodically according to a set period. For example, according to a set period, the lease number can be increased by a set gradient based on the lease number of the previous period in each period. For example, the lease number increases by 1 in each period.

[0100] For a distributed metadata service system, the root service node can periodically and incrementally update the lease number (SeqId) according to a set period T1, and provide the lease number updated in the current period to multiple metadata service nodes. Correspondingly, in embodiments where the service node is a metadata service node in the distributed metadata service system, the metadata service node can update its lease number by receiving the lease number provided by the root service node, and use the received lease number as the currently updated lease number (SeqId-1). In this application embodiment, the specific value of the period T1 is not limited. In some embodiments, the period T1 can be determined according to the heartbeat detection period of the root service node, such as the period T1 being equal to the heartbeat detection period of the root service node 202.

[0101] The lease number (SeqId-1) currently updated to by the service node is defined as the first lease number (SeqId-1). For the first lease number (SeqId-1), in step 302, a request list corresponding to the first lease number (SeqId-1) can be created. This request list is stored in the service node. Preferably, the request list can be persistently stored in the service node. The request list corresponding to each lease number is used to store the lease number, the identifier of the access request carrying the lease number, and the processing result of the access request.

[0102] The lease numbers stored by service nodes (such as metadata service nodes) have a set validity period t1. The validity period t1 is greater than the lease number update cycle of the aforementioned root service node, i.e., the cycle T1. That is, t1 > T1. If T1 = 1 minute, then t2 can be 5 minutes, etc.

[0103] Service nodes (such as metadata service nodes) can delete the request list of expired lease numbers after a lease number expires, thereby deleting the expired lease number, the identifier of the access request carrying the expired lease number, and the processing results of these access requests. In some embodiments, the request list of expired lease numbers can be deleted after a set duration t2 of the lease number's expiration. The set duration t2 is greater than the aforementioned validity period t1. Alternatively, after a lease number expires, when updating to a new lease number, the request list corresponding to the smallest expired lease number can be deleted, thus achieving lease number expiration deletion.

[0104] The client node can obtain the lease number from any service node to update the lease number. In this embodiment, for ease of description and distinction, the service node from which the client node obtains the lease number is defined as the first service node. That is, as follows... Figure 4As shown in step 401, the lease number can be obtained from the first service node. The first service node is the service node that successfully responds to the lease renewal request from the client node. Specifically, the client node can send a lease renewal request to any service node. For the service node that receives the lease renewal request, it can respond to the lease renewal request and determine the maximum lease number that is currently valid, which is defined as the second lease number (SeqId-2).

[0105] Specifically, for a service node (such as a metadata service node) that receives a lease update request, it can respond by querying the validity period of currently stored lease numbers. If there are valid lease numbers among the currently stored lease numbers, the largest lease number is determined from the valid lease numbers and used as the second lease number (SeqId-2), which is then returned to the client node 10. Correspondingly, if all lease numbers currently stored by the service node (such as the metadata service node) have expired, the lease numbers can be updated periodically and incrementally according to a set period T2, based on the largest lease number currently stored by the service node (such as the metadata service node). The update period T2 for the service node (such as the metadata service node) to self-update lease numbers is defined as the second period T2. In this embodiment, the service node (such as the metadata service node) can use the lease number updated in the current second period as the second lease number (SeqId-2) and return the second lease number (SeqId-2) to the client node. The current second cycle can be the first cycle of self-updating of service nodes (such as metadata service nodes).

[0106] Furthermore, the service node (or metadata service node) that receives the lease renewal request from the client node, for any second period T2 of self-renewal... i This allows the creation of the second cycle T2. i The updated request list corresponding to the lease number. This request list can store the corresponding second period T2. i Updated lease number (SeqId) i ), carrying the lease number (SeqId) i Access request and carrying the lease number (SeqId) i The result of processing the access request. i represents the i-th second cycle. i = 1, 2, 3...

[0107] For a distributed metadata management system, when a metadata service node receives a lease update request and all its stored lease numbers have expired, it can periodically and incrementally update the lease numbers based on the maximum lease number currently stored in the node, according to a set second period T2. For example, a set gradient can be added to the maximum stored lease number for each second period T2 to obtain the lease number for each second period T2. The automatic update of lease numbers by the metadata service node when all its stored lease numbers have expired reduces the dependency of the metadata service node's lease number updates on the root service node. Even if the root service node fails, the metadata service node can still update its lease numbers, which helps maintain and improve the idempotency of distributed metadata management.

[0108] Since the lease number of the metadata service node may be obtained through self-update or from access requests, in some cases, the maximum lease number of the metadata service node may be greater than the maximum lease number stored by the root service node. In this case, the root service node can update the lease number stored by the root service node to the maximum lease number stored by the metadata service node, and continue to periodically and incrementally update the lease number based on the maximum lease number stored by the metadata service node, according to the aforementioned first period T1.

[0109] To conserve storage resources, service nodes (such as metadata service nodes) can delete the request list of expired lease numbers after the lease number expires, thereby deleting the expired lease number, the identifier of the access request carrying the expired lease number, and the processing results of these access requests. In some embodiments, service node 20 can delete the request list of expired lease numbers after a set expiration time T3. The set expiration time T3 is longer than the aforementioned validity period T2.

[0110] Alternatively, after a lease number expires, the service node can delete the request list corresponding to the smallest lease number among the currently expired lease numbers when updating to a new lease number, thus achieving lease number expiration deletion. Specifically, the service node receiving the lease update request (such as the metadata service node) can delete any second period T2. i The request list corresponding to the smallest expired lease number in the stored lease numbers can be deleted periodically or irregularly to save storage resources.

[0111] In the aforementioned distributed metadata service system, a client node can request a lease number from any metadata service node to update the lease number. Specifically, a client node can send a lease update request to any metadata service node. Upon receiving the lease update request, the metadata service node can determine the maximum valid lease number, defined as the second lease number (SeqId-2). For details on the specific implementation of how the metadata service node determines the second lease number (SeqId-2), please refer to the aforementioned content on service node determination of the second lease number (SeqId-2), which will not be repeated here.

[0112] In practical applications, the service node (such as the metadata service node) that sends the lease update request to the client node may malfunction and fail to respond to the client node's lease update request, causing the client node's lease number update to fail. For the client node, if it does not receive a response to the lease update request within a set time period, it is determined that the lease number update has failed, meaning it failed to obtain the lease number from the service node (such as the metadata service node). When the lease number update fails, the client node can re-request the lease number from other metadata service nodes it has not yet requested, until the lease number update is successful. In this way, the client node can obtain the lease number from other service nodes when some metadata service nodes are malfunctioning, improving the lease number update success rate and enhancing system stability.

[0113] Based on the above analysis, when sending a lease update request, the client node can determine the target metadata service node from among multiple metadata service nodes that have not yet sent a lease update request. Optionally, the client node can randomly select one metadata service node from among the multiple metadata service nodes that have not yet sent a lease update request as the target metadata service node. Further, the client node can periodically send lease update requests to the target metadata service node according to the current update cycle. If obtaining the lease number from the target metadata service node fails, the update cycle is shortened, and a new target metadata service node is determined from the remaining metadata service nodes that have not sent a lease update request. Then, the shortened update cycle can be set as the current update cycle, and the operation of periodically sending lease update requests to the target metadata service node according to the current update cycle is returned until the lease number is successfully obtained. Using the same method, the client node sequentially requests lease number updates from metadata service nodes that have not been requested before until the lease number is successfully obtained, that is, until a metadata service node successfully responds to the lease update request and returns the lease number to the client node. In this way, when some metadata service nodes are abnormal, the client node can obtain the lease number from other metadata service nodes, thereby improving the success rate of lease number updates and enhancing system stability.

[0114] The metadata service data node that responds to the lease update request sent by the client node and returns the lease number to the client node is the first service node, and the lease number returned by the metadata service data node as the first service node to the client node is the aforementioned second lease number (SeqId-2).

[0115] On the other hand, if the client node fails to obtain the lease number from the target metadata service node, it can shorten the update cycle and continue to send lease update requests to the new target metadata service node, thereby updating the lease number as quickly as possible and improving lease update efficiency.

[0116] Accordingly, if the client node fails to obtain the lease number after sending a lease update request to all metadata service nodes, the client node will output a lease update failure message.

[0117] Upon receiving a lease renewal request, the metadata service node can respond to the request and determine the second lease number (SeqId-2) that is currently valid. For details on how the metadata service node responds to the lease renewal request and determines the second lease number (SeqId-2) that is currently valid, please refer to the aforementioned content on service nodes responding to lease renewal requests and determining the second lease number (SeqId-2) that is currently valid; these details will not be repeated here.

[0118] When a client node accesses a distributed service, in step 402, it can send an access request carrying the second lease number (SeqId-2) to the second service node, which is the destination service node of the access request, based on the second lease number (SeqId-2) obtained from the first service node. The second service node can be the first service node or any other service node, depending on the access requirements corresponding to the access request. For ease of description and distinction, the access request carrying the second lease number (SeqId-2) sent by the client node is defined as the second access request. The second lease number (SeqId-2) may be the aforementioned first lease number (SeqId-1) or any other lease number, depending on the specific lease number obtained by the client node from the first service node.

[0119] Specifically, the client node can determine the destination service node from multiple service nodes as the second service node based on the access request information. The access request information refers to information reflecting the purpose or intent of the access, and may include the data to be operated on and the address information or identifier of the service node corresponding to the data. The service node corresponding to the data to be operated on is the destination service node. For example, in some embodiments, the second access request is a data deletion request; in this case, the access request information may include: the identifier of the data to be deleted and the address information or identifier of the service node where the data to be deleted is located. The service node where the data to be deleted is located is the destination service node.

[0120] In the aforementioned distributed metadata management system, client nodes can determine the destination service node from multiple metadata service nodes based on the access request's requirements, thus designating it as the second service node. Specifically, client nodes can obtain the address information or identifier of the metadata service node corresponding to the data to be operated on from the access request information. The metadata service node specified by the address information or identifier of the metadata service node corresponding to the data to be operated on is the destination service node, which is also the second service node.

[0121] For the second service node (metadata service node), as shown in step 303, it can receive the second access request and respond to the second access request based on the second lease number (SeqId-2) carried in the second access request and the lease number (SeqId-3) currently stored in the service node.

[0122] Upon receiving the second access request, the second service node can respond to the second access request based on the currently stored first lease number set (SeqId-3) and the second lease number (SeqId-2) carried in the second access request. For a detailed implementation of the second service node's response to the second access request, please refer to [link to relevant documentation]. Figure 5 .like Figure 5 As shown, the specific process by which the second service node responds to the second access request based on the currently stored first lease number set (SeqId-3) and the second lease number (SeqId-2) carried in the second access request includes:

[0123] Step S1: Receive the second access request.

[0124] Step S2: Determine whether the currently stored first lease number set (SeqId-3) includes the second lease number (SeqId-2) carried in the second access request. If the determination result is yes, proceed to step S3; if the determination result is no, proceed to step S12.

[0125] Step S3: Determine whether the request list corresponding to the second lease number (SeqId-2) stored by the second service node (such as the metadata service node that received the second access request) includes the processing result corresponding to the identifier (UUID-2) of the second access request. If the determination result is yes, proceed to step S4; if the determination result is no, proceed to step S5.

[0126] Step S4: Return the processing result corresponding to the identifier (UUID-2) of the second access request stored in the request list corresponding to the second lease number (SeqId-2) to the client node.

[0127] Step S5: Determine whether the absolute value of the difference between the second lease number (SeqId-2) and the maximum lease number Max(SeqId-3) in the currently stored first lease number set (SeqId-3) is greater than the set difference threshold L, that is, determine whether Max(SeqId-3)-(SeqId-2) is greater than L. If the determination result is yes, proceed to step S13; if the determination result is no, proceed to step S6.

[0128] Step S6: Determine whether the request list corresponding to the second lease number (SeqId-2) contains the identifier (UUID-2) of the second access request. If the determination result is yes, proceed to step S10; if the determination result is no, proceed to step S7.

[0129] Step S7: Store the identifier (UUID-2) of the second access request into the request list corresponding to the second lease number (SeqId-2); then execute step S8.

[0130] Step S8: Process the second access request and obtain the processing result corresponding to the second access request. Then, execute step S9.

[0131] Step S9: Return the processing result corresponding to the second access request to the client node, and store the processing result corresponding to the second access request in the request list corresponding to the second lease number (SeqId-2).

[0132] Step S10: Wait for the processing result corresponding to the identifier (UUID-2) of the second access request in the request list corresponding to the second lease number (SeqId-2); and then execute step S11.

[0133] Step S11: Return the processing result corresponding to the identifier (UUID-2) of the second access request to the client node.

[0134] Step S13: Return error message to the client node.

[0135] In this embodiment, the server creates a request list for the lease numbers successfully updated to store the lease numbers updated successfully, the identifiers of the access requests carrying the lease numbers, and the processing results of the access requests. In this way, when the server receives an access request carrying a lease number, if it queries the processing result of the request with the same lease number and the same identifier in the stored request list, it is considered that the received access request is the same as the access request corresponding to the processing result stored in the request list, and directly returns the processing result stored in the request list as the response result of the received access request to the client node, so that the same access request is processed once and has the same processing result, realizing the idempotent processing of the access request. On the other hand, in a distributed system, the server and the client implement idempotent processing through lease numbers that increase with time. The client can obtain a lease number from any service node without maintaining a session with each service node, which can reduce the pressure on the server.

[0136] In the embodiment where the lease numbers, the identifiers of the access requests, and the processing results of the access requests stored in the request list are persistently stored in the service node, even if the service node or the service process restarts, the request list will not disappear. After the service node or the service process in the service node restarts, idempotent processing of the same access request can still be performed based on the lease numbers, the identifiers of the access requests, and the processing results of the access requests in the persistently stored request list.

[0137] If the second lease number (SeqId-2) carried by the second access request is less than the minimum lease number in the first lease number set (SeqId-3), that is, SeqId-2 < Min(SeqId-3), the second service node can return an error prompt message to the client node to prompt the user of the client node that the server cannot respond to the second access request, which can prevent errors caused by processing free requests.

[0138] In some embodiments, the first lease number set (SeqId-3) stored when receiving a second access request does not include the second lease number (SeqId-2). In this case, if the second lease number (SeqId-2) is greater than the largest lease number in the first lease number set (SeqId-3), it indicates that the second service node needs to update the lease number. In this case, the second lease number for the second service node is the currently successfully updated first lease number. Accordingly, the second service node can update the lease number to the second lease number, that is, create a request list corresponding to the second lease number, and store the second lease number and the identifier of the second access request (such as UUID-2) in the request list corresponding to the second lease number. Furthermore, the second service node can also process the second access request to obtain the processing result of the second access request. Then, the processing result of the second access request is returned to the client node, and the processing result of the second access request is stored in the request list corresponding to the second lease number.

[0139] In some embodiments of this application, the client node may also store the identifier of a completed access request (defined as a third access request) and the lease number carried by that access request. The third access request may include, or may not include, the second and third access requests, depending on the issuance time of the first, second, and third access requests. The lease number carried by the third access request may be one or more.

[0140] The number of third access requests sent to a service node (such as a metadata service node) may reach a set threshold, which is greater than or equal to 2 and is an integer. For ease of description, a service node whose number of received third access requests reaches the set threshold is defined as a third service node; and a metadata service node whose number of received third access requests reaches the set threshold is defined as a target metadata service node. Then, if the number of requests sent to the third service node (such as the target metadata service node) reaches the set threshold, the client node can, based on the identifier of the third access request and the corresponding lease number, request the third service node (such as the target metadata service node) to remove the access request identifier and the processing result of the access request from the request list corresponding to the lease number of the access request. In this way, on the one hand, the storage resources of the wooden template service node (such as the target metadata service node) can be saved; on the other hand, when the number of access requests completed for the same lease number reaches the set threshold, the third service node (such as the target metadata service node) is requested to delete the identifier and processing result of the access request for that lease number. This can reduce the number of times the client node accesses the service node (such as the target metadata service node) and reduce the access pressure on the service node (such as the target metadata service node).

[0141] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 301 and 302 can be device A; or the execution subject of step 301 can be device A, and the execution subject of step 302 can be device B; and so on.

[0142] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 301, 303, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0143] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the aforementioned request processing methods.

[0144] This application also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the aforementioned request processing methods. In this application, the specific implementation of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a computer-side client node, a program module, a plug-in, an installation package, a software development kit (SDK), an optical disc image file (such as an ISO file), a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited thereto.

[0145] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device includes a memory 60a and a processor 60b. The memory 60a is used to store computer programs.

[0146] Processor 60b is coupled to memory 60a and is used to execute computer programs to perform the steps in the request processing methods provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0147] In some alternative implementations, such as Figure 6 As shown, the electronic device may also include optional components such as a communication component 60c, a power supply component 60d, a display component 60e, and an audio component 60f. Figure 6 The diagram only shows some components and does not mean that the electronic device must contain them. Figure 6 The fact that all components are shown does not mean that an electronic device can only include... Figure 6 The components shown.

[0148] in addition, Figure 6 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the form factor of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0149] In this embodiment, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Electrically Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0150] In the embodiments of this application, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), a complex programmable logic device (CPLD), or other programmable devices; or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0151] In this embodiment, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), or other technologies.

[0152] In embodiments of this application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component can be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0153] In this embodiment, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0154] In embodiments of this application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with the user can be achieved through the audio component.

[0155] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0156] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0157] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0158] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0159] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0160] In a typical configuration, a computing device includes one or more processors (CPU, etc.), input / output interfaces, network interfaces, and memory.

[0161] Memory may include non-persistent storage in computer-readable media, such as random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0162] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0163] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the aforementioned element.

[0164] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A request processing system, characterized in that, include: Client nodes and multiple service nodes; The multiple service nodes provide distributed services; The multiple service nodes are used to update the lease number; For the first lease number that was successfully updated, create a request list corresponding to the first lease number; The request list is used to store the first lease number, the identifier of the first access request carrying the first lease number, and the processing result of the first access request; The client node is used to obtain the second lease number from the first service node among the plurality of service nodes; Send a second access request carrying the second lease number to the second service node among the plurality of service nodes; The second service node is configured to, if the processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number when the first lease number set currently stored includes the second lease number, then use the processing result corresponding to the identifier of the second access request as the response result of the second access request, and return the response result to the client node.

2. The system according to claim 1, characterized in that, The lease number increments over time; the second service node is specifically used for: If the first set of lease numbers currently stored includes the second lease number, and the absolute value of the difference between the second lease number and the largest lease number in the first set of lease numbers is greater than a set difference threshold, and no processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, then an error message is output to the client node. And / or, If the second lease number is less than the smallest lease number in the first lease number set, an error message is output to the client node.

3. The system according to claim 1 or 2, characterized in that, The distributed service is a distributed metadata service; The plurality of service nodes include: a root service node and a plurality of metadata service nodes; the plurality of metadata service nodes are used to manage the metadata of application data stored in the distributed storage system; the root service node is used to manage the plurality of metadata service nodes; When updating the lease number, the root service node is specifically used to: periodically and incrementally update the lease number according to a set first period; and send the lease number updated in the current first period to the multiple metadata service nodes; When updating the lease number, the multiple metadata service nodes are specifically used to: update the lease number by receiving the lease number provided by the root service node.

4. A request processing method, applicable to service nodes providing distributed services, characterized in that, The service node stores a request list corresponding to the first lease number that has been successfully updated; the request list is used to store the first lease number, the identifier of the first access request carrying the first lease number, and the processing result of the first access request; The method includes: Receive a second access request sent by the client node, carrying the second lease number; If the first set of lease numbers currently stored includes the second lease number, and if the processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, then the processing result corresponding to the identifier of the second access request is used as the response result of the second access request. The response result is returned to the client node.

5. The method according to claim 4, characterized in that, The lease number increments over time, and the method further includes: If the first set of lease numbers currently stored includes the second lease number, and the absolute value of the difference between the second lease number and the largest lease number in the first set of lease numbers is greater than a set difference threshold, and no processing result corresponding to the identifier of the second access request is found in the request list corresponding to the second lease number, then an error message is output to the client node. And / or, If the second lease number is less than the smallest lease number in the first lease number set, an error message is output to the client node.

6. The method according to claim 4, characterized in that, The lease number increments over time, and the method further includes: If the currently stored first set of lease numbers includes the second lease number, and if the absolute value of the difference between the second lease number and the largest lease number in the first set of lease numbers is less than or equal to a set difference threshold, and the identifier of the second access request is not found in the request list corresponding to the second lease number, then the identifier of the second access request is stored in the request list corresponding to the second lease number request, and... The second access request is processed to obtain the processing result of the second access request; The processing result of the second access request is stored in the request list corresponding to the second lease number; and the processing result of the second access request is returned to the client node.

7. The method according to claim 4, characterized in that, The lease number increments over time, and the method further includes: If the first set of lease numbers currently stored includes the second lease number, and if the absolute difference between the second lease number and the largest lease number in the first set of lease numbers is less than or equal to a set difference threshold, and the identifier of the second access request is found in the request list corresponding to the second lease number, but no processing result is found corresponding to the identifier of the second access request, then when the processing result corresponding to the identifier of the second access request exists in the request list corresponding to the second lease number, the processing result corresponding to the identifier of the second access request is used as the response result of the second access request and returned to the client node.

8. The method according to any one of claims 4-7, characterized in that, The service node is a metadata service node in a distributed metadata service system, and also includes: The system receives a lease number provided by the root service node in the distributed metadata service system as the first lease number; the root service node updates the lease number periodically and incrementally according to a set first period.

9. The method according to any one of claims 4-7, characterized in that, Also includes: In response to the lease update request sent by the client node, query the validity period of the lease numbers in the currently stored second lease number set; From the second set of lease numbers, determine the second lease number that is currently in effect; Return the second lease number to the client node.

10. The method according to claim 9, characterized in that, Also includes: If all lease numbers in the second lease number set expire, the lease number is updated periodically and incrementally according to the set second period, based on the largest lease number in the second lease number set, and the lease number updated in the current second period is returned to the client node as the second lease number.

11. The method according to claim 10, characterized in that, The lease number is incremented over time and also includes; For any second period, a request list corresponding to the target lease number updated in the second period is created. The request list corresponding to the target lease number is used to store the target lease number, the access request carrying the target lease number, and the processing result of the access request carrying the target lease number. And / or, Delete the request list corresponding to the smallest expired lease number in any of the lease numbers stored in the second cycle.

12. The method according to any one of claims 4-7, characterized in that, Also includes: If the second lease number is greater than the largest lease number in the first lease number set, the second lease number shall be used as the first lease number.

13. A request processing method, applicable to client nodes, characterized in that, The method includes: The second lease number is obtained from the first service node among multiple service nodes; the multiple service nodes provide distributed services and store a request list corresponding to the first lease number that has been successfully updated; the request list corresponding to the first lease number is used to store the first lease number, the identifier of the first access request carrying the first lease number, and the processing result of the first access request; Send a second access request carrying the second lease number to the second service node among the plurality of service nodes; Receive the response result of the second access request returned by the second service node; Wherein, if the second service node stores the second lease number in the first lease number set and the request list corresponding to the second lease number stores the processing result corresponding to the identifier of the second access request, the second service node shall use the processing result corresponding to the identifier of the second access request as the response result.

14. The method according to claim 13, characterized in that, The multiple service nodes are multiple metadata service nodes in a distributed metadata service system; Obtaining the second lease number from the first service node among multiple service nodes includes: The target metadata service node is determined from among the metadata service nodes that have not yet sent a lease renewal request; According to the current update cycle, the lease update request is periodically sent to the target metadata service node to request the lease number to be updated; If updating the lease number from the target metadata service node fails, the update cycle is shortened, and a new target metadata service node is determined from the remaining metadata service nodes that have not sent a lease update request. The shortened update cycle is used as the current update cycle, and the operation of periodically sending the lease update request to the target metadata service node according to the current update cycle is returned until the lease number is obtained from the metadata service node. Wherein, the metadata service node for which the client node obtains the lease number is the first service node, and the lease number obtained by the client node is the second lease number.

15. The method according to claim 14, characterized in that, Sending a second access request carrying the second lease number to the second service node among the plurality of service nodes includes: Based on the access request information of the second access request, a destination service node is determined from the plurality of metadata service nodes and used as the second service node; Send a second access request carrying the second lease number to the second service node.

16. The method according to claim 13, characterized in that, The method further includes: Store the identifier of the processed third access request and the lease number carried in the third access request; If the number of third access requests sent to the third service node reaches a set threshold, then based on the identifier of the third access request and the lease number corresponding to the third access request, the third service node is requested to delete the identifier of the third access request and the processing result of the third access request from the request list corresponding to the lease number carried by the third access request.

17. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 4-16.

18. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 4-16.

19. A computer program product, characterized in that, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to any one of claims 4-16.

Images