Request method and device, electronic equipment and readable storage medium

Abstract

The invention provides a request method and device, electronic equipment and a readable storage medium, the method is applied to a transfer service node, and the method comprises the following steps: obtaining a plurality of request data sent by an intelligent outbound system within a preset time period; judging whether the number of the multiple pieces of request data exceeds a preset number or not, wherein the preset number is the maximum number of request data which can be processed by a downstream system at the same time; and if yes, sending the request data which does not exceed the preset quantity in the multiple pieces of request data to the downstream system, and storing the request data which exceeds the preset quantity in the multiple pieces of request data in a queue, so as to send the request data which does not exceed the preset quantity in the queue to the downstream system after the downstream system processes the request data. The request data exceeding the concurrent processing capacity of the downstream system can be firstly stored in the queue, so that the downstream system can be prevented from directly rejecting the request data exceeding the concurrent processing capacity of the downstream system, and the request efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a request method, device, electronic device, and readable storage medium. Background Art

[0002] In the field of intelligent outbound calls, it is necessary to call the downstream location query service to query the location of the outbound mobile phone number, so as to make more efficient calls.

[0003] At present, the intelligent outbound call system is pre-connected with multiple downstream systems such as the location query system and the encryption and decryption system. When the intelligent outbound call system has a certain demand, the intelligent outbound call system will generate request data corresponding to the demand, and then send the request data to the corresponding downstream system. After receiving the request data, the downstream system generates response data based on the request data and feeds the response data back to the intelligent outbound call system. Based on the response data, the intelligent outbound call system performs more efficient outbound call operations.

[0004] However, the intelligent outbound call system generally adopts distributed deployment, and each node may generate request data at the same time. Moreover, as the business volume continues to grow, the number of nodes continues to increase, and the number of request data generated by each node at the same time is also increasing. This causes the downstream system to receive a large amount of request data at the same time. The number of request data that the downstream system can process concurrently is limited. If the number of request data received by the downstream system at the same time exceeds the concurrent number, the request data exceeding the concurrent number will be rejected by the downstream system, and the corresponding node request will fail. The corresponding node can only generate and send request data to the downstream system again. This will reduce the efficiency of requests and outbound calls. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a request method, device, electronic device and readable storage medium to improve the efficiency of requests and outbound calls.

[0006] In order to solve the above technical problems, the embodiments of the present application provide the following technical solutions:

[0007] The first aspect of the present application provides a request method, which is applied to a transit service node, the transit service node is connected to an intelligent outbound call system, and is used to intercept request data issued by the intelligent outbound call system. The transit service node is also connected to a downstream system of the intelligent outbound call system, and is used to send the request data to the downstream system. The method includes: obtaining multiple request data issued by the intelligent outbound call system within a preset time period; determining whether the number of multiple request data exceeds a preset number, the preset number being the maximum number of request data that the downstream system can process simultaneously; if so, sending the request data that does not exceed the preset number among the multiple request data to the downstream system, and storing the request data that exceeds the preset number among the multiple request data in a queue, so that after the downstream system has processed the request data, the request data that does not exceed the preset number in the queue is sent to the downstream system.

[0008] Compared with the prior art, the request method provided in the first aspect of the present application configures a transit service node between the intelligent outbound call system and the downstream system. Through the transit service node, the request data issued by the intelligent outbound call system is forwarded to the downstream system to realize the sending control of the request data. In this way, the request data that exceeds the concurrent processing capacity of the downstream system can be stored in the queue first, and after the downstream system can continue to process the request data, the request data in the queue will be sent to the downstream system for processing. It can avoid the downstream system directly rejecting the request data that exceeds its concurrent processing capacity, and thus avoid the intelligent outbound call system from regenerating and reissuing the rejected request data. The request data in the queue can be sent directly to the downstream system, thereby improving the efficiency of requests and outbound calls.

[0009] In some changed implementation modes of the first aspect of the present application, the intelligent outbound call system includes multiple intelligent outbound call nodes, each intelligent outbound call node sends request data within a preset time period, and the number of transit service nodes is multiple; before obtaining the multiple request data sent by the intelligent outbound call system within the preset time period, the method also includes: the target transit service node generates a correspondence between the multiple intelligent outbound call nodes and the multiple transit service nodes, and sends the correspondence to other transit service nodes, wherein the target transit service node is one of the multiple transit service nodes, and the other transit service nodes are nodes among the multiple transit service nodes except the target transit service node; obtaining the multiple request data sent by the intelligent outbound call system within the preset time period includes: each transit service node determines its corresponding intelligent outbound call node from the correspondence; each transit service node obtains the request data sent by its corresponding intelligent outbound call node within the preset time period.

[0010] When both the intelligent outbound call system and the transit service node include multiple nodes, before obtaining the request data from the intelligent outbound call system, it is necessary to generate a correspondence between each intelligent outbound call node and the corresponding transit service node based on the consideration of the request data sending efficiency, so that each transit service node obtains the request data from its corresponding intelligent outbound call node, ensuring that the request data can be efficiently transmitted from the intelligent outbound call node to the transit service node, and then from the transit service node to the downstream system, thereby improving the transmission efficiency of the request data.

[0011] In some modified implementations of the first aspect of the present application, the target transit service node generates a correspondence between multiple intelligent outbound call nodes and multiple transit service nodes, including: the target transit service node generates preset data, and sends the preset data to other transit service nodes, so that the target transit service node and other transit service nodes send the preset data to each intelligent outbound call node, so that each intelligent outbound call node sends feedback information to the corresponding transit service node based on the received preset data; the target transit service node determines the time consumed for transmitting data between each intelligent outbound call node and the target transit service node according to the time of sending the preset data and the time of receiving the feedback information; the target transit service node obtains the time consumed for transmitting data between each intelligent outbound call node and other transit service nodes from other transit service nodes, the time consumed in other transit service nodes is generated by other transit service nodes based on the time of sending the preset data and the time of receiving the feedback information, the target transit service node determines the number of requested data in its current queue, and obtains the number of requested data in the current queue of other transit service nodes; the target transit service node generates a correspondence between multiple intelligent outbound call nodes and multiple transit service nodes based on the obtained time consumed and number.

[0012] Since the time consumption and quantity can simply and comprehensively characterize the efficiency of transmitting the request data from the intelligent outbound call node to the transit service node, and then from the transit service node to the downstream system, based on the time consumption of transmitting the preset data between the intelligent outbound call node and the transit service node, and the number of request data in the current queue of the transit service node, a corresponding relationship can be generated efficiently and accurately, thereby improving the efficiency and accuracy of the corresponding relationship generation.

[0013] In some changed implementation modes of the first aspect of the present application, after each transit service node obtains the request data issued by the intelligent outbound call node corresponding to itself within a preset time period, the method also includes: each transit service node determines a first quantity of request data issued by the intelligent outbound call node corresponding to itself within a preset time period; each transit service node determines a second quantity of request data in its current queue; if the first transit service node determines that the sum of the first quantity and the second quantity corresponding to itself exceeds the preset quantity, the request data exceeding the preset quantity is sent to the second transit service node, and the second transit service node is a node that determines that the sum of the first quantity and the second quantity corresponding to itself does not exceed the preset quantity.

[0014] After each transit service node obtains the request data, if the number of request data is large, that is, the request data in the queue cannot be sent out at once, then the excess request data can be dispersed to the transit service nodes with smaller number of request data in other queues to ensure that the request data can be sent out in full next time, so that the request data can be sent to the downstream system as soon as possible, thereby improving the request efficiency.

[0015] In some changed implementation modes of the first aspect of the present application, before determining whether the number of multiple request data exceeds a preset number, the method also includes: obtaining the real-time number of request data that the downstream system can currently process; adjusting the preset number to the real-time number; determining whether the number of multiple request data exceeds the preset number, including: determining whether the number of multiple request data exceeds the real-time number.

