Adaptive invocation scheduling method and device for heterogeneous external data sources, equipment and medium

Abstract

The application discloses a self-adaptive calling scheduling method and device for heterogeneous external data sources, equipment and medium, relates to the field of resource scheduling, and comprises the following steps: configuring each thread pool corresponding to each isolation level and having thread resources and a queue; maintaining each running image containing a sliding window of an external data source and a classification history for each external data source; when the external data source is called and completed, extracting multi-dimensional running features of the external data source based on sampling data in the sliding window in the running image to determine a comprehensive score; and based on the comprehensive score, classifying the external data source to a target isolation level and routing and scheduling a calling request task of the external data source to a target thread pool corresponding to the target isolation level, so that the queue in the target thread pool executes the calling request task in the queue through thread resources in the target thread pool after the queue is determined to allow the calling request task to enter the queue based on a back pressure dimension. The application can construct a scheduling mechanism for external data sources.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling, and in particular to an adaptive call scheduling method, apparatus, device, and medium for heterogeneous external data sources. Background Technology

[0002] In business scenarios such as financial risk control and credit decision-making, applications typically need to call dozens to hundreds of external data source interfaces simultaneously. These external data sources vary significantly in terms of response latency, timeout rate, response body size, rate limiting strategies, and stability, and their operational characteristics continuously drift with the state of third-party services, resulting in a high degree of uncertainty for the host application when calling external data sources.

[0003] Existing solutions typically use a unified thread pool to handle all external data source calls. When slow or unstable data sources fill the worker threads and task queues, calls to fast data sources are forced to queue, causing a sharp increase in overall latency. When slow data sources return large response bodies, queued tasks accumulate in heap memory, potentially triggering Out Of Memory (OOM) errors and impacting the availability of the entire application. Some existing solutions use static classification to divide data sources into "fast" and "slow" groups and allocate them to different thread pools. However, static classification cannot adapt to dynamic changes in data source operating characteristics, and resource isolation fails once the classification becomes outdated. Existing simple dynamic classification schemes also have the following problems: frequent switching near classification boundaries leads to classification jitter and thread context overhead; indiscriminate degradation during pool overflow may trigger cascading overflows; tasks submitted to the original queue after classification changes cannot be migrated, resulting in an isolation lag window; backpressure mechanisms only consider queue length and are unaware of JVM (Java Virtual Machine) memory status, failing to effectively prevent memory exhaustion in scenarios with large response bodies.

[0004] Therefore, when an application simultaneously accesses multiple heterogeneous external data sources, how to accurately construct a scheduling mechanism for external data sources is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide an adaptive call scheduling method, apparatus, device, and medium for heterogeneous external data sources, which can accurately construct a scheduling mechanism for external data sources when an application simultaneously accesses multiple heterogeneous external data sources. The specific solution is as follows: Firstly, this application provides an adaptive call scheduling method for heterogeneous external data sources, applied to application systems running in a Java Virtual Machine environment and accessing heterogeneous external data sources; the adaptive call scheduling method includes: Configure thread pools corresponding to each isolation level, each with thread resources and queues; wherein, the isolation level is used to allocate external data sources to the corresponding thread pool; the queues in each thread pool adopt different backpressure dimensions; the backpressure dimension is the resource constraint type used when the external data source call request task enters the queue; Each of the aforementioned external data sources maintains a sliding window containing the external data source and a classification history for each running profile; the sliding window records the sampled data when the external data source is invoked; the classification history records the isolation level to which the external data source is assigned. Once the external data source is invoked, the multi-dimensional operational features of the external data source are extracted based on the sampled data in the sliding window in the corresponding operational profile to determine the corresponding comprehensive score. Based on the comprehensive score, the external data source is classified into the target isolation level, and the call request task of the external data source is routed and scheduled to the target thread pool corresponding to the target isolation level. So that after the queue in the target thread pool determines that the call request task is allowed to enter the queue based on the backpressure dimension, the call request task in the queue is executed by the thread resources in the target thread pool.

[0006] Optionally, the step of extracting multidimensional operational features from the external data source based on the sampled data in the sliding window to determine the corresponding comprehensive score includes: Extract multidimensional operational features of the external data source from the sampled data recorded in the sliding window; The sampled data includes the response latency when the external data source is invoked, the call error information, the response body size in bytes, and the sampling timestamp. The multidimensional operational features include latency features reflecting the central tendency of the response time of the external data source, error rate features reflecting the call stability of the external data source, volatility features reflecting the dispersion of the response time of the external data source, memory usage features determined based on the average size of the response body in bytes, and latency trend prediction based on historical data to predict the latency trend of the external data source. The multidimensional operational features are weighted, the weighted results are mapped to a score value, and the score value is determined as the comprehensive score of the external data source.

[0007] Optionally, the adaptive call scheduling method for heterogeneous external data sources further includes: The delay trend of the external data source is predicted based on the sampled data in the sliding window. When a call request task from the external data source is received, the predicted score of the external data source is determined based on the predicted delay trend. The predicted isolation level of the external data source is determined based on the predicted score, and the call request task is routed and scheduled to the thread pool corresponding to the predicted isolation level, so that after the external data source is called this time, the isolation level of the external data source is re-determined based on the sampled data in the updated sliding window.

[0008] Optionally, classifying the external data source to the target isolation level based on the comprehensive score includes: Based on the comprehensive score and using a state transition method with hysteresis interval, the external data source is classified into a target isolation level; wherein, the state transition method is to treat each isolation level as a state, take the isolation level to which the external data source is currently assigned as the current state, and drive the external data source to switch between the isolation levels according to the comprehensive score, so as to transition from the current state to the state corresponding to the target isolation level; The system includes a boundary threshold and a lag interval near the boundary threshold between adjacent isolation levels. When the comprehensive score falls within the lag interval, the current isolation level of the external data source remains unchanged. The width of the lag interval is dynamically adjusted based on the level switching frequency. The level switching frequency is the level switching frequency of the external data source determined based on the isolation levels recorded in the classification history. When the comprehensive score reaches the preset jump threshold, the external data source will be jumped from the current isolation level to the preset highest isolation level.

