Request processing recovery method and device, equipment, storage medium and program product

Abstract

The invention provides a request processing recovery method and device, equipment, a storage medium and a program product, and is applied to a target server, the method comprises the following steps: when a source server is abnormal, a virtual machine and virtual queue information corresponding to the virtual machine are migrated to the target server, and the virtual queue information comprises a plurality of processing requests generated by the virtual machine; a descriptor bitmap is determined in the virtual machine, the descriptor bitmap comprises the processing state of each processing request, and the processing state is an unprocessed state or a processed state; and according to the descriptor bitmap, determining at least one target processing request in an unprocessed state in the plurality of processing requests, and processing the at least one target processing request. Through the request processing recovery method in the application, the destination server can recover the processing of the plurality of processing requests according to the description bitmap.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a request processing recovery method, apparatus, device, storage medium, and program product. Background Technology

[0002] A server can include virtual machines and a storage backend. The storage backend can process input / output (I / O) requests generated by the virtual machines.

[0003] In related technologies, when a server malfunctions, it cannot determine which I / O requests have been processed and which have not, making it impossible to resume processing of I / O requests. Therefore, there is currently a lack of a method to resume processing of I / O requests when a server malfunctions. Summary of the Invention

[0004] This application provides a request processing recovery method, apparatus, device, storage medium, and program product to solve the problem of how to recover processing requests when a server malfunctions.

[0005] In a first aspect, embodiments of this application provide a request processing recovery method, applied to a destination server, the method comprising:

[0006] When the source server is abnormal, the virtual machine and the virtual queue information corresponding to the virtual machine are migrated to the destination server. The virtual queue information includes multiple processing requests generated by the virtual machine.

[0007] A descriptor bitmap is determined in the virtual machine, the descriptor bitmap including the processing status of each processing request, the processing status being either unprocessed or processed;

[0008] Based on the descriptor bitmap, at least one target processing request in the unprocessed state is determined among the plurality of processing requests, and the at least one target processing request is processed.

[0009] In one possible implementation, determining at least one target processing request of the unprocessed state among the plurality of processing requests based on the descriptor bitmap includes:

[0010] Identify at least one currently processed request;

[0011] In the descriptor bitmap, the processing status of the at least one currently processed request is set to the processed status to obtain an updated descriptor bitmap;

[0012] Based on the updated descriptor bitmap, at least one target processing request in the unprocessed state is determined among the plurality of processing requests.

[0013] In one possible implementation, the descriptor bitmap includes multiple bits; in the descriptor bitmap, setting the processing state of the at least one currently processed request to a processed state to obtain an updated descriptor bitmap includes:

[0014] In the descriptor bitmap, at least one bit to be reset is determined based on the index corresponding to the at least one currently processed request;

[0015] The at least one bit to be reset is set to a first value to set the processing status corresponding to the at least one currently processed request to a processed status, thereby obtaining an update descriptor bitmap.

[0016] In one possible implementation, determining at least one target processing request for the unprocessed state among the plurality of processing requests based on the updated descriptor bitmap includes:

[0017] In the updated descriptor bitmap, at least one target bit corresponding to the second value is determined;

[0018] The processing request corresponding to the at least one target bit is determined as the at least one target processing request.

[0019] In one possible implementation, the virtual queue information includes used rings; determining at least one currently processed request includes:

[0020] In the used ring, determine the currently used pointer and the next used entry that the currently used pointer points to;

[0021] In the virtual machine, determine the local used pointer, and in the used ring, determine the target used entry pointed to by the local used pointer;

[0022] In the used ring, at least one used entry between the target used entry and the next used entry is determined, and the processing request corresponding to the index in the at least one used entry is determined as at least one currently processed request.

[0023] In one possible implementation, the virtual queue information includes an available ring and a descriptor table; processing the at least one target processing request includes:

[0024] At least one target available entry is identified in the available ring;

[0025] The index corresponding to the at least one target processing request is stored in the at least one target available entry;

[0026] The at least one target processing request is processed based on the at least one available target entry and the descriptor table.

[0027] In one possible implementation, determining at least one target available entry in the available ring includes:

[0028] Based on the currently used pointers, determine the local available pointer corresponding to the first unprocessed request;

[0029] Determine the currently available pointer within the available ring;

[0030] Based on the local available pointer and the current available pointer, at least one target available entry is determined in the available ring, wherein the local available pointer points to the first available entry among the at least one target available entry.

[0031] In one possible implementation, determining the locally available pointer corresponding to the first unprocessed request based on the currently used pointer includes:

[0032] If the locally available pointer is inconsistent with the currently used pointer, then the locally available pointer is updated according to the currently used pointer.

[0033] In one possible implementation, for any target processing request, the at least one target processing request is processed according to the at least one target availability entry and the descriptor table, including:

[0034] Determine the first target available entry pointed to by the local available pointer from the at least one target available entry;

[0035] Obtain the first index from the available entries of the first target;

[0036] Based on the first index, a descriptor list is determined in the descriptor table, and the descriptor list is used to store the request information of the target processing request;

[0037] The request information of the first target processing request is obtained from the descriptor chain, and the first target processing request is processed according to the request information.

[0038] In one possible implementation, the method further includes:

[0039] After obtaining the first index from the first target available entry, the local available pointer is moved to the next available entry of the first target available entry;

[0040] After processing the first target processing request, the first index is stored in the used ring, and the processing status corresponding to the target processing request is updated to the processed status in the update descriptor bitmap according to the first index.

[0041] Secondly, embodiments of this application provide a request processing recovery apparatus applied to a destination server. The apparatus includes: a migration module, a first determining module, a second determining module, and a processing module, wherein...

[0042] The migration module is used to migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server when the source server is abnormal. The virtual queue information includes multiple processing requests generated by the virtual machine.

[0043] The first determining module is configured to determine a descriptor bitmap in the virtual machine, the descriptor bitmap including the processing status of each processing request, the processing status being either unprocessed or processed.

[0044] The second determining module is configured to determine, based on the descriptor bitmap, at least one target processing request in the unprocessed state among the plurality of processing requests;

[0045] The processing module is used to process the at least one target processing request.

