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

Abstract

The present disclosure provides a request processing recovery method and apparatus, a device, a storage medium, and a program product, which are applied to a destination server. The method comprises: when a source server is abnormal, migrating a virtual machine and virtual queue information corresponding to the virtual machine to a destination server, the virtual queue information comprising a plurality of processing requests generated by the virtual machine; determining a descriptor bitmap in the virtual machine, the descriptor bitmap comprising a processing state of each processing request, and the processing state being an unprocessed state or a processed state; and on the basis of the descriptor bitmap, determining at least one target processing request in the unprocessed state among the plurality of processing requests, and processing the at least one target processing request. By means of the request processing recovery method in the present disclosure, the destination server can recover the processing of the plurality of processing requests on the basis of the descriptor bitmap.

Description

[0001] This disclosure claims priority to Chinese Patent Application No. 202410693781.0, filed on May 30, 2024, entitled "Request Processing Recovery Method, Apparatus, Device, Storage Medium, and Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of computers, and more particularly to a request processing recovery method, apparatus, device, storage medium, and program product. Background Art A server may include a virtual machine and a storage backend. The storage backend can process input / output (I / O) requests generated by the virtual machine. In related technologies, when a server malfunctions, the server cannot determine which I / O requests have been processed and which have not, resulting in the inability to recover I / O request processing. Therefore, there is currently a lack of a method for recovering I / O request processing when a server malfunctions. The present disclosure 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. In a first aspect, an embodiment of the present disclosure provides a request processing recovery method applied to a destination server. The method includes: when a source server malfunctions, migrating a virtual machine and its corresponding virtual queue information to the destination server, the virtual queue information including multiple processing requests generated by the virtual machine; determining 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; and, based on the descriptor bitmap, determining at least one target processing request in the unprocessed state from among the multiple processing requests, and processing the at least one target processing request. In one possible implementation, determining at least one target processing request in the unprocessed state among the plurality of processing requests based on the descriptor bitmap includes: 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 the unprocessed state among the plurality of processing requests based on the updated descriptor bitmap.In one possible implementation, the descriptor bitmap includes multiple bits. 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 includes: determining at least one bit to be reset based on the index corresponding to the at least one currently processed request in the descriptor bitmap; setting the at least one bit to be reset to a first value to set the processing state corresponding to the at least one currently processed request to a processed state, thereby obtaining the updated descriptor bitmap. In one possible implementation, determining at least one target processing request in the unprocessed state among the multiple processing requests based on the updated descriptor bitmap includes: determining at least one target bit corresponding to a second value in the updated descriptor bitmap; and determining the processing request corresponding to the at least one target bit as the at least one target processing request. In one possible implementation, the virtual queue information includes a used ring; determining at least one currently processed request includes: 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 the at least one used entry as at least one currently processed request. 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: determining at least one target available entry in the available ring; storing the index corresponding to the at least one target processing request in the at least one target available entry; and processing the at least one target processing request according to the at least one target available entry and the descriptor table. In one possible implementation, determining at least one target available entry in the availability ring includes: determining a local available pointer corresponding to the first unprocessed request based on the currently used pointer; determining a 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, wherein the local available pointer points to the first available entry among the at least one target available entry. In another possible implementation, determining the local available pointer corresponding to the first unprocessed request based on the currently used pointer includes: if the local available pointer is inconsistent with the currently used pointer, then updating the local available pointer based on the currently used pointer.In one possible implementation, for any target processing request, processing the at least one target processing request based on the at least one target available entry and the descriptor table includes: determining a first target available entry pointed to by the local available pointer in the at least one target available entry; obtaining a first index in the first target available entry; determining a descriptor linked list in the descriptor table based on the first index, the descriptor linked list being used to store request information of the target processing request; obtaining the request information of the first target processing request in the descriptor linked list, and processing the first target processing request based on the request information. In one possible implementation, the method further includes: after obtaining the first index in the first target available entry, moving the local available pointer to the next available entry of the first target available entry; after processing the first target processing request, storing the first index in the used ring, and updating the processing status corresponding to the target processing request to a processed status in the updated descriptor bitmap based on the first index. Secondly, embodiments of this disclosure 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. The migration module is configured to migrate a virtual machine and its corresponding virtual queue information 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 includes a processing state for each processing request, where the processing state is either unprocessed or processed. The second determining module is configured to determine at least one target processing request in the unprocessed state from among the multiple processing requests based on the descriptor bitmap. The processing module is configured to process the at least one target processing request. In one possible implementation, the second determining module is specifically configured to: determine at least one currently processed request; set the processing state of the at least one currently processed request to processed state in the descriptor bitmap to obtain an updated descriptor bitmap; and determine at least one target processing request in the unprocessed state from among the multiple processing requests based on the updated descriptor bitmap.In one possible implementation, the descriptor bitmap includes multiple bits; the second determining module is specifically configured to: determine at least one bit to be reset in the descriptor bitmap based on the index corresponding to the at least one currently processed request; set the at least one bit to be reset to a first value to set the processing state corresponding to the at least one currently processed request to a processed state, thereby obtaining an updated descriptor bitmap. In one possible implementation, the second determining module is specifically configured to: determine at least one target bit corresponding to a second value in the updated descriptor bitmap; determine the processing request corresponding to the at least one target bit as the at least one target processing request. In one possible implementation, the virtual queue information includes a used ring; the second determining module is specifically configured to: determine a currently used pointer in the used ring, and determine the next used entry pointed to by the currently used pointer; determine a local used pointer in the virtual machine, and determine a target used entry pointed to by the local used pointer in the used ring; determine at least one used entry between the target used entry and the next used entry in the used ring, and determine the processing request corresponding to the index in the at least one used entry as at least one currently processed request. In one possible implementation, the virtual queue information includes unprocessed request information and a descriptor table; the processing module is specifically configured to: determine at least one target available entry in the available ring; store the index corresponding to the at least one target processing request in the at least one target available entry; and process the at least one target processing request according to the at least one target available entry and the descriptor table. In one possible implementation, the processing module is specifically configured to: determine a local available pointer corresponding to the first unprocessed request based on the currently used pointer; determine a currently available pointer in the availability ring; and determine at least one target available entry in the availability ring based on the local available pointer and the currently available pointer, wherein the local available pointer points to the first available entry among the at least one target available entry. In another possible implementation, the processing module is specifically configured to: update the local available pointer based on the currently used pointer if the local available pointer is inconsistent with the currently used pointer.In one possible implementation, for any target processing request, the processing module is specifically configured to: determine a first target available entry pointed to by the local available pointer among the at least one target available entry; obtain a first index in the first target available entry; determine a descriptor linked list in the descriptor table based on the first index, the descriptor linked list being used to store the request information of the target processing request; obtain the request information of the first target processing request from the descriptor linked list, and process the first target processing request based on the request information. In one possible implementation, the apparatus further includes: a moving module, a storage module, and an updating module, wherein the moving module is configured to: after obtaining the first index in the first target available entry, move the local available pointer to the next available entry of the first target available entry; the storage module is configured to: after processing the first target processing request, store the first index in the used ring; the updating module is configured to: update the processing status corresponding to the target processing request to a processed status in the updated descriptor bitmap based on the first index. Thirdly, embodiments of this disclosure provide an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method described in any one of the first aspects. Fourthly, embodiments of this disclosure 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 one of the first aspects. Fifthly, embodiments of this disclosure provide a computer program product, including a computer program, which, when executed by a processor, implements the method shown in any one of the first aspects. Embodiments of this disclosure provide 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 the virtual queue information corresponding to the virtual machine to the destination server, and determine a descriptor bitmap in the virtual machine. Then, based on the descriptor bitmap, at least one target processing request in an unprocessed state can be determined from multiple processing requests, and at least one target processing request can be processed. Since the virtual machine has a descriptor bitmap, it is possible to determine which processing requests have been processed and which have not. This allows for the continued processing of unprocessed requests. Therefore, the above method can be used to resume the processing of processing requests.The accompanying drawings, which are included to provide a further understanding of this disclosure and constitute a part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings: FIG1 is a schematic diagram of an available ring provided by an exemplary embodiment of the present disclosure; FIG2 is a schematic diagram of a used ring provided by an exemplary embodiment of the present disclosure; FIG3 is a schematic diagram of a descriptor table provided by an exemplary embodiment of the present disclosure; FIG4 is a schematic diagram of a scenario provided by an exemplary embodiment of the present disclosure; FIG5 is a schematic flowchart of a request processing method provided by an embodiment of the present disclosure; FIG6 is a schematic flowchart of a request processing recovery method provided by an exemplary embodiment of the present disclosure; FIG7 is a schematic structural diagram of a descriptor bitmap provided by an exemplary embodiment of the present disclosure; FIG8 is a schematic diagram of an updated descriptor bitmap provided by an exemplary embodiment of the present disclosure; FIG9 is a schematic flowchart of another request processing recovery method provided by an exemplary embodiment of the present disclosure; FIG10 is a schematic structural diagram of a request processing recovery device provided by an exemplary embodiment of the present disclosure; FIG11 is a schematic structural diagram of another request processing recovery device provided by an exemplary embodiment of the present disclosure; FIG12 is a schematic structural diagram of an electronic device provided by an exemplary embodiment of the present disclosure. 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, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with relevant laws, regulations, and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse. To make the purpose, technical solution, and advantages of this disclosure clearer, the technical solution of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure. Below, to facilitate understanding of the technical solution of this disclosure, the concepts involved in this disclosure are first explained:

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