[0016] Since the downstream system will also process request data sent by other businesses or other transit service nodes during operation, the number of request data that the downstream system can currently process is obtained in real time and updated in the transit service node to ensure that the request data sent by the transit service node to the downstream system can be processed smoothly, avoiding the rejection of request data due to excessive sending, and further improving request efficiency.

[0017] In some changed implementation modes of the first aspect of the present application, before obtaining the real-time number of request data that the downstream system can currently process, the method also includes: determining whether the number of multiple request data exceeds the burst number, the burst number being greater than a preset multiple of a preset number; if so, sending a capacity expansion request to the downstream system to increase the concurrent processing capacity of the request data by the downstream system; if not, obtaining the real-time number of request data that the downstream system can currently process.

[0018] When the number of request data in the transit service node is large, that is, when burst traffic occurs in the intelligent outbound call node, the transit service node sends an expansion request to the downstream system, so that the downstream system provides more resources to process a large amount of request data, thereby avoiding the accumulation of a large amount of sudden request data in the transit service node, improving the operating efficiency of the transit service node, and improving the efficiency of processing a large amount of sudden request data.

[0019] In some changed implementation modes of the first aspect of the present application, the transit service node includes a thread pool, the number of threads in the thread pool is the same as a preset number, and each thread can send a request data to a downstream system after being called; judging whether the number of multiple request data exceeds the preset number includes: calling a thread in the thread pool for multiple request data; if there is request data for which the thread is not called, determining that the number of multiple request data exceeds the preset number; if there is no request data for which the thread is not called, determining that the number of multiple request data does not exceed the preset number.

[0020] The calling status of threads in the thread pool is used to determine whether the current number of request data exceeds the concurrent processing capacity of the downstream system. Since there is no thread to call the request data that exceeds the concurrent processing capacity, the sending of these request data to the downstream system can be restricted. Compared with the token bucket algorithm, which requires continuous generation of new tokens, the statistics and sending control of thread calls are simpler and more convenient, and can improve the efficiency of request data sending control.

[0021] The second aspect of the present application provides a request device, which is applied to a transit service node. The transit service node is connected to an intelligent outbound call system and is used to intercept request data issued by the intelligent outbound call system. The transit service node is also connected to a downstream system of the intelligent outbound call system and is used to send the request data to the downstream system. The device includes: an acquisition module, which is used to acquire multiple request data issued by the intelligent outbound call system within a preset time period; a judgment module, which is used to judge whether the number of multiple request data exceeds a preset number, and the preset number is the maximum number of request data that the downstream system can process simultaneously; if so, entering the sending module; the sending module is used to send the request data that does not exceed the preset number among the multiple request data to the downstream system, and store the request data that exceeds the preset number among the multiple request data in a queue, so that after the downstream system has processed the request data, the request data that does not exceed the preset number in the queue can be sent to the downstream system.

[0022] The third aspect of the present application provides an electronic device, which includes: a processor, a memory, and a bus; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the method in the first aspect.

[0023] A fourth aspect of the present application provides a computer-readable storage medium, which includes: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the method in the first aspect.

[0024] The request device provided in the second aspect, the electronic device provided in the third aspect, and the computer-readable storage medium provided in the fourth aspect of the present application have the same or similar beneficial effects as the request method provided in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] By reading the detailed description below with reference to the accompanying drawings, the above and other purposes, features and advantages of the exemplary embodiments of the present application will become easy to understand. In the accompanying drawings, several embodiments of the present application are shown in an exemplary and non-limiting manner, and the same or corresponding reference numerals represent the same or corresponding parts, wherein:

[0026] Figure 1 The application scenario of the request method in the embodiment of the present application is shown as follows: Figure 1 ;

[0027] Figure 2 The process diagram of the request method in the embodiment of the present application is as follows: Figure 1 ;

[0028] Figure 3 The application scenario of the request method in the embodiment of the present application is shown as follows: Figure 2 ;

[0029] Figure 4 The process diagram of the request method in the embodiment of the present application is as follows: Figure 2 ;

[0030] Figure 5 The structure of the request device in the embodiment of the present application is shown in FIG. Figure 1 ;

[0031] Figure 6 The structure of the request device in the embodiment of the present application is shown in FIG. Figure 2 ;

[0032] Figure 7 Schematic diagram of the structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0033] The exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0034] It should be noted that, unless otherwise specified, the technical terms or scientific terms used in this application should have the common meanings understood by technicians in the field to which this application belongs.

[0035] At present, the intelligent outbound call system sends request data to the downstream system. Once the number of request data sent exceeds the concurrent processing capacity of the downstream system, the request data exceeding the concurrent processing capacity will be rejected by the downstream system. The intelligent outbound call system needs to generate new request data for the rejected request data, and then send the newly generated request data to the downstream system again. The repeated generation and sending of request data will reduce the efficiency of requests and outbound calls.

[0036] Although a counter or current limiting window can be configured between the intelligent outbound call system and the downstream system, if the number of request data sent by the intelligent outbound call system exceeds the number limit of the counter or current limiting window, the request data exceeding the number will not reach the downstream system and will be rejected by the downstream system, but will be rejected by the counter or current limiting window. The intelligent outbound call system still needs to generate new request data for the rejected request data, and then send the newly generated request data to the downstream system through the counter or current limiting window again. The request data will still be repeatedly generated and sent, and the request efficiency is low.

[0037] In view of this, an embodiment of the present application provides a request method, an apparatus, an electronic device, and a readable storage medium, and a transit service node is configured between the intelligent outbound call system and the downstream system. In the transit service node, a queue is configured. The request data generated by the intelligent outbound call system is first sent to the transit service node. The transit service node controls the number of request data sent to the downstream system according to the maximum concurrent processing capacity of the downstream system to process the request data, and controls the number of requests sent each time not to exceed the maximum concurrent processing capacity. The remaining request data is first temporarily stored in the queue, waiting to be sent to the downstream system next time. In this way, the request data that exceeds the maximum concurrent processing capacity of the downstream system will not be rejected, and the intelligent outbound call system does not need to regenerate these request data, nor does it need to reissue these request data, which can improve the efficiency of requests and outbound calls.

[0038] First, the application scenario of the request method provided in the embodiment of the present application is described.

[0039] Figure 1 The application scenario of the request method in the embodiment of the present application is shown as follows: Figure 1 , see Figure 1 As shown, the scenario may include: an intelligent outbound call system 11, a transit service node 12 and a downstream system 13.

[0040] The intelligent outbound call system 11, the transit service node 12 and the downstream system 13 can communicate with each other. In one example, the intelligent outbound call system 11, the transit service node 12 and the downstream system 13 are connected in sequence.

[0041] The intelligent outbound calling system 11 is used to make outbound calls through telephone numbers. The telephone numbers used for the calls are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions. The purpose of the call can be to remind the corresponding events according to the actual needs of the user or the relevant party.

[0042] The transit service node 12 is used to intercept the request data sent by the intelligent outbound call system 11 and send the request data to the downstream system 13. The transit service node 12 intercepts the request data sent by the intelligent outbound call system 11 and sends the request data to the downstream system 13, both of which are performed when the intelligent outbound call system 11 and the downstream system 13 have been authorized.

[0043] In the transfer service node 12, a preset number is configured to limit the number of request data sent to the downstream system 13 at one time. For example, if the preset number is 20, the intelligent outbound call system 11 in the transfer service node 12 obtains 100 request data, and the transfer service node 12 can only send 20 request data to the downstream system 13 at one time, and the 100 request data are sent to the downstream system 13 in 5 times.

