Multi-dimensional dynamic weighted round robin scheduling method and system for bank-enterprise direct connection query

Abstract

The application relates to a multi-dimension dynamic weighted polling scheduling method and system for bank-enterprise direct connection query, which comprises the following steps: acquiring account information of all accounts of an enterprise and initializing a sorting value of each account; screening out accounts to be queried in a current batch according to the initialized sorting value of each account; calling a bank-enterprise direct connection interface to query the balance or transaction details of the accounts in the current batch; calculating an average transaction number interval based on the transaction number of each account and adopting a zero-elimination average method; respectively calculating a new basic weight value, a historical transaction weight value and a real-time transaction weight value by adopting a specific calculation method; generating an account weight value; generating a new sorting value for each account in the current batch according to the account weight value; screening out accounts to be queried in the next batch of the current batch according to the new sorting value; and stopping until a preset iteration number is reached, completing the polling scheduling of the enterprise account query and being suitable for efficient query scheduling scenes in a large-scale bank account environment.

Description

Technical Field

[0001] This invention relates to the fields of financial technology and system scheduling technology, specifically to a multi-dimensional dynamic weighted round-robin scheduling method and system for direct bank-enterprise query. Background Technology

[0002] With the continuous improvement of enterprise financial management informatization, the bank-enterprise direct connection system, as a bridge connecting the enterprise's financial system and the bank's core system, plays an important role in business scenarios such as fund management, account reconciliation, and automatic reconciliation. This system is the core channel for real-time interaction between enterprises and banks. Enterprises conduct high-frequency queries (including account balances, transaction records, etc.) through the bank interface. Traditional polling query schemes are basically simple polling scheduling, with fixed intervals and a fixed number of accounts queried each time. This results in a fixed time interval between two queries for the same account. Distinguishing between frequently accessed accounts requires manual identification, placing them in a polling schedule with shorter intervals. A better approach is to set a query interval for the polling schedule (e.g., once every 10 minutes), and the system periodically initiates query requests according to a preset frequency, selecting a fixed number of accounts for each query in a fixed order. This scheduling method is simple in structure and easy to implement, and therefore widely used in early applications.

[0003] However, with the rapid growth in the number of enterprise accounts and the increasing differentiation of transaction behaviors, the traditional fixed polling mechanism has exposed a series of significant problems: 1) Serious resource waste: Query resources are wasted on dormant accounts (accounts that have not had any transaction activity in the banking system for a long time), and data for hot accounts accumulates. At the same time, there is a desire to be able to retrieve account balances and transaction records promptly after a transaction. 2) High response latency: Hot accounts (such as high-frequency trading accounts) are prone to data accumulation due to limited query frequency, making it impossible to obtain the latest account status in a timely manner, affecting the enterprise's ability to perceive changes in funds in real time. 3) Lack of dynamic adaptability: Account transaction behavior has obvious time-varying and sudden characteristics, while traditional scheduling strategies cannot make corresponding adjustments based on the account's historical behavior or real-time events. The scheduling strategy is rigid and difficult to adapt to complex and ever-changing business needs. 4) High cost of manual intervention: To alleviate the above problems, some systems have attempted to configure high-frequency accounts separately into higher-frequency scheduling queues. However, this method relies on manual identification of account activity and requires continuous maintenance of multiple scheduling strategies, which is cumbersome and error-prone, increasing operation and maintenance costs. 5) Lack of intelligent scheduling mechanism: Existing solutions generally lack an adaptive scheduling mechanism based on account behavior characteristics, failing to effectively combine historical trends and real-time events to optimize query priorities. The scheduling process lacks intelligence and foresight. In addition, although some studies have proposed scheduling methods based on machine learning or predictive models, their high algorithm complexity and deployment costs make them difficult to implement quickly in real-world production environments, especially when facing large-scale concurrent account queries, where performance bottlenecks exist.

[0004] In summary, no existing technology offers an intelligent scheduling method that can balance resource efficiency with data real-time performance. Therefore, there is an urgent need to propose a novel scheduling method that can dynamically adjust query frequency based on account transaction behavior to improve the intelligence level and operational efficiency of bank-enterprise direct connection systems. Summary of the Invention

[0005] To address the problems of low resource utilization leading to wasted query resources, poor response timeliness, lack of dynamic adaptability, and high labor costs in current bank-enterprise direct connection query processes, this invention provides a multi-dimensional dynamic weighted round-robin scheduling method for bank-enterprise direct connection queries. This method dynamically adjusts the query priority and frequency of each account based on its historical transactions, real-time transactions, and transaction proportions, thereby achieving efficient utilization of query resources and timely feedback of account data. This invention also relates to a multi-dimensional dynamic weighted round-robin scheduling system for bank-enterprise direct connection queries.

[0006] The technical solution of the present invention is as follows:

[0007] A multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries, characterized by the following steps:

[0008] S1: Obtain account information for all accounts of the enterprise, initialize the sorting value for each account, and generate a sorting value sequence; the account information includes the number of transactions, balance, transaction details, and total number of accounts;

[0009] S2: Based on the number of transactions for each account in the previous time period, the average number of transactions in the previous time period is calculated using the zero-removal averaging method. The expected weight value for each account in the current time period is dynamically calculated based on the comparison between the number of transactions in the previous time period and the average number of transactions in the previous time period. The base weight value for each account is then initialized and used as the original base weight value. The minimum weight value is calculated based on the original base weight value for each account, the maximum time interval between two consecutive queries for the same account (preset), the number of accounts processed in each round, and the interval between two consecutive rounds. The maximum weight value is calculated based on the sum of the original base weight values ​​for all accounts, the total number of accounts, and the number of accounts processed in each round. The system is segmented based on the relationship between the expected weight value and the original base weight value, and a new base weight value is calculated segmented by combining the minimum weight value, the maximum weight value, the original base weight value, the expected weight value, and the preset maximum single adjustment range.

[0010] S3: Calculate the historical transaction weight value based on the number of transactions of an account in a certain time period of the day and the historical average number of transactions in the same time period; then divide the account into segments based on the relationship between the transaction time of the latest transaction and the latest query time of the account, and calculate the real-time transaction weight value in combination with the polling cycle.

[0011] S4: Based on the initial sort value of each account in the sort value sequence, filter out the accounts to be queried in the current batch, and call the bank-enterprise direct connection interface to initiate an instruction to query the balance or transaction details of the accounts in the current batch; after the bank-enterprise direct connection interface instruction is completed, generate a new sort value for each account in the current batch based on multi-dimensional weight values ​​including new basic weight value, historical transaction weight value and real-time transaction weight value, and use the new sort value to update the corresponding initial sort value in the sort value sequence to obtain a new sort value sequence, and filter out the accounts to be queried in the next batch of the current batch based on the new sort value sequence;