[0046] In one possible implementation, the second determining module is specifically used for:

[0047] Identify at least one currently processed request;

[0048] In the descriptor bitmap, the processing status of the at least one currently processed request is set to the processed status to obtain an updated descriptor bitmap;

[0049] Based on the updated descriptor bitmap, at least one target processing request in the unprocessed state is determined among the plurality of processing requests.

[0050] In one possible implementation, the descriptor bitmap includes multiple bits; the second determining module is specifically used for:

[0051] In the descriptor bitmap, at least one bit to be reset is determined based on the index corresponding to the at least one currently processed request;

[0052] The at least one bit to be reset is set to a first value to set the processing status corresponding to the at least one currently processed request to a processed status, thereby obtaining an update descriptor bitmap.

[0053] In one possible implementation, the second determining module is specifically used for:

[0054] In the updated descriptor bitmap, at least one target bit corresponding to the second value is determined;

[0055] The processing request corresponding to the at least one target bit is determined as the at least one target processing request.

[0056] In one possible implementation, the virtual queue information includes used rings; the second determining module is specifically used for:

[0057] In the used ring, determine the currently used pointer and the next used entry that the currently used pointer points to;

[0058] In the virtual machine, determine the local used pointer, and in the used ring, determine the target used entry pointed to by the local used pointer;

[0059] In the used ring, at least one used entry between the target used entry and the next used entry is determined, and the processing request corresponding to the index in the at least one used entry is determined as at least one currently processed request.

[0060] In one possible implementation, the virtual queue information includes unprocessed request information and a descriptor table; the processing module is specifically used for:

[0061] At least one target available entry is identified in the available ring;

[0062] The index corresponding to the at least one target processing request is stored in the at least one target available entry;

[0063] The at least one target processing request is processed based on the at least one available target entry and the descriptor table.

[0064] In one possible implementation, the processing module is specifically used for:

[0065] Based on the currently used pointers, determine the local available pointer corresponding to the first unprocessed request;

[0066] Determine the currently available pointer within the available ring;

[0067] Based on the local available pointer and the current available pointer, at least one target available entry is determined in the available ring, wherein the local available pointer points to the first available entry among the at least one target available entry.

[0068] In one possible implementation, the processing module is specifically used for:

[0069] If the locally available pointer is inconsistent with the currently used pointer, then the locally available pointer is updated according to the currently used pointer.

[0070] In one possible implementation, a processing request is handled for any single target; the processing module is specifically used for:

[0071] Determine the first target available entry pointed to by the local available pointer from the at least one target available entry;

[0072] Obtain the first index from the available entries of the first target;

[0073] Based on the first index, a descriptor list is determined in the descriptor table, and the descriptor list is used to store the request information of the target processing request;

[0074] The request information of the first target processing request is obtained from the descriptor chain, and the first target processing request is processed according to the request information.

[0075] In one possible implementation, the device further includes: a mobile module, a storage module, and an update module, wherein,

[0076] The moving module is used to move the local available pointer to the next available entry of the first target available entry after obtaining the first index in the first target available entry;

[0077] The storage module is used to store the first index in the used ring after processing the first target processing request;

[0078] The update module is used to update the processing status corresponding to the target processing request to a processed status in the update descriptor bitmap according to the first index.

[0079] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0080] The memory stores computer-executed instructions;

[0081] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects.

[0082] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects.

[0083] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method shown in any of the first aspects.

[0084] This application provides a request processing recovery method, apparatus, device, storage medium, and program product. When the source server is abnormal, the destination server can migrate the virtual machine and its corresponding virtual queue information to the destination server, and determine a descriptor bitmap in the virtual machine. Then, based on the descriptor bitmap, at least one unprocessed target processing request can be identified from multiple processing requests, and this at least one target processing request can be processed. Since the virtual machine contains a descriptor bitmap, it is possible to determine which processing requests have been processed and which have not, thus allowing unprocessed requests to continue processing. Therefore, the above method can restore the processing of processing requests. Attached Figure Description

[0085] 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:

[0086] Figure 1 A schematic diagram of a usable ring provided for an exemplary embodiment of this application;

[0087] Figure 2 A schematic diagram of a used ring provided for an exemplary embodiment of this application;

[0088] Figure 3 A schematic diagram of a descriptor table provided for an exemplary embodiment of this application;

[0089] Figure 4 A schematic diagram of a scenario provided for an exemplary embodiment of this application;

[0090] Figure 5 A flowchart illustrating a request processing method provided in an embodiment of this application;

[0091] Figure 6 A flowchart illustrating a request processing recovery method provided for an exemplary embodiment of this application;

[0092] Figure 7 A schematic diagram of the structure of a descriptor bitmap provided for an exemplary embodiment of this application;

[0093] Figure 8 A schematic diagram of an update descriptor bitmap provided for an exemplary embodiment of this application;

[0094] Figure 9A flowchart illustrating another request processing recovery method provided for an exemplary embodiment of this application;

[0095] Figure 10 A schematic diagram of a request processing recovery device provided for an exemplary embodiment of this application;

[0096] Figure 11 A schematic diagram of another request processing recovery apparatus provided as an exemplary embodiment of this application;

[0097] Figure 12 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

[0098] 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 relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0099] 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.

[0100] To facilitate understanding of the technical solution of this application, the concepts involved in this application will first be explained:

[0101] (1) A virtual queue (VQ) is a queue for data exchange between a virtual machine and a storage backend.

[0102] (2) Storage backend refers to the hardware or software in the server that is responsible for handling I / O requests.

[0103] The main functions of the storage backend include: receiving and processing I / O requests from virtual machines; writing data to physical storage media (such as disks, solid-state drives, or cloud disks); and reading data from physical storage media.

[0104] (3) Virtual queue information refers to the information in a virtual queue. Virtual queue information may include available rings, used rings, and a descriptor table.

[0105] (4) The available ring can be used to store the index corresponding to unprocessed requests, that is, the index corresponding to the virtual machine's I / O / requests.

[0106] Below, in conjunction with Figure 1 The available rings are described.

[0107] Figure 1 A schematic diagram of a usable ring provided for an exemplary embodiment of this application. See also... Figure 1 The available ring can include the field avail_idx and 10 available entries.

