Electronic bank dynamic flow management method and system based on multi-dimensional data fusion

Abstract

The application discloses a kind of electronic bank dynamic flow control method and system based on multidimensional data fusion, belong to data processing technical field.The method includes: the multiple-source data in electronic bank system is collected and unified structured processing is carried out;Dynamic baseline is generated based on historical transaction data using sliding window algorithm, and dynamic baseline is corrected in combination with real-time cluster load state;Business priority and multi-tenant priority are calculated, and after dynamically adjusting weight coefficient according to load factor, weighted summation is obtained to obtain comprehensive priority;According to the comprehensive priority, generate token bucket parameters, execute service level throttling and interface level throttling, and dispatch requests according to queue weight proportion;The execution result is collected and returned to update dynamic baseline and calculation parameters.The application realizes adaptive adjustment and differentiated resource guarantee of throttling parameters through the synergistic effect of dynamic baseline calculation, comprehensive priority model, hierarchical throttling execution and closed-loop feedback.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a method and system for dynamic traffic management in electronic banking based on multi-dimensional data fusion. Background Technology

[0002] With the continuous online transformation of e-banking services, various business functions such as payments, transfers, marketing activities, and bulk payments are running concurrently on a unified technology platform. During marketing campaigns, flash sales, and the distribution of consumer vouchers, the system often experiences significantly higher traffic surges than usual. Existing technologies, such as the financial transaction management solution shown in CN119398923A, have been publicly disclosed. This solution constructs key-value information by acquiring the business identifier, product identifier, and channel identifier of the financial transaction, and then matches interface authorization management strategies, interface time management strategies, and interface traffic management strategies based on this key-value information to achieve multi-dimensional static management of financial interfaces.

[0003] However, the aforementioned existing technologies still have the following drawbacks: First, existing traffic control technologies rely on pre-configured static rule matching, which cannot dynamically generate rate limiting parameters based on historical traffic patterns and real-time cluster load status, resulting in a disconnect between rate limiting thresholds and the actual operating status of the system.

[0004] Second, existing technologies only match rules based on business, product, and channel identifiers, without introducing a differentiated priority model based on business value contribution and tenant carrying capacity, making it difficult to ensure resource allocation for high-value businesses and key tenants during peak periods.

[0005] Third, existing technologies employ a one-way strategy matching architecture, lacking a closed-loop feedback mechanism from rate limiting execution results to parameter correction, and thus cannot continuously optimize strategies based on execution effects such as response time and error rate. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method and system for dynamic traffic management in electronic banking based on multi-dimensional data fusion.

[0007] On the one hand, this invention provides a method for dynamic traffic management in electronic banking based on multi-dimensional data fusion, comprising the following steps: Data collection steps: Collect transaction logs, real-time monitoring indicators, infrastructure load, business attributes, and tenant attributes from the electronic banking system, and perform unified structured processing; Dynamic baseline calculation steps: A dynamic baseline is generated based on historical transaction data using a sliding window algorithm, and the dynamic baseline is corrected in combination with the real-time cluster load status; Priority calculation steps: Calculate business priority based on business type weight, transaction urgency, and user level; calculate multi-tenant priority based on institution type weight, transaction size ratio, and fulfillment rate; calculate load factor based on real-time cluster load status; dynamically adjust business priority weight coefficient and multi-tenant priority weight coefficient based on the load factor; and then perform a weighted sum of the business priority and the multi-tenant priority to obtain the comprehensive priority. Rate limiting parameter generation and execution steps: The business baseline traffic threshold is weighted and corrected according to the comprehensive priority to generate the token bucket filling rate and bucket capacity; Requests are allocated to processing queues of different priorities according to the comprehensive priority and scheduled according to the queue weight ratio; Service-level rate limiting is performed at the platform gateway layer based on business domain and multi-tenancy, and interface-level rate limiting is performed at the business gateway layer based on interface and business type. Closed-loop feedback steps: Collect the rate limiting execution results, response time and resource change data, and send them back to the analysis layer to update the calculation parameters of the dynamic baseline and comprehensive priority.

[0008] On the other hand, the present invention also provides an electronic banking dynamic flow management system based on multi-dimensional data fusion, comprising: The data acquisition module is configured to collect transaction logs, real-time monitoring indicators, infrastructure load, business attributes, and tenant attributes from the electronic banking system, and perform unified structured processing. The dynamic baseline calculation module is configured to generate a dynamic baseline based on historical transaction data using a sliding window algorithm, and to correct the dynamic baseline in combination with the real-time cluster load status. The priority calculation module is configured to calculate business priority based on business type weight, transaction urgency and user level, and calculate multi-tenant priority based on institution type weight, transaction scale ratio and fulfillment rate; calculate load factor according to real-time cluster load status, dynamically adjust business priority weight coefficient and multi-tenant priority weight coefficient based on the load factor, and then perform a weighted sum of the business priority and the multi-tenant priority to obtain the comprehensive priority. The rate limiting parameter generation and execution module is configured to perform weighted correction on the service baseline traffic threshold based on the comprehensive priority, generate the token bucket filling rate and bucket capacity; allocate requests to processing queues of different priorities according to the comprehensive priority, and schedule them according to the queue weight ratio; the rate limiting parameter generation and execution module includes: The platform gateway unit is configured to perform service-level rate limiting based on business domain and multi-tenancy. The business gateway unit is configured to perform interface-level rate limiting based on the interface and business type. The closed-loop feedback module is configured to collect the rate limiting execution results, response time, and resource change data, and send them back to the dynamic baseline calculation module and the priority calculation module to update the calculation parameters.

[0009] Compared with the prior art, this application has the following beneficial effects: 1. Achieving a technological leap from static preset to dynamic adaptive current limiting parameters. Existing technologies employ pre-configured static rule matching, where the rate limiting threshold remains fixed once set, failing to dynamically adjust based on historical traffic patterns and real-time system status. This application addresses this by collecting multi-source data, including transaction logs, real-time monitoring metrics, and infrastructure load. Based on historical transaction data, a sliding window algorithm is used to perform quantile statistics on request volume within a time window, filtering out occasional traffic fluctuations and extracting periodic patterns and steady-state characteristics of business traffic to generate a dynamic baseline. This dynamic baseline is then corrected by quantizing heterogeneous metrics such as CPU utilization, memory usage, and response time into continuous values, combined with real-time cluster load status. The synergistic effect of sliding window quantile statistics and multi-metric load fusion enables rate limiting parameters to adaptively adjust according to changes in system operating status, resolving the technical problem of the static threshold being disconnected from the actual system state in existing technologies.