[0012] S5: Based on the accounts to be queried in the next batch of the current batch, repeat the principle process of steps S1 to S4 until the preset number of iterations is reached, thus completing the polling schedule for enterprise account queries.

[0013] Preferably, in step S2, dynamically calculating the expected weight value for each account in the current time period based on the comparison between the number of transactions for each account in the previous time period and the average number of transactions in the range specifically includes:

[0014] If the number of transactions in the previous time period is less than the minimum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the minimum value of the average number of transactions range; if the number of transactions in the previous time period is greater than the maximum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the maximum value of the average number of transactions range; if the number of transactions in the previous time period is within the average number of transactions range, the expected weight value is equal to the preset benchmark value.

[0015] Preferably, in step S2, segmenting the data according to the relationship between the expected weight value and the original base weight value, and calculating the new base weight value segment by segment based on the minimum weight value, maximum weight value, original base weight value, expected weight value, and preset maximum single adjustment range value, specifically includes:

[0016] When the expected weight value is greater than the original basic weight value, the new basic weight value is calculated as follows: first, take the smaller value between the sum of the original basic weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the smaller value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value.

[0017] When the expected weight value is less than or equal to the original base weight value, the new base weight value is calculated as follows: first, take the larger value between the difference between the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the smaller value between the larger value and the maximum weight value; and finally, take the larger value between the smaller value and the minimum weight value.

[0018] Preferably, in step S3, an account weight value is generated based on a multi-dimensional weight value including a new basic weight value, a historical transaction weight value, and a real-time transaction weight value. After generating the account weight value, the activity level of each account is automatically identified based on the account weight value. Based on the activity level, all accounts are automatically divided into hot accounts and non-hot accounts, and the query frequency of hot accounts and non-hot accounts is dynamically adjusted.

[0019] Preferably, in step S3, segmenting an account based on the relationship between the transaction time of the latest transaction and the latest query time of that account, and calculating the real-time transaction weight value in segments in conjunction with the polling cycle, specifically includes:

[0020] If the transaction time of the latest transaction of an account is greater than the latest query time of the account, the real-time transaction weight value is calculated based on the difference between the transaction time and the query time of the previous batch, the ratio of the polling cycle, and the real-time transaction factor.

[0021] If the transaction time of the latest transaction of an account is less than or equal to the time of the latest query of the account, the real-time transaction weight value is zero.

[0022] A multi-dimensional dynamic weighted round-robin scheduling system for direct bank-enterprise connection queries is characterized by comprising, in sequence, an account information acquisition and sorting value initialization module, a basic weight value calculation module, a historical and real-time transaction weight calculation module, a new sorting value generation and account filtering module, and a round-robin scheduling iterative execution module.

[0023] The account information acquisition and sorting value initialization module acquires the account information of all accounts of the enterprise and initializes the sorting value of each account to generate a sorting value sequence; the account information includes the number of transactions, balance, transaction details and total number of accounts;

[0024] The basic weight value calculation module calculates the average number of transactions for each account in the previous time period based on the number of transactions for the current time period, using a zero-average method. It then dynamically calculates the expected weight value for each account in the current time period based on the comparison between the number of transactions for the previous time period and the average number of transactions range. Next, it initializes the basic weight value for each account as the original basic weight value. The module calculates the minimum weight value based on the original basic weight value, the maximum time interval between two consecutive queries for the same account, the number of accounts processed in each round, and the interval between two consecutive rounds. Finally, it calculates the maximum weight value based on the sum of the original basic weight values ​​for all accounts, the total number of accounts, and the number of accounts processed in each round. The module then segments the data according to the relationship between the expected weight value and the original basic weight value, and calculates a new basic weight value by combining the minimum weight value, the maximum weight value, the original basic weight value, the expected weight value, and the maximum single adjustment range.

[0025] The historical and real-time transaction weight calculation module calculates the historical transaction weight value based on the number of transactions of an account in a certain time period of the day and the historical average number of transactions in the same time period. Then, it divides the account into segments based on the relationship between the transaction time of the latest transaction and the latest query time of the account, and calculates the real-time transaction weight value in segments in combination with the polling cycle.

[0026] The new sorting value generation and account filtering module filters out the accounts to be queried in the current batch based on the initial sorting value of each account in the sorting value sequence, and calls the bank-enterprise direct connection interface to initiate an instruction to query the balance or transaction details of the accounts in the current batch; after the bank-enterprise direct connection interface instruction is completed, a new sorting value is generated for each account in the current batch based on a multi-dimensional weight value including the new basic weight value, historical transaction weight value and real-time transaction weight value, and the new sorting value is used to update the corresponding initial sorting value in the sorting value sequence to obtain a new sorting value sequence, and the next batch of accounts to be queried in the current batch is filtered out based on the new sorting value sequence;

[0027] The polling scheduling iterative execution module, based on the accounts to be queried in the next batch of the current batch, repeats the principle process from the account information acquisition and sort value initialization module to the new sort value generation and account filtering module until the preset number of iterations is reached, thus completing the polling scheduling of enterprise account queries.

[0028] Preferably, in the basic weight value calculation module, the expected weight value for each account in the current time period is dynamically calculated based on the comparison between the number of transactions of each account in the previous time period and the average number of transactions in the range. This specifically includes:

[0029] If the number of transactions in the previous time period is less than the minimum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the minimum value of the average number of transactions range; if the number of transactions in the previous time period is greater than the maximum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the maximum value of the average number of transactions range; if the number of transactions in the previous time period is within the average number of transactions range, the expected weight value is equal to the preset benchmark value.

[0030] Preferably, in the basic weight value calculation module, the calculation of the new basic weight value by segmenting according to the relationship between the expected weight value and the original basic weight value, and combining the minimum weight value, the maximum weight value, the original basic weight value, the expected weight value, and the preset maximum single adjustment range value, specifically includes:

[0031] When the expected weight value is greater than the original basic weight value, the new basic weight value is calculated as follows: first, take the smaller value between the sum of the original basic weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the smaller value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value.

[0032] When the expected weight value is less than or equal to the original base weight value, the new base weight value is calculated as follows: first, take the larger value between the difference between the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the smaller value between the larger value and the maximum weight value; and finally, take the larger value between the smaller value and the minimum weight value.

[0033] Preferably, in the historical and real-time transaction weight calculation module, an account weight value is generated based on a multi-dimensional weight value including a new basic weight value, a historical transaction weight value, and a real-time transaction weight value. After generating the account weight value, the activity level of each account is automatically identified based on the account weight value. Based on the activity level, all accounts are automatically divided into hot accounts and non-hot accounts, and the query frequency of hot accounts and non-hot accounts is dynamically adjusted.

[0034] Preferably, in the historical and real-time transaction weight calculation module, the real-time transaction weight value is calculated by segmenting the data based on the relationship between the transaction time of the latest transaction of an account and the latest query time of the account, and in conjunction with the polling cycle. Specifically, this includes:

[0035] If the transaction time of the latest transaction of an account is greater than the latest query time of the account, the real-time transaction weight value is calculated based on the difference between the transaction time and the query time of the previous batch, the ratio of the polling cycle, and the real-time transaction factor.

[0036] If the transaction time of the latest transaction of an account is less than or equal to the time of the latest query of the account, the real-time transaction weight value is zero.

[0037] The technical effects of this invention are as follows:

[0038] This invention provides a multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise queries. First, it acquires account information for all enterprise accounts and initializes the sorting value for each account to generate a sorting value sequence, ensuring fairness in the initial query. Then, based on the number of transactions for each account in the previous time period, it calculates the average number of transactions in the previous time period using a zero-removal averaging method. Finally, based on the comparison between the number of transactions for each account in the previous time period and the average number of transactions range, it dynamically calculates the expected weight value for each account in the current time period. By using the zero-removal averaging method to eliminate interference from accounts with zero transactions, it effectively removes outlier interference and accurately reflects the true average transaction level of all accounts. Based on the comparison between the number of transactions for each account in the previous time period and the average number of transactions in the range, the expected weight value for each account in the current time period is dynamically calculated. This involves converting the relative proportion of transaction counts into a weight value and establishing a linear relationship between transaction proportion and weight. The design goal of the basic weight is to make the proportion of account queries tend to be close to its proportion of transaction counts, that is, accounts with a high transaction proportion receive higher query priority. Then, the basic weight value of each account is initialized and used as the original basic weight value. A specific calculation method is used to calculate the minimum weight value and the maximum weight value. The minimum weight value and the maximum weight value are used to constrain the weight boundary to ensure that the maximum query interval of the same account meets the minimum frequency control requirements, forming a dynamic weighting mechanism. The minimum weight value guarantees the longest instruction query interval time of the account. In other words, by controlling the low frequency, the maximum query interval time of the same account is controlled. Even accounts that have been dormant for a long time can have their account balance and transaction history retrieved in a timely manner within the longest interval after a transaction, ensuring that even low-frequency accounts are not completely ignored. The maximum weight value ensures that the account is screened in each scheduling cycle of the bank-enterprise direct connection query, preventing high-frequency accounts (hot accounts) from consuming too many resources. The system segments the system based on the relationship between the expected weight value and the original base weight value. It then calculates the new base weight value by combining the minimum weight value, the maximum weight value, the original base weight value, the expected weight value, and the preset maximum single adjustment range value. This achieves dynamic weighted adjustment of the base weight. The maximum single adjustment range value controls the smooth transition of the weight, effectively avoiding scheduling instability caused by sudden weight changes. This improves the accuracy and rationality of weight calculation, and the maximum single adjustment range limit effectively avoids scheduling oscillations caused by sudden weight changes.Then, specific calculation methods are used to calculate historical transaction weight values ​​to reflect the transaction patterns of accounts within similar time periods (such as peak periods at the end of the month), allowing for advance adjustment of query frequency and improved prediction accuracy. Furthermore, the system is segmented based on the relationship between the transaction time of an account's latest transaction and the time of its latest query, and real-time transaction weight values ​​are calculated segmented according to the polling cycle. Through weighted calculations of historical and real-time dimensions, a multi-dimensional weighting system is perfected, resulting in multi-dimensional weight values ​​including new basic weight values, historical transaction weight values, and real-time transaction weight values. This can be understood as constructing a multi-dimensional dynamic weight calculation model that comprehensively considers an account's historical transaction situation, real-time transaction situation, and the proportion of the account's total number of transactions to the total number of transactions over a period of time. It considers the account's historical transactions, current transactions, and transaction proportions from multiple dimensions. Real-time transaction weight values ​​can quickly increase account priority after a transaction occurs, ensuring timely data updates and achieving event-driven response. The account weight values ​​affecting account ranking can be expanded and customized according to specific scenarios. After the direct bank-enterprise connection interface command is invoked, a new ranking value is generated for each account in the current batch based on the new basic weight value, historical transaction weight value, and real-time transaction weight value. This weighted result directly affects the dynamic scheduling of account query order. The next direct bank-enterprise connection scheduling will select the next batch of accounts to send query commands based on the new ranking value, realizing a closed-loop feedback in the scheduling process, improving the system's intelligence level, reducing computational overhead, and improving filtering efficiency. Each time, the direct bank-enterprise connection query scheduling repeatedly filters based on the ranking values ​​of all accounts, sends direct bank-enterprise connection query commands, calculates and updates the ranking value based on the account's basic weight value, historical transaction weight value, and real-time transaction weight value, completing the polling scheduling of enterprise account queries. This not only solves the problems of resource waste and response delay in traditional fixed polling scheduling, but also improves the flexibility, stability, and real-time performance of the direct bank-enterprise connection system in account queries by introducing an intelligent scheduling mechanism, demonstrating good engineering application prospects and promotional value.

[0039] This invention solves the problems of resource waste, response delay, and scheduling rigidity in traditional fixed-period polling by dynamically adjusting multi-dimensional weights (basic + historical + real-time) and using a closed-loop feedback mechanism, significantly improving system scheduling efficiency and the real-time performance of data updates. It achieves the following significant effects: 1) High resource utilization: By basing queries on an account's historical transaction behavior and long-term adjusted basic weight values, frequently traded accounts receive higher query priority. This means accounts with high transaction volumes have shorter query intervals and higher query resource utilization. For example, when an account's transaction frequency is significantly higher than average, the system gradually increases its new basic weight value, reducing its query interval from 15 minutes to 3 minutes, significantly improving data update frequency and query efficiency. Conversely, for low-frequency accounts, the query frequency is reduced accordingly, minimizing unnecessary interface calls and resource waste, thus significantly improving the overall resource utilization efficiency of the bank-enterprise direct connection system.

[0040] 2) Strong Real-Time Dynamic Adjustment Capability: By introducing a real-time transaction weighting mechanism, the system can detect changes in account transaction activity and dynamically adjust account weight values. Immediately after a transaction occurs, the system increases the account's real-time transaction weight value, rapidly increasing the query frequency and ensuring quick retrieval of transaction details and balance information. This achieves event-driven rapid response. For example, once an account has a transaction, the system will increase the query frequency of the account's balance and transaction details, effectively ensuring data timeliness and accuracy, and meeting the enterprise's real-time monitoring needs for fund changes.

[0041] 3) Historical transaction weighting enhances predictive ability: By calculating historical transaction weight values, the potential activity of an account can be predicted within similar time periods. For example, if an account usually trades frequently at 10:00 AM but has not traded on the same day, the system will still appropriately increase its weight to maintain a certain level of attention and prevent missing possible trading peaks, thereby improving the foresight and robustness of the scheduling strategy.