[0044] The downstream system 13 is used to process the request data. Different downstream systems 13 have different corresponding specific functions and can process different request data. For example: for a telephone number location query request, it is necessary to send it to the location query system through the transit service node 12 to query the number location. Another example: for a decryption request for encrypted data, it is necessary to send it to the encryption and decryption system through the transit service node 12 to decrypt the encrypted data. Therefore, the different request data generated by the intelligent outbound call system 11 needs to be sent to the corresponding downstream system 13 by the transit service node 12 according to the different requirements or types of the request data.

[0045] The downstream system 13 processes the request data to obtain response data, and then sends the response data to the transit service node 12, so as to be sent to the intelligent outbound call system 11 through the transit service node 12. Alternatively, the downstream system 13 directly sends the response data to the intelligent outbound call system 11 to improve the efficiency of the intelligent outbound call system 11 in receiving the response data.

[0046] After receiving the response data, the intelligent outbound call system 11 can perform a more efficient outbound call operation based on the response data. For example, after the intelligent outbound call system 11 obtains the number's location, it can provide a more accurate reminder to the number holder based on the number's location.

[0047] Next, the request method provided in the embodiment of the present application is described in detail.

[0048] Figure 2 The process diagram of the request method in the embodiment of the present application is as follows: Figure 1 , see Figure 2 As shown, the method may at least include S21-S24.

[0049] S21: Acquire multiple request data sent by the intelligent outbound call system within a preset time period.

[0050] Since the intelligent outbound call system adopts distributed deployment and as the business volume increases, the intelligent outbound call system will continuously generate request data. For the transit service node, it can continuously obtain the request data sent by the intelligent outbound call system.

[0051] The transit service node needs to make a judgment based on the number of request data obtained later, and a time window is required for the number of request data obtained. This time window can be called a preset period.

[0052] In actual applications, the preset time period can be 0.1s, 1s, 5s, etc. The specific duration of the preset time period is not limited here. It can be determined specifically according to the total business volume of the intelligent outbound call system. The preset time period is inversely proportional to the total business volume. In one embodiment, the preset time period is dynamically set according to the change in the size of the total business volume. When the total business volume increases, the preset time period can be shortened, so that request data can be obtained from the intelligent outbound call system at a high frequency, avoiding the accumulation of request data in the intelligent outbound call system, and improving the operating efficiency of the intelligent outbound call system. When the total business volume decreases, the preset time period can be extended, which can reduce the frequency of obtaining request data from the intelligent outbound call system and improve the operating efficiency of the transit service node.

[0053] S22: Determine whether the number of the plurality of request data exceeds the preset number. If yes, execute S23; if no, execute S24.

[0054] After obtaining the request data sent by the intelligent outbound call system within the preset time period, the number of request data obtained can be counted. In the quantity statistics, the content originally carried by the request data, such as telephone number, requester ID, recipient ID, etc., can be counted based on the number of corresponding contents. It is also possible to negotiate with the intelligent outbound call system in advance so that each time the intelligent outbound call system generates a request data, a sequence number is added to the request data and carried. The transit service node can determine the number of request data obtained by counting the number of sequence numbers.

[0055] The preset number is the maximum number of request data that the downstream system can process simultaneously. If the number of request data processed by the downstream system at the same time exceeds the preset number, the downstream system may become stuck or crash. Therefore, when configuring the downstream system, a maximum concurrent number is generally configured.

[0056] The preset quantity can be pre-configured in the transit service node. The preset quantity can be automatically determined according to the configuration information of the downstream system to improve the configuration efficiency of the preset quantity, or it can be actively provided by the administrator of the downstream system to improve the accuracy of the preset quantity configuration.

[0057] Compare the number of request data with the preset number. If the number of request data exceeds the preset number, it means that the downstream system cannot process the batch of request data obtained by the transit service node normally at one time and needs to send it in batches. If the number of request data does not exceed the preset number, it means that the downstream system can process this batch of request data normally at one time, and the transit service node can send this batch of request data to the downstream system at one time.

[0058] S23: Sending request data that does not exceed a preset number among multiple request data to a downstream system, and storing request data that exceeds a preset number among multiple request data in a queue, so that after the downstream system processes the request data, the request data that does not exceed the preset number in the queue is sent to the downstream system.

[0059] That is, when the amount of acquired request data exceeds the normal carrying capacity of the downstream system, the request data is sent to the downstream system in batches.

[0060] For example, assuming the preset number is 20, and 100 request data are currently obtained. First, request data 1-20 of the 100 request data are sent to the downstream system, and request data 21-100 are first stored in the queue. After the downstream system has processed them, request data 21-40 are sent to the downstream system, and the cycle is repeated until all request data in the queue are sent to the downstream system.

[0061] In determining whether the downstream system has completed the processing, the downstream system can send an indication signal to the transit service node after processing all the request data it has received. After receiving the indication signal, the transit service node can send the next batch of request data to the downstream system. The downstream system can also send a completion indication to the transit service node immediately after processing a request data. After receiving the completion indication, the transit service node sends the next request data to the downstream system. Of course, the transit service node can also monitor the downstream system in real time. When it monitors that the operating parameters of the downstream system have changed significantly, for example: the CPU occupancy rate is reduced by a preset rate value, the memory occupancy rate is reduced by a preset rate value, etc., it can also be determined that the downstream system has processed the current request data and can continue to send the next batch of request data to the downstream system.

[0062] Since the intelligent outbound call system is continuously running, it will send out request data at different time periods. After the transit service node receives multiple request data of the next time period, it will still determine that the number of these multiple request data exceeds the preset number. If it exceeds, the request data that does not exceed the preset number among these multiple request data will be sent to the downstream system, and the request data that exceeds the preset number will continue to be stored in the queue. At this point, the queue has stored request data that exceeds the preset number in two time periods. When the number of request data sent by the intelligent outbound call system in a certain time period is less than the preset number, or no request data is sent, the request data stored in the queue can be sent to the downstream system under the limit that the sending volume does not exceed the preset number.

[0063] For example, assuming that the preset number is 40, the transit service node receives request data No. 1-100 sent by the intelligent outbound call system in the first second. At this time, the request data No. 1-40 is directly sent to the downstream system, and the request data No. 41-100 is stored in the queue. The transit service node receives request data No. 101-200 sent by the intelligent outbound call system in the second second. At this time, the request data No. 101-140 is directly sent to the downstream system, and the request data No. 141-200 is stored in the queue. The transit service node receives request data No. 201-210 sent by the intelligent outbound call system in the third second. At this time, the request data No. 201-210 and No. 41-70 in the queue are sent to the downstream system. And so on, until all the request data in the queue are sent to the downstream system.

[0064] S24: Send multiple request data to the downstream system.

[0065] That is, when the amount of acquired request data does not exceed the normal carrying capacity of the downstream system, all of the request data are sent to the downstream system at once, and the downstream system can also process normally. At this time, all of the request data can be sent to the downstream system.

[0066] It can be seen from the above content that the request method provided in the embodiment of the present application configures a transit service node between the intelligent outbound call system and the downstream system. Through the transit service node, the request data issued by the intelligent outbound call system is forwarded to the downstream system to realize the sending control of the request data. In this way, the request data that exceeds the concurrent processing capacity of the downstream system can be stored in the queue first, and after the downstream system can continue to process the request data, the request data in the queue will be sent to the downstream system for processing. It can avoid the downstream system directly rejecting the request data that exceeds its concurrent processing capacity, and thus avoid the intelligent outbound call system from regenerating and reissuing the rejected request data. The request data in the queue can be sent directly to the downstream system, thereby improving the efficiency of requests and outbound calls.

[0067] Furthermore, as a Figure 2 As a refinement and extension of the method shown, the embodiment of the present application also provides a request method.