[0009] Optionally, the isolation level includes a target fast level, a target slow level, and a target standard level between the target fast level and the target slow level; The queue in the thread pool corresponding to the target fast level adopts backpressure in the counting dimension; wherein, the queue adopting the counting dimension determines whether to allow the call request task to enter the queue based on whether the number of current call request tasks in the queue reaches the first preset capacity limit. The queue in the thread pool corresponding to the target slow level adopts memory-level backpressure; wherein, the queue adopting memory-level backpressure obtains the available memory index of the Java Virtual Machine runtime before each enqueue operation, and allows the call request task to enter the queue only when the available memory index is greater than a preset memory threshold. The queue in the thread pool corresponding to the target standard level adopts a dual-dimensional backpressure of counting and memory dimensions. The queue with dual-dimensional backpressure only allows call request tasks to enter the queue when the number of current call request tasks in the queue has not reached the first preset capacity limit and the available memory index of the Java Virtual Machine is greater than the preset memory threshold.

[0010] Optionally, the step of routing and scheduling the call request task from the external data source to the target thread pool corresponding to the target isolation level includes: If the queue size in the target thread pool does not reach the preset overflow threshold, the call request task from the external data source will be submitted to the target thread pool. If the queue size in the target thread pool has reached the preset overflow threshold, the next-level thread pool is determined based on the cascading path formed by each isolation level, and the capacity status of the next-level thread pool is checked. If the capacity status has not reached the second preset capacity limit, the call request task is routed to the next-level thread pool.

[0011] Optionally, the adaptive call scheduling method for heterogeneous external data sources further includes: When submitting a call request task to the thread pool, the call request task is packaged into a task object carrying a route tag; the route tag includes the data source identifier of the external data source, the isolation level at the time of submission, the submission timestamp, and the estimated memory weight; When the target isolation level of the external data source is classified to be higher than the current isolation level, and the external data source meets the preset migration cooldown time, the queued task objects are retrieved in batches from the queue of the original thread pool corresponding to the current isolation level. Tasks whose data source identifiers in the route label match the external data source are submitted to the target thread pool, while task objects whose data source identifiers in the route label do not match the external data source are returned to the queue of the original thread pool.

[0012] Secondly, this application provides an adaptive call scheduling device for heterogeneous external data sources, applied to application systems running in a Java Virtual Machine environment and accessing heterogeneous external data sources; the adaptive call scheduling device includes: The thread pool configuration module is used to configure each thread pool, which corresponds to each isolation level and has thread resources and queues respectively. The isolation level is used to allocate external data sources to the corresponding thread pools. The queues in each thread pool adopt different backpressure dimensions. The backpressure dimension is the resource constraint type used when the call request task from the external data source enters the queue. The profile maintenance module is used to maintain a sliding window containing the external data source and a classification history for each running profile; the sliding window records the sampling data when the external data source is called; the classification history records the isolation level to which the external data source is assigned. The feature scoring module is used to extract multi-dimensional operational features of the external data source based on the sampled data in the sliding window in the corresponding operational profile after the external data source is invoked, so as to determine the corresponding comprehensive score. The classification and scheduling module is used to classify the external data source to the target isolation level based on the comprehensive score, and to route and schedule the call request tasks of the external data source to the target thread pool corresponding to the target isolation level, so that the queue in the target thread pool can execute the call request tasks in the queue through the thread resources in the target thread pool after the call request tasks are allowed to enter the queue based on the backpressure dimension.

[0013] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the aforementioned adaptive call scheduling method for heterogeneous external data sources.

[0014] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned adaptive call scheduling method for heterogeneous external data sources.

