A request processing method and device

Abstract

The present invention discloses a request processing method and device, and relates to the field of computer technology. A specific implementation of the method includes: verifying the request received from the interface caller according to the current limiting rules of the interface caller, and saving the verified request to the message queue corresponding to the interface caller; obtaining the pending request from the message queue of each interface caller according to the weight value of each interface caller, and generating a pending request package; processing the pending request package to generate a request processing result. This implementation can realize dynamic current limiting of each interface caller when receiving a request, and dynamically balance the current limiting according to the weight of each interface caller when processing a request, thereby reducing the resources consumed by processing requests, affecting the stability of the system, and by splitting the processing logic of the request and providing a compensation mechanism, it can improve the efficiency of request processing and facilitate the backtracking of historical information.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a request processing method and device. Background Art

[0002] As the complexity of Internet business processes increases, the frequency of request processing continues to increase, and it is particularly important to improve the speed and performance of the overall business process. In the scenario where multiple interface callers call the business interface at the same time, it is necessary to ensure that the request processing frequency of different interface callers is balanced. The current solution for interface request processing is to limit the overall flow of the business interface and asynchronously process all received requests through the message queue.

[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art:

[0004] When receiving requests, it is impossible to ensure that the request frequencies of various interface callers are balanced. When processing requests, it is impossible to ensure that the requests of various interface callers are processed evenly, resulting in more resources consumed in processing requests, low efficiency in request processing, and affecting the stability of the system. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a request processing method and device, which can realize dynamic current limiting of each interface caller when receiving a request, and dynamically balance the current limiting according to the weight of each interface caller when processing the request, thereby reducing the resources consumed in processing the request and improving the stability of the system. By splitting the processing logic of the request and providing a compensation mechanism, the efficiency of request processing can be improved, and the backtracking of historical information is facilitated.

[0006] To achieve the above objective, according to one aspect of an embodiment of the present invention, a request processing method is provided.

[0007] A request processing method comprises: verifying the received request of the interface caller according to the current limiting rule of the interface caller, and saving the verified request to the message queue corresponding to the interface caller; obtaining the pending request from the message queue of each interface caller according to the weight value of each interface caller, and generating a pending request package; processing the pending request package to generate a request processing result.

[0008] Optionally, the method further includes: determining the maximum number of requests to be processed for each interface caller based on a preset maximum number of request processing threshold and a first weight value of each interface caller, before verifying the received request from the interface caller according to the current limiting rules of the interface caller and saving the verified request in a message queue corresponding to the interface caller.

[0009] Optionally, the received request from the interface caller is verified according to the current limiting rules of the interface caller, and the verified request is saved in the message queue corresponding to the interface caller, including: creating a current limiting key-value pair according to the identifier of the interface caller and the request time, so as to count the number of received requests within a preset time period corresponding to the request time; if the number of received requests is less than the maximum request processing number of the interface caller, the verification is passed, and the verified request is saved in the message queue corresponding to the interface caller, otherwise, the verification fails.

[0010] Optionally, the method of obtaining pending requests from the message queue of each interface caller according to the weight value of each interface caller and generating a pending request package includes: for each of the interface callers, determining the number of requests extracted from the interface caller according to the weight value of each interface caller; and obtaining pending requests from the cache queue of each interface caller according to the number of requests extracted from each interface caller, and generating the pending request package.

[0011] Optionally, determining the number of requests extracted from the interface caller based on the weight value of each interface caller includes: calculating the sum of the weight values ​​of all interface callers based on the second weight value of each interface caller; calculating the maximum number of requests extracted from the interface caller by using the maximum request processing number threshold, the weight value of the interface caller, and the sum of the weight values; obtaining the current number of requests in the cache queue corresponding to the interface caller, comparing the current number of requests with the maximum number of requests extracted, and taking the smaller value as the number of requests extracted from the interface caller.

[0012] Optionally, the processing of the pending request package to generate a request processing result includes: logically splitting the processing flow of each request in the pending request package according to the processing transaction type included in the request, obtaining no less than one sub-processing flow, and generating no less than one pending sub-request package; batch processing of each of the pending sub-request packages with the same transaction to generate a request processing result.

[0013] Optionally, the pending request package also includes a batch number, which is generated by a preset code and a generation time of the pending request package. The processing of the pending request package also includes: storing the basic information of the pending request and the batch number in a database in association with each other.

[0014] According to another aspect of an embodiment of the present invention, a request processing device is provided.

[0015] A request processing device includes: a request saving module, which is used to verify the requests received from the interface caller according to the current limiting rules of the interface caller, and save the verified requests in the message queue corresponding to the interface caller; a pending request packet generation module, which is used to obtain pending requests from the message queue of each interface caller according to the weight value of each interface caller and generate a pending request packet; a request processing module, which is used to process the pending request packet to generate a request processing result.

[0016] Optionally, it also includes a maximum request quantity determination module, which is used to determine the maximum request processing quantity of each interface caller based on a preset maximum request processing quantity threshold and a first weight value of each interface caller.

[0017] Optionally, the request saving module is also used to: create a current limiting key-value pair based on the identifier of the interface caller and the request time, so as to count the number of received requests within a preset time period corresponding to the request time; if the number of received requests is less than the maximum request processing number of the interface caller, the verification passes, and the verified requests are saved in the message queue corresponding to the interface caller, otherwise, the verification fails.

[0018] Optionally, the pending request packet generation module is also used to: for each of the interface callers, determine the number of requests extracted from the interface caller according to the weight value of each interface caller; based on the number of requests extracted from each interface caller, obtain pending requests from the cache queue of each interface caller to generate the pending request packet.

[0019] Optionally, the pending request packet generation module is also used to: calculate the sum of the weight values ​​of all interface callers based on the second weight value of each interface caller; calculate the maximum request extraction number of the interface caller through the maximum request processing number threshold, the weight value of the interface caller, and the sum of the weight values; obtain the current number of requests in the cache queue corresponding to the interface caller, compare the current number of requests with the maximum number of request extractions, and take the smaller value as the request extraction number of the interface caller.

[0020] Optionally, the request processing module is also used to: logically split the processing flow of each request in the pending request package according to the processing transaction type included in the request, obtain no less than one sub-processing flow, and generate no less than one pending sub-request package; perform batch transaction processing on each of the pending sub-request packages to generate a request processing result.

[0021] Optionally, the pending request package also includes a batch number, which is generated by a preset code and a generation time of the pending request package. The request processing module is further used to: associate the basic information of the pending request with the batch number and store them in a database.

[0022] According to yet another aspect of the embodiments of the present invention, an electronic device is provided.

[0023] An electronic device includes: one or more processors; a memory for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the request processing method provided by an embodiment of the present invention.

[0024] According to yet another aspect of an embodiment of the present invention, a computer readable medium is provided.

[0025] A computer-readable medium stores a computer program, which, when executed by a processor, implements a request processing method provided by an embodiment of the present invention.

[0026] An embodiment of the above invention has the following advantages or beneficial effects: by verifying the received request of the interface caller according to the current limiting rules of the interface caller, and saving the verified request in the message queue corresponding to the interface caller; obtaining the pending requests from the message queue of each interface caller according to the weight value of each interface caller, and generating a pending request package; processing the pending request package to generate a technical solution for request processing results, which can realize dynamic current limiting of each interface caller when receiving a request, and dynamically balance the current limiting according to the weight of each interface caller when processing the request, thereby reducing the resources consumed in processing the request and affecting the stability of the system. By splitting the request processing logic and providing a compensation mechanism, the efficiency of request processing can be improved, and it is convenient to trace back historical information.

[0027] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0029] Figure 1 is a schematic diagram of main steps of a request processing method according to an embodiment of the present invention;