[0010] 2. Achieve multi-dimensional differentiated resource security Existing technologies only match rules based on three identifier dimensions: business, product, and channel. They do not introduce a priority model based on business value contribution, nor do they consider the differences in business scale, performance capability, and carrying capacity among different institutions in a multi-tenant scenario. This application constructs a comprehensive priority model that integrates business priority and multi-tenant priority: business priority uses a multi-dimensional weighted algorithm to quantify qualitative business value contribution into quantitative scores from three dimensions: business type weight, transaction urgency, and user level; multi-tenant priority also uses a multi-dimensional weighted algorithm to quantify tenant carrying capacity and cooperation stability into quantitative scores from three dimensions: institution type weight, transaction scale proportion, and performance rate; based on the real-time load factor interval (normal, light load, heavy load, overload), a piecewise linear interpolation method is used to smoothly map the business priority weight coefficient and the multi-tenant priority weight coefficient to avoid control jumps caused by discrete level switching; finally, a comprehensive priority is obtained through weighted summation and normalization, making the dynamic balance between business value and tenant contribution under different load states calculable. The above technical means work together to solve the technical problem of existing technologies being unable to achieve differentiated resource guarantee due to the lack of a quantitative priority model.

[0011] 3. Implement a complete computable link from state awareness to execution parameters. The logical relationship between rule matching results and rate limiting execution in existing technologies is unclear, and the rate limiting behavior of the system lacks predictability under different states. This application establishes a complete computable link from load factor calculation, dynamic adjustment of weight coefficients, generation of comprehensive priorities, to token bucket rate and capacity calculation, and queue weight scheduling. The load factor adopts a multi-index weighted fusion algorithm to quantify heterogeneous indicators such as CPU utilization, memory usage, and response time into continuous values ​​in the range of 0 to 1; the weight coefficient adopts a piecewise linear interpolation method to smoothly map according to the interval where the load factor is located; the comprehensive priority integrates business priority and multi-tenant priority through a weighted summation formula; the token bucket rate is determined by multiplying the baseline threshold and the priority coefficient, and the token bucket capacity is determined by multiplying the rate and the burst time window; the queue scheduling adopts a proportional allocation algorithm to allocate requests to processing queues with different weights according to the comprehensive priority. All the above links use continuous differentiable mathematical operations to form an end-to-end computation link, making the mapping relationship from input load indicators to output rate limiting parameters deterministic and reproducible, solving the technical problem of the lack of predictability in rate limiting decisions in existing technologies.

[0012] 4. Implement hierarchical collaborative current limiting and closed-loop feedback optimization Existing technologies employ a single-level rate limiting control architecture with an open-loop control structure, lacking the ability to perceive and correct execution effects. This application adopts a two-layer architecture: a platform gateway and a business gateway. The platform gateway performs service-level coarse-grained rate limiting based on business domains and multi-tenancy, allocating overall cluster traffic quotas. The business gateway performs interface-level fine-grained rate limiting based on interfaces and business types, precisely controlling the traffic of individual interface calls. A token inheritance mechanism is used between the two gateways, with the interface-level token bucket capacity of the business gateway proportionally allocated to the service-level token bucket capacity of the platform gateway, forming a collaborative constraint between layers. Configuration updates adopt a publish-subscribe pattern, using a Redis message queue to push rate limiting parameter changes to each gateway node in real time, achieving hot policy updates. Simultaneously, a complete closed loop is established: "data collection → dynamic baseline calculation → priority decision → rate limiting execution → effect feedback." The rate limiting execution results, response time, and resource change data are re-injected into the analysis layer, forming a negative feedback control loop, enabling the system to continuously self-optimize based on the policy execution effect. The combined effect of the above-mentioned technical means enables the current limiting system to evolve from open-loop control to closed-loop control, solving the technical problem of the disconnect between strategy and system operating state and the inability to continuously optimize in the existing technology.

[0013] 5. Achieve simultaneous improvement in system stability and resource utilization efficiency. The integrated synergy of the aforementioned technical features brings additional technical effects. These effects are not simply the sum of the individual features, but rather rely on the synergistic coupling between data acquisition, dynamic baseline calculation, priority decision-making, tiered rate limiting execution, and closed-loop feedback. The load factor, as a common variable, simultaneously drives dynamic baseline correction and priority weight adjustment: under low load, the load factor falls within the normal range, the dynamic baseline automatically raises the rate limiting threshold, and the priority weight coefficient tilts towards multi-tenant priority, allowing the system to fully utilize idle resources to process low-priority services; under high load, the load factor falls into the heavy or overload range, the dynamic baseline automatically lowers the rate limiting threshold, and the priority weight coefficient tilts towards business priority, ensuring high-value services are prioritized. Comprehensive priority, as a core intermediate variable, simultaneously drives token bucket parameter generation and queue weight allocation, forming a unified control of multiple execution stages by a single variable. Closed-loop feedback simultaneously transmits execution results back to the dynamic baseline calculation and priority calculation modules, forming a dual-path parameter update mechanism. Furthermore, the integrated design of real-time data acquisition, streaming computation, configuration hot updates, and the closed-loop feedback mechanism enables the end-to-end latency of system state awareness and policy correction to reach the second level. Through the aforementioned multivariable coupling and multi-path feedback integrated architecture, this application automatically raises the rate limiting threshold to make full use of idle resources under low load, and automatically lowers the rate limiting threshold for non-critical services under high load while prioritizing high-value services. At the same time, it achieves the maintenance of system stability and the improvement of resource utilization efficiency, solving the technical problem that it is difficult to balance the two in the prior art. Attached Figure Description

[0014] Figure 1 This is an overall flowchart of the dynamic traffic control method according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of the dynamic baseline calculation sub-process of Embodiment 1 of the present invention; Figure 3 This is a flowchart of the priority calculation sub-process of Embodiment 1 of the present invention; Figure 4 This is a flowchart of the flow limiting parameter generation and hierarchical execution sub-process of Embodiment 1 of the present invention; Figure 5 This is a flowchart of the closed-loop feedback sub-process of Embodiment 1 of the present invention; Figure 6 This is a block diagram of the dynamic traffic control system according to Embodiment 2 of the present invention. Detailed Implementation

[0015] To better understand the present invention, specific embodiments are described in detail below with reference to the accompanying drawings. It should be noted that the following embodiments are for illustrative purposes only and do not constitute a limitation on the scope of protection of the present invention.

[0016] In this invention, unless otherwise stated, the following terms have the following meanings: Business priority: refers to the priority evaluation value obtained by comprehensively quantifying multiple dimensions such as the contribution of business type to enterprise revenue, business risk level, transaction timeliness requirements, and user level of the user initiating the transaction. It is used to characterize the priority of business requests in traffic control.

[0017] Multi-tenant priority: refers to the priority assessment value obtained by comprehensively quantifying multiple dimensions of factors such as the cooperation level, transaction volume ratio, and performance of tenants (including member banks, channel institutions, partners, etc.), and is used to characterize the priority of tenants in traffic management.