[0015] In this application, thread pools are configured corresponding to each isolation level and each has thread resources and queues. The isolation level is used to allocate external data sources to the corresponding thread pool. Each thread pool's queues use a different backpressure dimension. The backpressure dimension is the resource constraint type used when an external data source's call request task enters the queue. Each external data source maintains a running profile containing a sliding window and classification history. The sliding window records sampled data when calling the external data source. The classification history records the isolation level to which the external data source is allocated. After the external data source is called, multi-dimensional running features of the external data source are extracted from the sampled data in the sliding window in the corresponding running profile to determine the corresponding comprehensive score. Based on the comprehensive score, the external data source is classified to a target isolation level, and the call request task of the external data source is routed and scheduled to the target thread pool corresponding to the target isolation level. This allows the queue in the target thread pool to execute the call request task in the queue after determining that the call request task is allowed to enter the queue based on the backpressure dimension, using the thread resources in the target thread pool. As can be seen from the above, this application maintains a dynamic operational profile for each external data source by configuring thread pools corresponding to multiple isolation levels and employing different backpressure dimensions. After each call, multi-dimensional features are extracted based on sliding window sampling data, and a comprehensive score is calculated. Then, based on the comprehensive score, the external data source is dynamically classified to the target isolation level and routed to the corresponding thread pool. This adaptively isolates slow or unstable data sources, preventing their impact on fast data sources. Simultaneously, a multi-dimensional backpressure mechanism prevents memory overflow, effectively improving system stability and resource utilization efficiency. Thus, this invention solves the problems of existing static classification and simple dynamic classification failing to adapt to dynamic changes in data sources, having a single backpressure dimension, and experiencing delayed task migration. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This is a flowchart of an adaptive invocation scheduling method for heterogeneous external data sources disclosed in this application; Figure 2 This is a schematic diagram of an adaptive invocation scheduling method architecture for heterogeneous external data sources disclosed in this application; Figure 3 This is a schematic diagram of a data source operation portrait data structure disclosed in this application; Figure 4 This application discloses a flowchart for multidimensional operational characteristic statistics and composite scoring calculation. Figure 5 This is a schematic diagram of a three-level classification double-hysteresis interval state transition disclosed in this application; Figure 6 This is a schematic diagram of a differentiated thread pool and differentiated queue backpressure strategy disclosed in this application; Figure 7 This is a schematic diagram of a cascaded path for a dynamic overflow route disclosed in this application; Figure 8 This application discloses a flowchart of cross-pool task migration during a classification change. Figure 9 This application discloses a complete flowchart of a call request processing method; Figure 10 This is a schematic diagram of the module structure of an adaptive call scheduling device for heterogeneous external data sources disclosed in this application; Figure 11 This is a schematic diagram of the structure of an adaptive call scheduling device for heterogeneous external data sources disclosed in this application; Figure 12 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Currently, a unified thread pool is typically used to handle all external data source calls. When slow or unstable data sources fill the worker threads and task queues, calls to fast data sources are forced to queue, causing a sharp increase in overall latency. When slow data sources return large response bodies, queued tasks accumulate in heap memory, potentially triggering OutOfMemoryError (OOM) errors and impacting the availability of the entire application. Some existing solutions use static classification to divide data sources into "fast" and "slow" groups and allocate them to different thread pools. However, static classification cannot adapt to dynamic changes in the operating characteristics of data sources, and resource isolation fails once the classification becomes outdated. Existing simple dynamic classification schemes also have the following problems: frequent switching near classification boundaries leads to classification jitter and thread context overhead; indiscriminate degradation during pool overflow may trigger cascading overflows; tasks submitted to the original queue cannot be migrated after classification changes, resulting in an isolation lag window; backpressure mechanisms only consider queue length and are unaware of JVM memory status, failing to effectively prevent memory exhaustion in scenarios with large response bodies. To address these issues, this application provides an adaptive call scheduling method, apparatus, device, and medium for heterogeneous external data sources, enabling the accurate construction of a scheduling mechanism for external data sources when an application simultaneously accesses multiple heterogeneous external data sources.

[0020] See Figure 1 As shown, this embodiment of the invention discloses an adaptive call scheduling method for heterogeneous external data sources, applied to application systems running in a Java Virtual Machine environment and accessing heterogeneous external data sources; the adaptive call scheduling method includes: Step S11: Configure each thread pool corresponding to each isolation level, each with thread resources and queues; wherein, the isolation level is used to allocate external data sources to the corresponding thread pool; the queues in each thread pool adopt different backpressure dimensions; the backpressure dimension is the resource constraint type adopted when the external data source call request task enters the queue.

[0021] In this embodiment, three isolation levels can be set: target fast level, target standard level, and target slow level, which correspond to three independent thread pools. Each thread pool has its own number of threads and task queue. The backpressure strategy of the queue is designed as counting backpressure, memory backpressure, or dual-dimensional backpressure depending on the level.

[0022] Specifically, the isolation levels include a target fast level, a target slow level, and a target standard level that is between the target fast level and the target slow level.

[0023] Wherein, the queue in the thread pool corresponding to the target fast level adopts backpressure in the counting dimension; wherein, the queue adopting the counting dimension determines whether to allow the call request task to enter the queue based on whether the number of current call request tasks in the queue reaches the first preset capacity limit.

[0024] The queue in the thread pool corresponding to the target slow level adopts memory-level backpressure. Before each enqueue operation, the queue using memory-level backpressure obtains the available memory index of the Java Virtual Machine runtime, and allows the call request task to enter the queue only when the available memory index is greater than a preset memory threshold.

[0025] The queue in the thread pool corresponding to the target standard level adopts a dual-dimensional backpressure of counting and memory dimensions. The queue with dual-dimensional backpressure only allows call request tasks to enter the queue when the number of current call request tasks in the queue has not reached the first preset capacity limit and the available memory index of the Java Virtual Machine is greater than the preset memory threshold.

[0026] Step S12: Maintain a sliding window containing the external data source and a classification history for each of the external data sources; the sliding window records the sampling data when the external data source is called; the classification history records the isolation level to which the external data source is assigned.

[0027] In this embodiment, the sliding window records the sampled data when calling external data sources; the classification history records the isolation level assigned to the external data source and the time of its change. Each data source has an independent operational profile for subsequent scoring and classification decisions.

[0028] Step S13: After the external data source is invoked, in the corresponding running profile, the multi-dimensional running features of the external data source are extracted based on the sampled data in the sliding window to determine the corresponding comprehensive score.

[0029] In this embodiment, the latest sampled data within the sliding window is fully utilized to calculate multidimensional features that reflect the current operating status of the data source, and a quantitative comprehensive score is obtained through weighted mapping as a classification basis.

[0030] Specifically, multidimensional operational features of the external data source are extracted from the sampled data recorded by the sliding window; wherein, the sampled data includes the response latency, call error information, response body byte size, and sampling timestamp when the external data source is invoked; wherein, the multidimensional operational features include latency features reflecting the central tendency of the response time of the external data source, error rate features reflecting the call stability of the external data source, volatility features reflecting the dispersion of the response time of the external data source, memory usage features determined based on the average value of the response body byte size, and latency trend prediction based on historical data to predict the latency trend of the external data source.

[0031] Furthermore, the multidimensional operational features are weighted, the weighted results are mapped to a score value, and the score value is determined as the comprehensive score of the external data source.

[0032] Step S14: Based on the comprehensive score, classify the external data source to the target isolation level, and route and schedule the call request task of the external data source to the target thread pool corresponding to the target isolation level, so that after the queue in the target thread pool is allowed to enter the queue based on the backpressure dimension, the call request task in the queue is executed by the thread resources in the target thread pool.