[0108] The field `avail_idx` can be used to index the next available entry and is maintained by the virtual machine.

[0109] Available entries can be used to store the index corresponding to unprocessed requests. For example, available entry [5] stores index 0.

[0110] In the availability ring, the current availability pointer (avail_idx) can be used to point to the next available entry to be used by the virtual machine; the local availability pointer (last_avail_idx) can be used to point to the next available entry to be processed by the storage backend.

[0111] For example, if the field avail_idx is 9, it means that avail_idx points to an available entry [9], indicating that the next available entry is an available entry [9]; if the local available pointer points to an available entry [5], it means that the next available entry to be processed is an available entry [5].

[0112] The processing requests corresponding to the indexes in multiple available entries between the local available pointer and the currently available pointer are unprocessed requests, which are pending processing by the storage backend.

[0113] (5) Used rings can be used to store indexes of processed requests.

[0114] Below, in conjunction with Figure 2 Explanation of the rings already used.

[0115] Figure 2 A schematic diagram of a used ring provided for an exemplary embodiment of this application. Please refer to... Figure 2 The used ring can include the field used_idx and 10 used entries.

[0116] The `used_idx` field can be used to index the next used entry and is maintained by the storage backend.

[0117] Used entries can be used to store the index corresponding to a processed request. For example, used entry [2] can store index 2.

[0118] In the used ring, the currently used pointer (used_idx) can be used to point to the next used entry to be used in the storage backend; the local used pointer (last_used_idx) can be used to point to the next used entry to be reclaimed in the virtual machine.

[0119] For example, if the field used_idx is 5, it means that used_idx points to a used entry[5], indicating that the next used entry is a used entry[5]; if the local used pointer points to a used entry[2], it means that the next used entry to be recycled is a used entry[2].

[0120] The processing requests corresponding to the indices of multiple used entries between the currently used pointer (used_idx) and the local used pointer are processed requests, and these multiple used entries are virtual machines waiting to be reclaimed.

[0121] (6) The descriptor table can be used to store I / O request information.

[0122] Below, in conjunction with Figure 3 Describe the descriptor table.

[0123] Figure 3 A schematic diagram of a descriptor table provided for an exemplary embodiment of this application. Please refer to... Figure 3 The descriptor table can include multiple descriptors, which can be used to store I / O request information.

[0124] For any given I / O request, the request information can be stored in multiple descriptors. These descriptors can be linked together to form a descriptor list corresponding to that I / O request. In other words, in the descriptor list, one I / O request corresponds to one descriptor list, and the descriptor list contains multiple descriptors used to store the request information for that I / O request.

[0125] For example, for I / O request 0, the request information of I / O request 0 can be stored in descriptor [0], descriptor [1] and descriptor [3]. These three descriptors can form descriptor list 0, which is the descriptor list 0 corresponding to I / O request 0 and stores the request information of I / O request 0.

[0126] (7) The in-flight descriptor bitmap includes multiple bits. Each bit can be used to represent the processing status of the corresponding I / O request. Optionally, the descriptor bitmap can reside in the virtual machine's memory.

[0127] If the bit is the first value (e.g., "0"), it means that the processing status of the previous I / O request corresponding to the bit is processed, or it can mean that there is currently no corresponding I / O request for the bit; if the bit is the second value (e.g., "1"), it means that the processing status of the I / O request corresponding to the bit is unprocessed.

[0128] Figure 4 This is a schematic diagram of a scenario provided for an exemplary embodiment of this application. Please refer to... Figure 4 This includes the source server and the destination server.

[0129] The source server may include a virtual machine, shared memory 1, and storage backend 1. The virtual machine and storage backend 1 can interact with each other through shared memory 1 for multiple processing requests (i.e., I / O requests). Shared memory 1 can be used to store virtual queue information, which may include multiple processing requests generated by the virtual machine.

[0130] When the source server malfunctions and cannot process multiple processing requests in the virtual queue information through the storage backend 1, the virtual machine and the virtual queue information corresponding to the virtual machine can be migrated to the destination server.

[0131] The destination server may include shared memory 2 and storage backend 2. After migrating the virtual machine and virtual queue information to the destination server, the virtual queue information can be stored in shared memory 2, and the storage backend 2 can be used to continue processing multiple processing requests in the virtual queue information to resume processing of multiple processing requests.

[0132] In related technologies, when a server malfunctions, it cannot determine which I / O requests have been processed and which have not, making it impossible to resume processing of I / O requests. Therefore, there is currently a lack of a method to resume processing of I / O requests when a server malfunctions.

[0133] To address the aforementioned technical problems, this application provides a request processing recovery method. In this method, a virtual machine contains a descriptor bitmap, which includes the processing status of each processing request. When the source server experiences an anomaly, the destination server can migrate the virtual machine and its corresponding virtual queue information to the destination server, determine the descriptor bitmap within the virtual machine, and then identify and process at least one unprocessed target processing request based on the descriptor bitmap. Through this method, the destination server can recover the processing of multiple processing requests based on the descriptor bitmap.

[0134] It is important to emphasize that virtual machine storage backends can be divided into two types: software-simulated storage backends and pass-through storage backends. The technical solution of this application is applicable to both types of storage backends.

[0135] The technical solutions shown in this application will now be described in detail through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; for identical or similar content, the description will not be repeated in different embodiments.

[0136] Below, in order to facilitate understanding of the technical solution of this application, we will first combine... Figure 5 This section explains the normal request processing procedure.

[0137] Figure 5 This is a flowchart illustrating a request processing method provided in an embodiment of this application. Please refer to [link / reference]. Figure 5 The method may include:

[0138] S501. Obtain a first processing request and store the request information of the first processing request in at least one descriptor in the descriptor table.

[0139] For example, the server can obtain the first processing request. Suppose that the request information of the first processing request can be stored in descriptors [2] and [3] in the descriptor table. Descriptors [2] and [3] can form a descriptor linked list corresponding to the first processing request.

[0140] S502. Determine the index corresponding to the first processing request based on at least one descriptor.