[0003] (2) The storage backend refers to the hardware or software in the server responsible for handling I / O requests. 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.

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

[0005] (4) The availability ring can be used to store the index corresponding to unprocessed requests, that is, the index corresponding to the virtual machine's I / O / request. The availability ring will be described below with reference to FIG1. ​​FIG1 is a schematic diagram of the availability ring provided by an exemplary embodiment of the present disclosure. Referring to FIG1, the availability ring may include a field avail_idx and 10 availability entries. The field availjdx can be used to index the next availability entry, which is maintained by the virtual machine. The availability entries can be used to store the index corresponding to unprocessed requests. For example, availability entry [5] stores index 0. In the availability ring, the current availability pointer (avail_idx) can be used to point to the next availability entry to be used by the virtual machine; the local availability pointer (last_avail_idx) can be used to point to the next availability entry to be processed in the storage backend. For example, if the field availjdx is 9, it means that availjdx points to availability entry [9], indicating that the next availability entry is availability entry [9]; if the local availability pointer points to availability entry [5], it means that the next availability entry to be processed is availability entry [5]. 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.

[0006] (5) The used ring can be used to store indexes of processed requests. The used ring will now be described with reference to FIG2. FIG2 is a schematic diagram of a used ring provided in an exemplary embodiment of this disclosure. Referring to FIG2, the used ring may include a field used_idx and 10 used entries. The field used_idx can be used to index the next used entry and is maintained by the storage backend. The used entries can be used to store indexes corresponding to processed requests. For example, index 2 can be stored in used entry [2]. OIn 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 by the virtual machine. For example, if the field used_idx is 5, it means that used_idx points to used entry [5], indicating that the next used entry is used entry [5]; if the local used pointer points to used entry [2], it means that the next used entry to be reclaimed is used entry [2]. The processing requests corresponding to the indices of the multiple used entries between the currently used pointer (usedjdx) and the local used pointer are processed requests, and these multiple used entries are to be reclaimed by the virtual machine.