[0018] Dynamic baseline: refers to the baseline value of business traffic obtained by statistical calculation using a sliding window algorithm based on historical transaction data. This baseline value is dynamically updated as time and system operating status change.

[0019] Load factor: refers to a continuous quantitative value ranging from 0 to 1, which is obtained by combining multiple load indicators such as cluster CPU utilization, memory utilization, and average response time according to preset weights. It is used to characterize the overall load level of the system.

[0020] Overall Priority: This refers to the final priority evaluation value obtained by weighted summation of business priority and multi-tenant priority, which is used to directly drive the calculation of rate limiting parameters and the scheduling of request queues.

[0021] Service-level rate limiting refers to coarse-grained traffic control executed at the platform gateway layer, based on business domains and multi-tenant dimensions, to control the traffic quota of a specific business domain or tenant at the overall cluster level.

[0022] Interface-level rate limiting: refers to fine-grained traffic control executed at the business gateway layer, based on the interface and business type, to control the call traffic of a single API interface under a specific business type.

[0023] Token Bucket Algorithm: A flow control algorithm in which the system adds tokens to the token bucket at a constant rate. Each request requires one token to be processed, and the maximum number of tokens in the bucket is the burst traffic carrying capacity.

[0024] Closed-loop feedback: refers to sending data such as rate limiting execution results, response time, error rate, and resource changes back to the analysis layer to update the calculation parameters of dynamic baseline and comprehensive priority, forming a complete control loop of "perception → analysis → decision → execution → feedback".

[0025] Example 1: Dynamic Traffic Control Method This embodiment provides a dynamic traffic control method for e-banking based on multi-dimensional data fusion. This method can be applied to e-banking systems to dynamically perceive, make dynamic decisions, implement tiered traffic limiting, and provide feedback correction for request traffic during peak business scenarios such as marketing activities (e.g., the issuance of digital consumer vouchers) and bulk transactions.

[0026] Figure 1 The overall process of the dynamic traffic control method described in Example 1 is shown, including five main steps: data acquisition, dynamic baseline calculation, priority calculation, flow limiting parameter generation and hierarchical execution, and closed-loop feedback, as well as the data flow and feedback loop between each step.

[0027] 1. Data Collection Electronic banking systems collect data from multiple sources through a data acquisition module. Specifically: Regarding log collection, the platform gateway, business gateway, and each microservice generate access logs and error logs upon receiving a request. Each microservice outputs request logs using a unified JSON log format, with core field definitions shown in Table 1.

[0028] Table 1: Example Table of Core Fields in JSON Logs

[0029] After being processed by the standardization plugin, the logs are sent to the log topic of the Kafka message queue in the JSON format described above.

[0030] In terms of metric collection, the gateway and microservices expose the Prometheus interface, and the Prometheus Agent periodically collects metrics such as query per second (QPS), response time (RT), error rate, and thread pool utilization of the business interface, and writes the collected metric data into a time-series database (InfluxDB is used in this embodiment).

[0031] For load data collection, the system collects infrastructure metrics of the server, including CPU utilization, memory utilization, and network input / output (IO), also through the Prometheus Agent.

[0032] The collected data serves as the input source for subsequent processing. Asynchronous decoupling is achieved through the Kafka message queue, providing near real-time data support for dynamic baseline calculation and bottleneck analysis.

[0033] 2. Dynamic baseline calculation The real-time computing module in the gateway center uses a streaming engine to consume transaction logs and metric data from Kafka, and calculates the load baseline based on the "business type + multi-tenant" dimension using a sliding window algorithm.

[0034] Figure 2 The document details the dynamic baseline calculation sub-process, including sliding window parameter configuration, window size and step size settings for different business types, statistical calculation, and dynamic threshold correction.

[0035] The window size and sliding step of the sliding window are dynamically adjusted according to the business type and traffic fluctuation characteristics to ensure that the baseline reflects the actual business patterns. Specific association rules are shown in Table 2.

[0036] Table 2: Example Table of Sliding Window Parameter Settings

[0037] In the table above, Standard deviation is a statistic that measures the dispersion of a set of data.

[0038] The calculation logic for the statistics within the window is as follows: First, the transaction logs and monitoring metrics of the consumption are grouped according to the dimension of "business type + multi-tenant", such as "critical business - tenant A" and "flash sale business - tenant B" to isolate the traffic characteristics of different scenarios.

[0039] Secondly, aggregate calculations are performed within each sliding window: the request volume baseline is taken as the P95 quantile. For example, a 10-minute window for critical business contains 30 1-minute QPS data points, and the P95 value of these data points is taken as the request volume baseline; the quality baseline is taken as the response time P99 and the error rate P90, and occasional 5xx errors are filtered out during the calculation; the resource baseline is taken as the mean of CPU utilization and memory utilization plus twice the standard deviation, which is used to identify resource bottlenecks.

[0040] Secondly, if the proportion of sudden traffic within the window exceeds 20% (e.g., in a flash sale scenario), the window size will be temporarily reduced by 50% (e.g., from 1 minute to 30 seconds) to improve the sensitivity of the baseline. When the window is reduced, the sliding step size is reduced by the same proportion (e.g., from 1 minute / 30 seconds to 30 seconds / 15 seconds), and the original parameters are restored after the sudden traffic event ends. At the same time, the statistics within the window (e.g., P95) are estimated from the window before the reduction using interpolation methods to prevent statistical jitter caused by insufficient sample size.

[0041] In addition, for high-priority services (such as a combination of critical services and core member banks), an additional 10% redundancy threshold is added when calculating window statistics. For example, when the P95 request volume is 1000 QPS, the actual baseline is set to 1100 QPS to ensure resource allocation. For low-priority services (such as a combination of general services and non-critical tenants), a strict P90 quantile is used when calculating window statistics to reserve more buffer resources for core scenarios.

[0042] The calculated dynamic baseline is persisted to an SQL database for persistent backup, and simultaneously stored in a Redis cluster to support high-speed read and write operations, allowing the policy configuration layer and rate limiting execution layer to query it in real time.

[0043] 3. Priority Calculation Figure 3 The priority calculation sub-processes are shown in detail, including business priority calculation, multi-tenant priority calculation, and load factor calculation. and Dynamic adjustment and comprehensive priority weighted summation are among the steps involved.

[0044] 3.1 Business Priority Calculation Business priority reflects the value contribution of a business type to the enterprise and the urgency of resource needs. It needs to be defined in multiple dimensions, including business type, transaction attributes, and user characteristics, to ensure that high-value and high-urgency businesses are given priority. The calculation of business priority integrates three core dimensions: business type weight, transaction urgency, and user level. An initial score is generated by weighted summation, and then normalized and mapped to the [0,1] interval. The quantification rules for each dimension are shown in Table 3.