[0033] In this embodiment, to avoid frequent jittering and switching of isolation levels of external data sources, this solution adopts a state transition method with a hysteresis interval to achieve accurate classification of isolation levels. The specific level classification logic is as follows: Based on the comprehensive score and using a state transition method with hysteresis intervals, the external data source is classified into a target isolation level. The state transition method involves treating each isolation level as a state, using the current isolation level of the external data source as the current state, and driving the external data source to switch between isolation levels according to the comprehensive score, transitioning from the current state to the state corresponding to the target isolation level. When the comprehensive score reaches a preset jump threshold, the external data source is jumped from its current isolation level to a preset highest isolation level.

[0034] The system includes a boundary threshold and a hysteresis interval near the boundary threshold between adjacent isolation levels. When the comprehensive score falls within the hysteresis interval, the current isolation level of the external data source remains unchanged. The width of the hysteresis interval is dynamically adjusted based on the level switching frequency. The level switching frequency is the level switching frequency of the external data source determined based on the isolation levels recorded in the classification history.

[0035] To predict the data source's operational status in advance and adapt to task scheduling strategies ahead of time, this solution introduces a delay trend prediction mechanism to achieve pre-scheduling optimization.

[0036] Specifically, the latency trend of the external data source is predicted based on the sampled data in the sliding window. When a call request task from the external data source is received, the predicted score of the external data source is determined based on the predicted latency trend. The predicted isolation level of the external data source is determined based on the predicted score, and the call request task is routed and scheduled to the thread pool corresponding to the predicted isolation level. This is so that after the external data source is called this time, the isolation level of the external data source is re-determined based on the sampled data in the updated sliding window.

[0037] After completing isolation level matching and initial task routing, in order to avoid the problems of single thread pool queue overflow and task backlog blocking, and to ensure stable throughput of massive call request tasks, this solution sets up a mechanism for dynamically adjusting the task mounting thread pool.

[0038] Specifically, if the queue size in the target thread pool has not reached the preset overflow threshold, the call request task from the external data source is submitted to the target thread pool; if the queue size in the target thread pool has reached the preset overflow threshold, the next-level thread pool is determined based on the cascading path formed by each isolation level, and the capacity status of the next-level thread pool is checked. If the capacity status has not reached the second preset capacity limit, the call request task is routed to the next-level thread pool.

[0039] Furthermore, when submitting the call request task to the thread pool, the call request task is packaged into a task object carrying a routing label; the routing label includes the data source identifier of the external data source, the isolation level at the time of submission, the submission timestamp, and the estimated memory weight.

[0040] When the target isolation level of the external data source is classified to be higher than the current isolation level, and the external data source meets the preset migration cooldown time, the queued task objects are retrieved in batches from the queue of the original thread pool corresponding to the current isolation level.

[0041] Next, task objects whose data source identifiers in the routing labels match the external data source are submitted to the target thread pool, while task objects whose data source identifiers in the routing labels do not match the external data source are returned to the queue of the original thread pool. Therefore, during dynamic scheduling and level switching, all call request tasks are standardized and packaged, and batch task migration logic is designed to achieve orderly task migration and avoid chaotic scheduling of existing tasks after level updates.

[0042] As can be seen from the above, this application maintains a dynamic operational profile for each external data source by configuring thread pools corresponding to multiple isolation levels and employing different backpressure dimensions. After each call, multi-dimensional features are extracted based on sliding window sampling data, and a comprehensive score is calculated. Then, based on the comprehensive score, the external data source is dynamically classified to the target isolation level and routed to the corresponding thread pool. This adaptively isolates slow or unstable data sources, preventing their impact on fast data sources. Simultaneously, a multi-dimensional backpressure mechanism prevents memory overflow, effectively improving system stability and resource utilization efficiency. Thus, this invention solves the problems of existing static classification and simple dynamic classification failing to adapt to dynamic changes in data sources, having a single backpressure dimension, and experiencing delayed task migration.

[0043] The following is combined Figure 2 The schematic diagram shown illustrates the technical solution of the embodiments of this application in detail.

[0044] First, it should be noted that this invention aims to construct a JVM resource isolation scheduling mechanism (rather than business scheduling) to completely isolate the uncertainty of external data source calls in scenarios where applications simultaneously access multiple heterogeneous external data sources with significantly different and continuously changing behavioral characteristics. The uncertainty propagation chain is as follows: slow or unstable external data source calls occupy worker threads for extended periods, causing fast data source calls to be unable to acquire thread resources and forced to wait in queues; queue accumulation leads to the continuous accumulation of Future objects (low-level waitable objects) and response body objects in the JVM heap memory; heap memory growth triggers increased GC (Garbage Collection) frequency and longer pause times, further exacerbating the latency deterioration of all data source calls; latency deterioration leads to more call timeouts, and timeout propagation triggers cascading failures. This invention aims to sever this propagation chain at the thread pool resource and queue backpressure levels.

[0045] Furthermore, it needs to be emphasized again that this invention is not a business rule scheduling mechanism, but rather a JVM resource isolation scheduling mechanism. The resource isolation object of this invention is the external data source (isolated according to the behavioral characteristics of the data source), not a single request. By continuously sensing the actual call characteristics of each external data source at runtime, it dynamically allocates them to thread pools with multiple isolation levels and differentiated resource configurations for processing. Combined with differentiated queue backpressure strategies, dynamic overflow routing, and cross-pool task migration, it cuts off the propagation path of external data source uncertainty within the application from three levels: thread resources, queue capacity, and heap memory.