[0007] (6) The descriptor table can be used to store the request information of I / O requests. The descriptor table will now be described with reference to FIG3. FIG3 is a schematic diagram of a descriptor table provided in an exemplary embodiment of this disclosure. Referring to FIG3, the descriptor table may include multiple descriptors, which can be used to store the request information of I / O requests. For any I / O request, the request information of the I / O request can be stored in multiple descriptors, and these multiple descriptors can be linked together to obtain a descriptor linked list corresponding to the I / O request. In other words, in the descriptor table, one I / O request corresponds to one descriptor linked list, and the descriptor linked list includes multiple descriptors. This descriptor linked list is used to store the request information of the I / O request. 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.

[0008] (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 be located in the memory of the virtual machine. If the bit is a first value (e.g., "0"), it indicates that the processing status of the previous I / O request corresponding to the bit is processed, or it can indicate that there is currently no corresponding I / O request for the bit; if the bit is a second value (e.g., "1"), it indicates that the processing status of the I / O request corresponding to the bit is unprocessed. Figure 4 is a schematic diagram of a scenario provided by an exemplary embodiment of this disclosure. Please refer to Figure 4, which includes a source server and a destination server. The source server may include a virtual machine, shared memory 1, and a storage backend lo. The virtual machine and the storage backend 1 can perform data interaction for multiple processing requests (i.e., I / O requests) through shared memory 1. Shared memory 1 can be used to store virtual queue information, which may include multiple processing requests generated by the virtual machine. When the source server malfunctions and cannot process multiple processing requests in the virtual queue information through storage backend 1, the virtual machine and its corresponding virtual queue information can be migrated to the destination server. 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 continue processing the multiple processing requests in the virtual queue information to restore processing of the multiple processing requests. In related technologies, when a server malfunctions, the server cannot determine which I / O requests have been processed and which have not, resulting in the inability to restore I / O request processing. Therefore, there is currently a lack of a method for restoring I / O request processing when the server malfunctions. To solve the above technical problem, this disclosure provides a request processing recovery method. In this method, the virtual machine has a descriptor bitmap, which includes the processing status of each processing request. When the source server fails, 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 at least one unprocessed target processing request based on the descriptor bitmap, and process at least one target processing request. Through this method, the destination server can resume processing multiple processing requests based on the descriptor bitmap. It is important to emphasize that the virtual machine's storage backend can be divided into two types: software-simulated storage backend and pass-through storage backend. The technical solution disclosed herein is applicable to both types of storage backends.The technical solutions disclosed herein 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, descriptions will not be repeated in different embodiments. To facilitate understanding of the technical solutions disclosed herein, a normal request processing process will first be described with reference to Figure 5. Figure 5 is a flowchart illustrating a request processing method provided by an embodiment of this disclosure. Referring to Figure 5, the method may include:

[0009] 5501. Obtain the first processing request and store the request information of the first processing request in at least one descriptor in the descriptor table. For example, the server can obtain the first processing request, and assume 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.

[0010] 5502. Determine the index corresponding to the first processing request based on at least one descriptor. 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. For example, if at least one descriptor includes descriptor [2] and descriptor [3], since the first descriptor is descriptor [2], and its corresponding index is 2, then the index corresponding to the first processing request can be determined as index 2.

[0011] 5503. Determine the first available entry pointed to by the current available pointer in the availability ring, and store the index corresponding to the first processing request in the first available entry. For example, if the first available entry pointed to by the current available pointer in the availability ring is an available entry [3], then index 2 can be stored in available entry [3]. 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].