[0068] Figure 3 The application scenario of the request method in the embodiment of the present application is shown as follows: Figure 2 , see Figure 3 As shown, the scenario may include: an intelligent outbound call system 11, a transit service node 12 and a downstream system 13.

[0069] The intelligent outbound call system 11 includes a plurality of intelligent outbound call nodes 111. Each intelligent outbound call node 111 sends request data within a preset time period. The number of the transfer service nodes 12 is multiple.

[0070] It should be noted that the types of the intelligent outbound call nodes 111 can be the same or different. For example, the intelligent outbound call nodes 111 can be one or more web-based intelligent outbound call services (web-services), interface-based intelligent outbound call services (api-services), and enterprise-based intelligent outbound call services (op-services).

[0071] The request data of each intelligent outbound call node 111 needs to be sent to the corresponding transit service node 12 to ensure that the request data can be sent to the transit service node 12 faster, and then sent to the downstream system 13 faster, thereby improving the transmission efficiency of the request data. Therefore, between multiple intelligent outbound call nodes 111 and multiple transit service nodes 12, according to the actual transmission situation and the need for efficient transmission, a corresponding relationship between each intelligent outbound call node 111 and its corresponding transit service node 12 is established in advance.

[0072] The number of the intelligent outbound call nodes 111 and the transit service nodes 12 may be the same or different, and needs to be determined according to the actual situation of the intelligent outbound call nodes 111 and the transit service nodes 12.

[0073] Furthermore, in the transit service node 12, a thread pool 121 is configured. The number of threads in the thread pool 121 is the same as the preset number. After a thread in the thread pool 121 is called, the number of threads in the thread pool 121 will decrease. After the thread is used up, it will return to the thread pool 121 to wait for the next call. After each thread is called, it can send a request data to the downstream system 13. In this way, by calling the thread in the thread pool 121, it is possible to simply and conveniently implement the control of sending the request data to the downstream system 13.

[0074] Figure 4 The process diagram of the request method in the embodiment of the present application is as follows: Figure 2 , see Figure 4 As shown, the method may at least include S41-S48.

[0075] S41: The target transit service node generates a correspondence relationship between a plurality of intelligent outbound call nodes and a plurality of transit service nodes, and sends the correspondence relationship to other transit service nodes.

[0076] The target transit service node is one of the multiple transit service nodes, and the other transit service nodes are nodes other than the target transit service node among the multiple transit service nodes.

[0077] Generally speaking, each intelligent outbound call node can send request data to any transit service node. However, for a certain intelligent outbound call node, when sending request data to different transit service nodes, the time when the request data is sent to the downstream system may vary. In order to be able to send the request data to the downstream system as soon as possible, it is necessary to select from multiple transit service nodes. To this end, before the intelligent outbound call node sends the request data to the transit service node, the corresponding relationship between each intelligent outbound call node and the transit service node is established in advance.

[0078] When establishing a corresponding relationship, a transit service node among multiple transit service nodes, namely the target transit service node, can establish the corresponding relationship. And other transit service nodes among multiple transit service nodes except the target transit service node can receive the corresponding relationship sent by the target transit service node. In this way, it can ensure that the corresponding relationships stored in multiple transit service nodes are consistent, and ensure that the request data of each intelligent outbound call node is transmitted in an orderly manner. In addition, when establishing a corresponding relationship, it is also necessary to follow the principle of being able to send the request data sent by multiple intelligent outbound call nodes to the downstream system in the shortest time.

[0079] The target transit service node here can be any transit service node among multiple transit service nodes, or a transit service node with the highest processing efficiency among multiple transit service nodes, so as to improve the efficiency of generating the corresponding relationship. The specific transit service node for generating the corresponding relationship is not limited here.

[0080] Specifically, the above step S41 may at least include steps A1 to A5.

[0081] Step A1: The target transit service node generates preset data and sends the preset data to other transit service nodes, so that the target transit service node and other transit service nodes send the preset data to each intelligent outbound call node, so that each intelligent outbound call node sends feedback information to the corresponding transit service node based on the received preset data.

[0082] Different intelligent outbound call nodes and transfer service nodes have different physical distances and different transmission network conditions between their corresponding servers, which will affect the time it takes for the intelligent outbound call node to send request data to the transfer service node. In order to accurately determine the time it takes to transmit data between each intelligent outbound call node and each transfer service node, the target transfer service node can use a preset data to perform transmission tests between different intelligent outbound call nodes and transfer service nodes.

[0083] The preset data here can be an empty file, a specified identifier, or any data with a specified data volume.

[0084] The target transit service node first generates preset data, and then sends the preset data to other transit service nodes. After the target transit service node and other transit service nodes obtain the preset data, they can send the preset data to each intelligent outbound call node respectively, and record the time of sending the preset data to each intelligent outbound call node. After the intelligent outbound call node receives the preset data, it will return feedback information to the corresponding transit service node (i.e., the transit service node that sends the preset data) based on the preset data. Since the number of transit service nodes and intelligent outbound call nodes is multiple, and each transit service node will send preset data to each intelligent outbound call node, each intelligent outbound call node will receive the preset data sent by each transit service node. The corresponding transit service node is the transit service node that sends preset data to the intelligent outbound call system. For example: intelligent outbound call node 1 sends preset data to transit service node 1. At this time, for intelligent outbound call node 1, transit service node 1 is the corresponding transit service node. Next, the target transit service node and other transit service nodes receive the feedback information and record the time of each feedback information received and the intelligent outbound call node that sends the feedback information, so as to determine the time required to transmit data between each intelligent outbound call node and the transit service node based on the recorded time.

[0085] Step A2: The target transit service node determines the time taken to transmit data between each intelligent outbound call node and the target transit service node according to the time of sending the preset data and the time of receiving the feedback information.

[0086] Step A3: The target transit service node obtains the time consumed for transmitting data between each intelligent outbound call node and other transit service nodes from other transit service nodes. The time consumed in other transit service nodes is generated by other transit service nodes based on the time for sending preset data and the time for receiving feedback information.

[0087] For example, assume that there are intelligent outbound call node 1, intelligent outbound call node 2 and intelligent outbound call node 3, as well as transit service node 1, transit service node 2 and transit service node 3. Among them, transit service node 1 is the target transit service node, and transit service node 2 and transit service node 3 are other transit service nodes. In the time-consuming calculation, transit service node 1 generates preset data and sends the preset data to transit service node 2 and transit service node 3. Transit service node 1 sends the preset data to intelligent outbound call node 1, intelligent outbound call node 2 and intelligent outbound call node 3, and records the time point 1 at this time. Intelligent outbound call node 1 sends feedback information to transit service node 1, and the transit service node records the time point 2 at this time. Intelligent outbound call node 2 sends feedback information to transit service node 1, and the transit service node records the time point 3 at this time. Intelligent outbound call node 3 sends feedback information to transit service node 1, and the transit service node records the time point 4 at this time. In this way, it is possible to calculate the transmission time between the intelligent outbound call node 1 and the transit service node 1 (time point 2-time point 1) / 2, the transmission time between the intelligent outbound call node 2 and the transit service node 1 (time point 3-time point 1) / 2, and the transmission time between the intelligent outbound call node 3 and the transit service node 1 (time point 4-time point 1) / 2. The time taken to transmit data between the intelligent outbound call node 1, the intelligent outbound call node 2 and the intelligent outbound call node 3 and the transit service node 2 and the transit service node 3 is similar to that of the above-mentioned transit service node 1, and will not be repeated here.

[0088] Step A4: The target transit service node determines the amount of request data in its current queue, and obtains the amount of request data in the current queue of other transit service nodes.

[0089] Since the transit service node is running continuously, the next batch of request data may be received before the previous batch of request data is sent. Therefore, there may be continuous request data in the queue of the transit service node. The more request data there is in the queue, the more time is needed to delay the request data acquisition, so as to avoid overloading the transit service node and maintain the normal operation of the transit service node.