[0046] Reference Figure 3 This application includes a data source operation profile mechanism. Specifically, an operation profile data structure is maintained for each external data source. This data structure includes: (1) a fixed-capacity circular buffer sliding window that records the sampled data of the most recent N calls to the data source. Each sampled data includes: response latency, whether an error occurred, response body byte size, and sampling timestamp; (2) a classification history circular array that records the most recent W classification decision results of the data source (i.e., the isolation level assigned to the data source); (3) the current isolation level (initially the lowest level); and (4) adaptive classification threshold parameters (maintained independently for each data source). The data source operation profile updates the sampled data after each external data source call and updates the classification history after each classification decision. Through the operation profile, the system establishes a continuously evolving understanding of the behavioral characteristics of each external data source. The response body byte size statistics in the profile directly provide a data basis for subsequent memory dimension backpressure decisions.

[0047] The runtime profile further includes resource profile dimensions for the data source: thread usage weight (reflecting the duration of worker thread usage for a single call to the data source), memory usage weight (reflecting the level of heap memory usage by the response body of the data source), and timeout propagation risk (reflecting the degree of blocking of shared thread resources when the data source is abnormal). These resource profile dimensions comprehensively reflect the pressure pattern of the data source on JVM resources, guiding subsequent classification and backpressure dimension selection.

[0048] Reference Figure 4 This application includes a multi-dimensional operational feature statistical mechanism. After each external data source call is completed, the following operational features are extracted from the sliding window sampling data of the data source and a comprehensive score is calculated: (a) latency feature: reflecting the central tendency of the data source's response time; (b) error rate feature: reflecting the call stability of the data source; (c) volatility feature: reflecting the dispersion of the data source's response time; (d) memory usage feature: calculating the average size of the response body in bytes, which is used as the memory weight coefficient of the data source for subsequent classification decisions and queue backpressure strategy selection; (e) latency trend prediction: predicting the latency trend of the data source based on historical data, which is used to determine the target isolation level in advance when the next call arrives. The comprehensive score maps the above multi-dimensional operational features to a single score value through a weighted method, and the weights are configurable parameters.

[0049] Based on the scoring results from external data sources, the data is classified into one of several isolation levels using a state transition method with hysteresis intervals. In a preferred embodiment, three isolation levels are used: FAST, NORMAL, and SLOW. Boundary thresholds are set between adjacent levels, and an extreme jump threshold is set to handle scenarios where the data source suddenly deteriorates (jumping directly from the lowest level to the highest level, skipping intermediate levels). To prevent level switching jitter, a hysteresis interval (dead zone) is set between adjacent levels; no level switch occurs when the score falls within the dead zone. The dead zone width is dynamically adjusted according to the switching frequency in the classification history: the dead zone is widened to suppress jitter when the switching frequency is high, and narrowed to improve sensitivity when the system is stable over a long period, achieving an independent adaptive threshold for each data source. The number of isolation levels is not limited to three; it can be configured to two or more levels depending on the scenario requirements.

[0050] Furthermore, refer to Figure 5 and Figure 6 As shown, this application configures thread pools with differentiated parameters and differentiated backpressure dimensions for different isolation levels. The design is based on the fact that external data sources with different behavioral characteristics exert varying degrees of pressure on JVM resources, thus necessitating the adoption of different resource constraint strategies.

[0051] Fast-level thread pool: The queue uses a variable-capacity blocking queue, employing only a counting-based capacity limit. Enqueueing is determined solely by whether the current number of elements in the queue has reached its capacity limit. This is because fast data sources have small response volumes and manageable memory usage; resource constraints aim to control queuing depth to ensure response speed.

[0052] Slow-speed thread pool: The queue adopts a memory-aware queue, using only the JVM memory limit dimension. Before each enqueue operation, the queue obtains the available JVM runtime memory metric and only allows enqueueing when the available memory exceeds a preset memory threshold. When memory is insufficient, the enqueue operation throws an exception, clearly distinguishing between queue full and insufficient memory rejection semantics. The engineering necessity of this pure memory-limiting strategy lies in the fact that slow data sources have large response volumes and long thread occupancy times. Each task node accumulated in the JVM heap memory holds a task context object and related memory objects (including Futures, request parameters, context metadata, etc.), whose memory consumption far exceeds the data structure overhead of the queue node itself. This results in memory pressure being disproportionate to the number of queued tasks. Memory pressure cannot be perceived solely through counting; backpressure must be established from the memory dimension to effectively cut off the propagation path from queue accumulation to heap memory bloat leading to OutOfMemoryError (OOM).

[0053] Standard-level thread pool (enabled in level 3 and above): The queue uses a hybrid limited-capacity queue, employing dual constraints of counting and JVM memory dimensions. Enqueueing requires both of the following to be met: the number of queue elements has not reached the capacity limit, and the available JVM memory is higher than the memory threshold. If either condition is not met, enqueueing is rejected (returning failure instead of throwing an exception, unlike the hard rejection semantics of the slow-level pool, allowing upper layers to route rejected tasks to the slow-level pool).

[0054] The differentiated design of the three strategies reflects the core understanding of this invention: the memory footprint of the data source determines the backpressure dimension that the queue should adopt, rather than using a uniform counting limit for all data sources. The capacity of each queue level can be dynamically adjusted at runtime.

[0055] Reference Figure 7 As shown, this application includes a dynamic overflow routing mechanism. When a request is classified into a certain level of thread pool but the queue of that pool has reached its overflow threshold, the request is routed to the next level pool according to the cascading path. Overflow routing not only considers the queue state of the current pool but also checks the capacity state of the target pool to avoid routing overflow tasks to a full pool. The overflow thresholds of each level of pool are updated through a dynamic adjustment mechanism, and debouncing constraints are applied to prevent frequent threshold changes.