[0045] Table 3: Example Table of Business Priority Quantification Rules

[0046] The initial score is calculated as follows: BusinessPriority = Business Type Weight × Transaction Urgency × User Level.

[0047] For example, a core transaction (weight 1.0) is a real-time arrival (weight 1.0) from a VIP user (weight 1.0), with an initial score of 1.0 × 1.0 × 1.0 = 1.0; a query transaction (weight 0.3) is a delayed arrival (weight 0.3) from a new user (weight 0.3), with an initial score of 0.3 × 0.3 × 0.3 = 0.027.

[0048] Business priorities can be dynamically adjusted according to the scenario: During peak hours, the weight of core transactions (such as payments) is increased from 1.0 to 1.2 to ensure that users can complete transactions quickly; during marketing campaigns, the weight of marketing-related businesses (such as coupon redemption) is increased from 0.7 to 0.9 to promote campaign conversion; when a risk event occurs, the weight of high-risk businesses (such as large-amount transfers) is reduced from 1.0 to 0.8 to increase risk verification steps.

[0049] 3.2 Multi-tenant Priority Calculation Multi-tenant priority reflects an institution's contribution to the enterprise and the stability of the cooperation. It needs to be defined in multiple dimensions, including institution type, transaction size, and performance, to ensure that institutions with high contribution and high stability receive priority resources. The calculation of multi-tenant priority integrates three core dimensions: institution type weight, transaction size ratio, and performance rate. An initial score is generated by weighted summation, and then normalized to the [0,1] interval (0 is the lowest, 1 is the highest). The quantification rules for each dimension are shown in Table 4.

[0050] Table 4: Example Table of Multi-Tenant Priority Quantification Rules

[0051] The initial score is calculated as follows: LegalEntityPriority = Institution Type Weight × Transaction Size Ratio × Fulfillment Rate.

[0052] For example, a directly affiliated branch (weight 1.0) accounts for 60% of the transaction volume (weight 1.0) and has a fulfillment rate of 99.5% (weight 1.0), so its initial score is 1.0 × 1.0 × 1.0 = 1.0; a rural bank (weight 0.3) accounts for 5% of the transaction volume (weight 0.1) and has a fulfillment rate of 85% (weight 0.1), so its initial score is 0.3 × 0.1 × 0.1 = 0.003.

[0053] Multi-tenant priorities need to be updated regularly (weekly or monthly) based on the statistical data of the previous period to reflect changes in institutional contributions: if an institution's transaction volume share increases from 30% to 50%, the transaction volume share weight increases from 0.7 to 1.0; if an institution's fulfillment rate decreases from 99% to 95%, the fulfillment rate weight decreases from 1.0 to 0.7; if a third-party institution is upgraded to a directly affiliated branch, the institution type weight increases from 0.3 to 1.0.

[0054] 3.3 Comprehensive Priority Calculation Overall priority is determined by the business priority weighting coefficient. and multi-tenant priority weight coefficient The priority is obtained by weighted summation of business priority and multi-tenant priority, and the calculation formula is: Priority = ×BusinessPriority+ ×LegalEntityPriority.

[0055] and The initial value is determined in conjunction with the company's strategic goals: if the company's current focus is on improving the user experience of core transactions, then... Take 0.7, Take 0.3; if the company's current focus is on maintaining cooperation with key institutions, then... Take 0.3, Take 0.7; if the company needs to balance business and organization, then Take 0.5, Take 0.5.

[0056] and The system needs to be dynamically adjusted based on its status. The system status is divided into four levels based on two dimensions: overall cluster load and critical resource bottlenecks. The load level classification is shown in Table 5.

[0057] Table 5: Example Table of Load Level Parameter Settings

[0058] The load factor is a quantitative indicator that combines various metrics such as CPU utilization, memory utilization, and average response time into a single value between 0 and 1. Its calculation formula is as follows: LoadFactor=0.5×(CPU_usage / 100)+0.3×(MEM_usage / 100)+0.2×min(AvgRT / BaselineP99,1) Among them, CPU_usage is the cluster CPU utilization rate (%), MEM_usage is the cluster memory utilization rate (%), AvgRT is the average cluster response time (ms), and BaselineP99 is the 99th percentile response time of the business baseline (ms).

[0059] Based on the interval division of the load factor, a piecewise linear interpolation method is used to calculate... and : Under normal conditions (0 ≤ LoadFactor < 0.6), system resources are sufficient, and the default load balancing strategy is adopted: =0.6, =0.4.

[0060] Under light load conditions (0.6 ≤ LoadFactor < 0.8), resources become strained. linear increase Linear decrease: =0.6 + 0.5 × (LoadFactor - 0.6), =0.4-0.5×(LoadFactor-0.6).

[0061] Under heavy load conditions (0.8 ≤ LoadFactor < 0.9), resources are scarce. Further increase Further reduction: =0.7 + 1.0 × (LoadFactor - 0.8), =0.3-1.0×(LoadFactor-0.8).

[0062] Under overload conditions (0.9 ≤ LoadFactor ≤ 1), the system is on the verge of collapse; priority is given to ensuring the operation of the business. =0.9, =0.1.

[0063] 4. Rate limiting parameter generation and tiered execution Figure 4 The document details the sub-processes for generating rate limiting parameters and executing them in layers, including token bucket parameter calculation, platform gateway service-level rate limiting, business gateway interface-level rate limiting, queue allocation and scheduling, and other steps.

[0064] 4.1 Generation of current limiting parameters The rate limiting parameters include the token bucket filling rate and bucket capacity, both of which are calculated based on the business baseline traffic threshold and priority coefficient.

[0065] The baseline traffic threshold for a business is determined based on historical statistics, such as using the 95th percentile. For a specific interface, the request volume data for the same period over the past 30 days under this business type is statistically analyzed, and the 95th percentile is calculated as the baseline traffic threshold for the business, indicating that the traffic will not exceed this level 95% of the time under normal circumstances.

[0066] Historical transaction data is stored in InfluxDB using a time-series data model, organized in three layers: business dimension, multi-tenant dimension, and time dimension. Every day at 2:00 AM (off-peak business period), the real-time computing module triggers a batch processing task to query historical transaction data from InfluxDB for the past 30 days, aggregating it by "business + multi-tenant + time period" dimensions to calculate statistics such as average daily request volume, peak request volume, request volume standard deviation, error rate quantiles, and response time quantiles. The processed statistical results are written to the Redis cluster in the configuration center in JSON format for use when generating rate limiting rules. If the P95 for a certain dimension changes by more than 20% compared to the previous day, a configuration pre-check mechanism is triggered: comparing the traffic for that dimension in the Kafka real-time logs over the past hour, if the traffic in the past hour has reached 110% of the P95, it is determined to be a genuine traffic increase, and the new P95 is retained; otherwise, it is determined to be data anomaly, and the P95 is rolled back to the previous day.