[0090] In a queue, a piece of request data will occupy a piece of storage space, or occupy a row of a table used to store request data. The transit service node can determine the number of request data in the current queue by finding the amount of storage space occupied by the request data, or the number of rows with actual content in the table storing the request data. The number of request data in the current queue of the target transit service node can be directly obtained by the target transit service node itself. The number of request data in the current queue of other transit service nodes can be obtained by the target transit service node from other transit service nodes after the other transit service nodes obtain it by themselves. In some examples, after obtaining the number of request data, other transit service nodes will send a message including the number of request data to the target transit service node. After receiving the message, the target transit service node parses the message to obtain the number of request data obtained by other transit service nodes. In some other examples, the target transit service node sends a request message to other transit service nodes to request the number of request data obtained by other transit service nodes; after receiving the request message, the other transit service nodes return a feedback message including the number of request data to the target transit service node, and after receiving the feedback message, the target transit service node parses the feedback message to obtain the number of request data obtained by other transit service nodes.

[0091] Step A5: The target transit service node generates a correspondence between multiple intelligent outbound call nodes and multiple transit service nodes based on the acquired time consumption and quantity.

[0092] Among them, between each intelligent outbound call node and its corresponding transfer service node, the time consumption and the quantity can be directly proportional or inversely proportional.

[0093] In principle, between a certain intelligent outbound call node and a transit service node, the shorter the transmission time, the better, and the fewer the number of request data in the queue, the better. However, between an intelligent outbound call node with short transmission time and a transit service node, the number of request data in the transit service node queue is not necessarily the smallest. In order to achieve a balanced match between intelligent outbound call nodes and transit service nodes, and to achieve efficient transmission of request data as a whole, the intelligent outbound call nodes and transit service nodes can be paired based on the ranking of the multiplication result of the time consumption and the number, and the intelligent outbound call nodes and transit service nodes can be preferentially selected from both ends of the ranking for pairing.

[0094] For example, suppose that intelligent outbound call node 1, intelligent outbound call node 2, and intelligent outbound call node 3 are paired with transit service node 1 and transit service node 2. The time consumed between each intelligent outbound call node and the transit service node, as well as the number of request data in the current queue of each intelligent outbound call node are as follows:

[0095] Intelligent outbound call node 1-transfer service node 1, takes 1 second;

[0096] Intelligent outbound call node 2-transfer service node 1, taking 2s;

[0097] Intelligent outbound call node 3-transfer service node 1, takes 3s;

[0098] Intelligent outbound call node 1-transfer service node 2, taking 2s;

[0099] Intelligent outbound call node 2-transfer service node 2, takes 3s;

[0100] Intelligent outbound call node 3-transfer service node 2, taking 1 second;

[0101] Intelligent outbound call node 1, the number of requested data in the queue is 1;

[0102] Intelligent outbound call node 2, the number of request data in the queue is 5;

[0103] Intelligent outbound call node 3, the number of requested data in the queue is 10.

[0104] The result of multiplying the time consumption and the number of each intelligent outbound call node and the transfer service node is as follows:

[0105] Intelligent outbound call node 1-transit service node 1, 1;

[0106] Intelligent outbound call node 2-transfer service node 1, 10;

[0107] Intelligent outbound call node 3-transfer service node 1, 30;

[0108] Intelligent outbound call node 1-transit service node 2, 2;

[0109] Intelligent outbound call node 2-transfer service node 2, 15;

[0110] Intelligent outbound call node 3-transfer service node 2, 10.

[0111] The correspondence between the intelligent outbound call node and the transfer service node is determined based on 1 and 30 first, then based on 2 and 15, and finally based on 10.

[0112] Based on the above description, the corresponding relationship is established as follows:

[0113] The intelligent outbound call node 1 and the intelligent outbound call node 3 both correspond to the transit service node 1, and the intelligent outbound call node 2 corresponds to the transit service node 2.

[0114] In this way, on the one hand, the request data in the intelligent outbound call node is quickly transmitted to the transit service node, and the current request data in the transit service node queue is relatively small, so the newly transmitted request data can be sent to the downstream system as soon as possible, realizing real-time processing of the request data, and the intelligent outbound call node can continue to share the request data with other intelligent outbound call nodes, improving the efficiency of request processing. On the other hand, there is a large amount of current request data in the transit service node queue, and the intelligent outbound call node transmits slowly, so there is not much request data transmitted, so there is enough time for the transit service node to send the current request data to the downstream system, ensuring the efficient operation of the transit service node, and thus improving the efficiency of sending request data.

[0115] In addition to generating the corresponding relationship in the above manner, the corresponding relationship can also be obtained by manually specifying each intelligent outbound call node and its corresponding transfer service node.

[0116] For each transit service node, each time the request data is obtained, the corresponding relationship can be updated once to ensure the maximum efficiency of the request data transmission. Of course, the corresponding relationship can also be updated after a period of time, and the request data can also be obtained according to the initially configured corresponding relationship.

[0117] S42: Each transit service node determines its corresponding intelligent outbound call node from the corresponding relationship.

[0118] S43: Each transit service node obtains the request data sent by its corresponding intelligent outbound call node within a preset time period.

[0119] Continuing with the above example, the corresponding relationship includes: the intelligent outbound call node 1 and the intelligent outbound call node 3 both correspond to the transit service node 1, and the intelligent outbound call node 2 corresponds to the transit service node 2. For the transit service node 1, it is necessary to obtain the request data sent by the intelligent outbound call node 1 within the preset time period, and to obtain the request data sent by the intelligent outbound call node 3 within the preset time period. For the transit service node 2, it is necessary to obtain the request data sent by the intelligent outbound call node 2 within the preset time period.

[0120] The specific acquisition method has been described in detail in the above step S21 and will not be repeated here.

[0121] After each transit service node obtains the request data from its corresponding intelligent outbound call node, one or several transit service nodes may obtain a lot of request data. Due to the limited available resources, the transit service node cannot send all the request data to the downstream system the next time. In order to send the request data to the downstream system as soon as possible, the excess request data can be transferred to the transit service node with surplus available resources.

[0122] Specifically, after the above step S43, the method may include:

[0123] Step B1: Each transit service node determines a first quantity of request data sent by its corresponding intelligent outbound call node within a preset time period.

[0124] Step B2: Each transit service node determines the second quantity of request data in its current queue.

[0125] In determining the amount of requested data, the above step S22 and step A2 have been described in detail, please refer to the previous description, and will not be repeated here.

[0126] For each transit service node, it is necessary to determine whether the first number of request data it obtains and the second number of request data in its current queue exceed the preset number. If it exceeds the preset number, it means that the corresponding transit service node cannot send all its existing request data when sending request data to the downstream system next time, and the request data that cannot be sent in the next time can be processed separately to speed up the sending. For example: transfer to an idle transit service node, merge duplicate request data, etc. If it does not exceed the preset number, it means that the corresponding transit service node can send all its existing request data when sending request data to the downstream system next time. At this time, no additional processing is required, and the request data only needs to wait for sending in the transit service node.

[0127] Step B3: If the first transit service node determines that the sum of the first quantity and the second quantity corresponding to itself exceeds the preset quantity, the request data exceeding the preset quantity is sent to the second transit service node, and the second transit service node is a node that determines that the sum of the first quantity and the second quantity corresponding to itself does not exceed the preset quantity.

[0128] The first transit service node is any transit service node. The second transit service node may be determined from nodes other than the first transit service node.

[0129] The second transit service node may preferentially select a currently idle transit service node, which can realize the maximum efficient transmission of request data and improve request efficiency. The second transit service node may also select any transit service node whose number of request data to be sent next time has not exceeded a preset number.