[0042] 4) Low computational overhead and high execution efficiency: By using the account sorting value instead of directly using the account weight value to filter the accounts to be queried in the current batch, the account filtering process can be completed with only one sorting, and the scheduling complexity is O(1) (a measure of algorithm complexity, representing time complexity), which greatly reduces the computational overhead and improves the execution efficiency of the scheduling algorithm, especially suitable for application scenarios with a large number of accounts and high scheduling frequency.

[0043] 5) Intelligent Account Type Differentiation: The system automatically identifies popular and non-popular accounts based on their account weight values ​​and assigns them different query frequencies. For example, for high-frequency trading accounts, the system gradually increases their base weight and real-time trading weight, shortening their query interval from 15 minutes to 3 minutes; while for inactive accounts that have not traded for a long time, the system appropriately reduces their overall weight value and extends the query cycle, thereby achieving optimal resource allocation and intelligent management.

[0044] 6) Robust minimum frequency control mechanism: By pre-setting the maximum time interval between two consecutive queries for each account, it ensures that the account is queried at least once within the preset time, even if the account is in a state of no transactions. For example, setting the maximum time interval to 30 minutes can prevent inactive accounts from being completely ignored due to long-term inactivity, ensuring the integrity and security of account data and meeting compliance requirements.

[0045] 7) Stable scheduling process, avoiding oscillations: By setting minimum and maximum weight values, as well as a maximum limit on the magnitude of a single adjustment, the change in basic weights is ensured to be gradual and smooth, avoiding scheduling instability caused by sudden changes. This smooths out excessive weight changes and controls the automatic weight offset each time to prevent oscillations caused by sudden weight changes. For example, even if an account experiences a surge in trading volume in a short period, its weight will not spike all at once, but will gradually approach the ideal value, thus maintaining the stability and consistency of system operation.

[0046] 8) Modular design and easy expansion: By separating the bank-enterprise direct connection interface query scheduling from the account weight update logic, the two are designed to operate independently without interference, with clear functions. For example, the corresponding account sorting value is adjusted using the current batch of account weight values ​​after the bank-enterprise direct connection interface call is completed. That is, the sorting value is updated only after the current batch of account queries is completed, without affecting the ongoing interface call task. This improves the system's stability and provides good architectural support for subsequent function expansion and technology iteration.

[0047] This invention also relates to a multi-dimensional dynamic weighted round-robin scheduling system for direct bank-enterprise connection queries. This system corresponds to the aforementioned multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries. It can be understood as a system that implements the aforementioned multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries. It includes, in sequence, an account information acquisition and sorting value initialization module, a basic weight value calculation module, a historical and real-time transaction weight calculation module, a new sorting value generation and account filtering module, and a round-robin scheduling iterative execution module. These modules work collaboratively to evaluate account activity levels by comprehensively considering three dimensions: basic weight, historical transaction weight, and real-time transaction weight, thus providing a more comprehensive reflection of the account's true status. Specifically, the basic weight reflects long-term trends, the historical weight identifies periodic patterns, and the real-time weight responds to sudden changes. The synergistic effect of these three factors enhances the scientific nature and adaptability of scheduling decisions, avoiding biases and misjudgments caused by single indicators. Attached Figure Description

[0048] Figure 1 This is a flowchart of the multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise query, as described in this invention.

[0049] Figure 2 This is a schematic diagram illustrating the working principle of the multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise query in this invention. Detailed Implementation

[0050] The present invention will now be described with reference to the accompanying drawings.

[0051] This invention relates to a multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise query, which optimizes the high-frequency account data interaction process between enterprises and banks, improves query resource utilization and real-time response. The flowchart of this method is as follows: Figure 1 As shown, the schematic diagram is as follows: Figure 2 The aforementioned system primarily includes one bank-enterprise direct connection polling scheduler and three weight adjustment schedulers (expandable): basic weight adjustment scheduler, historical transaction weight adjustment scheduler, and real-time transaction weight adjustment scheduler. It also features scalability. The system comprises the following steps:

[0052] S1: The bank-enterprise direct connection polling scheduler obtains the account information of all enterprise accounts and initializes the sorting value of each account (the initial sorting value of each account is 0 every day), generating a sorting value sequence; the account information includes the number of transactions, balance, transaction details, total number of accounts, account number, account name, currency, account type, account status, bank code, last (most recent) balance query time, and last (most recent) details query time, etc.; among which, the sorting value of all accounts is reset to 0 every day.

[0053] S2: The basic weight adjustment scheduling is based on the number of transactions for each account in the previous time period (e.g., the previous day) and uses a zero-average method to calculate the average number of transactions in the previous time period. Then, based on the comparison between the number of transactions for each account in the previous time period and the average number of transactions in the previous time period, the expected weight value for the current time period is dynamically calculated. The basic weight value for each account is then initialized and used as the original basic weight value. The minimum weight value is calculated based on the original basic weight value for each account, the preset maximum time interval between two consecutive queries for the same account, the number of accounts processed in each round, and the interval between two consecutive rounds. The maximum weight value is calculated based on the sum of the original basic weight values ​​for all accounts, the total number of accounts, and the number of accounts processed in each round. Finally, the system segments the data according to the relationship between the expected weight value and the original basic weight value, and calculates the new basic weight value segment by combining the minimum weight value, the maximum weight value, the original basic weight value, the expected weight value, and the preset maximum single adjustment range.

[0054] Specifically, firstly, based on the number of transactions for each account in the previous time period, and using the zero-removal and halving method, the average number of transactions in the previous time period is calculated according to the following formula:

[0055]

[0056] Then, based on the comparison between the number of transactions for each account in the previous time period and the average number of transactions in the previous time period, the expected weight value for each account in the current time period is dynamically calculated. Specifically, if the number of transactions in the previous time period is less than the minimum value of the average number of transactions in the previous time period, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the minimum value of the average number of transactions in the previous time period; if the number of transactions in the previous time period is greater than the maximum value of the average number of transactions in the previous time period, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the maximum value of the average number of transactions in the previous time period; if the number of transactions in the previous time period is within the average number of transactions in the previous time period, the expected weight value is equal to a preset benchmark value (e.g., a benchmark value of 1), as shown in the following formula:

[0057]

[0058] For example, suppose there are 10 accounts with the following transaction counts from the previous day: [0, 5, 8, 12, 15, 18, 20, 25, 30, 0]. Excluding accounts with 0 transactions, the remaining accounts are [5, 8, 12, 15, 18, 20, 25, 30]. Calculate the average transaction count for the remaining accounts: Average = (5 + 8 + 12 + 15 + 18 + 20 + 25 + 30) / 8 = 16.625. Set the interval as [average × 0.8, average × 1.2] = [13.3, 19.95]. If account A's transaction count from the previous day = 15 ∈ [13.3, 19.95] → W 期望权重值 =1; If account B's number of transactions the previous day = 3 < 13.3 → W 期望权重值 =3 / 13.3≈0.23; If account D's number of transactions the previous day = 25 > 19.95 → W 期望权重值 =25 / 19.95≈1.25.