[0056] Reference Figure 8This application also includes cross-pool task migration during classification changes. As an enhanced mechanism for resource isolation, when the operational isolation level of an external data source increases (i.e., the data source slows down), tasks already waiting to be executed in the original thread pool queue are migrated to the target thread pool. When a task is submitted to the thread pool, it is packaged into an executable task object with routing tag metadata, which includes: data source identifier, isolation level at submission, submission timestamp, and estimated memory weight. When a level change triggers migration: (1) the migration cooldown time is checked; (2) queued tasks are retrieved in batches from the source thread pool queue; (3) the tasks to be migrated are matched according to the data source identifier in the routing tag; (4) the matched tasks are submitted to the target pool, and the unmatched tasks are returned to the source queue; (5) a batch limit is introduced to prevent instantaneous overload. Migration is only triggered when the data source behavior deteriorates.

[0057] Reference Figure 9 The complete invocation process of this solution can be divided into seven steps: Request pre-routing, which involves obtaining the data source's operational profile, calculating a prediction score based on latency trend prediction, determining the prediction level according to the classification state transition method, determining the final target pool through dynamic overflow routing, and submitting the task. Invocation execution and sampling, which involves executing the data source call and recording latency, errors, and response body size. Statistical update, which involves updating the sliding window and latency trend prediction. Multi-dimensional feature calculation and scoring, which involves extracting multi-dimensional operational features (including memory usage features) and calculating a comprehensive score. Classification decision, which involves determining the new level according to the state transition method and adjusting the threshold based on the switching frequency. Classification change handling, which involves triggering cross-pool task migration if the level increases. Periodic adjustment, which involves periodically refreshing the overflow threshold and dynamically rebalancing thread resources based on the utilization rate of each pool and queue waiting time.

[0058] Reference Figure 10 The apparatus of this application may include: a running profile module, a multi-dimensional running feature calculation module, a delay trend prediction module, a dynamic classification module, a classification engine module, a multi-level differentiated thread pool management module, a differentiated queue backpressure module, a dynamic overflow routing module, and a cross-pool task migration module.

[0059] Furthermore, this application does not impose mandatory restrictions on the implementation of certain technical features, specifically: In the secondary mode, the NORMAL pool and hybrid capacity-limited queue can be disabled, and only the FAST pool (count-limited) and SLOW pool (memory-limited) can be used, with classification degenerating into a two-state transition with a single lag interval. This scheme is suitable for scenarios with a small number of external data sources and significant polarization in behavioral characteristics.

[0060] Delayed forecasting methods can be replaced by other time series forecasting methods, such as moving averages and Kalman filters, and are not limited to exponentially weighted moving averages.

[0061] The weights and scaling factors of the multidimensional feature composite score can be dynamically adjusted through configuration files, or the weights can be automatically optimized based on historical classification accuracy through online learning.

[0062] The third stage (periodic probing) in the three-stage strategy for overflow thresholds can be disabled, using only the initial probing and linear growth / multiplicative reduction stages.

[0063] Methods for perceiving the frequency of classification fluctuations can use simpler statistics such as the number of classification switching times or the duration of classification, and are not limited to methods for calculating information metrics.

[0064] Therefore, it can be seen that this application, through differentiated thread pools and differentiated backpressure dimensions, severs the cascading failure chain from slow data source long-term thread occupation to queue accumulation to heap memory expansion to GC deterioration to timeout propagation at three levels: thread resources, queue capacity, and heap memory. The memory-aware queue of the slow-rate pool checks JVM available memory metrics before enqueuing, directly preventing OOM caused by the accumulation of large response bodies at the queue level. This eliminates the need for post-event GC or process-level memory limits, and throws clear exception semantics when memory is insufficient, facilitating differentiated processing at higher levels. The response body byte size statistically analyzed in the runtime profile is used for both classification scoring and backpressure dimension selection, creating a closed loop between classification decisions and resource constraint strategies at the memory level, rather than a disconnect between classification and backpressure. Cross-pool task migration migrates queued tasks to the new pool the instant the classification changes, eliminating the isolation lag window where queued tasks still occupy resources in the original pool even after the classification has changed. The dead zone width is dynamically adjusted based on the switching frequency in the classification history, adapting to the fluctuating characteristics of different data sources without requiring manually set fixed thresholds. Overflow routing checks the target pool capacity status to avoid routing tasks to a full pool, preventing secondary loss. It supports configuring different numbers of isolation levels according to scenario requirements, facilitating gradual deployment and verification.

[0065] Accordingly, see Figure 11 As shown, this application provides an adaptive call scheduling device for heterogeneous external data sources, applied to an application system running in a Java Virtual Machine environment and accessing heterogeneous external data sources; the adaptive call scheduling device includes: The thread pool configuration module 11 is used to configure each thread pool, which corresponds to each isolation level and has thread resources and queues respectively; wherein, the isolation level is used to allocate external data sources to the corresponding thread pools; the queues in each thread pool adopt different backpressure dimensions; the backpressure dimension is the resource constraint type adopted when the external data source call request task enters the queue; The profile maintenance module 12 is used to maintain each running profile, which includes a sliding window and classification history of the external data source, for each of the external data sources; the sliding window records the sampling data when the external data source is called; and the classification history records the isolation level to which the external data source is assigned. Feature scoring module 13 is used to extract multi-dimensional operational features of the external data source based on the sampled data in the sliding window in the corresponding operational profile after the external data source is invoked, so as to determine the corresponding comprehensive score. The classification and scheduling module 14 is used to classify the external data source to the target isolation level based on the comprehensive score, and to route and schedule the call request task of the external data source to the target thread pool corresponding to the target isolation level, so that the queue in the target thread pool can execute the call request task in the queue through the thread resources in the target thread pool after the call request task is allowed to enter the queue based on the backpressure dimension.

[0066] In some specific embodiments, the feature scoring module 13 specifically includes: The feature extraction unit is used to extract multidimensional operational features of the external data source from the sampled data recorded by the sliding window; The sampled data includes the response latency when the external data source is invoked, the call error information, the response body size in bytes, and the sampling timestamp. The multidimensional operational features include latency features reflecting the central tendency of the response time of the external data source, error rate features reflecting the call stability of the external data source, volatility features reflecting the dispersion of the response time of the external data source, memory usage features determined based on the average size of the response body in bytes, and latency trend prediction based on historical data to predict the latency trend of the external data source. The first scoring determination unit is used to weight each of the multidimensional operational features, map the weighted result to a score value, and determine the score value as the comprehensive score of the external data source.