[0030] Figure 2 is a schematic diagram of a process flow of a request packet to be processed according to an embodiment of the present invention;

[0031] Figure 3is a schematic diagram of a process flow of multi-threaded processing requests according to an embodiment of the present invention;

[0032] Figure 4 is a schematic diagram of a request processing flow according to an embodiment of the present invention;

[0033] Figure 5 is a schematic diagram of main modules of a request processing device according to an embodiment of the present invention;

[0034] Figure 6 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0035] Figure 7 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0036] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0037] Figure 1 It is a schematic diagram of main steps of a request processing method according to an embodiment of the present invention.

[0038] like Figure 1 As shown, a request processing method according to an embodiment of the present invention mainly includes the following steps S101 to S103.

[0039] Step S101: According to the current limiting rule of the interface caller, the received request of the interface caller is verified, and the verified request is saved in the message queue corresponding to the interface caller.

[0040] In one embodiment, according to the current limiting rules of the interface caller, the received request of the interface caller is verified, and before the verified request is saved in the message queue corresponding to the interface caller, it can also include: determining the maximum request processing number of each interface caller based on a preset maximum request processing number threshold and the first weight value of each interface caller.

[0041] Specifically, the first weight value may be determined according to the importance of each interface caller, the urgency of request processing, etc., and the calculation formula for the maximum number of request processing of the i-th interface caller may be:

[0042] E i =S*Wi / W 总

[0043] Among them, E i represents the maximum number of requests processed by the i-th interface caller, S represents the maximum number of requests processed by the interface, and W i represents the first weight value of the i-th interface caller, W 总 Represents the sum of the first weight values ​​of all interface callers.

[0044] The following describes in detail the request processing method of an embodiment of the present invention in a product release scenario based on the product release of each supplier as an example. In this embodiment, the interface caller takes each supplier as an example, and the request processing method is executed by the product release interface, for example.

[0045] Figure 2 It is a schematic diagram of a process of request packets to be processed according to an embodiment of the present invention.

[0046] like Figure 2 As shown, in one embodiment, according to the current limiting rules of the interface caller, the received request of the interface caller is verified, and the verified request is saved in the message queue corresponding to the interface caller, which may include: creating a current limiting key-value pair according to the interface caller's identifier and request time to count the number of received requests within a preset time period corresponding to the request time; if the number of received requests is less than the maximum request processing number of the interface caller, the verification is passed, and the verified request is saved in the message queue corresponding to the interface caller, otherwise, the verification fails.

[0047] Specifically, for each supplier (i.e., the interface caller), a cache sliding window is created through a current limiting key-value pair (i.e., a current limiter). The current limiting key-value pair may include a supplier ID and a request time, such as key = supplier ID_current second (i.e., request time), and value is the number of requests that the supplier stores in the message queue in the current second (i.e., the number of requests received). Each time a request is stored, the value will be incremented. At the same time, the validity period of the current limiting key-value pair can be set to 2 seconds. After 2 seconds, the current limiting key-value pair will become invalid to avoid the current limiting key-value pair from occupying too much storage space. Compare value with the maximum number of requests processed by the supplier. If value is less than the maximum number of requests processed by the interface caller, the verification is passed, and the verified request is saved in the message queue corresponding to the supplier. Otherwise, the verification fails, and an over-limit error is returned. Among them, each supplier (such as supplier A, supplier B, supplier C) has a corresponding current limiter (such as current limiter A, current limiter B, current limiter C).

[0048] Step S102: Obtain pending requests from the message queue of each interface caller according to the weight value of each interface caller, and generate a pending request package.

[0049] In one embodiment, pending requests are obtained from the message queue of each interface caller according to the weight value of each interface caller, and a pending request package is generated, which may include: for each interface caller, determining the number of requests to be extracted from the interface caller according to the weight value of each interface caller; according to the number of requests to be extracted from each interface caller, obtaining pending requests from the cache queue of each interface caller, and generating a pending request package.

[0050] In one embodiment, determining the number of requests extracted by an interface caller based on the weight value of each interface caller can include: calculating the sum of the weight values ​​of all interface callers based on the second weight value of each interface caller; calculating the maximum number of requests extracted by the interface caller through the maximum request processing number threshold, the weight value of the interface caller, and the sum of the weight values; obtaining the current number of requests in the cache queue corresponding to the interface caller, comparing the current number of requests with the maximum number of requests extracted, and taking the smaller value as the number of requests extracted by the interface caller.

[0051] Specifically, after the products of multiple suppliers are saved to each message queue, the product packages can be assembled for consumption according to the weight balancing algorithm. The weight balancing algorithm is determined based on the current system throughput (i.e., the maximum request processing number threshold) and the second weight value set by different suppliers. The system throughput is the maximum product delivery capacity of the system obtained after continuous indicator stress testing. The second weight value of the supplier can be set according to the importance of the supplier, the urgency of product release and other indicators. The higher the second weight value, the larger the product consumption pipeline of the supplier and the faster the product release speed. The formula for calculating the maximum number of requests extracted by the supplier can be:

[0052] F i =S*X i / X 总