[0067] The formula for calculating the token bucket filling rate is: rate = baseline × Priority, where baseline is the business baseline traffic threshold and Priority is the overall priority.

[0068] The formula for calculating the token bucket capacity is: burst = rate × T, where T is the burst time window, and in this embodiment, T is 2 seconds.

[0069] 4.2 Layered Rate Limiting Implementation Rate limiting is implemented using a two-layer architecture consisting of a platform gateway and a business gateway.

[0070] The platform gateway layer performs service-level rate limiting, which is overall traffic control of the service cluster based on the dimensions of "business domain + multi-tenancy". The real-time computing module in the gateway center injects service-level token buckets into Redis based on business priority and dynamic load baseline. For example, the capacity of the critical business bucket is set to 60% of the total QPS of the cluster, with an additional 20% of burst tokens reserved. When a request enters the platform gateway, the rate limiting processor sends a service-level token bucket deduction request to Redis, carrying the service type identifier (such as X-Service-Type:key_business). Redis executes the token bucket algorithm through Lua scripts: replenishing bucket_capacity / 60 tokens per second, and checking whether the remaining tokens are greater than or equal to the number of tokens required by the request before deduction; if so, the request is allowed; otherwise, it is rejected or queued.

[0071] The business gateway layer performs interface-level rate limiting, which is single-interface call traffic control based on "interface + business priority". After obtaining a service-level token from the platform gateway, the business gateway requests an interface-level token bucket from Redis. For example, the createOrder interface bucket capacity for critical businesses is set to 80% of the critical service bucket capacity, and the queryOrder interface bucket capacity is set to 20% of the critical service bucket capacity. When a request enters the business gateway, the rate limiting processor sends an interface-level token bucket deduction request to Redis, carrying the interface identifier (such as X-Interface:createOrder). Redis executes the same token bucket algorithm via Lua scripts.

[0072] The local rate limiter acts as a localized execution engine for single-point rate limiting. When a request reaches the gateway node, it doesn't need to query Redis every time. Instead, the local rate limiter quickly determines whether rate limiting is necessary based on the configuration cache in memory (also using the token bucket algorithm), reducing access pressure on Redis and improving rate limiting response speed. When the configuration in Redis changes, a message notification triggers a node update. The node first updates its local configuration (pulling the latest rate limiting rules from Redis into memory), then clears the local rate limiter cache, ensuring that the next rate limiting decision uses the new configuration for initialization, guaranteeing the configuration takes effect.

[0073] Based on the overall priority, requests are allocated to processing queues of different priorities: if the overall priority is greater than 0.6, it enters the high-priority queue; if the overall priority is greater than 0.3 and less than or equal to 0.6, it enters the medium-priority queue; otherwise, it enters the low-priority queue. During processing, scheduling is performed according to the queue weight ratio. For example, if the weight distribution of the three queues is 5:2:1, it means that after processing 5 requests in the high-priority queue, 2 requests are processed in the medium-priority queue, and finally 1 request is processed in the low-priority queue, and so on.

[0074] 5. Closed-loop feedback Figure 5 The closed-loop feedback sub-process is shown in detail, including the collection of execution results, calculation of quality coefficients, and release of parameter updates, as well as the feedback loop that sends data back to the dynamic baseline calculation module and the priority calculation module.

[0075] After rate limiting is implemented, the data acquisition layer writes the results (including the number of allowed, rejected, and queued requests), response time, error rate, and resource changes to the Kafka message queue. The real-time computing module consumes this data and updates the quality coefficients for each service.

[0076] The quality coefficient is calculated based on the success rate and response time over the past 5 minutes: if the success rate is greater than 99.9%, the quality coefficient is 1.05 (reward); if the success rate is greater than 95% and less than or equal to 99.9%, the quality coefficient is 1.0; if the success rate is less than or equal to 95%, the quality coefficient is 0.8 (penalty). The final value of the business type weight is equal to the base weight multiplied by the quality coefficient.

[0077] The real-time calculation module simultaneously recalculates the load factor based on the updated data, and then recalculates... and Then, the overall priority is recalculated, and finally, new token bucket parameters are generated and published to the Redis cluster. The platform gateway and business gateway detect configuration changes through configuration listeners, update their local caches, and enter the next adjustment cycle.

[0078] Through the above steps, this method forms a complete technical chain of "data acquisition → dynamic baseline calculation → priority calculation → flow limiting parameter generation and hierarchical execution → closed-loop feedback".

[0079] Example 2: Dynamic Flow Control System This embodiment provides an electronic banking dynamic traffic management system based on multi-dimensional data fusion, which is used to execute the method described in Embodiment 1.

[0080] like Figure 6 As shown, the dynamic traffic control system of the present invention includes: The data acquisition module is configured to collect transaction logs, real-time monitoring metrics, infrastructure load, and business and tenant attributes from the e-banking system, and perform unified structured processing. The data acquisition module includes: a log acquisition unit, used to collect access logs and error logs from the platform gateway, business gateway, and microservices, which are then processed by a log standardization plugin and sent to a Kafka log topic; a metric acquisition unit, used to collect metrics such as query rate per second, response time, error rate, and thread pool utilization of business interfaces through the Prometheus Agent, and write them to a time-series database; and a load acquisition unit, used to collect infrastructure metrics such as server CPU utilization, memory utilization, and network I / O, also connected to Prometheus for collection.

[0081] The dynamic baseline calculation module is configured to generate dynamic baselines based on historical transaction data using a sliding window algorithm, and to correct these dynamic baselines in conjunction with real-time cluster load status. The dynamic baseline calculation module includes: a stream processing engine unit, used to consume transaction logs and metric data from Kafka in a streaming manner, and calculate the load baseline based on the "business type + multi-tenant" dimension using the sliding window algorithm; a window parameter configuration unit, used to dynamically adjust the window size and sliding step size according to business type (critical business, flash sale business, general business) and traffic fluctuation characteristics; a statistics calculation unit, used to calculate the request volume baseline (P95 quantile), quality baseline (response time P99, error rate P90), and resource baseline (mean of CPU / memory utilization plus twice the standard deviation) within each window; a threshold correction unit, used to temporarily reduce the window size when the proportion of sudden traffic exceeds a preset threshold, and to perform redundancy adjustments to the baseline according to business priority; and a baseline storage unit, used to persist the dynamic baseline to an SQL database and a Redis cluster.