[0067] In some specific embodiments, the adaptive call scheduling device for heterogeneous external data sources further includes: The second scoring determination unit is used to predict the delay trend of the external data source based on the sampled data in the sliding window. When the external data source is received as a call request task, the unit determines the predicted score of the external data source based on the predicted delay trend. The level determination unit is used to determine the predicted isolation level of the external data source based on the predicted score, and to route and schedule the call request task to the thread pool corresponding to the predicted isolation level, so that after the external data source is called this time, the isolation level of the external data source is re-determined based on the sampled data in the updated sliding window.

[0068] In some specific embodiments, the classification and scheduling module 14 specifically includes: A data source classification unit is used to classify the external data source to a target isolation level based on the comprehensive score and using a state transition method with hysteresis interval; wherein, the state transition method is to treat each isolation level as a state, take the isolation level currently assigned to the external data source as the current state, and drive the external data source to switch between the isolation levels according to the comprehensive score, so as to transition from the current state to the state corresponding to the target isolation level; The system includes a boundary threshold and a lag interval near the boundary threshold between adjacent isolation levels. When the comprehensive score falls within the lag interval, the current isolation level of the external data source remains unchanged. The width of the lag interval is dynamically adjusted based on the level switching frequency. The level switching frequency is the level switching frequency of the external data source determined based on the isolation levels recorded in the classification history. The level jump unit is used to jump the classification of the external data source from the current isolation level to the preset highest isolation level when the comprehensive score reaches the preset jump threshold.

[0069] In some specific implementations, the isolation level includes a target fast level, a target slow level, and a target standard level between the target fast level and the target slow level; The queue in the thread pool corresponding to the target fast level adopts backpressure in the counting dimension; wherein, the queue adopting the counting dimension determines whether to allow the call request task to enter the queue based on whether the number of current call request tasks in the queue reaches the first preset capacity limit. The queue in the thread pool corresponding to the target slow level adopts memory-level backpressure; wherein, the queue adopting memory-level backpressure obtains the available memory index of the Java Virtual Machine runtime before each enqueue operation, and allows the call request task to enter the queue only when the available memory index is greater than a preset memory threshold. The queue in the thread pool corresponding to the target standard level adopts a dual-dimensional backpressure of counting and memory dimensions. The queue with dual-dimensional backpressure only allows call request tasks to enter the queue when the number of current call request tasks in the queue has not reached the first preset capacity limit and the available memory index of the Java Virtual Machine is greater than the preset memory threshold.

[0070] In some specific embodiments, the classification and scheduling module 14 specifically includes: The task submission unit is used to submit the external data source call request task to the target thread pool if the queue size in the target thread pool has not reached a preset overflow threshold. The task routing unit is used to determine the next-level thread pool based on the cascading path formed by each isolation level if the queuing amount in the target thread pool has reached the preset overflow threshold, and to check the capacity status of the next-level thread pool. If the capacity status has not reached the second preset capacity limit, the task routing unit routes the call request to the next-level thread pool.

[0071] In some specific embodiments, the adaptive call scheduling device for heterogeneous external data sources further includes: The task packaging unit is used to package the call request task into a task object carrying a routing label when the call request task is submitted to the thread pool; the routing label includes the data source identifier of the external data source, the isolation level at the time of submission, the submission timestamp, and the estimated memory weight; The object retrieval unit is used to retrieve queued task objects in batches from the queue of the original thread pool corresponding to the current isolation level when the target isolation level to which the external data source is classified is higher than the current isolation level, provided that the external data source meets the preset migration cooldown time. The object return unit is used to submit the task objects to be migrated that match the data source identifier in the route label with the external data source to the target thread pool, and to return the task objects that do not match the data source identifier in the route label to the queue of the original thread pool.

[0072] Furthermore, embodiments of this application also disclose an electronic device, Figure 12This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the adaptive call scheduling method for heterogeneous external data sources disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0073] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0074] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0075] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the adaptive invocation scheduling method for heterogeneous external data sources executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0076] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned adaptive call scheduling method for heterogeneous external data sources. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0077] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0078] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0079] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0080] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0081] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An adaptive call scheduling method for heterogeneous external data sources, characterized in that, It is applicable to application systems running in a Java Virtual Machine environment that access heterogeneous external data sources; The adaptive call scheduling method includes: Configure thread pools corresponding to each isolation level, each with thread resources and queues; wherein, the isolation level is used to allocate external data sources to the corresponding thread pool; the queues in each thread pool adopt different backpressure dimensions; the backpressure dimension is the resource constraint type used when the external data source call request task enters the queue; Each of the aforementioned external data sources maintains a sliding window containing the external data source and a classification history for each running profile; the sliding window records the sampled data when the external data source is invoked; the classification history records the isolation level to which the external data source is assigned. Once the external data source is invoked, the multi-dimensional operational features of the external data source are extracted based on the sampled data in the sliding window in the corresponding operational profile to determine the corresponding comprehensive score. Based on the comprehensive score, the external data source is classified into the target isolation level, and the call request task of the external data source is routed and scheduled to the target thread pool corresponding to the target isolation level. So that after the queue in the target thread pool determines that the call request task is allowed to enter the queue based on the backpressure dimension, the call request task in the queue is executed by the thread resources in the target thread pool.