[0130] For example, assume that the intelligent outbound call node 1 generates 100 request data, which are sent to the transit service node 1. There are 10 request data in the current queue of the transit service node 1, 2 request data in the current queue of the transit service node 2, 5 request data in the current queue of the transit service node 3, and 20 request data in the current queue of the transit service node 4, and the preset number is 20. At this time, of these 100 data, 10 request data can be stored in the queue of the transit service node 1, 18 request data can be stored in the queue of the transit service node 2, and 15 request data can be stored in the queue of the transit service node 3. The remaining 57 data can be repeatedly merged, and then the merged request data can be distributed and processed among all the transit service nodes.

[0131] There is a situation here that there is no second transit service node, that is, the request data in all transit service nodes cannot be fully sent in the next time. At this time, the request data in the first transit service node can be distributed among all transit service nodes. The first transit service node first fills a part of the request data it obtains in its queue to a preset number. The remaining request data can be evenly divided among all transit service nodes, or it can be distributed among all transit service nodes according to the "positive correlation between transmission efficiency and request data size" according to the transmission efficiency of the transit service node. For example: there are 20 request data remaining, the transmission frequency of transit service node 1 is 2 per second, and the transmission frequency of transit service node 2 is 10 per second. Then, the remaining 4 request data are sent to the transit service node, and the remaining 16 request data are sent to transit service node 2.

[0132] Step B4: If the first transit service node determines that the sum of the first quantity and the second quantity corresponding to itself does not exceed the preset quantity, the request data is stored in the queue of the first transit service node.

[0133] Each transit service node can send all the request data in the next transmission. At this time, each transit service node can store the acquired request data in its queue, waiting for the next transmission, and then send it to the downstream system for processing.

[0134] Sometimes, the downstream system may be processing other business data at the same time, or the request data of the same business has not been fully processed in the downstream system. At this time, if the request data is sent according to the preset number, some of the request data cannot be processed and will be rejected. In order to avoid this situation, the preset number in the transit service node can be updated in real time according to the real-time processing of the downstream system. Of course, the sending of request data can also be controlled according to the preset number.

[0135] S44: Obtain the real-time quantity of request data that the downstream system can currently process.

[0136] In the downstream system, the maximum concurrency of the downstream system can be subtracted from the current processing capacity to obtain a real-time number that can be processed concurrently, and the real-time number is stored in a preset location. In this way, the transit service node can directly obtain the real-time number of request data that the downstream system can currently process from the preset location of the downstream system.

[0137] Alternatively, the transit service node counts the number of request data that have been issued in real time, combines the maximum concurrency of the downstream system and the time it takes for the downstream system to process a single request data, and calculates the real-time number of request data that the downstream system can currently process.

[0138] S45: Adjust the preset quantity to the real-time quantity.

[0139] As the intelligent outbound call system continues to operate, the maximum concurrency of the downstream system's initial state may be adjusted to be reduced. When the downstream system becomes increasingly idle, the real-time number will continue to increase. When the downstream system becomes increasingly busy, the real-time number will continue to decrease. This will enable dynamic and precise control of the request data sent by the transit service node to the downstream system.

[0140] S46: Determine whether the number of the multiple request data exceeds the real-time number. If yes, execute S47; if no, execute S48.

[0141] The principle and purpose of judging whether the number of multiple request data exceeds the real-time number are similar to those of judging whether the number of multiple request data exceeds the preset number in the above step S22. Please refer to the previous description and no further details will be given here.

[0142] It should be noted here that both the preset number mentioned above and the real-time number here are the numbers configured in a certain transit service node. For the downstream system, there is a total concurrency number, and the number of transit service nodes is multiple, so the total concurrency number needs to be distributed to multiple transit service nodes. One distribution method is equal distribution, that is, dividing the total concurrency number by the number of transit service nodes. Another distribution method is unequal distribution, which can be distributed according to the number of request data historically received by the transit service node using the principle of positive correlation.

[0143] For the real-time control of the above-mentioned request data sending volume, when encountering burst traffic, capacity expansion can also be performed to avoid the transit service node from being stuck or crashed due to burst traffic, thereby improving the operating efficiency of the transit service node and further improving the sending and processing efficiency of the request data.

[0144] Specifically, before the above step S44, the method may further include:

[0145] Step C1: Determine whether the number of the multiple request data exceeds the burst number. If yes, execute step C2; if no, execute step C3.

[0146] The number of bursts here is a preset multiple of the preset number. The preset multiple can be 2, 3, etc. In other words, when the number of multiple request data is large, that is, when multiple request data form a burst flow, corresponding measures need to be taken to quickly digest the burst flow. Specifically, the downstream system can be expanded, and the transit service node can call the interface with the same function as the downstream system to process the request data.

[0147] Step C2: Send a capacity expansion request to the downstream system to increase the concurrent processing capacity of the request data in the downstream system, and then execute step S44, so that multiple request data can be sent to the downstream system faster and processed by the downstream system.

[0148] When burst traffic occurs, the transit service node can immediately send a capacity expansion request to the downstream system. After receiving the capacity expansion request, the downstream system determines that the transit service node or the intelligent outbound call system needs to be expanded through the content of the capacity expansion request, and can simultaneously enable the backup server, or the downstream system provides the transit service node with a system interface with the same function as its own. In this way, the number of concurrent request data processed by the downstream system can be multiplied, and the real-time number obtained by the transit service node also increases accordingly, so that more request data can be sent to the downstream system at the same time, speeding up the processing efficiency of burst traffic and avoiding blocking and crashing of the transit service node.

[0149] After the burst traffic is processed, the transit service node can send a capacity reduction request to the downstream system to make the downstream system shut down the backup server or the corresponding interface to enable the downstream system to operate normally.

[0150] Step C3: Execute step S44.

[0151] In the absence of burst traffic, the transit service node can update the quantity in real time according to the maximum quantity of request data that the downstream system can currently process, so that multiple request data can be sent to the downstream system in batches according to the real-time quantity.

[0152] Whether it is to determine whether the amount of requested data exceeds the real-time amount or exceeds the preset amount, it can be determined through the threads in the thread pool in the transit service node.

[0153] Specifically, the above step S46 may include:

[0154] Step D1: for multiple request data, calling threads in the thread pool.

[0155] Step D2: If there is request data of an uncalled thread, it is determined that the number of the plurality of request data exceeds a preset number.

[0156] Step D3: If there is no request data of an uncalled thread, it is determined that the number of the plurality of request data does not exceed a preset number.

[0157] In the thread pool, you can configure the same number of threads as the preset number. Every time a request data needs to be sent to the downstream system, a thread in the thread pool is called, and the number of threads in the thread pool will be reduced by one. After the request data is sent to the downstream system, the called thread will return to the thread pool. In this way, through the calling status of the threads in the thread pool, it is possible to know whether the request data exceeds the preset number, and it is also possible to achieve precise control of the sending of request data.

[0158] For example, suppose the preset number in a transit service node is 10, 10 threads are pre-configured in the thread pool, and 15 request data are currently obtained. For the 1st to 10th request data, 10 threads in the thread pool can be called to send them to the downstream system respectively. At this time, there are 5 request data left and no threads can be used, and it is determined that the number of multiple request data exceeds the preset number. Conversely, if 5 request data are currently obtained, these 5 data can be called to send them to the downstream system by 5 threads in the thread pool respectively. At this time, there are 5 threads left in the thread pool and no remaining request data. It can be determined that the number of multiple request data does not exceed the preset number.

[0159] By checking the calling situations of threads in the thread pool, it is possible to determine whether the number of multiple request data exceeds the preset number, thereby avoiding the process of analyzing the content of the request data and the process of comparing the quantity. The embodiment of the present application checks the thread calling situation, which is simple and convenient compared to the analysis and comparison of specific data, and can improve the efficiency of judging whether the number of multiple request data exceeds the preset number, thereby improving the request efficiency.