[0012] 5504. 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. For example, if the first processing request corresponds to index 2, then based on index 2, the first bit can be determined to be 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.

[0013] 5505. Send a notification to the storage backend via the virtual machine to notify the storage backend to process the first processing request.

[0014] 5506. Process the first processing request through the storage backend. 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. 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 of the first available entry through the storage backend for subsequent use.

[0015] 5507. 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. For example, if the first used entry pointed to by the currently 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]. O 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.

[0016] 5508. An interrupt is sent 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 the first bit in the descriptor bitmap is updated to the first value according to the index in the first used entry. 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. After the virtual machine reclaims the first used entry, the virtual machine moves the local used pointer to the next used entry of the first used entry for subsequent use. In the embodiments of this disclosure, the virtual machine maintains a descriptor bitmap. Through the descriptor bitmap, the available ring, the used ring, and the descriptor table, the storage backend can process multiple processing requests generated by the virtual machine; and during the process of multiple processing requests, the storage backend can maintain the local available pointer and the currently used pointer, and the virtual machine can maintain the currently available pointer and the local used pointer. The following describes, with reference to Figures 6-9, a method for handling and recovering multiple processing requests when the source server is abnormal. Figure 6 is a flowchart illustrating a request processing recovery method provided by an exemplary embodiment of this disclosure. Referring to Figure 6, the method may include:

[0017] 5601. When the source server fails, the virtual machine and its corresponding virtual queue information are migrated to the destination server. The execution entity in this embodiment can be the destination server or a request processing recovery device located in the destination server. The request processing recovery device can be implemented in software or a combination of software and hardware. The request processing 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. The source server may include virtual machines and a storage backend. The storage backend can process multiple processing requests generated by the virtual machine. At least one virtual queue may exist between the virtual machine and the storage backend. Virtual queue information refers to the information in any virtual queue, which may include multiple processing requests generated by the virtual machine. Optionally, the processing request may be an I / O request. When the source server fails, i.e., when the source server cannot process multiple processing requests through the storage backend, the destination server can migrate the virtual machine and its corresponding virtual queue information to the destination server to restore processing of multiple processing requests through the storage backend in the destination server. 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.

[0018] 5602. Determine the descriptor bitmap in the virtual machine. The descriptor bitmap may include the processing status of each processing request, which can be either unprocessed or processed. The descriptor bitmap will now be described with reference to FIG7. FIG7 is a schematic diagram of the structure of a descriptor bitmap provided by an exemplary embodiment of this disclosure. Referring to FIG7, for example, the descriptor bitmap may include 10 bits, namely the 0th bit, the 1st bit, ..., the 9th bit. For any given bit, the bit may 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. As shown in FIG7, the 0th bit is 1, indicating that the processing status of processing request 0 corresponding to the 0th bit is unprocessed; the 1st bit is 0, indicating that the processing status of processing request 1 corresponding to the 1st bit is processed. It should be noted that multiple bits in the descriptor bitmap are initialized to a first value. Since at least one virtual queue can exist between the virtual machine and the storage backend, a corresponding descriptor bitmap can be set in the virtual machine for any virtual queue. The destination server can determine the descriptor bitmap corresponding to the virtual queue in the virtual machine. For example, for virtual queue 1, the destination server can determine the descriptor bitmap corresponding to virtual queue 1 in the virtual machine. It should be noted that the technical solution disclosed herein is applied to any virtual queue between the virtual machine and the storage backend.