[0053] Among them, F i represents the maximum number of requests extracted by the i-th interface caller (i.e., supplier), S represents the maximum number of requests processed by the interface, and X i represents the second weight value of the i-th interface caller, X 总Represents the sum of the second weight values ​​of all interface callers. For example, the maximum request processing threshold can be 10,000 per minute. There are currently 3 suppliers at the same time. The second weight value of supplier A is 5, the second weight value of supplier B is 2, and the second weight value of supplier C is 3. The sum of the second weight values ​​is 10, and the maximum number of requests extracted by supplier A is: 10,000*5 / 10=5,000. Get the current number of requests (i.e., the number of products) in the cache queue corresponding to supplier A. Assuming that the current number of requests is 4,000, which is less than the calculated maximum number of requests extracted, the number of requests extracted by supplier A is 4,000. Similarly, the number of requests extracted by supplier B and supplier C can be obtained. According to the number of requests extracted by each supplier, the pending requests (i.e., the products to be released) are obtained from each message queue to generate a request package (i.e., product package).

[0054] In one embodiment, the pending request package may further include a batch number, which may be generated by a preset code and the generation time of the pending request package. The preset code may indicate the type of request, such as a request for product release, and the generation time may be indicated by a timestamp.

[0055] Step S103: Process the request packet to be processed to generate a request processing result.

[0056] Figure 3 The figure is a flowchart of multi-threaded request processing according to an embodiment of the present invention.

[0057] like Figure 3 As shown, in one embodiment, processing the request package to be processed to generate the request processing result may include: logically splitting the processing flow of each request in the request package to be processed according to the type of processing transaction included in the request, obtaining no less than one sub-processing flow, and generating no less than one sub-request package to be processed; batch-processing each sub-request package to be processed to generate the request processing result. Processing the request package to be processed may also include: associating the basic information of the request to be processed with the batch number and storing it in a database. Among them, batch processing (batchInsert) is a database batch processing instruction. When encountering a large amount of data batch storage operation, it can be stored in the warehouse through network interaction at one time, avoiding multiple network interaction polling storage, and improving performance.

[0058] Specifically, two threads can be used to process the product package for product release. The basic information and batch number of the product to be released are stored in the database through the first thread. The basic information storage belongs to the non-core process. The role is to facilitate the backtracking of historical information when there is a problem with the core process or batch modification. The product collection can be located by the abnormal batch number. The product release process is performed on the product to be released through the second thread, and the product release process is logically split into multiple sub-processing processes, and multiple sub-request packages to be processed are generated. Each sub-request package to be processed is batch-processed with a transaction to generate a request processing result. Among them, the processing flow of database-related operations can be synthesized into a sub-processing process to generate a corresponding sub-MQ message (i.e., a sub-request package to be processed). The database-related operations may include inserting basic product information, inserting product price information, inserting product inventory information, inserting product supplier association information, and other operations. Other operations may include uploading pictures on the cloud, inserting and updating ES (a search and data analysis engine), and operating log records. In this way, short transaction operations of the database can be fully guaranteed. At the same time, some components on the cloud support batch processing, which is more convenient and improves product release efficiency.

[0059] Figure 4 It is a flowchart of request processing according to an embodiment of the present invention.

[0060] like Figure 4 As shown, in one embodiment, firstly, the unified product delivery interface of the supplier is dynamically limited, and the basic product delivery information of different suppliers is cached in the queue. Then, according to the weight balancing algorithm, different numbers of product sets are extracted from different queues for assembly, and the assembled product packages are sent through messages. Two threads are used to process the messages, one thread is responsible for batch saving basic product information into the warehouse, and the other thread processes the product package through the product release process. The processing flow is split, and one message thread is used to process the same transaction warehousing operation, and other message threads are used for other long-term operations. This can not only ensure the balance of product delivery, but also greatly improve the speed of product delivery.

[0061] The embodiment of the present invention utilizes a time window current limiting strategy to ensure that different interface callers can configure different traffic flows as needed, and at the same time, uses a cache message queue to buffer basic data, generates product packages in segments, and asynchronously saves basic data in batches through MQ to reduce database pressure, thereby ensuring the original request data of the interface caller at the fastest speed. At the same time, a weight balancing algorithm is used to capture cache queue data of different interface callers according to the strategy to perform subsequent operations on complex processes. If an exception occurs in the cache, the data segment can be traced back from the database for retries. Complex processes are decomposed using MQ, and operations that need to be written to the library are uniformly batched using transactions. At the same time, time-consuming network calls are executed asynchronously. The embodiment of the present invention can ensure balanced operations between multiple interface callers while improving the processing performance of complex processes.

[0062] Figure 5 It is a schematic diagram of main modules of a request processing device according to an embodiment of the present invention.

[0063] like Figure 5 As shown, a request processing device 500 according to an embodiment of the present invention mainly includes: a request storage module 501 , a request packet generation module 502 to be processed, and a request processing module 503 .