[0141] Since at least one descriptor can form a descriptor linked list corresponding to the first processing request, the index corresponding to the first descriptor in the descriptor linked list can be determined as the index corresponding to the first processing request.

[0142] For example, if at least one descriptor includes descriptor [2] and descriptor [3], since the first descriptor is descriptor [2] and the corresponding index is 2, then the index corresponding to the first processing request can be determined to be index 2.

[0143] S503. Determine the first available entry pointed to by the current available pointer in the available ring, and store the index corresponding to the first processing request in the first available entry.

[0144] For example, if the first available entry pointed to by the current available pointer in the available ring is an available entry [3], then index 2 can be stored in the available entry [3].

[0145] After storing the index corresponding to the first processing request in the first available entry, the virtual machine can move the current available pointer to the next available entry of the first available entry for subsequent use. For example, after storing index 2 in available entry [3], the current available pointer can be moved to the next available entry of available entry [3], i.e., available entry [4].

[0146] S504. Based on the index corresponding to the first processing request, determine the first bit corresponding to the first processing request in the descriptor bitmap, and update the first bit to the second value.

[0147] For example, if the first processing request corresponds to index 2, then based on index 2, the first bit can be determined as the second bit in the descriptor bitmap, and the second bit can be updated to 1, indicating that there is a first processing request to be processed.

[0148] S505: Send a notification to the storage backend via the virtual machine to notify the storage backend to process the first processing request.

[0149] S506. The first processing request is processed through the storage backend.

[0150] Optionally, the server can obtain the index corresponding to the first processing request from the first available entry pointed to by the local available pointer in the availability ring through the storage backend, and obtain the request information of the first processing request from the descriptor table according to the index corresponding to the first processing request, and then process the first processing request according to the request information.

[0151] After obtaining the index corresponding to the first processing request from the first available entry, the local available pointer can be moved to the next available entry from the storage backend for subsequent use.

[0152] S507. After the storage backend processes the first processing request, the index corresponding to the first processing request is stored in the first used entry pointed to by the currently used pointer in the used ring.

[0153] For example, if the first used entry pointed to by the current used pointer in the used ring is a used entry [5], then the index 2 corresponding to the first processing request can be stored in the used entry [5].

[0154] After storing the index corresponding to the first processing request in the first used entry pointed to by the currently used pointer, the current used pointer can be moved to the next used entry of the first used entry through the storage backend for subsequent use.

[0155] S508. Send an interrupt to the virtual machine through the storage backend to notify the virtual machine to reclaim the first used entry pointed to by the local used pointer, and update the first bit in the descriptor bitmap to the first value according to the index in the first used entry.

[0156] For example, an interrupt can be sent to the virtual machine through the storage backend to notify the virtual machine to reclaim the used entry pointed to by the local used pointer [5]. Since the used entry [5] stores the index 2 corresponding to the first processing request, the first bit, i.e. the second bit, in the descriptor bitmap can be updated to 0 according to the index 2 to indicate that the first processing request has been processed.

[0157] After the virtual machine reclaims the first used entry, it moves the local used pointer to the next used entry for subsequent use.

[0158] In this embodiment, a descriptor bitmap is maintained in the virtual machine. Through the descriptor bitmap, available ring, used ring, and descriptor table, the storage backend can process multiple processing requests generated by the virtual machine; and during the processing of multiple processing requests, the storage backend can maintain local available pointers and currently used pointers, and the virtual machine can maintain currently available pointers and locally used pointers.

[0159] Below, in conjunction with Figures 6-9 This section describes the methods for handling and recovering from multiple processing requests when the source server encounters an error.

[0160] Figure 6 This is a flowchart illustrating a request processing recovery method provided for an exemplary embodiment of this application. Please refer to [link / reference]. Figure 6 The method may include:

[0161] S601. When the source server is abnormal, migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server.

[0162] The execution entity in this application embodiment can be a destination server or a request processing and recovery device installed in the destination server. The request processing and recovery device can be implemented in software or a combination of software and hardware. The request processing and recovery device can be a processor in the destination server. For ease of understanding, the following description uses the destination server as the execution entity.

[0163] The source server can include virtual machines and storage backends. The storage backend can process multiple processing requests generated by the virtual machines.

[0164] At least one virtual queue can exist between the virtual machine and the storage backend. Virtual queue information refers to the information in any virtual queue, which can include multiple processing requests generated by the virtual machine.

[0165] Optionally, the request to be processed can be an I / O request.

[0166] When the source server fails, i.e. when the source server is unable to process multiple processing requests through the storage backend, the destination server can migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server so that the processing of multiple processing requests can be resumed through the storage backend in the destination server.

[0167] For example, if the source server is running virtual machine 1 and virtual machine 1 has a corresponding virtual queue 1, then when the source server is abnormal, the destination server can migrate virtual machine 1 and the virtual queue information corresponding to virtual machine 1 (i.e., the information of virtual queue 1) to the destination server.

[0168] S602. Determine the descriptor bitmap in the virtual machine.

[0169] The descriptor bitmap can include the processing status of each processing request, which can be either unprocessed or processed.

[0170] Below, in conjunction with Figure 7 This section describes the descriptor bitmap.

[0171] Figure 7 This is a schematic diagram illustrating the structure of a descriptor bitmap provided for an exemplary embodiment of this application. Please refer to... Figure 7 For example, a descriptor bitmap may include 10 bits, namely the 0th bit, the 1st bit, ..., the 9th bit.

[0172] For any given bit, the bit can correspond to a processing request. If the bit is a first value (e.g., "0"), it can indicate that the processing status of the processing request corresponding to the bit is processed; if the bit is a second value (e.g., "1"), it can indicate that the processing status of the processing request corresponding to the bit is unprocessed.

[0173] like Figure 7 In the diagram, the 0th bit being 1 indicates that the processing status of processing request 0 corresponding to the 0th bit is unprocessed; the 1st bit being 0 indicates that the processing status of processing request 1 corresponding to the 1st bit is processed.

[0174] It should be noted that multiple bits in the descriptor bitmap are initialized to the first value.

[0175] Since at least one virtual queue can exist between the virtual machine and the storage backend, a corresponding descriptor bitmap can be configured within the virtual machine for any given virtual queue. The destination server can determine the descriptor bitmap corresponding to the virtual queue within the virtual machine.