2. The adaptive call scheduling method for heterogeneous external data sources according to claim 1, characterized in that, The multidimensional operational features of the external data source are extracted based on the sampling data in the sliding window to determine the corresponding comprehensive score, including: Extract multidimensional operational features of the external data source from the sampled data recorded in the sliding window; The sampled data includes the response latency when the external data source is invoked, the call error information, the response body size in bytes, and the sampling timestamp. The multidimensional operational features include latency features reflecting the central tendency of the response time of the external data source, error rate features reflecting the call stability of the external data source, volatility features reflecting the dispersion of the response time of the external data source, memory usage features determined based on the average size of the response body in bytes, and latency trend prediction based on historical data to predict the latency trend of the external data source. The multidimensional operational features are weighted, the weighted results are mapped to a score value, and the score value is determined as the comprehensive score of the external data source.

3. The adaptive call scheduling method for heterogeneous external data sources according to claim 1, characterized in that, Also includes: The delay trend of the external data source is predicted based on the sampled data in the sliding window. When a call request task from the external data source is received, the predicted score of the external data source is determined based on the predicted delay trend. The predicted isolation level of the external data source is determined based on the predicted score, and the call request task is routed and scheduled to the thread pool corresponding to the predicted isolation level, so that after the external data source is called this time, the isolation level of the external data source is re-determined based on the sampled data in the updated sliding window.

4. The adaptive call scheduling method for heterogeneous external data sources according to claim 1, characterized in that, The process of classifying the external data source to the target isolation level based on the comprehensive score includes: Based on the comprehensive score and using a state transition method with hysteresis interval, the external data source is classified into a target isolation level; wherein, the state transition method is to treat each isolation level as a state, take the isolation level to which the external data source is currently assigned as the current state, and drive the external data source to switch between the isolation levels according to the comprehensive score, so as to transition from the current state to the state corresponding to the target isolation level; The system includes a boundary threshold and a lag interval near the boundary threshold between adjacent isolation levels. When the comprehensive score falls within the lag interval, the current isolation level of the external data source remains unchanged. The width of the lag interval is dynamically adjusted based on the level switching frequency. The level switching frequency is the level switching frequency of the external data source determined based on the isolation levels recorded in the classification history. When the comprehensive score reaches the preset jump threshold, the external data source will be jumped from the current isolation level to the preset highest isolation level.

5. The adaptive call scheduling method for heterogeneous external data sources according to claim 1, characterized in that, The isolation levels include a target fast level, a target slow level, and a target standard level that is between the target fast level and the target slow level; The queue in the thread pool corresponding to the target fast level adopts backpressure in the counting dimension; wherein, the queue adopting the counting dimension determines whether to allow the call request task to enter the queue based on whether the number of current call request tasks in the queue reaches the first preset capacity limit. The queue in the thread pool corresponding to the target slow level adopts memory-level backpressure; wherein, the queue adopting memory-level backpressure obtains the available memory index of the Java Virtual Machine runtime before each enqueue operation, and allows the call request task to enter the queue only when the available memory index is greater than a preset memory threshold. The queue in the thread pool corresponding to the target standard level adopts a dual-dimensional backpressure of counting and memory dimensions. The queue with dual-dimensional backpressure only allows call request tasks to enter the queue when the number of current call request tasks in the queue has not reached the first preset capacity limit and the available memory index of the Java Virtual Machine is greater than the preset memory threshold.

6. The adaptive call scheduling method for heterogeneous external data sources according to claim 1, characterized in that, The step of routing and scheduling the call request task from the external data source to the target thread pool corresponding to the target isolation level includes: If the queue size in the target thread pool does not reach the preset overflow threshold, the call request task from the external data source will be submitted to the target thread pool. If the queue size in the target thread pool has reached the preset overflow threshold, the next-level thread pool is determined based on the cascading path formed by each isolation level, and the capacity status of the next-level thread pool is checked. If the capacity status has not reached the second preset capacity limit, the call request task is routed to the next-level thread pool.

7. The adaptive call scheduling method for heterogeneous external data sources according to any one of claims 1 to 6, characterized in that, Also includes: When submitting a call request task to the thread pool, the call request task is wrapped into a task object carrying a route tag; The routing label includes the data source identifier of the external data source, the isolation level at the time of submission, the submission timestamp, and the estimated memory weight; When the target isolation level of the external data source is classified to be higher than the current isolation level, and the external data source meets the preset migration cooldown time, the queued task objects are retrieved in batches from the queue of the original thread pool corresponding to the current isolation level. Tasks whose data source identifiers in the route label match the external data source are submitted to the target thread pool, while task objects whose data source identifiers in the route label do not match the external data source are returned to the queue of the original thread pool.

8. An adaptive call scheduling device for heterogeneous external data sources, characterized in that, It is applicable to application systems running in a Java Virtual Machine environment that access heterogeneous external data sources; The adaptive call scheduling device includes: The thread pool configuration module is used to configure each thread pool, which corresponds to each isolation level and has thread resources and queues respectively. The isolation level is used to allocate external data sources to the corresponding thread pools. The queues in each thread pool adopt different backpressure dimensions. The backpressure dimension is the resource constraint type used when the call request task from the external data source enters the queue. The profile maintenance module is used to maintain a sliding window containing the external data source and a classification history for each running profile; the sliding window records the sampling data when the external data source is called; the classification history records the isolation level to which the external data source is assigned. The feature scoring module is used to extract multi-dimensional operational features of the external data source based on the sampled data in the sliding window in the corresponding operational profile after the external data source is invoked, so as to determine the corresponding comprehensive score. The classification and scheduling module is used to classify the external data source to the target isolation level based on the comprehensive score, and to route and schedule the call request tasks of the external data source to the target thread pool corresponding to the target isolation level, so that the queue in the target thread pool can execute the call request tasks in the queue through the thread resources in the target thread pool after the call request tasks are allowed to enter the queue based on the backpressure dimension.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the adaptive call scheduling method for heterogeneous external data sources as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the adaptive invocation scheduling method for heterogeneous external data sources as described in any one of claims 1 to 7.

Images