[0019] S603. Based on the descriptor bitmap, determine at least one target processing request in an unprocessed state among multiple processing requests, and process the at least one target processing request. In an optional embodiment, the at least one target processing request in an unprocessed state can be determined from multiple processing requests based on the descriptor bitmap in the following manner: determine at least one currently processed request; set 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 determine at least one target processing request in an unprocessed state among multiple processing requests based on the updated descriptor bitmap. 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 state to a processed state 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 state of the at least one currently processed request to a processed state in the descriptor bitmap to obtain an updated descriptor bitmap. For example, if the descriptor bitmap is as shown in Figure 7, assuming the destination server can determine three currently processed requests, namely processing request 2, processing request 3, and processing request 4, and assuming that the second bit in the descriptor bitmap corresponds to processing request 2, the third bit corresponds to processing request 3, and the fourth bit corresponds to processing request 4, then the destination server can update the second bit to "0" according to processing request 2 to indicate that the processing status of processing request 2 is processed; it can update the third bit to "0" according to processing request 3 to indicate that the processing status of processing request 3 is processed; and it can update the fourth bit to "0" according to processing request 4 to indicate that the processing status of processing request 4 is processed. This yields the updated descriptor bitmap, as shown in Figure 8. Figure 8 is a schematic diagram of the updated descriptor bitmap provided by an exemplary embodiment of this disclosure. 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. For example, if the updated descriptor bitmap is as shown in Figure 8, then based on the updated descriptor bitmap, the processing status of the processing requests corresponding to the 0th, 5th, 6th, and 7th bits 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.In this embodiment of the disclosure, when the source server is abnormal, the destination server can migrate the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server, and determine the descriptor bitmap in the virtual machine. Then, based on the descriptor bitmap, at least one target processing request in an unprocessed state can be determined from multiple processing requests, and at least one target processing request can be processed. Since the virtual machine has a descriptor bitmap, it is possible to determine which processing requests have been processed and which have not, thereby allowing unprocessed processing requests to continue processing. Therefore, the processing of processing requests can be restored through the above method. Below, based on the embodiment shown in FIG6 and in conjunction with FIG9, the above request processing recovery method will be described in detail. FIG9 is a schematic flowchart of another request processing recovery method provided by an exemplary embodiment of the present disclosure. Referring to FIG9, the method may include:

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

[0021] 5902. Determine the descriptor bitmap in the virtual machine. It should be noted that the execution process of steps S901-S902 can be found in the execution process of steps S601-S602, and will not be repeated here.

[0022] 5903. Determine at least one currently processed request. In an optional embodiment, at least one currently processed request can be determined as follows: Determine the currently used pointer in the used ring, and determine the next used entry pointed to by the currently used pointer; Determine the local used pointer in the virtual machine, and determine the target used entry pointed to by the local used pointer in the used ring; In the used ring, determine at least one used entry between the target used entry and the next used entry, and determine the processing request corresponding to the index in at least one used entry as at least one currently processed request. The virtual queue information may include the used ring. The used ring can be referred to in the embodiment of Figure 2. The target used entry is the next used entry to be reclaimed in the virtual machine. For example, if the used ring is as shown in Figure 2, 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, then the target used entry pointed to by the local used pointer can be determined as a used entry [2] in the used ring. It should be noted that at the current moment, the next used entry has not yet been used and is a used entry that is about to be used. Therefore, the next used entry has not yet stored any content. 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. It should be noted that the at least one used entry includes the target used entry, but does not include the next used entry. For example, if the target used entry is a used entry [2] and the next used entry is a used entry [5], then three used entries between used entry (2) and used entry [5] can be determined, namely used entry [2], used entry [3], and used entry [4]. If the indices stored in the three used entries are index 2, index 3, and index 4 respectively, then processing request 2 corresponding to index 2, processing request 3 corresponding to index 3, and processing request 4 corresponding to index 4 can all be determined as currently processed requests. Optionally, when the local used pointer and the currently 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, since the used entry has not yet stored an index, it can be determined that there is no currently processed request.

[0023] 5904. In the descriptor bitmap, set the processing status of at least one currently processed request to the processed state to obtain an updated descriptor bitmap. Optionally, the updated descriptor bitmap can be obtained by setting the processing status of at least one currently processed request to the processed state in the descriptor bitmap as follows: In the descriptor bitmap, determine at least one bit to be reset based on the index corresponding to at least one currently processed request; set at least one bit to be reset to a first value to set the processing status corresponding to at least one currently processed request to the processed state to obtain an updated descriptor bitmap. For example, if there are 3 currently processed requests, namely processing request 2, processing request 3, and processing request 4, with corresponding indices of index 2, index 3, and index 4, and if the descriptor bitmap is as shown in Figure 7, then based on these 3 indices, determine the 2nd, 3rd, and 4th bits in the descriptor bitmap, and update these 3 bits to "0" to obtain the updated descriptor bitmap as shown in Figure 8. Optionally, if there are no currently processed requests, there is no need to update the descriptor bitmap to obtain an updated descriptor bitmap.

[0024] 5905. Based on the update descriptor bitmap, determine at least one target processing request in an unprocessed state among multiple processing requests. In an optional embodiment, at least one target processing request in an unprocessed state can be determined from multiple processing requests based on the update descriptor bitmap as follows: In the update descriptor bitmap, determine at least one target bit that is a second value; determine the processing request corresponding to the at least one target bit as at least one target processing request. For example, if the update descriptor bitmap is as shown in Figure 8, and the second value is 1, then the destination server can determine four target bits that are "1" in the update descriptor bitmap, namely the 0th bit, the 5th bit, the 6th bit, and the 7th bit. Since when a bit is "1", it indicates that the processing status of the processing request corresponding to that bit is unprocessed, if the 0th bit corresponds to processing request 0, the 5th bit corresponds to processing request 5, the 6th bit corresponds to processing request 6, and the 7th bit corresponds to processing request 7, then these four processing requests can be determined as target processing requests. 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. Optionally, regardless of whether the target processing request is determined from among multiple processing requests based on the updated descriptor bitmap or the descriptor bitmap, it is possible to determine that there is no target processing request among the multiple processing requests, meaning that all current processing requests have been processed and there are no unprocessed processing requests. In this case, steps S906-S908 do not need to be executed.