[0176] For example, for virtual queue 1, the destination server can determine the descriptor bitmap corresponding to virtual queue 1 in the virtual machine.

[0177] It should be noted that the technical solution of this application is executed for any virtual queue between the virtual machine and the storage backend.

[0178] S603. Based on the descriptor bitmap, determine at least one target processing request that is in an unprocessed state among multiple processing requests, and process at least one target processing request.

[0179] In an optional embodiment, at least one target processing request in an unprocessed state can be determined from among multiple processing requests based on a descriptor bitmap in the following manner: determining at least one currently processed request; setting the processing state of the at least one currently processed request to a processed state in the descriptor bitmap to obtain an updated descriptor bitmap; and determining at least one target processing request in an unprocessed state from among multiple processing requests based on the updated descriptor bitmap.

[0180] When the source server is abnormal, there may be a situation where the storage backend has processed at least one currently processed request, but has not set the corresponding processing status to processed in the descriptor bitmap based on the at least one currently processed request. Therefore, the destination server can determine at least one currently processed request and set the processing status of the at least one currently processed request to processed in the descriptor bitmap, thus obtaining an updated descriptor bitmap.

[0181] For example, if the descriptor bitmap is like Figure 7 As shown in the diagram, assuming the destination server can determine three currently processed requests: request 2, request 3, and request 4, and assuming the second bit in the descriptor bitmap corresponds to request 2, the third bit to request 3, and the fourth bit to request 4, the destination server can update the second bit to "0" based on request 2 to indicate that request 2 is processed; it can update the third bit to "0" based on request 3 to indicate that request 3 is processed; and it can update the fourth bit to "0" based on request 4 to indicate that request 4 is processed. This will result in an updated descriptor bitmap, as shown below. Figure 8 As shown. Figure 8 A schematic diagram of an update descriptor bitmap provided for an exemplary embodiment of this application.

[0182] After obtaining the updated descriptor bitmap, at least one target processing request in an unprocessed state can be determined based on the updated descriptor bitmap, and the at least one target processing request can be processed.

[0183] For example, if updating the descriptor bitmap as follows Figure 8 As shown, based on the updated descriptor bitmap, the processing status of the processing requests corresponding to bits 0, 5, 6, and 7 can be determined to be unprocessed. Therefore, the four processing requests corresponding to these four bits can be identified as four target processing requests. The destination server can then resume processing these four target processing requests.

[0184] In this embodiment, when the source server malfunctions, the destination server can migrate the virtual machine and its corresponding virtual queue information to the destination server. A descriptor bitmap is then determined within the virtual machine. Based on the descriptor bitmap, at least one unprocessed target processing request can be identified from among multiple processing requests, and this unprocessed request can be processed. Since the virtual machine contains a descriptor bitmap, it is possible to determine which processing requests have been processed and which have not. Therefore, unprocessed requests can continue to be processed, and the above method can restore the processing of processing requests.

[0185] Below, in Figure 6 Based on the illustrated embodiments, combined with Figure 9 The above request processing and recovery methods will be explained in detail.

[0186] Figure 9 A flowchart illustrating another request processing recovery method provided for an exemplary embodiment of this application. Please refer to... Figure 9 The method may include:

[0187] S901. When the source server is abnormal, migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server.

[0188] S902. Determine the descriptor bitmap in the virtual machine.

[0189] It should be noted that the execution process of steps S901 to S902 can be found in the execution process of steps S601 to S602, and will not be repeated here.

[0190] S903. Identify at least one currently processed request.

[0191] In an alternative embodiment, at least one currently processed request can be determined by: determining a currently used pointer in the used ring and determining the next used entry pointed to by the currently used pointer; determining a local used pointer in the virtual machine and determining the target used entry pointed to by the local used pointer in the used ring; determining at least one used entry between the target used entry and the next used entry in the used ring, and determining the processing request corresponding to the index in at least one used entry as at least one currently processed request.

[0192] The virtual queue information may include used rings. Used rings can be found in [link to relevant documentation]. Figure 2 Example.

[0193] The target used entry is the next used entry to be reclaimed by the virtual machine.

[0194] For example, if a ring has already been used Figure 2 As shown, the destination server can determine that the current used pointer is 5, and can determine that the next used entry pointed to by the current used pointer is a used entry [5]. The destination server can determine the local used pointer in the virtual machine. If the local used pointer is 2, it can determine the target used entry pointed to by the local used pointer as a used entry in the used ring [2].

[0195] It should be noted that at the current moment, the next used entry has not yet been used; it is the used entry that is about to be used. Therefore, the next used entry does not yet contain any content.

[0196] In the used ring, the destination server determines at least one used entry between the target used entry and the next used entry, and determines the processing request corresponding to the index in at least one used entry as at least one currently processed request.

[0197] It should be noted that the at least one used entry includes the target used entry, but does not include the next used entry.

[0198] For example, if the target used entry is used entry [2] and the next used entry is used entry [5], then the three used entries between used entry [2] and used entry [5] can be identified as used entry [2], used entry [3], and used entry [4]. If the indices stored in these three used entries are index 2, index 3, and index 4, then the processing request 2 corresponding to index 2, the processing request 3 corresponding to index 3, and the processing request 4 corresponding to index 4 can all be identified as the currently processed requests.

[0199] Optionally, when the local used pointer and the current used pointer point to the same used entry, that is, when the next used entry and the target used entry are the same used entry, it can be determined that there is no currently processed request since the index has not yet been stored in the used entry.

[0200] S904. In the descriptor bitmap, set the processing status of at least one currently processed request to the processed status to obtain an updated descriptor bitmap.

[0201] Optionally, the updated descriptor bitmap can be obtained by setting the processing status of at least one currently processed request to a processed state in the descriptor bitmap as follows: In the descriptor bitmap, at least one bit to be reset is determined according to the index corresponding to at least one currently processed request; the at least one bit to be reset is set to a first value to set the processing status corresponding to at least one currently processed request to a processed state, thereby obtaining the updated descriptor bitmap.