[0160] Furthermore, while determining the quantity of requested data, the request data is controlled and sent, combining the determination and sending processes at the same time, further improving the request efficiency.

[0161] It should be noted here that in the thread pool, a preset number of threads are configured in the initial state. The preset number is consistent with the number of request data that can be processed by the downstream system in the initial state. As the downstream system continuously receives and processes request data, the number of request data that the downstream system can currently process is also constantly changing. When there are still request data being processed in the downstream system, the number of request data that the downstream system can currently process is reduced from the preset number in the initial state to the real-time number. When the downstream system has processed the request data therein, the number of request data that the downstream system can currently process is increased from the real-time number to the preset number. Therefore, the number of available threads in the thread pool needs to be adjusted in real time to ensure that the request data sent to the downstream system just makes the downstream system in a full-volume processing state. It will neither cause the downstream system to receive too much request data at one time nor cause waste of resources in the downstream system, ensuring that the request data can be continuously and efficiently processed by the downstream system, thereby improving the processing efficiency of the request.

[0162] In the process of controlling the increase and decrease of available threads in the thread pool, taking the reduction of the number of available threads in the thread pool from the preset number to the real-time number as an example, the thread pool is originally configured with a preset number of threads. In order to make only the real-time number of threads available in the thread pool, the current number of threads in the thread pool needs to be reduced. The specific reduction can be locking threads or closing threads. For example: the preset number is 10, the real-time number is 8, and the thread pool is initially configured with 10 threads. At this time, any two threads in the thread pool that are inefficient or not frequently used can be locked, so that only 8 threads can be used in the thread pool. After the real-time number becomes 9 or 10, the locked one or two threads can be unlocked.

[0163] S47: Send the request data that does not exceed the real-time quantity among the multiple request data to the downstream system, and store the request data that exceeds the real-time quantity among the multiple request data in a queue, so that after the downstream system processes the request data, the request data that does not exceed the real-time quantity in the queue is sent to the downstream system.

[0164] S48: Send multiple request data to the downstream system.

[0165] By calling threads in the thread pool, a real-time amount or less than the real-time amount of request data can be sent to the downstream system at one time.

[0166] After the downstream system receives the request data, it processes it based on the request data, generates response data, and then sends the response data to the corresponding transit service node, which forwards it to the corresponding intelligent outbound call node through the corresponding transit service node. Alternatively, the corresponding intelligent outbound call node is directly determined based on the content in the request data, and the response data is then sent directly to the corresponding intelligent outbound call node to improve the request response rate.

[0167] At this point, the request method provided in the embodiments of the present application has been fully described.

[0168] Based on the same inventive concept, as an implementation of the above method, the embodiment of the present application also provides a request device.

[0169] Figure 5 The structure of the request device in the embodiment of the present application is shown in FIG. Figure 1 , see Figure 5 As shown, the device is applied to a transit service node, which is connected to an intelligent outbound call system and is used to intercept request data sent by the intelligent outbound call system. The transit service node is also connected to a downstream system of the intelligent outbound call system and is used to send the request data to the downstream system.

[0170] The device may include: an acquisition module 51, a judgment module 52 and a sending module 53. The acquisition module 51, the judgment module 52 and the sending module 53 are connected in sequence.

[0171] The acquisition module 51 is used to acquire a plurality of request data sent by the intelligent outbound calling system within a preset time period.

[0172] The judging module 52 is used to judge whether the number of the plurality of request data exceeds a preset number, where the preset number is the maximum number of request data that can be processed simultaneously by the downstream system. If yes, the sending module 53 is entered.

[0173] The sending module 53 is used to send the request data that does not exceed the preset number among the multiple request data to the downstream system, and to store the request data that exceeds the preset number among the multiple request data in a queue, so that after the downstream system processes the request data, the request data that does not exceed the preset number in the queue is sent to the downstream system.

[0174] Furthermore, as a Figure 5 As a refinement and expansion of the device shown, the embodiment of the present application also provides a request device.

[0175] Figure 6 The structure of the request device in the embodiment of the present application is shown in FIG. Figure 2 , see Figure 6 As shown, the device is applied to a transit service node, which is connected to an intelligent outbound call system and is used to intercept request data sent by the intelligent outbound call system. The transit service node is also connected to a downstream system of the intelligent outbound call system and is used to send the request data to the downstream system.

[0176] The intelligent outbound call system includes multiple intelligent outbound call nodes, each of which sends request data within a preset time period, and the number of transfer service nodes is multiple.

[0177] The transit service node includes a thread pool. The number of threads in the thread pool is the same as the preset number. After each thread is called, it can send a request data to the downstream system.

[0178] The device may include: a generating module 61, an acquiring module 62, an updating module 63, a judging module 64 and a sending module 65. The generating module 61, the acquiring module 62, the updating module 63, the judging module 64 and the sending module 65 are connected in sequence.

[0179] Generation module 61 is used for the target transit service node to generate a correspondence between multiple intelligent outbound call nodes and multiple transit service nodes, and send the correspondence to other transit service nodes, wherein the target transit service node is one of the multiple transit service nodes, and the other transit service nodes are nodes among the multiple transit service nodes except the target transit service node.

[0180] The generation module 61 may include: a time-consuming determination unit 611, a quantity determination unit 612, and a corresponding relationship unit 613. The time-consuming determination unit 611, the quantity determination unit 612, and the corresponding relationship unit 613 are connected in sequence.

[0181] The time-consuming determination unit 611 is used for the target transit service node to generate preset data and send the preset data to other transit service nodes, so that the target transit service node and other transit service nodes send the preset data to each intelligent outbound call node, thereby enabling each intelligent outbound call node to send feedback information to the corresponding transit service node based on the received preset data.

[0182] The time consumption determining unit 611 is also used for the target transit service node to determine the time consumption for transmitting data between each intelligent outbound call node and the target transit service node according to the time for sending preset data and the time for receiving feedback information.

[0183] The time determination unit 611 is also used for the target transit service node to obtain the time consumed in transmitting data between each intelligent outbound call node and other transit service nodes from other transit service nodes. The time consumed in other transit service nodes is generated by other transit service nodes based on the time for sending preset data and the time for receiving feedback information.

[0184] The quantity determining unit 612 is used for the target transit service node to determine the quantity of request data in its current queue, and to obtain the quantity of request data in the current queue of other transit service nodes.

[0185] The corresponding relationship unit 613 is used for the target transit service node to generate a corresponding relationship between multiple intelligent outbound call nodes and multiple transit service nodes based on the acquired time consumption and quantity.

[0186] The acquisition module 62 may include: an outbound call determination unit 621, a request acquisition unit 622, and a request adjustment unit 623. The outbound call determination unit 621, the request acquisition unit 622, and the request adjustment unit 623 are connected in sequence.

[0187] The outbound call determination unit 621 is used for each transit service node to determine its corresponding intelligent outbound call node from the corresponding relationship.

[0188] The request acquisition unit 622 is used for each transit service node to acquire the request data sent by the corresponding intelligent outbound call node within a preset time period.

[0189] The request adjustment unit 623 is used for each transit service node to determine the first number of request data sent by the corresponding intelligent outbound call node within a preset time period; each transit service node determines the second number of request data in its current queue; if the first transit service node determines that the sum of the first number and the second number corresponding to itself exceeds the preset number, the request data exceeding the preset number will be sent to the second transit service node, and the second transit service node is a node that determines that the sum of the first number and the second number corresponding to itself does not exceed the preset number.

[0190] The updating module 63 may include: a quantity expansion unit 631 and a quantity updating unit 632 . The quantity expansion unit 631 is connected to the quantity updating unit 632 .