[0082] A priority calculation module, configured to calculate the service priority based on the service type weight, transaction urgency, and user level, and calculate the multi-tenant priority based on the institution type weight, transaction scale ratio, and fulfillment rate; calculate the load factor according to the real-time cluster load status, dynamically adjust the service priority weight coefficient and the multi-tenant priority weight coefficient based on the load factor, and then perform weighted summation on the service priority and the multi-tenant priority to obtain the comprehensive priority. The priority calculation module includes: a service priority calculation unit, configured to calculate the initial score of the service priority according to the service type weight, transaction urgency, and user level, and perform normalization processing; a multi-tenant priority calculation unit, configured to calculate the initial score of the multi-tenant priority according to the institution type weight, transaction scale ratio, and fulfillment rate, and perform normalization processing; a load factor calculation unit, configured to calculate the load factor according to the CPU usage rate, memory usage rate, and average response time according to the preset weight; a weight coefficient adjustment unit, configured to dynamically adjust the service priority weight coefficient by using the piecewise linear interpolation method according to the interval where the load factor is located and the multi-tenant priority weight coefficient ; a weighted summation unit, configured to calculate the comprehensive priority according to Priority= ×BusinessPriority+ ×LegalEntityPriority.

[0083] A rate limiting parameter generation and execution module, configured to perform weighted correction on the service baseline traffic threshold according to the comprehensive priority, generate the filling rate and bucket capacity of the token bucket; allocate requests to different priority processing queues according to the comprehensive priority, and perform scheduling according to the queue weight ratio. The rate limiting parameter generation and execution module includes: a baseline threshold acquisition unit, configured to query historical transaction data from the time series database and calculate the service baseline traffic threshold (P95 percentile); a token bucket parameter generation unit, configured to calculate the filling rate according to rate=baseline×Priority, and calculate the bucket capacity according to burst=rate×T; a queue allocation unit, configured to allocate requests to a high-priority queue (Priority>0.6), a medium-priority queue (0.3<Priority≤0.6), or a low-priority queue (Priority≤0.3) according to the comprehensive priority; a queue scheduling unit, configured to perform weighted round-robin scheduling according to the preset queue weight ratio (such as 5:2:1).

[0084] The rate limiting parameter generation and execution module also includes a platform gateway unit and a business gateway unit. The platform gateway unit is configured to perform service-level rate limiting based on business domain and multi-tenancy, including: a token bucket pre-allocation subunit, used to inject service-level token buckets into Redis based on business priority and dynamic load baseline; a token request subunit, used to initiate a service-level token bucket deduction request to Redis when a request enters the platform gateway; a local rate limiter subunit, used to maintain a rate limiting counter in the gateway node's memory to reduce Redis access pressure; and a configuration listening subunit, used to subscribe to Redis configuration change messages and update local rate limiting rules in real time. The business gateway unit is configured to perform interface-level rate limiting based on interface and business type, including: a token bucket inheritance subunit, used to obtain a service-level token from the platform gateway and then request an interface-level token bucket from Redis, with the interface-level token bucket capacity proportionally allocated up to the service-level token bucket capacity; an interface token request subunit, used to initiate an interface-level token bucket deduction request to Redis when a request enters the business gateway; and a configuration refresh subunit, used to update the local configuration and clear the local rate limiter cache when the configuration changes.

[0085] The closed-loop feedback module is configured to collect rate limiting execution results, response time, and resource change data, and send them back to the dynamic baseline calculation module and priority calculation module to update the calculation parameters. The closed-loop feedback module includes: an execution result acquisition unit, used to obtain rate limiting execution results (number of allowed passes, number of rejected passes, number of queued passes), response time, error rate, and resource change data from the data acquisition module; a quality coefficient calculation unit, used to calculate the quality coefficient based on the success rate over the past 5 minutes (K_quality=1.05 when success rate > 99.9%, K_quality=1.0 when success rate < success rate ≤ 99.9%, and K_quality=0.8 when success rate ≤ 95%); and a parameter update and publication unit, used to publish the updated quality coefficient, load factor, and other parameters to the Redis cluster, triggering the next round of adjustments.

[0086] In addition, the system includes a configuration and caching layer and a business service layer. The configuration and caching layer includes an SQL database and a Redis cluster. The SQL database is used for persistent storage and version management of rate limiting rules, while the Redis cluster serves as a global configuration center to host rate limiting configurations, message queues, and distributed rate limiting counters. The business service layer includes critical business microservices, flash sale business microservices, and general business microservices, each handling corresponding types of business requests.

[0087] Figure 6In this process, the data acquisition module sends the collected data to the dynamic baseline calculation module via a Kafka message queue; the dynamic baseline generated by the dynamic baseline calculation module is transmitted to the priority calculation module; the comprehensive priority generated by the priority calculation module is transmitted to the rate limiting parameter generation and execution module; the rate limiting parameter generation and execution module performs rate limiting control through the platform gateway unit and the business gateway unit and then forwards the request to the business service layer; the execution result is returned to the dynamic baseline calculation module and the priority calculation module through the closed-loop feedback module, forming a complete closed loop.

[0088] Example 3: Application Case in Peak Marketing Campaign Scenarios This embodiment uses the scenario of an e-bank issuing digital consumer vouchers during the "618 Shopping Festival" as an example to illustrate the specific application of the technical solution of this application.

[0089] Scenario Description: At 10:00:00 on June 18, 2026, an e-banking company distributes 100,000 digital consumption vouchers via its mobile banking app. It is estimated that over 50,000 users will simultaneously click to claim the vouchers within the first second of the event's start. The bank's system comprises three categories of services: critical business (payment, transfer), flash sale business (voucher claiming, flash sale items), and general business (balance inquiry, points redemption). Tenants include branches directly under the head office, ordinary member banks, and alliance channels.

[0090] Implementation process: Before the event began, the data collection module continuously collected historical transaction data. The dynamic baseline calculation module analyzed the traffic distribution during the same period (10:00-11:00 on weekdays) over the past 30 days and calculated the following baseline QPS: 1200 for payment transactions, 800 for transfer transactions, 5000 for voucher redemption transactions, and 3000 for balance inquiry transactions.

[0091] The priority calculation module calculates the priority based on preset rules: The consumer voucher redemption service is a flash sale service, with a service type weight of 0.7, a transaction urgency weight of 0.9 (temporarily increased from 0.7 to 0.9 during marketing campaigns), a regular user level weight of 0.7, and a service priority of 0.7 × 0.9 × 0.7 = 0.441. The head office's directly affiliated branches have an institution type weight of 1.0, a transaction volume share weight of 0.7 (approximately 35%), a fulfillment rate weight of 1.0 (99.5% success rate), and a multi-tenant priority of 1.0 × 0.7 × 1.0 = 0.7.