[0064] The request saving module 501 is used to verify the received request of the interface caller according to the current limiting rule of the interface caller, and save the verified request into the message queue corresponding to the interface caller.

[0065] The pending request packet generating module 502 is used to obtain pending requests from the message queue of each interface caller according to the weight value of each interface caller, and generate a pending request packet.

[0066] The request processing module 503 is used to process the request packet to be processed to generate a request processing result.

[0067] In one embodiment, a maximum request quantity determination module (not shown in the figure) may also be included, which is used to determine the maximum request processing quantity of each interface caller based on a preset maximum request processing quantity threshold and a first weight value of each interface caller.

[0068] In one embodiment, the request saving module 501 is specifically used to: create a current limiting key-value pair based on the identifier of the interface caller and the request time to count the number of received requests within a preset time period corresponding to the request time; if the number of received requests is less than the maximum request processing number of the interface caller, the verification is successful, and the verified request is saved in the message queue corresponding to the interface caller, otherwise, the verification fails.

[0069] In one embodiment, the pending request packet generation module 502 is specifically used to: for each interface caller, determine the number of requests extracted from the interface caller according to the weight value of each interface caller; according to the number of requests extracted from each interface caller, obtain the pending requests from the cache queue of each interface caller to generate a pending request packet.

[0070] In one embodiment, the pending request packet generation module 502 is specifically used to: calculate the sum of the weight values ​​of all interface callers based on the second weight value of each interface caller; calculate the maximum request extraction number of the interface caller through the maximum request processing number threshold, the weight value of the interface caller, and the sum of the weight values; obtain the current number of requests in the cache queue corresponding to the interface caller, compare the current number of requests with the maximum number of request extractions, and use the smaller value as the request extraction number of the interface caller.

[0071] In one embodiment, the request processing module 503 is specifically used to: logically split the processing flow of each request in the request package to be processed according to the processing transaction type included in the request, obtain no less than one sub-processing flow, and generate no less than one sub-request package to be processed; batch process each sub-request package to be processed with the same transaction to generate a request processing result.

[0072] In one embodiment, the request package to be processed may also include a batch number, which may be generated by a preset code and the generation time of the request package to be processed. The request processing module 503 is specifically used to associate the basic information of the request to be processed with the batch number and store it in a database.

[0073] In addition, the specific implementation content of the request processing device in the embodiment of the present invention has been described in detail in the above request processing method, so the repeated content will not be described again here.

[0074] Figure 6 An exemplary system architecture 600 is shown to which the request processing method or request processing apparatus according to the embodiment of the present invention can be applied.

[0075] like Figure 6 As shown, system architecture 600 may include terminal devices 601, 602, 603, network 604 and server 605. Network 604 is used to provide a medium for communication links between terminal devices 601, 602, 603 and server 605. Network 604 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0076] Users can use terminal devices 601, 602, and 603 to interact with server 605 through network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

[0077] The terminal devices 601 , 602 , and 603 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers, etc.

[0078] The server 605 may be a server that provides various services, such as a background management server (only an example) that supports shopping websites browsed by users using terminal devices 601, 602, and 603. The background management server may process the received request processing request and other data according to the flow limiting rules of the interface caller, verify the received request of the interface caller, and save the verified request to the message queue corresponding to the interface caller; obtain the pending request from the message queue of each interface caller according to the weight value of each interface caller, and generate a pending request package; process the pending request package to generate a request processing result, etc., and feed back the processing result (such as the request processing result - only an example) to the terminal device.

[0079] It should be noted that the request processing method provided in the embodiment of the present invention is generally executed by the server 605 , and accordingly, the request processing device is generally set in the server 605 .

[0080] It should be understood that Figure 6 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0081] Reference below Figure 7 , which shows a schematic diagram of the structure of a computer system 700 of a terminal device or a server suitable for implementing an embodiment of the present invention. Figure 7 The terminal device or server shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0082] like Figure 7As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage part 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the system 700 are also stored. The CPU 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0083] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed, so that a computer program read therefrom is installed into the storage section 708 as needed.

[0084] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit (CPU) 701, the above-mentioned functions defined in the system of the present invention are executed.

[0085] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0086] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0087] The modules involved in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be set in a processor. For example, they may be described as: a processor includes a request saving module, a request packet generation module to be processed, and a request processing module. The names of these modules do not constitute a limitation on the module itself in some cases. For example, the request saving module may also be described as "a module for verifying the received request of the interface caller according to the current limiting rules of the interface caller, and saving the verified request to the message queue corresponding to the interface caller".