[0202] For example, if there are 3 currently processed requests, namely Request 2, Request 3, and Request 4, with corresponding indices of index 2, index 3, and index 4 respectively, and the descriptor bitmap is as follows: Figure 7 As shown, based on these three indices, the 2nd, 3rd, and 4th bits can be determined in the descriptor bitmap, and these three bits can be updated to "0", resulting in the following: Figure 8 The update descriptor bitmap shown.

[0203] Optionally, if there are no currently processed requests, there is no need to update the descriptor bitmap to obtain an updated descriptor bitmap.

[0204] S905. Based on the updated descriptor bitmap, determine at least one target processing request that is in an unprocessed state among multiple processing requests.

[0205] In an optional embodiment, at least one target processing request in an unprocessed state can be determined from among multiple processing requests based on an update descriptor bitmap as follows: at least one target bit in the update descriptor bitmap is determined as a second value; and the processing request corresponding to the at least one target bit is determined as at least one target processing request.

[0206] For example, if updating the descriptor bitmap as follows Figure 8 As shown, if the second value is 1, the destination server can identify the four target bits that are "1" in the update descriptor bitmap: bit 0, bit 5, bit 6, and bit 7. Since a bit being "1" indicates that the processing status of the corresponding request is unprocessed, if bit 0 corresponds to request 0, bit 5 to request 5, bit 6 to request 6, and bit 7 to request 7, then these four requests can be identified as the target processing requests.

[0207] Optionally, if the descriptor bitmap is not updated in step S904, at least one target processing request in an unprocessed state can be determined from among multiple processing requests based on the descriptor bitmap.

[0208] Optionally, whether the target processing request is determined from multiple processing requests based on the updated descriptor bitmap or the descriptor bitmap, it is possible to determine that the target processing request does not exist among the multiple processing requests, meaning that all current processing requests have already been processed and there are no unprocessed processing requests. In this case, steps S906 to S908 do not need to be executed.

[0209] S906. In the available ring, identify at least one target available entry.

[0210] In an alternative embodiment, at least one target available entry can be determined in the availability ring by: determining the local available pointer corresponding to the first unprocessed request based on the currently used pointer; determining the current available pointer in the availability ring; and determining at least one target available entry in the availability ring based on the local available pointer and the current available pointer.

[0211] The local available pointer points to the next available entry to be processed, which corresponds to the processing request, i.e., the first unprocessed request.

[0212] Optionally, the local available pointer corresponding to the first unprocessed request can be determined based on the currently used pointer in the following way: if the local available pointer is inconsistent with the currently used pointer, the local available pointer is updated based on the currently used pointer.

[0213] Since the local available pointer points to the next available entry to be processed in the storage backend, and the currently used pointer points to the next used entry that has already been processed in the storage backend, before the origin server encounters an exception, it is possible that when processing the current processing request through the storage backend, the local available pointer has already been moved to the next available entry to be processed (corresponding to the next processing request to be processed). However, when the origin server encounters an exception, the processing of the current processing request is interrupted and not completed. Therefore, the index corresponding to the current processing request is not stored in the used ring or the used entry corresponding to the currently used pointer. As a result, the processing request that the currently used pointer is about to correspond to (i.e., the current processing request) has failed and needs to be reprocessed. In this case, the local available pointer can be updated based on the currently used pointer.

[0214] For example, if the locally available pointer is 6 and the currently used pointer is 5, then the locally available pointer is updated to 5 based on the currently used pointer. If the available pointer is in a ring... Figure 1As shown, the destination server can determine that the current available pointer is 9. The destination server can determine that the available entry corresponding to the local available pointer is available entry [5], and can determine that the available entry corresponding to the current available pointer is available entry [9]. Then, in the available ring, the four available entries between available entry [5] and available entry [9], namely available entry [5], available entry [6], available entry [7], and available entry [8], are determined as four target available entries.

[0215] It should be noted that the at least one target available entry includes the available entry corresponding to the local available pointer, but does not include the available entry corresponding to the current available pointer.

[0216] S907. Store at least one index corresponding to a target processing request in at least one target available entry.

[0217] Since updating a bit to "1" in the descriptor bitmap is done by determining the bit corresponding to the processing request based on the index of the processing request, and then updating the bit corresponding to the processing request to 1, the index of the corresponding target processing request can be determined based on the index of each target bit.

[0218] For example, if there are 4 target processing requests and 4 target bits, the correspondence is shown in Table 1.

[0219] Table 1

[0220] Target bit Target processing request index Target available entries The 0th bit Request 0 processed Index 0 Available entries [5] 5th bit Process Request 5 Index 5 Available entries [6] The 6th bit Process Request 6 Index 6 Available entries [7] The 7th bit Process Request 7 Index 7 Available entries [8]

[0221] The index of the corresponding target processing request can then be determined based on each target bit, as shown in Table 1. The destination server can store the indices of these four target processing requests in four target available entries, such as... Figure 1 As shown in the image.

[0222] S908. Process at least one target processing request based on at least one target available entry and a descriptor table.

[0223] Optionally, for any target processing request, the target processing request can be processed in the following manner, based on at least one target available entry and a descriptor table: determine the first target available entry pointed to by the local available pointer in at least one target available entry; obtain the first index in the first target available entry; determine the descriptor linked list in the descriptor table based on the first index; obtain the request information of the first target processing request in the descriptor linked list, and process the first target processing request based on the request information.

[0224] For example, the destination server can determine the first target available entry corresponding to the local available pointer as an available entry from among the four target available entries [5], and then obtain the first index as index 0 from the available entry [5]. The destination server can then use index 0 to... Figure 3 The descriptor table shown determines the descriptor list 0 corresponding to processing request 0. Descriptor list 0 may include descriptor [0], descriptor [1], and descriptor [3]. The destination server can obtain the request information of processing request 0 from descriptor list 0 through the storage backend, and process processing request 0 according to the request information.

[0225] It should be noted that after the destination server obtains the first index from the first target available entry through the storage backend, it can move the local available pointer to the next available entry of the first target available entry. For example, when the local available pointer points to an available entry [5], after the destination server obtains index 0 in the available entry [5] through the storage backend, it can move the local available pointer to the next available entry, i.e., the available entry [6], so that the next unprocessed request can be processed next time.