[0025] 5906. In the availability ring, determine at least one target available entry. In an optional embodiment, at least one target available entry can be determined in the availability ring as follows: Based on the currently used pointer, determine the local available pointer corresponding to the first unprocessed request; determine the current available pointer in the availability ring; based on the local available pointer and the current available pointer, determine at least one target available entry in the availability ring. The local available pointer points to the next available entry to be processed, and the processing request corresponding to the next available entry to be processed is also the first unprocessed request. Optionally, the local available pointer corresponding to the first unprocessed request can be determined based on the currently used pointer as follows: If the local available pointer is inconsistent with the currently used pointer, then update the local available pointer based on the currently used pointer. 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 processed used entry in the storage backend. Before the source server encounters an anomaly, it's possible that while processing the current request through the storage backend, the local available pointer has already been moved to the next available entry (corresponding to the next pending processing request). However, when the source server encounters an anomaly, processing of the current request is interrupted and incomplete. Consequently, the index corresponding to the current processing request is not stored in the used ring or the used entry corresponding to the current used pointer. Therefore, the processing request that the current used pointer is about to correspond to (i.e., the current processing request) has failed and needs to be reprocessed. The local available pointer can be updated based on the current used pointer. For example, if the local available pointer is 6 and the current used pointer is 5, then the local available pointer is updated to 5 based on the current used pointer. If the availability ring is as shown in Figure 1, then 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 an available entry [5], and can determine that the available entry corresponding to the current available pointer is an available entry [9]. Therefore, within the availability 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. It should be noted that this 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.

[0026] 5907. Store at least one index corresponding to a target processing request in at least one target available entry. Since updating a bit to "1" in the descriptor bitmap is done by determining the bit corresponding to the processing request based on its index, and then updating that bit to 1, the index of the corresponding target processing request can be determined based on the index of each target bit. For example, if there are 4 target processing requests and 4 target bits, the index of the corresponding target processing request can be determined based on each target bit, as shown in Table 1. Table 1 As shown in Table 1, the destination server can store the index of the four target processing requests in the four target available entries, as shown in Figure 1.