[0092] At the start of the activity (10:00:00), the system load surged dramatically: CPU utilization jumped from 25% to 85%, and the average response time increased from 150ms to 450ms (baseline P99 was 300ms). The load factor calculation unit calculated a LoadFactor of approximately 0.86, indicating the system was under heavy load. The weighting coefficient adjustment unit used piecewise linear interpolation. =0.7 + 1.0 × (0.86 - 0.8) = 0.76, =0.3-1.0×(0.86-0.8)=0.24. The overall priority calculation formula is Priority=0.76×0.441+0.24×0.7=0.335+0.168=0.503.

[0093] The rate limiting parameter generation module calculates the token bucket parameters based on the overall priority: the baseline QPS of the consumer voucher redemption interface is 5000, the overall priority is 0.503, the filling rate rate = 5000 × 0.503 = 2515 QPS, and the bucket capacity burst = 2515 × 2 = 5030 tokens.

[0094] The tiered rate limiting module begins operation: the platform gateway performs service-level rate limiting on the voucher redemption service, restricting the entire service cluster to no more than 2515 QPS; the business gateway further performs interface-level rate limiting on the specific redemption interface. Simultaneously, based on a comprehensive priority of 0.503 (between 0.3 and 0.6), requests are allocated to the medium-priority queue and scheduled with the high-priority queue (payment transactions) according to a weighted ratio (5:2:1).

[0095] During the activity, the closed-loop feedback module collects execution results every second. When the error rate is detected to rise to 2%, the quality coefficient is reduced from 1.0 to 0.8, the business type weight is reduced from 0.7 to 0.56, the overall priority is reduced accordingly, the rate limiting parameters are automatically tightened, and the system enters self-protection mode.

[0096] Implementation Results: Through this technical solution, the e-banking system successfully processed more than 80,000 claim requests during the peak period of consumer voucher distribution. Key business operations (payment and transfer) were not affected, the error rate was kept below 1.5%, and the system did not crash or experience a cascading failure.

[0097] Example 4: Application Cases in Degradation and Fault Tolerance Scenarios This embodiment uses the degradation and fault tolerance mechanism of the system under abnormal failure as a scenario to illustrate the robustness guarantee of the technical solution of this application.

[0098] Scenario 1: Redis cluster read / write timeout When the Redis cluster experiences a token bucket counter timeout due to network jitter, the platform gateway's rate limiting processor detects the Redis operation failure and immediately degrades to local rate limiting mode. The local rate limiter maintains the count within the gateway process using a sliding window algorithm, sacrificing distributed consistency to prioritize rate limiting accuracy within a single node. Simultaneously, the gateway reports the "Redis operation failed" anomaly to the monitoring center, triggering an alarm. Once Redis recovers, the rate limiting processor automatically switches back to distributed rate limiting mode.

[0099] Scenario 2: Redis cluster completely crashes When the Redis cluster completely crashes, the configuration listeners of the platform gateway and business gateway cannot read the rate limiting configuration from Redis. At this time, the gateway automatically switches to reading the old configuration from its local cache (the configuration fully fetched from Redis and stored in memory when the gateway starts). Simultaneously, it enables built-in static rate limiting rules as a last line of defense, such as "global rate limit of 1000 QPS" or "critical interface single instance rate limit of 100 QPS." The gateway marks the "Redis unavailable" status in the response header so that downstream services are aware of the degradation status.

[0100] Scenario 3: Real-time computing module data acquisition timeout When the real-time computing module pulls load metrics from Prometheus for more than 3 seconds, or when the historical baseline calculation fails due to slow database queries, the real-time computing module uses the last valid load index (such as the successful data cached in the last minute) as a substitute. If there is no available historical data, the default conservative load index of 0.7 is used to temporarily reduce the rate limiting sensitivity (allowing more requests to pass) and avoid excessive rate limiting due to missing data.

[0101] Scenario 4: Gateway center configuration persistence timeout When the rate limiting rules time out of being saved to the SQL database (e.g., due to master database failure or network interruption), the gateway center temporarily caches the rules in a local memory queue and marks them as "pending synchronization." The rate limiting logic for new requests continues to use the old version of the configuration to avoid inconsistencies caused by the configuration not being persisted. After the database recovers, the write operation is retried asynchronously.

[0102] Scenario 5: Redis message queue unavailable When the Redis message queue (configuration change notification channel) becomes unavailable, the gateway center starts a local configuration change log to record rule updates that were not broadcast. Once Redis recovers, the logs are replayed in batches to complete configuration synchronization. Before synchronization, if the downstream gateway's configuration listener detects a timeout, it polls the gateway center for the latest configuration at a fixed interval (e.g., 10 seconds) as a compensation mechanism.

[0103] Implementation Results: Through the aforementioned layered fallback, state awareness, and post-event recovery fault tolerance mechanisms, the technical solution of this application can maintain the basic availability of the rate limiting function under various fault scenarios, avoid system avalanche due to single point of failure, and has high engineering robustness.

[0104] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from the principles of the present invention, and these improvements and modifications should also fall within the scope of protection of the present invention.

[0105] The scope of protection sought by this invention is defined by the claims. The technical features described in the claims and their equivalents constitute the basic scope of protection of this invention. Based on the claims, the description and drawings are used to interpret the meaning of the claims, but should not be construed as limiting the scope of protection of the claims.

[0106] In particular, although the technical solution of this invention is described with electronic banking as the application scenario, its core idea—dynamic traffic control based on multi-dimensional data fusion—is also applicable to other high-concurrency distributed systems with similar technical requirements (such as e-commerce platform flash sale systems, ticketing systems, online education registration systems, etc.). Any application of the core methods and systems of this invention to other technical fields, or any non-substantial modifications, substitutions, or combinations thereof, shall fall within the scope of protection of this invention.

Claims