[0059] Then, based on the original base weight value O of each account, the preset maximum time interval δ between two consecutive queries for the same account, the number of accounts processed (queried) in each round, and the interval between two consecutive rounds (also known as the interval between each round), the minimum weight value is calculated according to the following formula:

[0060]

[0061] By setting a maximum time interval between two consecutive queries, with a default value of 60 minutes, the minimum weight value ensures that an account will be queried at least once within this time interval, even if the account has not had any transactions for a long period. This mechanism prevents inactive accounts from being completely ignored due to prolonged inactivity, ensuring the integrity and security of account data and meeting compliance requirements.

[0062] Then, the maximum weight value is calculated based on the sum of the original base weight values ​​of all accounts, the total number of accounts, and the number of accounts processed in each round, using the following formula:

[0063]

[0064] Then, based on the relationship between the expected weight value and the original base weight value for each account, the account is segmented. The new base weight value for each account is then calculated segment by segment, taking into account the minimum weight value, maximum weight value, original base weight value, expected weight value, and the preset maximum single adjustment range. That is, when the expected weight value W... 期望权重值When (abbreviated as W) is greater than the original base weight value O, the new base weight value is calculated as follows: First, take the smaller value MIN(O+δ,W) between the sum of the original base weight value and the maximum single adjustment amplitude value O+δ and the expected weight value W. Then, take the minimum value MIN(maximum weight value, MIN(O+δ,W)) between the smaller value MIN(O+δ,W) and the maximum weight value. Finally, take the larger value MAX(minimum weight value, MIN(maximum weight value, MIN(O+δ,W))) between the minimum value MIN(maximum weight value, MIN(O+δ,W)) and the minimum weight value. When the expected weight value W... 期望权重值 When (abbreviated as W) is less than or equal to the original base weight value O, the new base weight value is calculated as follows: First, take the larger value MAX(O-δ,W) between the difference between the original base weight value and the maximum single adjustment amplitude value O-δ and the expected weight value W. Then, take the smaller value MIN(maximum weight value,MAX(O-δ,W)) between the larger value MAX(O-δ,W) and the maximum weight value. Finally, take the larger value MAX(minimum weight value,MIN(maximum weight value,MAX(O-δ,W))) between the minimum value MIN(maximum weight value,MAX(O-δ,W)) and the minimum weight value, as shown in the following formula:

[0065]

[0066] Where O is the original base weight value, W is the expected weight value, and δ is the maximum single adjustment amplitude, which controls the maximum change and makes the weight change smoother, without fluctuations. The segmented and step-by-step calculation of this new base weight value reflects the constraints and constraint levels, thereby more accurately defining the rules of the technical solution.

[0067] When calculating the new base weight value (which can also be understood as updating the base weight value), the system first calculates the proportion of the account's transactions from the previous day to the total number of transactions, and compares this to the proportion of its current base weight to the total weight of all accounts (i.e., the total weight). If the transaction percentage is greater than the weight percentage, it indicates that the account is actively trading but has a low weight, and its base weight will be appropriately increased; conversely, it will be appropriately decreased. Simultaneously, a target weight value is calculated for the account, and the base weight value is gradually adjusted towards this target weight value using linear or non-linear interpolation. Furthermore, to prevent sudden weight changes from affecting scheduling stability, a maximum single adjustment range is set, limiting the range of changes in the base weight value each time. For accounts with long-term inactivity, the system also sets a minimum query frequency to ensure that even with a low weight, the account is queried periodically, ensuring at least one query within the maximum time interval to prevent data loss. This achieves intelligent, stable, and controllable adjustment of account weights, ensuring the real-time data of high-frequency accounts while also considering the overall stability and resource utilization of the system.

[0068] S3: The historical transaction weight adjustment scheduling calculates the historical transaction weight value based on the number of transactions of an account in a certain time period of the day and the historical average number of transactions in the same time period. The real-time transaction weight adjustment scheduling calculates the real-time transaction weight value based on the relationship between the transaction time of a certain account's latest transaction and the time of the account's latest query, combined with the polling cycle. The account weight value is generated based on the new basic weight value, the historical transaction weight value and the real-time transaction weight value.

[0069] Specifically, historical transaction weights are adjusted shortly based on historical transaction data within the same time period. The historical transaction weight adjustment schedule compares the average number of transactions over the most recent time (e.g., the last two weeks) and characteristic dates (same day last week, same day last month, beginning of the month, end of the month, etc.) within the same time period (e.g., two hours before and after the current time) with the number of transactions within the same time period on the current day, adjusting the historical transaction weight value accordingly. The historical transaction weight value is calculated based on the number of transactions by the account during a specific time period on the current day, and the historical average number of transactions for the same time period, using the following formula:

[0070]

[0071] Specifically, transactions within a given time period are accelerated when the number of transactions is less than the historical average, and decelerated when the number of transactions exceeds the historical average. A deceleration offset is configured, and deceleration only occurs when the ratio of the current number of transactions to the historical average exceeds this offset. In other words, if an account's number of transactions in the current time period is lower than its historical average, the system considers the account "potentially about to become active" and increases its weight in advance ("accelerated"). If an account's number of transactions in the current time period is higher than its historical average, the system considers it "already very active" and appropriately reduces its weight ("decelerated"). Furthermore, not all instances of "above the historical average" result in immediate deceleration; instead, a "deceleration offset" is set, and the deceleration mechanism is only triggered when the ratio of the current number of transactions to the historical average exceeds this offset.

[0072] For example, when the historical transaction weight adjustment is executed at 10:00 AM, the system calculates the historical average number of transactions within the same time period (9:00 AM to 11:00 AM) on historical characteristic dates. Historical characteristic dates include the past 14 days, the same day of the previous month, and, if the current day is the beginning or end of the month, the beginning or end of the previous month. The system compares the number of transactions in the current (daytime) time period (9:00 AM to 11:00 AM) with the historical average number of transactions, and makes a judgment based on a preset deceleration offset value: If the current number of transactions is less than the historical average number of transactions, it indicates that the account's current activity level is lower than historical levels, and the system will appropriately increase its historical transaction weight to enhance its visibility; if the current number of transactions is greater than the historical average number of transactions, but its ratio to the historical average number of transactions does not exceed the deceleration offset value, the historical transaction weight will be maintained or slightly increased; if the current number of transactions is significantly higher than the historical average number of transactions (i.e., ratio > deceleration offset value), the system determines that the account is in a high-activity state and will appropriately reduce its weight to avoid excessive resource allocation. Through the above mechanism, the system can intelligently adjust based on the account's historical transaction history and make short-term adjustments based on the account's usage habits.