[0027] S908. Process at least one target processing request based on at least one target available entry and a descriptor table. 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. For example, the destination server can determine the first target available entry corresponding to the local available pointer as an available entry [5] from four target available entries, and then obtain the first index as index 0 in the available entry [5]. The destination server can determine the descriptor linked list 0 corresponding to processing request 0 in the descriptor table shown in FIG3 based on index 0. The descriptor linked list 0 may include descriptor [0], descriptor [1] and descriptor [3]. The destination server can obtain the request information for processing request 0 from descriptor list 0 through the storage backend, and process processing request 0 according to the request information. It should be noted that after obtaining the first index from the first target available entry through the storage backend, the destination server 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 obtaining index 0 from the available entry [5] through the storage backend, the destination server can move the local available pointer to the next available entry, i.e., the available entry [6], so as to process the next unprocessed request. After processing the first target processing request through the storage backend, the destination server 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. 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. The destination server can update the bit corresponding to the first index to the first value in the update descriptor bitmap according to the first index, so as to update the processing status of the target processing request to the processed status. For example, after the destination server processes the processing request 0 through the storage backend, it stores index 0 in the used entry [5] pointed to by the currently used pointer in the used ring shown in Figure 2, and moves the currently used pointer to the next used entry, that is, the used entry [6].The destination server can update the 0th bit corresponding to index 0 to "0" in the updated descriptor bitmap based on index 0, thereby updating the processing status of processing request 0 to the processed state. In this embodiment, when the source server is abnormal, the destination server migrates the virtual machine and the virtual queue information corresponding to the virtual machine to the destination server. The destination server can determine the descriptor bitmap in the virtual machine and determine at least one currently processed request, and then set the processing status of at least one currently processed request to the processed state in the descriptor bitmap to obtain the updated descriptor bitmap. Based on the updated descriptor bitmap, the destination server can determine at least one target processing request in an unprocessed state among multiple processing requests, and determine at least one target available entry in the availability ring, and then store the index corresponding to at least one target processing request in the at least one target available entry. The destination server can process at least one target processing request based on at least one target available entry and the descriptor table. Because the virtual machine contains a descriptor bitmap, the destination server can determine which processing requests have been processed and which have not through the descriptor bitmap, and thus can continue processing the unprocessed requests. Therefore, the processing of processing requests can be resumed through the above method. It should be noted that the various processing steps (S901-S908) shown in the embodiment of FIG9 do not constitute a specific limitation on the request processing recovery process. In other embodiments of this disclosure, the request processing recovery process may include more or fewer steps than in the embodiment of FIG9. For example, the request processing recovery process may include some of the steps in the embodiment of FIG9, or some steps in the embodiment of FIG9 may be replaced by steps with the same function, or some steps in the embodiment of FIG9 may be split into multiple steps, etc. FIG10 is a schematic diagram of the structure of a request processing recovery device provided by an exemplary embodiment of this disclosure.Please refer to Figure 10. The request processing recovery device 10 includes: a migration module 11, a first determining module 12, a second determining module 13, and a processing module 14. The migration module 11 is used to migrate the virtual machine and its corresponding virtual queue information 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 12 is used to determine a descriptor bitmap in the virtual machine. The descriptor bitmap includes the processing status of each processing request, which is either unprocessed or processed. The second determining module 13 is used to determine at least one target processing request in the unprocessed state from among the multiple processing requests based on the descriptor bitmap. The processing module 14 is used to process the at least one target processing request. The request processing recovery device provided in this embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar and will not be repeated here. In one possible implementation, the second determining module 13 is specifically configured to: determine at least one currently processed request; set 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 determine at least one target processing request in the unprocessed state among the plurality of processing requests based on the updated descriptor bitmap. In one possible implementation, the descriptor bitmap includes a plurality of bits; the second determining module 13 is specifically configured to: determine at least one bit to be reset in the descriptor bitmap based on the index corresponding to the at least one currently processed request; set the at least one bit to be reset to a first value to set the processing state corresponding to the at least one currently processed request to a processed state to obtain an updated descriptor bitmap. In one possible implementation, the second determining module 13 is specifically configured to: determine at least one target bit corresponding to a second value in the updated descriptor bitmap; and determine the processing request corresponding to the at least one target bit as the at least one target processing request. In one possible implementation, the virtual queue information includes a used ring; the second determining module 13 is specifically configured to: determine a currently used pointer in the used ring, and determine the next used entry pointed to by the currently used pointer; determine a local used pointer in the virtual machine, and determine the target used entry pointed to by the local pointer in the used ring; determine at least one used entry between the target used entry and the next used entry in the used ring, and determine the processing request corresponding to the index in the at least one used entry as at least one currently processed request.In one possible implementation, the virtual queue information includes unprocessed request information and a descriptor table; the processing module 14 is specifically used to: determine at least one target available entry in the availability ring; store the index corresponding to the at least one target processing request in the at least one target available entry; and process the at least one target processing request according to the at least one target available entry and the descriptor table. In one possible implementation, the processing module 14 is specifically used to: determine a local available pointer corresponding to the first unprocessed request according to the currently used pointer; determine a current available pointer in the availability ring; and determine at least one target available entry in the availability ring according to the local available pointer and the current available pointer, wherein the local available pointer points to the first available entry among the at least one target available entries. In one possible implementation, the processing module 14 is specifically used to: update the local available pointer according to the currently used pointer if the local available pointer is inconsistent with the currently used pointer. In one possible implementation, for any target processing request, the processing module 14 is specifically configured to: determine a first target available entry pointed to by the local available pointer in the at least one target available entry; obtain a first index in the first target available entry; determine a descriptor linked list in the descriptor table according to the first index, the descriptor linked list being used to store the request information of the target processing request; obtain the request information of the first target processing request from the descriptor linked list, and process the first target processing request according to the request information. The request processing recovery device provided in this disclosure embodiment can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, and will not be repeated here. Figure 11 is a schematic diagram of another request processing recovery device provided in an exemplary embodiment of this disclosure. Please refer to Figure 11. Based on the embodiment shown in Figure 10, the request processing recovery device 10 may further include: a moving module 15, a storage module 16, and an update module 17. 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 from the first target available entry. The storage module 16 is used to store the first index in the used ring after processing the first target processing request. The update module 17 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.The request processing recovery device provided in this disclosure can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar and will not be repeated here. Figure 12 is a schematic diagram of an electronic device provided in an exemplary embodiment of this disclosure. Referring 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. The memory 22 stores computer execution instructions; the processor 21 executes the computer execution instructions stored in the memory 22, causing the processor 21 to execute the method as shown in the above method embodiments. The electronic device shown in Figure 12 can be a server or a destination server as described in any of the above embodiments. Accordingly, this disclosure provides a computer-readable storage medium storing computer execution instructions, which, when executed by a processor, are used to implement the method described in the above method embodiments. Accordingly, this disclosure may also provide a computer program product, including a computer program, which, when executed by a processor, can implement the method shown in the above method embodiments. Those skilled in the art should understand that the embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure may take the form of a computer program product implemented 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. This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. 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, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.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 that implement the functions specified in one or more flowcharts and / or one or more block diagrams. These computer program instructions may also be loaded onto a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams, whereby the instructions that execute on the computer or other programmable device provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, 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. Computer-readable media includes both permanent and non-persistent, removable and non-removable media; information storage can be implemented 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 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 media, such as modulated data signals and carrier waves. 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 a..." does not exclude the presence of other identical elements in the process, method, product, or apparatus that includes said element. The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