[0088] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs. When the above one or more programs are executed by a device, the device includes: verifying the received request of the interface caller according to the current limiting rules of the interface caller, and saving the verified request to the message queue corresponding to the interface caller; obtaining the pending request from the message queue of each interface caller according to the weight value of each interface caller, and generating a pending request packet; processing the pending request packet to generate a request processing result.

[0089] According to the technical solution of the embodiment of the present invention, the received request of the interface caller is verified according to the current limiting rules of the interface caller, and the verified request is saved in the message queue corresponding to the interface caller; the pending request is obtained from the message queue of each interface caller according to the weight value of each interface caller, and a pending request package is generated; the pending request package is processed to generate a request processing result. It is possible to implement dynamic current limiting of each interface caller when receiving a request, and dynamically balance the current limiting according to the weight of each interface caller when processing a request, thereby reducing the resources consumed in processing requests and affecting the stability of the system. By splitting the processing logic of the request and providing a compensation mechanism, the efficiency of request processing can be improved, and it is convenient to trace back historical information.

[0090] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A request processing method, characterized in that: include: Determine the maximum number of requests to be processed by each interface caller based on a preset maximum number of request processing thresholds and a first weight value of each interface caller; According to the current limiting rules of the interface caller, the received request of the interface caller is verified, and the request that passes the verification is saved in the message queue corresponding to the interface caller, including: creating a current limiting key-value pair according to the identifier of the interface caller and the request time to count the number of received requests within a preset time period corresponding to the request time; if the number of received requests is less than the maximum request processing number of the interface caller, the verification is passed, and the request that passes the verification is saved in the message queue corresponding to the interface caller, otherwise, the verification fails; Obtain pending requests from the message queue of each interface caller according to the weight value of each interface caller, and generate a pending request package; The request packet to be processed is processed to generate a request processing result.

2. The method according to claim 1, characterized in that The method of obtaining the pending requests from the message queue of each interface caller according to the weight value of each interface caller and generating a pending request package includes: For each of the interface callers, determining the number of requests to be extracted from the interface caller according to the weight value of each interface caller; According to the number of requests extracted from each of the interface callers, the pending requests are obtained from the cache queue of each of the interface callers to generate the pending request package.

3. The method according to claim 2, characterized in that The step of determining the number of requests to be extracted from the interface caller according to the weight value of each interface caller includes: Calculate the sum of the weight values ​​of all interface callers according to the weight value of each interface caller; Calculate the maximum number of requests extracted by the interface caller through the maximum request processing number threshold, the weight value of the interface caller, and the sum of the weight values; The current number of requests in the cache queue corresponding to the interface caller is obtained, the current number of requests is compared with the maximum number of requests to be extracted, and the smaller value is used as the number of requests to be extracted of the interface caller.

4. The method according to claim 1, characterized in that The processing of the request packet to be processed to generate a request processing result includes: According to the type of processing transactions included in the request, the processing flow of each request in the request package to be processed is logically split to obtain no less than one sub-processing flow, and no less than one sub-request package to be processed is generated; Batch transaction processing is performed on each of the to-be-processed sub-request packets to generate a request processing result.

5. The method according to claim 4, characterized in that The request package to be processed also includes a batch number, and the batch number is generated by a preset code and a generation time of the request package to be processed. The processing of the request package to be processed also includes: The basic information of the pending request and the batch number are associated and stored in a database.

6. A request processing device, characterized in that: include: A maximum request quantity determination module, used to determine the maximum request processing quantity of each interface caller based on a preset maximum request processing quantity threshold and a first weight value of each interface caller; A request saving module, used to verify the received request of the interface caller according to the current limiting rule of the interface caller, and save the verified request to the message queue corresponding to the interface caller, including: creating a current limiting key-value pair according to the identifier of the interface caller and the request time, so as to count the number of received requests within a preset time period corresponding to the request time; if the number of received requests is less than the maximum request processing number of the interface caller, the verification is passed, and the verified request is saved to the message queue corresponding to the interface caller, otherwise, the verification fails; A pending request packet generation module is used to obtain pending requests from the message queue of each interface caller according to the weight value of each interface caller and generate a pending request packet; The request processing module is used to process the request packet to be processed to generate a request processing result.

7. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 5.

8. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images