[0073] Real-time transaction weighting increases an account's weight after each transaction, enabling faster retrieval of account balances and transaction history. The real-time transaction weighting adjustment is based on the interval between the latest transaction time and the last query time. It segments the account based on the relationship between the transaction time of the latest transaction (i.e., the latest / most recent transaction time) and the account's last query time (which can also be understood as the account's last query time, or the last bank-enterprise direct connection query scheduling time), and calculates the real-time transaction weight value segmented according to the polling cycle, using the following formula:

[0074]

[0075] After a transaction occurs, the system increases the frequency of subsequent queries, shortening the time to retrieve account balances and transaction details. Specifically, whenever an account makes a transaction, the system immediately triggers an event monitoring mechanism, identifying factors such as transaction type (e.g., incoming / outgoing), transaction amount, and whether it occurred on a holiday, calculating a real-time transaction weight increment, and adding it to the current account's real-time transaction weight value. For example, if an account makes a large transfer at 3:00 PM, the system will immediately increase its real-time transaction weight by 20%, ensuring that the account is prioritized in the next batch of scheduling. Through this mechanism, the system can respond quickly after an account makes a transaction, retrieving the latest balance and transaction details within 5 minutes, effectively ensuring the timeliness and accuracy of data and meeting the enterprise's real-time monitoring needs for fund changes.

[0076] Finally, an account weight value is generated based on the new base weight value, historical transaction weight value, and real-time transaction weight value. After generating the account weight value, the activity level of each account is automatically identified based on the account weight value. All accounts are automatically classified into hot and non-hot accounts based on activity level, and the query frequency of hot and non-hot accounts is dynamically adjusted. The base weight changes over time, gradually causing the proportion of account queries to converge with the proportion of account transactions, with hot accounts showing high query frequency and short intervals between queries. The change in base weight is smoother, avoiding sudden weight fluctuations.

[0077] S4: Based on the initial sort value of each account in the sort value sequence, filter out the accounts to be queried in the current batch, and call the bank-enterprise direct connection interface to initiate an instruction to query the balance or transaction details of the accounts in the current batch; after the bank-enterprise direct connection interface instruction is completed, generate a new sort value for each account in the current batch based on multi-dimensional weight values ​​including new basic weight value, historical transaction weight value and real-time transaction weight value, and use the new sort value to update the corresponding initial sort value in the sort value sequence to obtain a new sort value sequence, and filter out the accounts to be queried in the next batch of the current batch based on the new sort value sequence.

[0078] Specifically, the bank-enterprise direct connection system's polling query scheduler periodically selects a fixed number (e.g., 10) of accounts to call the bank-enterprise direct connection interface to query account balances or transaction details. Using the account sorting value to sort from smallest to largest can quickly filter out the accounts to call the interface in the current batch. Therefore, the accounts to be queried in the current batch are selected based on the initial sorting value of each account in the sorting value sequence. For example, if the initial sorting value in the sorting value sequence is 0, then 10 accounts are randomly selected from the sorting value sequence as the accounts to be queried in the current batch. After selecting the accounts, the bank-enterprise direct connection interface is called using the accounts in this batch to initiate the command to query the balance or transaction details of the accounts in the current batch.

[0079] After the direct bank-enterprise connection interface instruction is invoked in step S1, a new sorting value is generated for each account in the current batch based on the new basic weight value, historical transaction weight value, and real-time transaction weight value. The new sorting value is calculated according to the following formula:

[0080]

[0081] Among them, WH is the historical transaction weight, and WT is the real-time transaction weight. The larger the weight value, the smaller the increase in the ranking value, the smaller the time interval for account query, and the faster the query frequency.

[0082] Then, update the corresponding initialized sort value in the sort value sequence with the new sort value to obtain a new sort value sequence. Based on the new sort value sequence, filter out the accounts to be queried in the next batch of the current batch.

[0083] S5: The bank-enterprise direct connection polling scheduling is based on the accounts to be queried in the next batch of the current batch, and repeats the principle process of steps S1 to S4 until the preset number of iterations is reached, thus completing the polling scheduling of enterprise account queries.

[0084] This invention provides a multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries, such as... Figure 2 The working principle illustrated revolves around account sorting and weight adjustment, driving the bank-enterprise direct connection query process. After the bank-enterprise direct connection polling and scheduling is initiated, it filters the batch of accounts to be queried according to rules, driving subsequent account sorting and weight calculation; this is the initial trigger point of the process. Account filtering and sorting are key upstream steps. The sorting value calculation is based on the account sorting value, selecting the accounts to be queried in the current batch from the accounts to be queried, determining "which accounts to query first," acting as the process's "filter." The filtered accounts are used to call the bank-enterprise direct connection interface. After the interface call is completed, the account sorting value is adjusted in reverse based on the result, forming a closed loop of "filtering-execution-feedback adjustment," ensuring dynamic optimization of the sorting. The account weight system, formed by multi-dimensional weight adjustment and scheduling, is the core control logic. Account weights are divided into three categories: basic weights, historical transaction weights, and real-time transaction weights. Each is dynamically adjusted through different scheduling logics, jointly determining the account ranking priority: Basic weights: Adjusted based on the percentage difference, combined with constraints such as "expected weight adjustment range and minimum frequency," and using data such as the previous day's weight and the proportion of transaction counts, forming the baseline framework for weights; Historical transaction weights: Associated with characteristic dates (same day last week, same day last month, etc.), calculating the average proportion of transaction counts on similar dates, influencing weights from the perspective of historical patterns, reflecting historical behavioral inertia; Real-time transaction weights: Based on the time difference of the most recent transaction and real-time transaction weight factors (linked to the bank-enterprise direct connection scheduling time), focusing on current transaction dynamics, allowing weights to reflect the latest business situation, and achieving real-time dynamic control. These weights are continuously updated through corresponding scheduling (basic / historical / real-time transaction weight adjustment scheduling), accurately controlling the account query priority, ensuring that the bank-enterprise direct connection polling both conforms to historical patterns and keeps up with real-time business changes. This invention features a closed loop of execution and feedback. The selected accounts are used to call the bank-enterprise direct connection interface to check the balance and transaction details, thus completing the actual business query. After the interface call ends, the weight of the current batch of accounts is adjusted and the sorting value is updated based on the results, so that the account selection and weight of the next round of scheduling are more reasonable, forming a complete closed loop of "scheduling-execution-optimization" to ensure that the process continuously adapts to business needs.

[0085] This invention also relates to a multi-dimensional dynamic weighted round-robin scheduling system for direct bank-enterprise connection queries. This system corresponds to the aforementioned multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries and can be understood as a system implementing the aforementioned method. The system includes, in sequence, an account information acquisition and sorting value initialization module, a basic weight value calculation module, a historical and real-time transaction weight calculation module, a new sorting value generation and account filtering module, and a round-robin scheduling iterative execution module. Specifically,

[0086] The account information acquisition and sorting value initialization module acquires the account information of all accounts of the enterprise and initializes the sorting value of each account to generate a sorting value sequence; the account information includes the number of transactions, balance, transaction details and total number of accounts;

[0087] The basic weight value calculation module calculates the average number of transactions for each account in the previous time period based on the number of transactions for the current time period, using a zero-average method. It then dynamically calculates the expected weight value for each account in the current time period based on the comparison between the number of transactions for the previous time period and the average number of transactions range. Next, it initializes the basic weight value for each account as the original basic weight value. The module calculates the minimum weight value based on the original basic weight value, the maximum time interval between two consecutive queries for the same account, the number of accounts processed in each round, and the interval between two consecutive rounds. Finally, it calculates the maximum weight value based on the sum of the original basic weight values ​​for all accounts, the total number of accounts, and the number of accounts processed in each round. The module then segments the data according to the relationship between the expected weight value and the original basic weight value, and calculates a new basic weight value by combining the minimum weight value, the maximum weight value, the original basic weight value, the expected weight value, and the maximum single adjustment range.

[0088] The historical and real-time transaction weight calculation module calculates the historical transaction weight value based on the number of transactions of an account in a certain time period of the day and the historical average number of transactions in the same time period. Then, it divides the account into segments based on the relationship between the transaction time of the latest transaction and the latest query time of the account, and calculates the real-time transaction weight value in segments in combination with the polling cycle.

[0089] The new sorting value generation and account filtering module filters out the accounts to be queried in the current batch based on the initial sorting value of each account in the sorting value sequence, and calls the bank-enterprise direct connection interface to initiate an instruction to query the balance or transaction details of the accounts in the current batch; after the bank-enterprise direct connection interface instruction is completed, a new sorting value is generated for each account in the current batch based on a multi-dimensional weight value including the new basic weight value, historical transaction weight value and real-time transaction weight value, and the new sorting value is used to update the corresponding initial sorting value in the sorting value sequence to obtain a new sorting value sequence, and the next batch of accounts to be queried in the current batch is filtered out based on the new sorting value sequence;

[0090] The polling scheduling iterative execution module, based on the accounts to be queried in the next batch of the current batch, repeats the principle process from the account information acquisition and sort value initialization module to the new sort value generation and account filtering module until the preset number of iterations is reached, thus completing the polling scheduling of enterprise account queries.

[0091] Preferably, in the basic weight value calculation module, the expected weight value for each account in the current time period is dynamically calculated based on the comparison between the number of transactions in the previous time period and the average number of transactions in the range. Specifically, this includes:

[0092] If the number of transactions in the previous time period is less than the minimum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the minimum value of the average number of transactions range; if the number of transactions in the previous time period is greater than the maximum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the maximum value of the average number of transactions range; if the number of transactions in the previous time period is within the average number of transactions range, the expected weight value is equal to the preset benchmark value.

[0093] Preferably, in the basic weight value calculation module, the new basic weight value is calculated by segmenting the data according to the relationship between the expected weight value and the original basic weight value, and combining the minimum weight value, maximum weight value, original basic weight value, expected weight value, and preset maximum single adjustment range value. Specifically, this includes:

[0094] When the expected weight value is greater than the original basic weight value, the new basic weight value is calculated as follows: first, take the smaller value between the sum of the original basic weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the smaller value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value.

[0095] When the expected weight value is less than or equal to the original base weight value, the new base weight value is calculated as follows: first, take the larger value between the difference between the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the smaller value between the larger value and the maximum weight value; and finally, take the larger value between the smaller value and the minimum weight value.

[0096] Preferably, in the historical and real-time transaction weight calculation module, an account weight value is generated based on a multi-dimensional weight value including a new basic weight value, historical transaction weight value, and real-time transaction weight value. After generating the account weight value, the activity level of each account is automatically identified based on the account weight value. Based on the activity level, all accounts are automatically divided into hot accounts and non-hot accounts, and the query frequency of hot accounts and non-hot accounts is dynamically adjusted.

[0097] Preferably, in the historical and real-time transaction weight calculation module, the real-time transaction weight value is calculated by segmenting the data based on the relationship between the transaction time of the latest transaction of an account and the latest query time of the account, and combining this with the polling cycle. Specifically, this includes:

[0098] If the transaction time of the latest transaction of an account is greater than the latest query time of the account, the real-time transaction weight value is calculated based on the difference between the transaction time and the query time of the previous batch, the ratio of the polling cycle, and the real-time transaction factor.

[0099] If the transaction time of the latest transaction of an account is less than or equal to the time of the latest query of the account, the real-time transaction weight value is zero.

[0100] This invention provides an objective and scientific multi-dimensional dynamic weighted polling scheduling method and system for direct bank-enterprise connection queries. By comprehensively evaluating account activity across three dimensions—basic weight, historical transaction weight, and real-time transaction weight—it can more comprehensively reflect the true status of accounts. The basic weight reflects long-term trends, the historical weight identifies periodic patterns, and the real-time weight responds to sudden changes. The synergistic effect of these three factors enhances the scientific rigor and adaptability of scheduling decisions, avoiding biases and misjudgments caused by single indicators. This invention uses account ranking as a guide, dynamic adjustment of weights (basic / historical / real-time) as its core, and a closed-loop scheduling-execution-feedback mechanism as a guarantee for direct bank-enterprise connection polling. Through multi-dimensional weight adjustments, account queries are both orderly and aligned with business dynamics.

[0101] It should be noted that the specific embodiments described above enable those skilled in the art to more fully understand the present invention, but do not limit the present invention in any way. Therefore, although the present invention has been described in detail with reference to the accompanying drawings and embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention. In short, all technical solutions and improvements that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the present invention patent.

Claims

1. A multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries, characterized in that, Includes the following steps: S1: Obtain account information for all accounts of the enterprise, initialize the sorting value for each account, and generate a sorting value sequence; the account information includes the number of transactions, balance, transaction details, and total number of accounts; S2: Based on the number of transactions for each account in the previous time period, and using the zero-removal averaging method, calculate the average number of transactions in the previous time period; and dynamically calculate the expected weight value for each account in the current time period based on the comparison between the number of transactions in the previous time period and the average number of transactions range. Specifically, if the number of transactions in the previous time period is less than the minimum value of the average number of transactions range, calculate the expected weight value based on the ratio of the number of transactions in the previous time period to the minimum value of the average number of transactions range; if the number of transactions in the previous time period is greater than the maximum value of the average number of transactions range, calculate the expected weight value based on the ratio of the number of transactions in the previous time period to the maximum value of the average number of transactions range; if the number of transactions in the previous time period is within the average number of transactions range, the expected weight value is equal to the preset benchmark value. The system re-initializes the base weight value for each account and uses it as the original base weight value. The minimum weight value is calculated based on the original base weight value for each account, the preset maximum time interval between two consecutive queries for the same account, the number of accounts processed in each round, and the interval between two consecutive rounds. The maximum weight value is calculated based on the sum of the original base weight values ​​for all accounts, the total number of accounts, and the number of accounts processed in each round. The system then segments the data according to the relationship between the expected weight value and the original base weight value, and calculates the new base weight value segment by segment using the minimum weight value, maximum weight value, original base weight value, expected weight value, and the preset maximum single adjustment range. The base weight value specifically includes: when the expected weight value is greater than the original base weight value, the new base weight value is calculated as follows: first, take the smaller value between the sum of the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the smaller value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value. When the expected weight value is less than or equal to the original base weight value, the new base weight value is calculated as follows: first, take the larger value between the difference between the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the larger value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value. S3: Calculate the historical transaction weight value based on the number of transactions of an account within a certain time period of the day and the historical average number of transactions for the same time period. Then, segment the account based on the relationship between the transaction time of the latest transaction and the latest query time, and calculate the real-time transaction weight value segmented by the polling cycle. Specifically, if the transaction time of the latest transaction of an account is greater than the latest query time, the real-time transaction weight value is calculated based on the difference between the transaction time and the query time of the previous batch, the ratio of the polling cycle, and the real-time transaction factor. If the transaction time of the latest transaction of an account is less than or equal to the latest query time, the real-time transaction weight value is zero. S4: Based on the initial sort value of each account in the sort value sequence, filter out the accounts to be queried in the current batch, and call the bank-enterprise direct connection interface to initiate an instruction to query the balance or transaction details of the accounts in the current batch; after the bank-enterprise direct connection interface instruction is completed, generate a new sort value for each account in the current batch based on multi-dimensional weight values ​​including new basic weight value, historical transaction weight value and real-time transaction weight value, and use the new sort value to update the corresponding initial sort value in the sort value sequence to obtain a new sort value sequence, and filter out the accounts to be queried in the next batch of the current batch based on the new sort value sequence; S5: Based on the accounts to be queried in the next batch of the current batch, repeat the principle process of steps S1 to S4 until the preset number of iterations is reached, thus completing the polling schedule for enterprise account queries.

2. The multi-dimensional dynamic weighted round-robin scheduling method for direct bank-enterprise connection queries according to claim 1, characterized in that, In step S3, an account weight value is generated based on a multi-dimensional weight value including a new basic weight value, a historical transaction weight value, and a real-time transaction weight value. After generating the account weight value, the activity level of each account is automatically identified based on the account weight value. Based on the activity level, all accounts are automatically divided into hot accounts and non-hot accounts, and the query frequency of hot accounts and non-hot accounts is dynamically adjusted.

3. A multi-dimensional dynamic weighted round-robin scheduling system for direct bank-enterprise connection queries, characterized in that, This includes, in sequence, an account information acquisition and sorting value initialization module, a basic weight value calculation module, a historical and real-time transaction weight calculation module, a new sorting value generation and account filtering module, and a polling scheduling iterative execution module. The account information acquisition and sorting value initialization module acquires the account information of all accounts of the enterprise and initializes the sorting value of each account to generate a sorting value sequence; the account information includes the number of transactions, balance, transaction details and total number of accounts; The basic weight value calculation module calculates the average number of transactions for each account in the previous time period based on the number of transactions for the current time period, using a zero-removal averaging method. It then dynamically calculates the expected weight value for each account in the current time period based on the comparison between the number of transactions for the previous time period and the average number of transactions range. Specifically, if the number of transactions in the previous time period is less than the minimum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the minimum value of the average number of transactions range; if the number of transactions in the previous time period is greater than the maximum value of the average number of transactions range, the expected weight value is calculated based on the ratio of the number of transactions in the previous time period to the maximum value of the average number of transactions range; if the number of transactions in the previous time period is within the average number of transactions range, the expected weight value is equal to a preset benchmark value. The system re-initializes the base weight value for each account and uses it as the original base weight value. The minimum weight value is calculated based on the original base weight value for each account, the preset maximum time interval between two consecutive queries for the same account, the number of accounts processed in each round, and the interval between two consecutive rounds. The maximum weight value is calculated based on the sum of the original base weight values ​​for all accounts, the total number of accounts, and the number of accounts processed in each round. The system then segments the data according to the relationship between the expected weight value and the original base weight value, and calculates the new base weight value segment by segment using the minimum weight value, maximum weight value, original base weight value, expected weight value, and the preset maximum single adjustment range. The base weight value specifically includes: when the expected weight value is greater than the original base weight value, the new base weight value is calculated as follows: first, take the smaller value between the sum of the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the smaller value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value. When the expected weight value is less than or equal to the original base weight value, the new base weight value is calculated as follows: first, take the larger value between the difference between the original base weight value and the maximum single adjustment range value and the expected weight value; then, take the minimum value between the larger value and the maximum weight value; and then, take the larger value between the minimum value and the minimum weight value. The historical and real-time transaction weight calculation module calculates the historical transaction weight value based on the number of transactions of an account during a certain time period of the day and the historical average number of transactions during the same time period. Then, it segments the account based on the relationship between the transaction time of the latest transaction and the latest query time, and calculates the real-time transaction weight value segmented by the polling cycle. Specifically, if the transaction time of the latest transaction of an account is greater than the latest query time, the real-time transaction weight value is calculated based on the difference between the transaction time and the previous batch of query times, the ratio of the polling cycle, and the real-time transaction factor. If the transaction time of the latest transaction of an account is less than or equal to the latest query time, the real-time transaction weight value is zero. The new sorting value generation and account filtering module filters out the accounts to be queried in the current batch based on the initial sorting value of each account in the sorting value sequence, and calls the bank-enterprise direct connection interface to initiate an instruction to query the balance or transaction details of the accounts in the current batch; after the bank-enterprise direct connection interface instruction is completed, a new sorting value is generated for each account in the current batch based on a multi-dimensional weight value including the new basic weight value, historical transaction weight value and real-time transaction weight value, and the new sorting value is used to update the corresponding initial sorting value in the sorting value sequence to obtain a new sorting value sequence, and the next batch of accounts to be queried in the current batch is filtered out based on the new sorting value sequence; The polling scheduling iterative execution module, based on the accounts to be queried in the next batch of the current batch, repeats the principle process from the account information acquisition and sort value initialization module to the new sort value generation and account filtering module until the preset number of iterations is reached, thus completing the polling scheduling of enterprise account queries.

4. The multi-dimensional dynamic weighted round-robin scheduling system for direct bank-enterprise connection queries according to claim 3, characterized in that, The historical and real-time transaction weight calculation module also generates account weight values ​​based on multi-dimensional weight values, including new basic weight values, historical transaction weight values, and real-time transaction weight values. After generating account weight values, it automatically identifies the activity level of each account based on the account weight values, automatically classifies all accounts into hot accounts and non-hot accounts based on the activity level, and dynamically adjusts the query frequency of hot accounts and non-hot accounts.

Images