[0191] The quantity expansion unit 631 is used to determine whether the number of multiple request data exceeds the burst number, and the burst number is greater than a preset multiple of a preset number; if so, an expansion request is sent to the downstream system to increase the concurrent processing capacity of the request data by the downstream system, and then enter the quantity update unit 632, so that the multiple request data can be sent to the downstream system faster and processed by the downstream system; if not, enter the quantity update unit 632.

[0192] The quantity updating unit 632 is used to obtain the real-time quantity of the request data that the downstream system can currently process; and adjust the preset quantity to the real-time quantity.

[0193] The judging module 64 is used to judge whether the number of the multiple request data exceeds the real-time number. If yes, the sending module 65 is entered.

[0194] The judgment module 64 is specifically used to call a thread in the thread pool for multiple request data; if there is request data for which the thread is not called, it is determined that the number of the multiple request data exceeds the preset number; if there is no request data for which the thread is not called, it is determined that the number of the multiple request data does not exceed the preset number.

[0195] The preset quantity here is also applicable to the determination of the real-time quantity. For details, please refer to the relevant instructions in the aforementioned steps D1-D3, which will not be repeated here.

[0196] The sending module 65 is used to send the request data that does not exceed the real-time quantity among the multiple request data to the downstream system, and to store the request data that exceeds the real-time quantity among the multiple request data in a queue, so that after the downstream system processes the request data, the request data that does not exceed the real-time quantity in the queue is sent to the downstream system.

[0197] It should be noted here that the description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0198] Based on the same inventive concept, an embodiment of the present application also provides an electronic device.

[0199] Figure 7 This is a schematic diagram of the structure of the electronic device in the embodiment of the present application, see Figure 7 As shown, the electronic device may include: a processor 71, a memory 72, and a bus 73; wherein the processor 71 and the memory 72 communicate with each other via the bus 73; the processor 71 is used to call program instructions in the memory 72 to execute the methods in one or more of the above embodiments.

[0200] It should be noted that the description of the above electronic device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the electronic device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

[0201] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium, which may include: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the method in one or more of the above embodiments.

[0202] It should be noted here that the description of the above storage medium embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the storage medium embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0203] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A request method, characterized in that: The method is applied to a transfer service node, the transfer service node is connected to the intelligent outbound call system, and is used to intercept request data sent by the intelligent outbound call system. The transfer service node is also connected to a downstream system of the intelligent outbound call system, and is used to send the request data to the downstream system. The method includes: Obtain multiple request data sent by the intelligent outbound call system within a preset time period; Determine whether the number of the multiple request data exceeds a preset number, where the preset number is the maximum number of request data that the downstream system can process simultaneously; If so, the request data that does not exceed the preset number among the multiple request data are sent to the downstream system, and the request data that exceeds the preset number among the multiple request data are stored in a queue, so that after the downstream system processes the request data, the request data that does not exceed the preset number in the queue are sent to the downstream system.

2. The method according to claim 1, characterized in that: The intelligent outbound call system includes a plurality of intelligent outbound call nodes, each of which sends request data within the preset time period, and the number of the transfer service nodes is multiple; Before obtaining a plurality of request data sent by the intelligent outbound calling system within a preset time period, the method further includes: The target transit service node generates a correspondence relationship between multiple intelligent outbound call nodes and multiple transit service nodes, and sends the correspondence relationship to other transit service nodes, wherein the target transit service node is one of the multiple transit service nodes, and the other transit service nodes are nodes of the multiple transit service nodes other than the target transit service node; The obtaining of multiple request data sent by the intelligent outbound calling system within a preset time period includes: Each transit service node determines its corresponding intelligent outbound call node from the corresponding relationship; Each transit service node obtains the request data sent by its corresponding intelligent outbound call node within a preset time period.

3. The method according to claim 2, characterized in that The target transfer service node generates a correspondence relationship between a plurality of intelligent outbound call nodes and a plurality of transfer service nodes, including: The target transit service node generates preset data, and sends the preset data to the other transit service nodes, so that the target transit service node and the other transit service nodes send the preset data to each intelligent outbound call node, so that each intelligent outbound call node sends feedback information to the corresponding transit service node based on the received preset data; The target transit service node determines the time taken to transmit data between each intelligent outbound call node and the target transit service node according to the time of sending the preset data and the time of receiving the feedback information; The target transit service node obtains the time consumed for transmitting data between each intelligent outbound call node and the other transit service node from the other transit service node, where the time consumed in the other transit service node is generated by the other transit service node based on the time for sending preset data and the time for receiving feedback information; The target transit service node determines the number of request data in its current queue, and obtains the number of request data in the current queue of the other transit service node; The target transit service node generates a correspondence between a plurality of intelligent outbound call nodes and a plurality of transit service nodes based on the acquired time consumption and quantity.

4. The method according to claim 2, characterized in that: After each transit service node obtains the request data sent by its corresponding intelligent outbound call node within a preset time period, the method further includes: Each transit service node determines a first quantity of request data sent by its corresponding intelligent outbound call node within a preset time period; Each transit service node determines a second amount of request data in its current queue; If the first transit service node determines that the sum of the first quantity and the second quantity corresponding to itself exceeds the preset quantity, the request data exceeding the preset quantity is sent to the second transit service node, and the second transit service node is a node that determines that the sum of the first quantity and the second quantity corresponding to itself does not exceed the preset quantity.

5. The method according to any one of claims 1 to 4, characterized in that Before determining whether the number of the plurality of request data exceeds a preset number, the method further includes: Get the real-time number of request data that the downstream system can currently process; Adjusting the preset quantity to the real-time quantity; The determining whether the number of the plurality of request data exceeds a preset number includes: It is determined whether the quantity of the plurality of request data exceeds the real-time quantity.

6. The method according to claim 5, characterized in that Before obtaining the real-time amount of request data that the downstream system can currently process, the method further includes: Determining whether the number of the plurality of request data exceeds a burst number, the burst number being greater than a preset multiple of a preset number; If yes, a capacity expansion request is sent to the downstream system so that the downstream system can increase the concurrent processing capacity of the requested data; If not, the step of obtaining the real-time quantity of request data that the downstream system can currently process is performed.

7. The method according to any one of claims 1 to 4, characterized in that The transit service node includes a thread pool, the number of threads in the thread pool is the same as the preset number, and each thread can send a request data to the downstream system after being called; The determining whether the number of the plurality of request data exceeds a preset number includes: For multiple request data, call threads in the thread pool; If there is request data of an uncalled thread, determining that the number of the plurality of request data exceeds a preset number; If there is no request data of the uncalled thread, it is determined that the number of the plurality of request data does not exceed a preset number.

8. A request device, characterized in that: The device is applied to a transfer service node, the transfer service node is connected to the intelligent outbound call system, and is used to intercept request data sent by the intelligent outbound call system. The transfer service node is also connected to a downstream system of the intelligent outbound call system, and is used to send the request data to the downstream system. The device includes: An acquisition module is used to acquire multiple request data sent by the intelligent outbound call system within a preset time period; A judging module is used to judge whether the number of the plurality of request data exceeds a preset number, where the preset number is the maximum number of request data that the downstream system can process simultaneously; if so, entering the sending module; The sending module is used to send the request data that does not exceed the preset number among the multiple request data to the downstream system, and store the request data that exceeds the preset number among the multiple request data in a queue, so that after the downstream system processes the request data, the request data that does not exceed the preset number in the queue is sent to the downstream system.

9. An electronic device, characterized in that: The electronic device comprises: a processor, a memory, and a bus; wherein the processor and the memory communicate with each other via the bus; and the processor is used to call program instructions in the memory to execute the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The storage medium comprises: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the method as claimed in any one of claims 1 to 7.

Images