[0226] After the destination server processes the first target processing request through the storage backend, it stores the first index in the used ring and updates the processing status corresponding to the target processing request to the processed status in the update descriptor bitmap according to the first index.

[0227] Specifically, after processing the first target processing request through the storage backend, the destination server stores the first index in the used entry pointed to by the currently used pointer in the used ring, and moves the currently used pointer to the next used entry. Based on the first index, the destination server can update the bit corresponding to the first index to a first value in the update descriptor bitmap, thereby updating the processing status of the target processing request to the processed state.

[0228] For example, after the destination server processes request 0 through the storage backend, in such a way... Figure 2 The index 0 is stored in the used entry pointed to by the currently used pointer in the used ring shown [5], and the current used pointer is moved to the next used entry, i.e., the used entry [6]. The destination server can update the 0th bit corresponding to index 0 to "0" in the update descriptor bitmap according to index 0, so as to update the processing status corresponding to processing request 0 to the processed status.

[0229] In this embodiment, when the source server fails, the destination server migrates the virtual machine and its corresponding virtual queue information to the destination server. The destination server can determine a descriptor bitmap within the virtual machine and identify at least one currently processed request. It can then set the processing status of the at least one currently processed request to "processed" in the descriptor bitmap, obtaining an updated descriptor bitmap. Based on the updated descriptor bitmap, the destination server can identify at least one unprocessed target processing request among multiple processing requests and determine at least one target available entry in the availability ring. It can then store the index corresponding to the at least one target processing request in the at least one target available entry. The destination server can process the at least one target processing request based on the at least one target available entry and the descriptor table. Since the virtual machine contains a descriptor bitmap, the destination server can determine which processing requests have been processed and which have not, thus allowing it to continue processing unprocessed requests. Therefore, the above method can restore the processing of processing requests.

[0230] It should be noted that, in Figure 9 The various processing steps (S901-S908) shown in the embodiments do not constitute a specific limitation on the request processing recovery process. In other embodiments of this application, the request processing recovery process may include more than Figure 9 The embodiments may include more or fewer steps. For example, a request processing recovery process may include... Figure 9 Some steps in the embodiments, or, Figure 9 Some steps in the embodiments can be replaced by steps with the same function, or Figure 9 Some steps in the embodiments can be broken down into multiple steps, etc.

[0231] Figure 10 This is a schematic diagram of a request processing recovery apparatus provided for an exemplary embodiment of this application. Please refer to... Figure 10 The request processing and recovery device 10 includes: a migration module 11, a first determination module 12, a second determination module 13, and a processing module 14, wherein...

[0232] The migration module 11 is used to migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server when the source server is abnormal. The virtual queue information includes multiple processing requests generated by the virtual machine.

[0233] The first determining module 12 is configured to determine a descriptor bitmap in the virtual machine, the descriptor bitmap including the processing status of each processing request, the processing status being either unprocessed or processed.

[0234] The second determining module 13 is configured to determine, based on the descriptor bitmap, at least one target processing request in the unprocessed state among the plurality of processing requests;

[0235] The processing module 14 is used to process the at least one target processing request.

[0236] The request processing and recovery device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0237] In one possible implementation, the second determining module 13 is specifically used for:

[0238] Identify at least one currently processed request;

[0239] In the descriptor bitmap, the processing status of the at least one currently processed request is set to the processed status to obtain an updated descriptor bitmap;

[0240] Based on the updated descriptor bitmap, at least one target processing request in the unprocessed state is determined among the plurality of processing requests.

[0241] In one possible implementation, the descriptor bitmap includes multiple bits; the second determining module 13 is specifically used for:

[0242] In the descriptor bitmap, at least one bit to be reset is determined based on the index corresponding to the at least one currently processed request;

[0243] The at least one bit to be reset is set to a first value to set the processing status corresponding to the at least one currently processed request to a processed status, thereby obtaining an update descriptor bitmap.

[0244] In one possible implementation, the second determining module 13 is specifically used for:

[0245] In the updated descriptor bitmap, at least one target bit corresponding to the second value is determined;

[0246] The processing request corresponding to the at least one target bit is determined as the at least one target processing request.

[0247] In one possible implementation, the virtual queue information includes used rings; the second determining module 13 is specifically used for:

[0248] In the used ring, determine the currently used pointer and the next used entry that the currently used pointer points to;

[0249] In the virtual machine, determine the local used pointers, and in the used ring, determine the target used entry pointed to by the local pointers;

[0250] In the used ring, at least one used entry between the target used entry and the next used entry is determined, and the processing request corresponding to the index in the at least one used entry is determined as at least one currently processed request.

[0251] In one possible implementation, the virtual queue information includes unprocessed request information and a descriptor table; the processing module 14 is specifically used for:

[0252] At least one target available entry is identified in the available ring;

[0253] The index corresponding to the at least one target processing request is stored in the at least one target available entry;

[0254] The at least one target processing request is processed based on the at least one available target entry and the descriptor table.

[0255] In one possible implementation, the processing module 14 is specifically used for:

[0256] Based on the currently used pointers, determine the local available pointer corresponding to the first unprocessed request;

[0257] Determine the currently available pointer within the available ring;

[0258] Based on the local available pointer and the current available pointer, at least one target available entry is determined in the available ring, wherein the local available pointer points to the first available entry among the at least one target available entry.

[0259] In one possible implementation, the processing module 14 is specifically used for:

[0260] If the locally available pointer is inconsistent with the currently used pointer, then the locally available pointer is updated according to the currently used pointer.

[0261] In one possible implementation, a processing request is handled for any given target; specifically, the processing module 14 is used for:

[0262] Determine the first target available entry pointed to by the local available pointer from the at least one target available entry;

[0263] Obtain the first index from the available entries of the first target;

[0264] Based on the first index, a descriptor list is determined in the descriptor table, and the descriptor list is used to store the request information of the target processing request;

[0265] The request information of the first target processing request is obtained from the descriptor chain, and the first target processing request is processed according to the request information.