1. A method for dynamic traffic management in e-banking based on multi-dimensional data fusion, characterized in that, Includes the following steps: Collect transaction logs, real-time monitoring indicators, infrastructure load, business attributes, and tenant attributes from the electronic banking system, and perform unified structured processing. A dynamic baseline is generated based on historical transaction data using a sliding window algorithm, and the dynamic baseline is then corrected in conjunction with the real-time cluster load status. Business priority is calculated based on business type weight, transaction urgency, and user level; multi-tenant priority is calculated based on institution type weight, transaction size ratio, and fulfillment rate. The load factor is calculated based on the real-time cluster load status, and the formula for calculating the load factor is as follows: LoadFactor=0.5×(CPU_usage / 100)+0.3×(MEM_usage / 100)+0.2×min(AvgRT / BaselineP99,1) Wherein, CPU_usage is the cluster CPU utilization, MEM_usage is the cluster memory utilization, AvgRT is the cluster average response time, and BaselineP99 is the 99th percentile response time of the business baseline. Based on the interval where the load factor is located, the service priority weight coefficient is calculated using a piecewise linear interpolation method. and multi-tenant priority weight coefficient : When 0 ≤ LoadFactor < 0.6, =0.6, =0.4; When 0.6 ≤ LoadFactor < 0.8, =0.6 + 0.5 × (LoadFactor - 0.6), =0.4 - 0.5 × (LoadFactor - 0.6); When 0.8 ≤ LoadFactor < 0.9, =0.7 + 1.0 × (LoadFactor - 0.8), =0.3 - 1.0 × (LoadFactor - 0.8); When 0.9 ≤ LoadFactor ≤ 1.0, =0.9, =0.1; The service priority and the multi-tenant priority are then weighted and summed to obtain the comprehensive priority. The formula for calculating the comprehensive priority is as follows: Priority= ×BusinessPriority+ ×LegalEntityPriority; The service baseline traffic threshold is weighted and adjusted according to the comprehensive priority to generate the token bucket filling rate and bucket capacity; requests are allocated to processing queues of different priorities according to the comprehensive priority and scheduled according to the queue weight ratio; service-level rate limiting is performed at the platform gateway layer based on business domain and multi-tenancy, and interface-level rate limiting is performed at the business gateway layer based on interface and business type; wherein, a token inheritance mechanism is used between service-level rate limiting and interface-level rate limiting, and the token bucket capacity of the interface-level rate limiting is proportionally allocated with the token bucket capacity of the service-level rate limiting as the upper limit; Collect data on rate limiting execution results, response time, and resource changes to update the calculation parameters of the dynamic baseline and the comprehensive priority.

2. The method for dynamic traffic management of electronic banking based on multi-dimensional data fusion according to claim 1, characterized in that, The correction of the dynamic baseline includes: grouping transaction logs and monitoring metrics according to the "business type + multi-tenant" dimension; calculating the quantiles of the request volume baseline, the response time quantiles and error rate quantiles of the quality baseline, and the statistical values ​​of the CPU utilization and memory utilization of the resource baseline within each sliding window; temporarily reducing the window size when the proportion of burst traffic exceeds a preset threshold; and adjusting the redundancy threshold of the baseline according to business priority.

3. The method for dynamic traffic management of electronic banking based on multi-dimensional data fusion according to claim 1, characterized in that, The token bucket filling rate is rate = baseline × Priority, where baseline is the service baseline traffic threshold and Priority is the overall priority; the token bucket capacity is burst = rate × T, where T is the burst time window.

4. The method for dynamic traffic management of electronic banking based on multi-dimensional data fusion according to claim 1, characterized in that, The method further includes: calculating a quality coefficient based on the success rate within a preset time window in the past, wherein the quality coefficient is: a reward value when the success rate is greater than a first threshold, a baseline value when the success rate is less than or equal to the first threshold but greater than a second threshold, and a penalty value when the success rate is less than or equal to the second threshold; the updated business type weight is obtained by multiplying the base weight of the business type weight by the quality coefficient.

5. The method for dynamic traffic management of electronic banking based on multi-dimensional data fusion according to claim 2, characterized in that, The window size and sliding step size of the sliding window are dynamically adjusted according to the business type and traffic fluctuation characteristics: a first window size and a first step size are used for critical businesses, a second window size smaller than the first window size and a second step size smaller than the first step size are used for flash sales, and a third window size between the first window size and the second window size is used for general businesses.

6. The method for dynamic traffic management of electronic banking based on multi-dimensional data fusion according to claim 1, characterized in that, The allocation of requests to processing queues of different priorities based on the overall priority includes: when the overall priority is greater than the first threshold, the request enters the high-priority queue; when the overall priority is less than or equal to the first threshold but greater than the second threshold, the request enters the medium-priority queue; and in other cases, the request enters the low-priority queue. Weighted round-robin scheduling is performed according to the preset weight ratio of the high-priority queue, the medium-priority queue, and the low-priority queue.

7. An electronic banking dynamic flow control system based on multi-dimensional data fusion, characterized in that, include: The data acquisition module is configured to collect transaction logs, real-time monitoring indicators, infrastructure load, business attributes, and tenant attributes from the electronic banking system, and perform unified structured processing. The dynamic baseline calculation module is configured to generate a dynamic baseline based on historical transaction data using a sliding window algorithm, and to correct the dynamic baseline in combination with the real-time cluster load status. The priority calculation module is configured to calculate business priority based on business type weight, transaction urgency and user level, and to calculate multi-tenant priority based on institution type weight, transaction scale ratio and fulfillment rate. The load factor is calculated based on the real-time cluster load status, and the formula for calculating the load factor is as follows: LoadFactor=0.5×(CPU_usage / 100)+0.3×(MEM_usage / 100)+0.2×min(AvgRT / BaselineP99,1) Wherein, CPU_usage is the cluster CPU utilization, MEM_usage is the cluster memory utilization, AvgRT is the cluster average response time, and BaselineP99 is the 99th percentile response time of the business baseline. Based on the interval where the load factor is located, the service priority weight coefficient is calculated using a piecewise linear interpolation method. and multi-tenant priority weight coefficient : When 0 ≤ LoadFactor < 0.6, =0.6, =0.4; When 0.6 ≤ LoadFactor < 0.8, =0.6 + 0.5 × (LoadFactor - 0.6), =0.4 - 0.5 × (LoadFactor - 0.6); When 0.8 ≤ LoadFactor < 0.9, =0.7 + 1.0 × (LoadFactor - 0.8), =0.3 - 1.0 × (LoadFactor - 0.8); When 0.9 ≤ LoadFactor ≤ 1.0, =0.9, =0.1; The service priority and the multi-tenant priority are then weighted and summed to obtain the comprehensive priority. The formula for calculating the comprehensive priority is as follows: Priority= ×BusinessPriority+ ×LegalEntityPriority; The rate limiting parameter generation and execution module is configured to perform weighted correction on the service baseline traffic threshold based on the comprehensive priority, generate the token bucket filling rate and bucket capacity; allocate requests to processing queues of different priorities according to the comprehensive priority, and schedule them according to the queue weight ratio; the rate limiting parameter generation and execution module includes: The platform gateway unit is configured to perform service-level rate limiting based on business domain and multi-tenancy. The business gateway unit is configured to perform interface-level rate limiting based on the interface and business type. The service-level rate limiting and the interface-level rate limiting adopt a token inheritance mechanism, and the token bucket capacity of the interface-level rate limiting is proportionally allocated with the token bucket capacity of the service-level rate limiting as the upper limit. The closed-loop feedback module is configured to collect the rate limiting execution results, response time, and resource change data, and send them back to the dynamic baseline calculation module and the priority calculation module to update the calculation parameters.

Images