Method, device, electronic device and storage medium for request queue optimization
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING KINGSOFT CLOUD NETWORK TECH CO LTD
- Filing Date
- 2024-12-27
- Publication Date
- 2026-06-30
AI Technical Summary
In existing technologies, the limited request queue capacity of the regional server in an HBase cluster causes access requests to metadata tables to fail, resulting in offline job failures.
By receiving queue data calculated by a counter in the request queue, it is determined whether the preset threshold has been exceeded. A new temporary request queue is then created and the target access request is loaded into it, with requests in the temporary request queue being processed first.
It effectively alleviated the problem of access request failures caused by insufficient request queue capacity, reduced the access pressure on the metadata table, and prevented offline job failures.
Smart Images
Figure CN122309041A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of queue optimization technology, and in particular to a method, apparatus, electronic device, and storage medium for requesting queue optimization. Background Technology
[0002] The rapid development of social informatization and networking has led to an explosive increase in data volume. HBase (Hadoop Database), as a distributed, column-oriented open-source database, is widely used in the field of data storage.
[0003] When external applications access the HBase cluster using HBase clients, they can accelerate data access by accessing metadata tables. Currently, all access requests to metadata tables can only be accepted and processed by a single regional server. Considering that the memory of the regional server is limited, the capacity of the request queue for storing access requests is also limited. When accessing the metadata table in a concentrated manner, the limited capacity of the request queue prevents the unlimited storage of access requests, causing many access requests to the metadata table to fail and resulting in the failure of offline jobs. Summary of the Invention
[0004] In view of this, in order to effectively alleviate the problem of access request failures caused by the limited capacity of the request queue, which cannot accept unlimited access requests to the metadata table, resulting in offline job failures, this application provides a method, apparatus, electronic device, and storage medium for request queue optimization.
[0005] In a first aspect, embodiments of this application provide a method for optimizing request queues, the method being applied to a regional server with deployed metadata tables, the method comprising:
[0006] The queue data is calculated by a counter in the request queue; wherein the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue.
[0007] Determine whether the queue data exceeds a preset data threshold;
[0008] If it is determined that the queue data exceeds the preset data threshold, a new temporary request queue for the target access request is created.
[0009] The target access request is moved from the request queue to the temporary request queue, and the request processing thread is called to process the target access request in the temporary request queue first.
[0010] Optionally, as described above, the queue data includes the percentage of target access requests corresponding to the target access request and the percentage of queue capacity used corresponding to the request queue;
[0011] The target access request percentage data is calculated based on the first access request volume of the target access requests and the total access request volume in the request queue; wherein, the total access request volume is the sum of the first access request volume and the second access request volume of the non-target access requests;
[0012] The queue capacity percentage data is calculated based on the total number of access requests and the maximum number of access requests in the request queue.
[0013] Optionally, as described above, determining whether the queue data exceeds a preset data threshold includes:
[0014] Determine whether the target access request percentage data exceeds a preset access request percentage threshold, and whether the queue used capacity percentage data exceeds a queue used capacity percentage threshold.
[0015] Optionally, as described above, the step of creating a temporary request queue for the target access request includes:
[0016] Create a temporary request queue for the target access request in non-heap memory.
[0017] Optionally, as described above, the method further includes:
[0018] If the target access request percentage data does not exceed the preset access request percentage threshold, and / or the queue used capacity percentage data does not exceed the queue used capacity percentage threshold, the request processing thread is invoked to process the access requests in the request queue sequentially.
[0019] Optionally, as described above, the method further includes:
[0020] Periodically check whether the target access request in the temporary request queue is empty;
[0021] If the target access request in the temporary request queue is found to be empty, the request processing thread that was processing the target access request in the temporary request queue is released.
[0022] Optionally, as described above, the method further includes:
[0023] The idle time when the target access request in the temporary request queue is empty is recorded.
[0024] Determine whether the idle time exceeds a preset time threshold;
[0025] If the idle time exceeds the preset time threshold, the temporary request queue is destroyed.
[0026] Secondly, embodiments of this application provide an apparatus for request queue optimization, the apparatus being applied to a regional server with a deployed metadata table, the apparatus comprising:
[0027] The receiving module is used to receive queue data calculated by a counter in the request queue; wherein the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue.
[0028] The determination module is used to determine whether the queue data exceeds a preset data threshold;
[0029] A new module is created to create a temporary request queue for the target access request when it is determined that the queue data exceeds the preset data threshold.
[0030] The loading processing module is used to load the target access request from the request queue into the temporary request queue, and to call the request processing thread to prioritize the processing of the target access request in the temporary request queue.
[0031] Thirdly, embodiments of this application provide an electronic device, comprising: a processor and a memory, wherein the processor is configured to execute a request queue optimization program stored in the memory to implement the aforementioned request queue optimization method.
[0032] Fourthly, embodiments of this application provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the above-described request queue optimization method.
[0033] In this embodiment of the invention, queue data calculated by a counter in the request queue is used. This queue data is calculated from target access requests and non-target access requests to the metadata table in the request queue, serving as an indicator to measure the access volume of the metadata table and the used capacity of the request queue. The system determines whether the queue data exceeds a preset data threshold. If the queue data exceeds the preset data threshold, a temporary request queue for the target access requests is created. The target access requests are moved from the request queue to the temporary request queue, and the request processing thread prioritizes processing the target access requests in the temporary request queue. In this technical solution, when the queue data indicates a large access volume to the metadata table and insufficient used capacity of the request queue, creating a temporary request queue and moving the target access requests to the metadata table from the request queue to the temporary request queue significantly reduces the problem of failed access requests to the metadata table due to limited request queue capacity, thus preventing offline job failures. It also effectively alleviates the access pressure on the server in the region where the metadata table is located. Attached Figure Description
[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.
[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0036] Figure 1 A schematic diagram of an application environment for a request queue optimization method provided in this application embodiment;
[0037] Figure 2 A flowchart illustrating a request queue optimization method provided in an embodiment of this application;
[0038] Figure 3 A flowchart illustrating another request queue optimization method provided in an embodiment of this application;
[0039] Figure 4 A flowchart illustrating another request queue optimization method provided in an embodiment of this application;
[0040] Figure 5 A block diagram illustrating an embodiment of a request queue optimization apparatus provided in this application;
[0041] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0042] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0043] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0044] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0045] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.
[0046] Foundational technologies in artificial intelligence generally include sensors, dedicated AI chips, cloud computing, storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.
[0047] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0048] To facilitate understanding of the embodiments of this application, the following will provide further explanation and description with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.
[0049] This application provides a method for optimizing request queues, which can be applied to applications such as... Figure 1 In this application environment, the regional server, which deploys metadata tables within the HBase cluster, communicates with HBase clients. The regional server receives access requests from clients, which can be targeted access requests for accessing the metadata tables, or other non-target access requests. Clients include, but are not limited to, PDAs, desktop computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, cloud computing devices, and personal digital assistants (PDAs). The computer equipment corresponding to the regional server can be a standalone server or a server cluster consisting of multiple servers; no specific limitation is made here.
[0050] This application provides a method for request queue optimization; see [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of a request queue optimization method provided in this application. Figure 2 The process shown may include the following steps:
[0051] Step 201: Receive queue data calculated by a counter set in the request queue;
[0052] The request queue of the regional server is used to receive target access requests sent by clients for accessing the metadata table, as well as non-target access requests that do not target the metadata table, and to manage and handle the target access requests and non-target access requests concurrently.
[0053] When initializing the request queue, the server in the aforementioned region sets a counter in the request queue. This counter is used to calculate the queue data every time a new target access request or non-target access request enters the request queue.
[0054] The queue data is calculated from the target access requests and non-target access requests to the metadata table in the request queue. It is used to measure the access volume of the metadata table and the used capacity of the request queue. It can be understood that the queue data can directly indicate whether the access volume to the metadata table is large or small, and whether the used capacity of the request queue is sufficient or insufficient.
[0055] Step 202: Determine whether the queue data exceeds the preset data threshold;
[0056] The aforementioned preset data threshold is a pre-set critical value used to indicate that the access volume of the metadata table is high and the used capacity of the request queue is insufficient. This preset data threshold is set according to actual needs and is not limited here.
[0057] Step 203: If it is determined that the queue data exceeds the preset data threshold, a new temporary request queue for the target access request is created.
[0058] If the queue data exceeds the preset data threshold, it indicates that the access volume of the metadata table is high and the used capacity of the request queue is insufficient. In this case, the access request volume may exceed the capacity limit of the request queue, resulting in the failure of access requests to the metadata table and causing offline jobs to fail. In order to solve the above technical problems, in this embodiment, a temporary request queue can be created for the target access request to store the target access request for the metadata table. This is equivalent to expanding the queue capacity of the request queue and greatly reducing the problem of offline jobs failing due to the failure of access requests to the metadata table caused by the limited capacity of the request queue.
[0059] Step 204: Move the target access request from the request queue to the temporary request queue, and call the request processing thread to process the target access request in the temporary request queue first.
[0060] All unprocessed target access requests in the request queue are moved to a temporary request queue. At this time, the request processing thread begins to prioritize processing the target access requests in the temporary request queue until all target access requests in the temporary request queue have been processed, thereby significantly alleviating the access pressure on the server in the region where the metadata table is located.
[0061] In this embodiment of the invention, queue data calculated by a counter in the request queue is used. This queue data is calculated from target access requests and non-target access requests to the metadata table in the request queue, serving as an indicator to measure the access volume of the metadata table and the used capacity of the request queue. The system determines whether the queue data exceeds a preset data threshold. If the queue data exceeds the preset data threshold, a temporary request queue for the target access requests is created. The target access requests are moved from the request queue to the temporary request queue, and the request processing thread prioritizes processing the target access requests in the temporary request queue. In this technical solution, when the queue data indicates a large access volume to the metadata table and insufficient used capacity of the request queue, creating a temporary request queue and moving the target access requests to the metadata table from the request queue to the temporary request queue significantly reduces the problem of failed access requests to the metadata table due to limited request queue capacity, thus preventing offline job failures. It also effectively alleviates the access pressure on the server in the region where the metadata table is located.
[0062] Furthermore, creating a new temporary request queue on the regional server only when the metadata table has high access volume and the request queue is insufficient in capacity has a simple strategy structure and will not cause security or resource consumption problems caused by a significant increase in the complexity of the service architecture.
[0063] As described above, queue data is a metric used to measure the access volume of the metadata table and the used capacity of the request queue. Therefore, queue data includes the percentage of target access requests corresponding to the target access requests and the percentage of used capacity of the request queue. That is, the access volume of the metadata table is measured by the percentage of target access requests, and the used capacity of the request queue is measured by the percentage of used capacity of the queue.
[0064] The target access request percentage data is calculated based on the first access request volume of target access requests and the total access request volume in the request queue; the total access request volume is the sum of the first access request volume and the second access request volume of non-target access requests.
[0065] For ease of understanding, the target access request percentage is calculated using the following formula:
[0066] Target access request percentage = (First access request volume / Total access request volume) * 100%;
[0067] Alternatively, the target access request percentage data = first access request volume / total access request volume; the target access request percentage data can be expressed as a percentage or a fraction, and there is no restriction here.
[0068] Taking the percentage of target access requests as an example, if the number of first access requests for target access requests is 1000 and the number of second access requests for non-target access requests is 500, then the percentage of target access requests is (1000 / 1500)*100% = 66.67%.
[0069] The queues mentioned above were calculated using capacity percentage data based on the total number of access requests and the maximum number of access requests in the request queue. This maximum number of access requests is the maximum number of access requests that the request queue can accommodate. This maximum number of access requests is related to the memory and underlying data structure of the regional server, and therefore no limit is imposed on it here.
[0070] For ease of understanding, the percentage of queue capacity used is calculated using the following formula:
[0071] Queue used capacity percentage = (Total access requests / Maximum access requests) * 100%;
[0072] Alternatively, the queue used capacity percentage data = total access requests / maximum access requests; the queue used capacity percentage data can be expressed as a percentage or a fraction, and there is no restriction here.
[0073] Continuing with the previous example, let's take the percentage of queue used capacity as an example. If the maximum number of access requests is 2000, the number of first access requests is 1000, and the number of second access requests (not the target access requests) is 500. Then the percentage of queue used capacity is (1500 / 2000)*100% = 75%.
[0074] Given that the aforementioned queue data comprises the percentage of target access requests and the percentage of queue capacity used, Figure 2 Based on this, see Figure 3 , Figure 3 A flowchart illustrating an embodiment of another request queue optimization method provided in this application. Figure 3 The process shown may include the following steps:
[0075] Step 301: Receive the target access request percentage data and queue used capacity percentage data calculated by the counters set in the request queue;
[0076] Step 302: Determine whether the target access request percentage data exceeds the preset access request percentage threshold and whether the queue used capacity percentage data exceeds the queue used capacity percentage threshold.
[0077] Since the queue data includes the percentage of target access requests and the percentage of queue used capacity, the above preset data thresholds include the preset access request percentage threshold and the preset queue used capacity percentage threshold.
[0078] The preset access request percentage threshold is a pre-set threshold for a large number of accesses to the metadata table, and the queue used capacity percentage threshold is a pre-set threshold for insufficient used capacity in the request queue. These preset access request percentage thresholds and queue used capacity percentage thresholds can be set according to actual needs and are not limited here.
[0079] If the percentage of target access requests exceeds the preset threshold and the percentage of queue used capacity exceeds the threshold, it indicates that the metadata table has a large number of accesses and the request queue has insufficient used capacity. In this case, step 303 needs to be executed.
[0080] If the target access request percentage data does not exceed the preset access request percentage threshold, and / or the queue used capacity percentage does not exceed the queue used capacity percentage threshold, it indicates that the metadata table access volume is not large and / or the request queue used capacity is sufficient. In this case, step 305 needs to be executed.
[0081] Step 303: Create a temporary request queue for the target access request in the non-heap memory;
[0082] When the metadata table is accessed frequently and the request queue is insufficient, the regional server can create a temporary request queue for the target access request in non-heap memory. This is because the available non-heap memory capacity of the service is much higher than that of the heap memory, and this capacity is not included in the capacity of the regular request queue. Therefore, creating a temporary request queue in non-heap memory instead of in heap memory can alleviate the capacity and performance pressure of the process heap memory, and can also provide a higher queue capacity to store the target access request.
[0083] Step 304: Move the target access request from the request queue to the temporary request queue, and call the request processing thread to process the target access request in the temporary request queue first.
[0084] For details, please refer to the process description. Figure 2 The relevant descriptions in the provided embodiments will not be repeated here.
[0085] Step 305: Call the request processing thread to process the access requests in the request queue in sequence.
[0086] If the access volume to the metadata table is not high and / or the request queue has sufficient capacity, it means that the access pressure on the regional server is not high. There will be no problem of requests to the metadata table failing due to the access request volume exceeding the capacity limit of the request queue, which would cause offline jobs to fail. In this case, the target access requests and non-target access requests in the request queue can be processed in the usual way of processing access requests. That is, the request processing thread can retrieve the target access requests or non-target access requests from the request queue in sequence for processing.
[0087] The method in this embodiment can significantly reduce the problem of failed requests to the metadata table caused by insufficient request queue capacity, which can lead to offline job failures, when the metadata table has a large number of accesses and the request queue is not full. This can be achieved by creating a temporary request queue in non-heap memory and transferring the target access requests to the metadata table from the request queue to the temporary request queue. This can also effectively alleviate the access pressure on the server in the region where the metadata table is located. When the metadata table has a small number of accesses and / or the request queue is full, the target access requests and non-target access requests in the request queue can be processed in the conventional way of processing access requests.
[0088] exist Figure 2 Based on this, see Figure 4 , Figure 4 A flowchart illustrating an embodiment of another request queue optimization method provided in this application. Figure 4 The process shown may include the following steps:
[0089] Step 401: Receive queue data calculated by a counter set in the request queue; wherein, the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue.
[0090] Step 402: Determine whether the queue data exceeds the preset data threshold;
[0091] Step 403: If it is determined that the queue data exceeds the preset data threshold, a new temporary request queue for the target access request is created.
[0092] Step 404: Move the target access request from the request queue to the temporary request queue, and call the request processing thread to process the target access request in the temporary request queue first.
[0093] For details of steps 401 to 404 above, please refer to [link / reference]. Figure 2 The relevant descriptions in the provided embodiments will not be repeated here.
[0094] Step 405: Periodically check whether the target access request in the temporary request queue is empty;
[0095] If the target access request in the temporary request queue is found to be empty, it indicates that the target access request in the temporary request queue has been processed and step 406 is executed; if the target access request in the temporary request queue is found to be not empty, it indicates that the target access request in the temporary request queue has not been processed and step 404 continues to execute the request retrieval processing thread to prioritize processing the target access request in the temporary request queue.
[0096] Step 406: Release the request processing thread that is handling the target access request in the temporary request queue;
[0097] When all target access requests in the temporary request queue have been processed, the request processing thread that was processing the target access requests in the temporary request queue can be released so that the request processing thread can continue to process non-target access requests and target access requests in the request queue.
[0098] Step 407: Calculate the idle time when the target access request is empty in the temporary request queue;
[0099] Step 408: Determine whether the idle time exceeds the preset time threshold;
[0100] The preset duration threshold can be 20 minutes, 30 minutes, or 40 minutes. The specific preset duration threshold can be set according to actual needs and is not limited here.
[0101] If the idle time exceeds the preset time threshold, proceed to step 409; if the idle time does not exceed the preset time threshold, proceed to step 407 to continue to count the idle time when the target access request in the temporary request queue is empty.
[0102] Step 409: Destroy the temporary request queue.
[0103] When the idle time exceeds a preset time threshold, the access pressure on the metadata table is considered to have ended. At this time, the temporary request queue is destroyed. This step can effectively avoid additional resource occupation during non-special periods (when the access pressure on the metadata table ends).
[0104] The method in this embodiment can temporarily increase the queue capacity of the request queue in special scenarios by creating a temporary request queue for the target access request, and can also destroy the temporary request queue in a timely manner according to the actual situation to avoid additional resource consumption.
[0105] See Figure 5 This is a block diagram illustrating an embodiment of a request queue optimization apparatus provided in this application. Figure 5As shown, the device includes:
[0106] The receiving module 501 is used to receive queue data calculated by a counter in the request queue; wherein, the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue.
[0107] The determination module 502 is used to determine whether the queue data exceeds a preset data threshold.
[0108] A new module 503 is created to create a temporary request queue for the target access request when the queue data exceeds a preset data threshold.
[0109] The loading processing module 504 is used to load the target access request from the request queue into the temporary request queue, and to call the request processing thread to prioritize the processing of the target access request in the temporary request queue.
[0110] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0111] As an optional implementation, the queue data includes the percentage of target access requests corresponding to the target access request and the percentage of queue capacity used corresponding to the request queue;
[0112] The target access request percentage data is calculated based on the first access request volume of target access requests and the total access request volume in the request queue; where the total access request volume is the sum of the first access request volume and the second access request volume of non-target access requests;
[0113] The queue capacity percentage data is calculated based on the total number of access requests and the maximum number of access requests in the request queue.
[0114] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0115] As an optional implementation, the determination module 502 is also used to determine whether the target access request percentage data exceeds the preset access request percentage threshold and whether the queue used capacity percentage data exceeds the queue used capacity percentage threshold.
[0116] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0117] As an optional implementation, the newly created module 503 is also used to create a temporary request queue for the target access request in the non-heap memory.
[0118] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0119] As an optional implementation, the above-described apparatus further includes:
[0120] The sequential processing module is used to invoke the request processing thread to sequentially process the access requests in the request queue when the target access request percentage data does not exceed the preset access request percentage threshold, and / or the queue used capacity percentage data does not exceed the queue used capacity percentage threshold.
[0121] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0122] As an optional implementation, the above-described apparatus further includes:
[0123] The timed check module is used to periodically check whether the target access request in the temporary request queue is empty;
[0124] The release module is used to release the request processing thread that handles the target access request in the temporary request queue when it is found that the target access request in the temporary request queue is empty.
[0125] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0126] As an optional implementation, the above-described apparatus further includes:
[0127] The statistics module is used to count the idle time when the target access request in the temporary request queue is empty;
[0128] The duration determination module is used to determine whether the idle time exceeds a preset duration threshold.
[0129] The destruction module is used to destroy the temporary request queue when the idle time exceeds a preset time threshold.
[0130] Specifically, the detailed process by which each module in the device of this invention implements its function can be found in the relevant description in the method embodiment, and will not be repeated here.
[0131] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6The illustrated electronic device 1200 includes at least one processor 1201, a memory 1202, at least one network interface 1204, and other user interfaces 1203. The various components in the electronic device 1200 are coupled together via a bus system 1205. It is understood that the bus system 1205 is used to implement communication between these components. In addition to a data bus, the bus system 1205 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 6 The general labeled all buses as Bus System 1205.
[0132] The user interface 1203 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).
[0133] It is understood that the memory 1202 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 1202 described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0134] In some implementations, memory 1202 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 12021 and application program 12022.
[0135] The operating system 12021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 12022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this application embodiment can be included in the application program 12022.
[0136] In this embodiment, by calling the program or instructions stored in memory 1202, specifically the program or instructions stored in application program 12022, processor 1201 executes the method steps provided in each method embodiment, including, for example:
[0137] The queue data is calculated by a counter set in the request queue; the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue.
[0138] Determine whether the queue data exceeds a preset data threshold;
[0139] If the queue data exceeds a preset data threshold, a new temporary request queue for the target access request is created.
[0140] The target access request is moved from the request queue to the temporary request queue, and the request processing thread is called to process the target access request in the temporary request queue first.
[0141] Optionally, as described above, the queue data includes the percentage of target access requests corresponding to the target access request and the percentage of queue capacity used corresponding to the request queue;
[0142] The target access request percentage data is calculated based on the first access request volume of target access requests and the total access request volume in the request queue; where the total access request volume is the sum of the first access request volume and the second access request volume of non-target access requests;
[0143] The queue capacity percentage data is calculated based on the total number of access requests and the maximum number of access requests in the request queue.
[0144] Optionally, as described above, determining whether the queue data exceeds a preset data threshold includes:
[0145] Determine whether the percentage of target access requests exceeds the preset threshold for access request percentage, and whether the percentage of queue used capacity exceeds the threshold for queue used capacity percentage.
[0146] Optionally, as described above, a temporary request queue for the target access request is created, including:
[0147] Create a temporary request queue for the target access request in non-heap memory.
[0148] Optionally, as described above, the method further includes:
[0149] If the target access request percentage data does not exceed the preset access request percentage threshold, and / or the queue used capacity percentage data does not exceed the queue used capacity percentage threshold, the request processing thread is invoked to process the access requests in the request queue sequentially.
[0150] Optionally, as described above, the method further includes:
[0151] Periodically check if the target access request in the temporary request queue is empty;
[0152] If the target access request in the temporary request queue is found to be empty, release the request processing thread that was handling the target access request in the temporary request queue.
[0153] Optionally, as described above, the method further includes:
[0154] Count the idle time when the target access request in the temporary request queue is empty;
[0155] Determine whether the idle time exceeds a preset time threshold;
[0156] If the idle time exceeds a preset time threshold, the temporary request queue is destroyed.
[0157] The methods disclosed in the embodiments of this application can be applied to or implemented by the processor 1201. The processor 1201 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in the processor 1201. The processor 1201 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1202. Processor 1201 reads the information in memory 1202 and completes the steps of the above method in conjunction with its hardware.
[0158] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of this application, or combinations thereof.
[0159] For software implementation, the techniques described herein can be implemented through units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or external to the processor.
[0160] The electronic device provided in this embodiment may be as follows: Figure 6 The electronic device shown can perform the following: Figure 2-4 This involves all steps of the method for optimizing the request queue, thereby achieving... Figure 2-4 For details on the technical effects of the request queue optimization method shown, please refer to [link / reference]. Figure 2-4 The relevant descriptions are presented concisely and will not be elaborated upon here.
[0161] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.
[0162] The above-described request queue optimization method can be implemented when one or more programs in the storage medium can be executed by one or more processors.
[0163] The processor executes a request queue optimization program stored in memory to implement the following steps of the request queue optimization method:
[0164] The queue data is calculated by a counter set in the request queue; the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue.
[0165] Determine whether the queue data exceeds a preset data threshold;
[0166] If the queue data exceeds a preset data threshold, a new temporary request queue for the target access request is created.
[0167] The target access request is moved from the request queue to the temporary request queue, and the request processing thread is called to process the target access request in the temporary request queue first.
[0168] Optionally, as described above, the queue data includes the percentage of target access requests corresponding to the target access request and the percentage of queue capacity used corresponding to the request queue;
[0169] The target access request percentage data is calculated based on the first access request volume of target access requests and the total access request volume in the request queue; where the total access request volume is the sum of the first access request volume and the second access request volume of non-target access requests;
[0170] The queue capacity percentage data is calculated based on the total number of access requests and the maximum number of access requests in the request queue.
[0171] Optionally, as described above, determining whether the queue data exceeds a preset data threshold includes:
[0172] Determine whether the percentage of target access requests exceeds the preset threshold for access request percentage, and whether the percentage of queue used capacity exceeds the threshold for queue used capacity percentage.
[0173] Optionally, as described above, a temporary request queue for the target access request is created, including:
[0174] Create a temporary request queue for the target access request in non-heap memory.
[0175] Optionally, as described above, the method further includes:
[0176] If the target access request percentage data does not exceed the preset access request percentage threshold, and / or the queue used capacity percentage data does not exceed the queue used capacity percentage threshold, the request processing thread is invoked to process the access requests in the request queue sequentially.
[0177] Optionally, as described above, the method further includes:
[0178] Periodically check if the target access request in the temporary request queue is empty;
[0179] If the target access request in the temporary request queue is found to be empty, release the request processing thread that was handling the target access request in the temporary request queue.
[0180] Optionally, as described above, the method further includes:
[0181] Count the idle time when the target access request in the temporary request queue is empty;
[0182] Determine whether the idle time exceeds a preset time threshold;
[0183] If the idle time exceeds a preset time threshold, the temporary request queue is destroyed.
[0184] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0185] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0186] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method of request queue optimization, characterized by, The method is applied to a regional server with a deployed metadata table, and the method includes: The queue data is calculated by a counter in the request queue; wherein the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue. Determine whether the queue data exceeds a preset data threshold; If it is determined that the queue data exceeds the preset data threshold, a new temporary request queue for the target access request is created. The target access request is moved from the request queue to the temporary request queue, and the request processing thread is called to process the target access request in the temporary request queue first.
2. The method of claim 1, wherein, The queue data includes the percentage of target access requests corresponding to the target access request and the percentage of queue capacity used corresponding to the request queue. The target access request percentage data is calculated based on the first access request volume of the target access requests and the total access request volume in the request queue; wherein, the total access request volume is the sum of the first access request volume and the second access request volume of the non-target access requests; The queue capacity percentage data is calculated based on the total number of access requests and the maximum number of access requests in the request queue.
3. The method of claim 2, wherein, The determination of whether the queue data exceeds a preset data threshold includes: Determine whether the target access request percentage data exceeds a preset access request percentage threshold, and whether the queue used capacity percentage data exceeds a queue used capacity percentage threshold.
4. The method of claim 1, wherein, The newly created temporary request queue for the target access request includes: Create a temporary request queue for the target access request in non-heap memory.
5. The method of claim 3, wherein, The method further includes: If the target access request percentage data does not exceed the preset access request percentage threshold, and / or the queue used capacity percentage data does not exceed the queue used capacity percentage threshold, the request processing thread is invoked to process the access requests in the request queue sequentially.
6. The method of claim 1, wherein, The method further includes: Periodically check whether the target access request in the temporary request queue is empty; If the target access request in the temporary request queue is found to be empty, the request processing thread that was processing the target access request in the temporary request queue is released.
7. The method of claim 6, wherein, The method further includes: The idle time when the target access request in the temporary request queue is empty is recorded. Determine whether the idle time exceeds a preset time threshold; If the idle time exceeds the preset time threshold, the temporary request queue is destroyed.
8. An apparatus for request queue optimization, the apparatus comprising: The device is applied to a regional server where a metadata table is deployed. The device includes: The receiving module is used to receive queue data calculated by a counter in the request queue; wherein the queue data is calculated from the target access requests and non-target access requests to access the metadata table in the request queue, and is used to measure the access volume of the metadata table and the used capacity of the request queue. The determination module is used to determine whether the queue data exceeds a preset data threshold; A new module is created to create a temporary request queue for the target access request when it is determined that the queue data exceeds the preset data threshold. The loading processing module is used to load the target access request from the request queue into the temporary request queue, and to call the request processing thread to prioritize the processing of the target access request in the temporary request queue.
9. An electronic device, comprising: include: A processor and a memory, the processor being configured to execute a request queue optimization program stored in the memory to implement the request queue optimization method according to any one of claims 1 to 7.
10. A storage medium, characterized by The storage medium stores one or more programs, which can be executed by one or more processors to implement the request queue optimization method according to any one of claims 1 to 7.