[0266] The request processing and recovery device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0267] Figure 11 A schematic diagram of another request processing recovery apparatus provided for an exemplary embodiment of this application. Please refer to... Figure 11 ,exist Figure 10 Based on the illustrated embodiment, the request processing recovery device 10 may further include: a moving module 15, a storage module 16, and an update module 17, wherein,

[0268] The moving module 15 is used to move the local available pointer to the next available entry of the first target available entry after obtaining the first index in the first target available entry;

[0269] The storage module 16 is used to store the first index in the used ring after processing the first target processing request;

[0270] The update module 17 is used to update the processing status corresponding to the target processing request to the processed status in the update descriptor bitmap according to the first index.

[0271] The request processing and recovery device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0272] Figure 12 This is a schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Please refer to... Figure 12 The electronic device 20 may include a processor 21 and a memory 22. Exemplarily, the processor 21 and the memory 22 are interconnected via a bus 23.

[0273] The memory 22 stores computer-executed instructions;

[0274] The processor 21 executes the computer execution instructions stored in the memory 22, causing the processor 21 to perform the method as shown in the above method embodiment.

[0275] Figure 12The electronic device shown can be the server or the destination server described in any of the above embodiments.

[0276] Accordingly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the above-described method embodiments.

[0277] Accordingly, embodiments of this application may also provide a computer program product, including a computer program, which, when executed by a processor, can implement the methods shown in the above-described method embodiments.

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

[0279] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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 illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0280] 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.

[0281] 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.

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

[0283] 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.

[0284] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic 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 computer-readable media, such as modulated data signals and carrier waves.

[0285] 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 a process, method, article, or apparatus. Without further limitation, 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 said element.

[0286] 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 recovery method, characterized in that, Applied to a destination server, the method includes: When the source server is abnormal, the virtual machine and the virtual queue information corresponding to the virtual machine are migrated to the destination server. The virtual queue information includes multiple processing requests generated by the virtual machine. A descriptor bitmap is determined in the virtual machine, the descriptor bitmap including the processing status of each processing request, the processing status being either unprocessed or processed; Based on the descriptor bitmap, at least one target processing request in the unprocessed state is determined among the plurality of processing requests, and the at least one target processing request is processed.

2. The method according to claim 1, characterized in that, Based on the descriptor bitmap, determining at least one target processing request in the unprocessed state among the plurality of processing requests includes: Identify at least one currently processed request; In the descriptor bitmap, the processing status of the at least one currently processed request is set to the processed status to obtain an updated descriptor bitmap; Based on the updated descriptor bitmap, at least one target processing request in the unprocessed state is determined among the plurality of processing requests.

3. The method according to claim 2, characterized in that, The descriptor bitmap includes multiple bits; in the descriptor bitmap, setting the processing status of the at least one currently processed request to a processed state to obtain an updated descriptor bitmap includes: In the descriptor bitmap, at least one bit to be reset is determined based on the index corresponding to the at least one currently processed request; The at least one bit to be reset is set to a first value to set the processing status corresponding to the at least one currently processed request to a processed status, thereby obtaining an update descriptor bitmap.

4. The method according to claim 2 or 3, characterized in that, Based on the updated descriptor bitmap, determining at least one target processing request in the unprocessed state among the plurality of processing requests includes: In the updated descriptor bitmap, at least one target bit corresponding to the second value is determined; The processing request corresponding to the at least one target bit is determined as the at least one target processing request.

5. The method according to any one of claims 2-4, characterized in that, The virtual queue information includes used rings; Identify at least one currently processed request, including: In the used ring, determine the currently used pointer and the next used entry that the currently used pointer points to; In the virtual machine, determine the local used pointer, and in the used ring, determine the target used entry pointed to by the local used pointer; In the used ring, at least one used entry between the target used entry and the next used entry is determined, and the processing request corresponding to the index in the at least one used entry is determined as the at least one currently processed request.

6. The method according to any one of claims 1-5, characterized in that, The virtual queue information includes available rings and a descriptor table; Processing the at least one target processing request includes: At least one target available entry is identified in the available ring; The index corresponding to the at least one target processing request is stored in the at least one target available entry; The at least one target processing request is processed based on the at least one available target entry and the descriptor table.

7. The method according to claim 6, characterized in that, Determining at least one target available entry in the available ring includes: Based on the currently used pointers, determine the local available pointer corresponding to the first unprocessed request; Determine the currently available pointer within the available ring; Based on the local available pointer and the current available pointer, at least one target available entry is determined in the available ring, wherein the local available pointer points to the first available entry among the at least one target available entry.

8. The method according to claim 7, characterized in that, Based on the currently used pointers, determine the local available pointer corresponding to the first unprocessed request, including: If the locally available pointer is inconsistent with the currently used pointer, then the locally available pointer is updated according to the currently used pointer.

9. The method according to any one of claims 6-8, characterized in that, Process requests for any single target; Processing the at least one target processing request based on the at least one available target entry and the descriptor table includes: Determine the first target available entry pointed to by the local available pointer from the at least one target available entry; Obtain the first index from the available entries of the first target; Based on the first index, a descriptor list is determined in the descriptor table, and the descriptor list is used to store the request information of the target processing request; The request information of the first target processing request is obtained from the descriptor chain, and the first target processing request is processed according to the request information.

10. The method according to claim 9, characterized in that, The method further includes: After obtaining the first index from the first target available entry, the local available pointer is moved to the next available entry of the first target available entry; After processing the first target processing request, the first index is stored in the used ring, and the processing status corresponding to the target processing request is updated to the processed status in the update descriptor bitmap according to the first index.

11. A request processing recovery device, characterized in that, Applied to a destination server, the device includes: a migration module, a first determining module, a second determining module, and a processing module, wherein, The migration module is used to migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server when the source server is abnormal. The virtual queue information includes multiple processing requests generated by the virtual machine. The first determining module is configured to determine a descriptor bitmap in the virtual machine, the descriptor bitmap including the processing status of each processing request, the processing status being either unprocessed or processed. The second determining module is configured to determine, based on the descriptor bitmap, at least one target processing request in the unprocessed state among the plurality of processing requests; The processing module is used to process the at least one target processing request.

12. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, cause the electronic device to perform the method according to any one of claims 1-10.

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

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-10.

Images