CLAIM 1. A request processing recovery method in which, The method applied to a destination server comprises: when a source server is abnormal, migrating a virtual machine and virtual queue information corresponding to the virtual machine to the destination server, wherein the virtual queue information comprises a plurality of processing requests generated by the virtual machine; determining a descriptor bitmap in the virtual machine, wherein the descriptor bitmap comprises a processing state of each processing request, and the processing state is an unprocessed state or a processed state; determining at least one target processing request in the plurality of processing requests in the unprocessed state according to the descriptor bitmap, and processing the at least one target processing request.

2. The method of claim 1, wherein, According to the descriptor bitmap, the at least one target processing request in the plurality of processing requests in the unprocessed state is determined, comprising: determining at least one current processed request; setting the processing state of the at least one current processed request to the processed state in the descriptor bitmap to obtain an updated descriptor bitmap; and determining at least one target processing request in the plurality of processing requests in the unprocessed state according to the updated descriptor bitmap.

3. The method of claim 2, wherein, The descriptor bitmap comprises a plurality of bits; setting the processing state of the at least one current processed request to the processed state in the descriptor bitmap to obtain an updated descriptor bitmap comprises: determining at least one bit to be reset in the descriptor bitmap according to an index corresponding to the at least one current processed request; and setting the at least one bit to be reset to a first value to set the processing state corresponding to the at least one current processed request to the processed state to obtain the updated descriptor bitmap.

4. The method according to claim 2 or 3, wherein, According to the updated descriptor bitmap, the at least one target processing request in the plurality of processing requests in the unprocessed state is determined, comprising: determining at least one target bit corresponding to a second value in the updated descriptor bitmap; and determining a processing request corresponding to the at least one target bit as the at least one target processing request.

5. The method of any one of claims 2-4, wherein, The virtual queue information comprises a used ring; The at least one current processed request is determined, comprising: determining a current used pointer in the used ring, and determining a next used entry pointed to by the current used pointer; determining a local used pointer in the virtual machine, and determining a 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 a processing request corresponding to an index in the at least one used entry as the at least one current processed request.

6. The method according to any one of claims 1 to 5, wherein, The virtual queue information comprises a used ring and a descriptor table; processing the at least one target processing request comprises: determining at least one target available entry in the available ring; storing an index corresponding to the at least one target processing request in the at least one target available entry; and processing the at least one target processing request according to the at least one target available entry and the descriptor table.

7. The method according to claim 6, wherein, determining at least one target available entry in the available ring comprises: determining a local available pointer corresponding to a first unprocessed request according to the current used pointer; determining a current available pointer in the available ring; and determining at least one target available entry in the available ring according to the local available pointer and the current available pointer, the local available pointer pointing to a first available entry in the at least one target available entry.

8. The method according to claim 7, wherein, determining a local available pointer corresponding to a first unprocessed request according to the current used pointer comprises: if the local available pointer is inconsistent with the current used pointer, updating the local available pointer according to the current used pointer.

9. The method of any one of claims 6-8, wherein, for any one target processing request; processing the at least one target processing request according to the at least one target available entry and the descriptor table comprises: determining a first target available entry pointed to by the local available pointer in the at least one target available entry; obtaining a first index in the first target available entry; determining a descriptor linked list in the descriptor table according to the first index, the descriptor linked list being used to store request information of the target processing request; obtaining request information of the first target processing request in the descriptor linked list, and processing the first target processing request according to the request information.

10. The method according to claim 9, wherein, The method further comprises: after obtaining the first index in the first target available entry, moving the local available pointer to a next available entry of the first target available entry; and after processing the first target processing request, storing the first index in the used ring, and updating a processing state corresponding to the target processing request to a processed state in the updated descriptor bitmap according to the first index.

11. A request processing recovery apparatus, wherein, The device, applied to a destination server, includes: a migration module, a first determining module, a second determining module, and a processing module. The migration module is used to migrate virtual machines and their corresponding virtual queue information 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 used to determine a descriptor bitmap in the virtual machine. The descriptor bitmap includes the processing status of each processing request, which is either unprocessed or processed. The second determining module is used to determine at least one target processing request in the unprocessed state from among the multiple processing requests based on the descriptor bitmap. The processing module is used to process the at least one target processing request.

12. An electronic device, wherein, include: At least one processor; The electronic device also includes a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to cause the electronic device to perform the method according to any one of claims 1-10.

13. A computer-readable storage medium, wherein, 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, wherein, When the computer program is executed by the processor, it implements the method as described in any one of claims 1T 0. ​

Images