CFS warehouse management system and method based on request shunting and elastic scaling technology

Abstract

The application discloses a CFS warehouse management system and method based on request shunting and elastic scaling technology, comprising a request shunting module, a processing channel module, an elastic scaling control module and a data layer module. Through the cooperation of the request shunting module and the three types of processing channels, the application can intelligently classify and isolate the concurrent requests during the peak period of tidal business, ensure that the core transaction is not blocked, solve the problem of slow response, and improve the high-concurrency processing capability and response speed. The elastic scaling control module combines the real-time load of the system and the CFS business index to realize the prediction and dynamic allocation of resources, which can not only actively cope with the peak and prevent service unavailability, but also automatically release resources during the flat period, thereby changing from passive hardware upgrade to intelligent elastic scheduling, ensuring stability and reducing cost. The application intelligently distinguishes the request attributes and resource consumption, routes them to the most suitable channel, realizes optimal scheduling of requests and fine allocation of resources, and solves the systematic performance bottleneck of the CFS system.

Description

Technical Field

[0001] This invention relates to the field of warehouse management information technology, and in particular to a CFS warehouse management system and method based on request routing and elastic scaling technology. Background Technology

[0002] As a crucial node in international logistics and supply chains, container freight stations (CFS) exhibit significant tidal characteristics in their business activities, with business volume surging dramatically during periods such as ship berthing and cut-off times. During these periods, a large number of freight forwarders, trucking companies, customs brokers, and other users simultaneously access the CFS warehouse management system to perform operations such as entering, querying, modifying, and printing documents regarding cargo status.

[0003] Such a surge of high-concurrency access requests within a short period can put enormous pressure on the CFS warehouse management system's servers, databases, and other infrastructure, leading to slow system response, sluggish user interface, and severely impacting on-site operational efficiency. In extreme cases, the database connection pool may be exhausted, causing the entire system to become unavailable, halting warehousing operations, and resulting in significant economic losses.

[0004] In existing technologies, solving high concurrency problems typically involves hardware upgrades (such as increasing the number of servers or improving database configuration) or basic load balancing strategies. However, hardware upgrades are costly and lack flexibility, making them uneconomical in responding to business fluctuations. Basic load balancing strategies, on the other hand, often fail to intelligently differentiate between the business attributes and resource consumption levels of requests, making it difficult to achieve optimal request scheduling and resource allocation under limited resource conditions. Therefore, they cannot fundamentally address the system performance bottleneck in the specific scenario of CFS. Summary of the Invention

[0005] To address the problems existing in the prior art, embodiments of the present invention provide a CFS warehouse management system and method based on request routing and elastic scaling technology.

[0006] As one aspect of the present invention, embodiments of the present invention provide a CFS warehouse management system based on request routing and elastic scaling technology, comprising:

[0007] The request routing module, deployed on the API gateway, is used to receive business requests from clients and analyze the business requests according to preset classification rules to determine the category to which the business requests belong. The categories include real-time critical requests, real-time lightweight requests, or non-real-time batch requests.

[0008] A processing channel module connected with the request shunting module, configured to receive the request routed by the request shunting module and process the request; the processing channel module comprises a core transaction channel configured to process the real-time key request, a fast query channel configured to process the real-time light request, and an asynchronous task queue configured to cache and dispatch the non-real-time batch request;

[0009] An elastic control module configured to monitor resource load indexes of the system, and perform a dynamic horizontal expansion operation, a horizontal contraction operation or keep the current instance number unchanged on the application server instance in the system according to a size relationship between the resource load indexes and a preset threshold value and a CFS service index;

[0010] A data layer module comprising a master database and at least one slave database; the master database is configured to process a write operation from the core transaction channel, and the slave database is configured to process a read operation from the fast query channel.

[0011] In one embodiment, the elastic control module comprises:

[0012] A pressure index determination unit configured to determine a core coupling pressure score according to a current number of work vessels, a maximum number of vessels supported by the system, a current average complexity of requests and a preset maximum complexity, determine a predicted traffic pressure score according to a system peak throughput of the system and a predicted future request amount, determine a backlog health pressure score according to a current number of pending documents and a document processing threshold of the system, and determine a comprehensive CFS service pressure index according to the core coupling pressure score, the predicted traffic pressure score and the backlog health pressure score;

[0013] A basic instance determination unit configured to determine a basic instance number according to the comprehensive CFS service pressure index, a preset minimum instance number and a preset maximum instance number of the system;

[0014] A correction factor determination unit configured to determine a pressure overload ratio of the system according to a resource real-time pressure index of the system and a preset system target pressure threshold, and determine a real-time pressure correction factor of the system according to the pressure overload ratio;

[0015] A target instance determination unit configured to determine a preliminary target instance number according to the basic instance number and the real-time pressure correction factor, and determine an instance target number of a next scaling period of the system according to the preliminary target instance number and a preset instance number limit;

[0016] An operation unit configured to perform a corresponding horizontal expansion operation, a horizontal contraction operation or keep the current instance number unchanged on the application server instance of a next scaling period of the system according to the instance target number of the next scaling period.

[0017] In one embodiment, the pressure index determination unit further comprises:

[0018] The first determination sub-unit is configured to perform the following steps: step A11, dividing the current number of vessels of the system by the maximum number of vessels supported by the system to obtain a vessel load rate between 0 and 1; step A12, dividing the average complexity weight of the current business request by the preset maximum complexity benchmark to obtain an operation complexity intensity value between 0 and 1; step A13, performing z times of power operation on the vessel load rate and performing y times of power operation on the operation complexity intensity value; and step A14, multiplying the operation results of the power operation of the vessel load rate and the operation complexity intensity value to obtain a core coupling pressure score.

[0019] The second determination sub-unit is configured to perform the following steps: step B11, dividing the total amount of business requests per unit time in the predicted future preset period by the peak throughput of the system to obtain a predicted traffic load rate; and step B12, multiplying the predicted traffic load rate by the corresponding weight coefficient γ to obtain a predicted traffic pressure score.

[0020] The third determination sub-unit is configured to perform the following steps: step C11, dividing the number of job orders in the processing state in the current system by the preset processing order threshold of the system to obtain an order backlog rate; step C12, performing natural logarithm calculation on the sum of 1 and the order backlog rate; and step C13, multiplying the logarithm calculation result by the corresponding weight coefficient δ to obtain an order backlog health degree pressure score.

[0021] The fourth determination sub-unit is configured to add the core coupling pressure score, the predicted traffic pressure score, and the order backlog health degree pressure score to obtain a comprehensive CFS business pressure index.

[0022] In one embodiment, the base instance determination unit is further configured to perform the following steps:

[0023] Step A21, obtaining the preset minimum instance number and the preset maximum instance number of the system, and subtracting the minimum instance number from the maximum instance number to obtain a difference value, which is an instance number interval span value available for elastic scheduling;

[0024] Step A22, multiplying the comprehensive CFS business pressure index by the instance number interval span value to obtain an instance increment;

[0025] Step A23, adding the instance increment to the preset minimum instance number of the system to obtain a preliminary instance number value, and performing an upward rounding operation on the preliminary instance number value, and the rounded value is the base instance number.

[0026] In one embodiment, the correction factor determination unit is further configured to perform the following steps:

[0027] Step A31, subtracting the system preset resource pressure target threshold value from the current system resource pressure index to obtain a system pressure exceeding value; wherein when the system pressure exceeding value is less than 0, the system pressure exceeding value is set to 0;

[0028] Step A32, dividing the system pressure exceeding value by the resource pressure target threshold value to obtain a system pressure overload ratio;

[0029] Step A33, adding 1 to the system pressure overload ratio to obtain a real-time pressure correction factor of the system.

[0030] In one embodiment, the target instance determination unit is further configured to perform the following steps:

[0031] Step A41, multiplying the base instance number determined by the base instance determination unit by the real-time pressure correction factor determined by the correction factor determination unit, and rounding up the product to obtain an integer, which is the preliminary target instance number after real-time load correction;

[0032] Step A42, comparing the preliminary target instance number with the system preset minimum instance number, and taking the larger one as the lower limit of the instance number;

[0033] Step A43, comparing the lower limit of the instance number obtained in step A42 with the system preset maximum instance number, and taking the smaller one as the target number of application server instances N(t+1) to be maintained in the next scaling period;

[0034] The operation unit is further configured to compare the N(t+1) with the instance number N(t) of the current scaling period; if N(t+1) > N(t), perform horizontal expansion operation to make the application server instance number of the next scaling period reach N(t+1); if N(t+1) < N(t), perform horizontal shrinkage operation to make the application server instance number of the next scaling period reach N(t+1); if they are equal, keep the application server instance number unchanged.

[0035] As another aspect of the embodiment, the application provides a CFS warehouse management method based on request distribution and elastic scaling technology, comprising:

[0036] receiving a service request from a client, and analyzing the service request according to a preset classification rule to determine the category to which the service request belongs, the category including real-time key request, real-time light request or non-real-time batch request;

[0037] The real-time critical requests are assigned to the core transaction channel for processing, the real-time lightweight requests are assigned to the fast query channel for processing, and the non-real-time batch requests are assigned to the asynchronous task queue for caching and scheduling.

[0038] The system monitors the resource load metrics of the system and, based on the relationship between the resource load metrics and preset thresholds, as well as CFS business metrics, performs dynamic horizontal scaling up, horizontal scaling down, or keeps the current number of instances unchanged for the application server instances in the system.

[0039] Write operations from the core transaction channel are handled using the primary database, and read operations from the fast query channel are handled using at least one secondary database.

[0040] In one embodiment, the monitoring system uses resource load metrics, and based on the relationship between the resource load metrics and a preset threshold, as well as CFS business metrics, dynamically performs horizontal scaling up or down operations on application server instances in the system, or maintains the current number of instances, including:

[0041] The core coupling pressure score is determined based on the current number of operating vessels, the system's maximum supported vessel count, the current average request complexity, and the preset maximum complexity value; the predicted traffic pressure score is determined based on the system's peak throughput and the predicted future request volume; the backlog health pressure score is determined based on the current number of pending documents and the system's document processing threshold; and the comprehensive CFS business pressure index is determined based on the core coupling pressure score, the predicted traffic pressure score, and the backlog health pressure score.

[0042] The basic number of instances is determined based on the comprehensive CFS business pressure index, the minimum number of instances preset by the system, and the maximum number of instances.

[0043] The system pressure overload ratio is determined based on the system's real-time resource pressure index and the preset system target pressure threshold; the system's real-time pressure correction factor is determined based on the pressure overload ratio.

[0044] The initial target number of instances is determined based on the base number of instances and the real-time pressure correction factor; the target number of instances for the next scaling cycle of the system is determined based on the initial target number of instances and the preset instance number limit.

[0045] Based on the target number of instances for the next scaling cycle, perform corresponding horizontal scaling operations, horizontal scaling operations, or keep the current number of instances unchanged for the application server instances in the next scaling cycle of the system.

[0046] In one embodiment, determining the comprehensive CFS business stress index includes:

[0047] Step A11: Divide the current number of operating vessels in the system by the maximum number of vessels that the system can support to obtain a vessel load factor between 0 and 1;

[0048] Step A12: Divide the average complexity weight of the current business request by the preset maximum complexity baseline to obtain an operation complexity strength value between 0 and 1.

[0049] Step A13: Perform z-fold power operation on the ship load rate and y-fold power operation on the operation complexity intensity value;

[0050] Step A14: Multiply the ship load rate calculation result after exponentiation with the operation complexity intensity value calculation result to obtain the core coupling pressure score;

[0051] Step B11: Divide the predicted total number of business requests per unit time within the predicted future preset time period by the system peak throughput to obtain the predicted traffic load rate;

[0052] Step B12: Multiply the predicted flow load rate by its corresponding weighting coefficient x to obtain the predicted flow pressure score;

[0053] Step C11: Divide the number of pending work orders in the current system by the system's preset processing threshold to obtain the backlog rate.

[0054] Step C12: Calculate the natural logarithm of the sum of 1 and the document backlog rate;

[0055] Step C13: Multiply the logarithmic calculation result by its corresponding weighting coefficient δ to obtain the backlog health stress score;

[0056] Step C14: Add the core coupling pressure score, the predicted flow pressure score, and the backlog health pressure score together. The result is the comprehensive CFS business pressure index.

[0057] The beneficial effects of the above-mentioned technical solutions provided in the embodiments of the present invention include at least the following:

[0058] Compared with existing technologies, the CFS warehouse management system and method based on request routing and elastic scaling technology provided in this invention, through the collaborative work of the request routing module and three types of processing channels, intelligently classifies and isolates massive concurrent requests during peak business periods, ensuring that core transactions are not blocked by batch queries or reporting tasks, and that most real-time requests are responded to quickly. This effectively solves the problems of slow system response and operational lag, and improves the system's high-concurrency processing capabilities and response speed. The elastic scaling control module, by integrating real-time system load and CFS business indicators, realizes the prediction and dynamic allocation of resources. It can proactively cope with business peaks to prevent the system from becoming unavailable due to resource exhaustion, and automatically release resources during off-peak periods. This realizes the transformation from passive hardware upgrades to intelligent elastic scheduling, reducing operating costs while ensuring stability, achieving intelligent elastic scaling, and ensuring system stability and cost optimization. This invention goes beyond basic load balancing strategies, intelligently distinguishing the business attributes and resource consumption levels of requests. By routing requests to appropriate processing channels (such as core transaction channels to ensure data consistency, fast query channels to utilize caching, and asynchronous queues to decouple time-consuming tasks), and prioritizing critical business operations when resources are limited, it achieves better request scheduling and fine-grained resource allocation. This solves the systemic performance bottleneck in specific CFS scenarios and enables optimal request scheduling and fine-grained resource allocation.

[0059] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0060] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0061] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0062] Figure 1 This is a schematic diagram of the CFS warehouse management system based on request routing and elastic scaling technology provided in an embodiment of the present invention;

[0063] Figure 2 This is a flowchart of the CFS warehouse management method based on request routing and elastic scaling technology provided in an embodiment of the present invention. Detailed Implementation

[0064] Exemplary embodiments of the present disclosure will be described in greater detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure can be more thoroughly understood, and so that the full scope of the present disclosure is conveyed to those skilled in the art.

[0065] In the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", "far", "near", "front", "back", and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, the terms "first", "second", "third" are only for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0066] In the description of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "mounting", "connection", "connection" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0067] The embodiment of the present application provides a CFS warehouse management system based on request shunting and elastic scaling technology, as shown in Figure 1 The CFS warehouse management system comprises:

[0068] A request shunting module is disposed in the API gateway, configured to receive a service request from a client, and perform real-time analysis on the service request according to a preset classification rule, determine a category to which the service request belongs, and the category comprises a real-time key request, a real-time light request or a non-real-time batch request.

[0069] A processing channel module is connected with the request shunting module, configured to receive and process the request routed by the request shunting module; the processing channel module comprises a core transaction channel for processing the real-time key request, a quick query channel for processing the real-time light request, and an asynchronous task queue for caching and scheduling the non-real-time batch request.

[0070] An elastic scaling control module is configured to monitor resource load indicators of the system and perform dynamic horizontal scaling, horizontal scaling or keep the current instance number unchanged according to the size relationship between the resource load indicators and the preset threshold and the CFS service indicators.

[0071] A data layer module includes a master database and at least one slave database; the master database is configured to process write operations from the core transaction channel, and the slave database is configured to process read operations from the fast query channel.

[0072] The request shunting module is deployed at the API gateway level of the system and serves as a unified entrance for all external service requests. When a service request arrives, the module performs real-time analysis according to the following steps.

[0073] Request feature extraction: First, the received service request is parsed to extract key feature metadata. These features include, but are not limited to, HTTP request methods (such as GET, POST, PUT, DELETE), request access paths (URLPath, such as / api / inbound / confirm, / api / stock / query, / api / report / daily), query parameters (Query Parameters) or specific business identifiers in the request body (Request Body).

[0074] Rule base matching: The extracted features are matched with a predefined and configurable classification rule base. The rule base is pre-set by the system administrator according to the CFS business logic, and its core is a set of condition-classification mapping rules. For example:

[0075] Real-time critical request rule: If the request method is POST, PUT or DELETE, and the access path contains keywords such as / update, / confirm, / submit, etc., the request is classified as a real-time critical request. Such requests usually involve inventory status changes, goods in and out of warehouse confirmation and other core transactional operations.

[0076] Real-time lightweight request rule: If the request method is GET, and the access path contains keywords such as / query, / search, / get, / list, etc., the request is classified as a real-time lightweight request. Such requests are mainly for goods status query, inventory quantity retrieval and other read-only operations.

[0077] Non-real-time batch request rule: if the access path contains keywords such as / report, / export, / download, / history, etc., regardless of the request method, the request will be classified as a non-real-time batch request. Such requests are usually computationally or I / O intensive tasks such as generating data reports, exporting history records, etc.

[0078] Classification result output: According to the first rule matched, the module immediately assigns a classification label (such as "real-time key") to the current business request and synchronously sends the request and its classification result to the subsequent processing channel module.

[0079] In the above system, the application server instance is a computing unit that carries specific business logic processing capabilities; and the channel and queue are request scheduling and distribution mechanisms located before these instances. Among them, the core transaction channel and the fast query channel serve as synchronous processing paths, routing real-time requests directly to idle application server instances for immediate processing; the asynchronous task queue serves as an asynchronous buffer, temporarily storing non-real-time tasks, and is pulled for processing by dedicated application server instances as needed. The above-mentioned core transaction channel, fast query channel, and asynchronous task queue work together to achieve intelligent scheduling of requests and efficient use of resources.

[0080] The beneficial effects of the above technical solution are: compared with the prior art, the CFS warehouse management system based on request shunting and elastic scaling technology provided by the embodiment of the application, through the cooperative work of the request shunting module and the three types of processing channels, intelligently classifies and isolates the massive concurrent requests during the peak period of tidal business, which ensures that the core transaction is not blocked by batch query or report tasks, and most of the real-time requests can be quickly responded, fundamentally solving the problem of slow system response and operation lag, and significantly improving the system high-concurrency processing capability and response speed. The elastic scaling control module realizes the accurate prediction and dynamic allocation of resources by integrating the system real-time load and CFS business indicators (such as ship port planning), which not only actively responds to business peaks to prevent the system from being unavailable due to resource depletion, but also automatically releases resources during business slack periods, realizing the transition from passive hardware upgrade to intelligent elastic scheduling, ensuring stability while significantly reducing operating costs, achieving intelligent elastic scaling, and effectively ensuring system stability and cost optimization. The present application goes beyond the basic load balancing strategy, can intelligently distinguish the business attributes and resource consumption of requests, routes the requests to the most suitable processing channel (such as the core transaction channel to ensure data consistency, the fast query channel to utilize cache, and the asynchronous queue to decouple time-consuming tasks), and prioritizes critical business in the case of limited resources, achieving optimal scheduling of requests and fine allocation of resources, and solving the systemic performance bottleneck in the specific scenario of CFS.

[0081] In one embodiment, the elastic scaling control module comprises:

[0082] a pressure index determination unit configured to determine a core coupling pressure score according to a current number of operating ships, a maximum number of supported ships of the system, a current average complexity of requests, and a preset maximum value of complexity; determine a predicted traffic pressure score according to a system peak throughput of the system and a predicted future request amount; determine a backlog health pressure score according to a current number of pending documents and a document processing threshold of the system; and determine a comprehensive CFS business pressure index according to the core coupling pressure score, the predicted traffic pressure score, and the backlog health pressure score;

[0083] a base instance determination unit configured to determine a base instance number according to the comprehensive CFS business pressure index, a preset minimum instance number, and a preset maximum instance number of the system;

[0084] a correction factor determination unit configured to determine a pressure overload ratio of the system according to a resource real-time pressure index of the system and a preset target pressure threshold of the system; and determine a real-time pressure correction factor of the system according to the pressure overload ratio;

[0085] a target instance determination unit configured to determine a preliminary target instance number according to the base instance number and the real-time pressure correction factor; and determine an instance target number of a next scaling period of the system according to the preliminary target instance number and a preset instance number limit;

[0086] an operation unit configured to perform a corresponding horizontal expansion operation, a horizontal contraction operation, or keep the current instance number unchanged on the application server instance of the next scaling period of the system according to the instance target number of the next scaling period.

[0087] The current number of operating ships refers to the total number of ships that are actively interacting with the CFS warehouse management system. The maximum number of supported ships of the system refers to the maximum number of ship operations that the CFS warehouse management system can efficiently handle simultaneously while ensuring a preset service level.

[0088] A document refers to a core business voucher and instruction carrier throughout the warehouse operation process, which can be understood as a warehouse operation work order or operation permit. Each document represents an entity logistics operation that must be recorded, tracked, and completed by the system. Specifically, the documents in the current number of pending documents mainly include but are not limited to the following types: warehouse-in type documents such as warehouse-in notification (indicating incoming goods information), receipt, and shelving instruction (indicating that the worker will move the received goods to the designated storage location); warehouse-out type documents such as warehouse-out order / pickup order, picking order, and delivery order; and in-warehouse operation documents such as relocation order, inventory order, and disassembly / assembly operation order.

[0089] The current request average complexity is a quantitative measure of the overall technical difficulty of the requests processed by the system within a specific time window. The calculation method is as follows: a complexity weight database is established in advance, which assigns a fixed complexity weight value to different types of business operations. The higher the weight value, the more system resources (CPU, database I / O, processing time) are consumed. For example: low complexity (weight = 1), involving simple key-value queries such as single number-based cargo status queries and empty storage space queries. Medium complexity (weight = 2), involving multi-table association and condition filtering queries such as historical flow queries and combined condition inventory queries. High complexity (weight = 3), involving core transactional write operations such as cargo warehousing confirmation, warehouse status update, and inventory quantity deduction. Extra-high complexity (weight = 4 or 5), involving complex batch processing or computing tasks such as mixed unloading pallet warehousing operations and inventory counting result batch confirmation. The system uses a sliding time window (such as the last 5 minutes) as the statistical period. For each business request processed within the window, the complexity weight database is queried based on the request path and method to determine the complexity weight Ci. The complexity weights of all requests within the window are accumulated to obtain the total complexity. The total number of requests n within the window is counted. The total complexity is divided by n to obtain the current request average complexity. The higher the average complexity, the more resource-intensive requests the system is processing, triggering more aggressive expansion strategies.

[0090] wherein the real-time in the resource real-time pressure index of the system refers to that the monitoring data relied on for calculation is derived from a preset short time window before the start of the current scaling decision period (a period of time in the current scaling period), to ensure that the decision basis can sensitively reflect the latest load state of the system. The calculation formula of the resource real-time pressure index of the system is shown in formula (1) as follows:

[0091] (1)

[0092] Wherein, the P(t) represents the resource real-time stress index of the system, which can also be understood as the resource stress index of the system corresponding to the current scaling period t; α+β+γ=1, the values of α, β and γ are all greater than 0 and less than 1, which are the relative importance of CPU resource, memory resource and database resource in the system respectively, for example, if the system is computation-intensive, then α=0.5, β=0.3 and γ=0.2 can be set. CPU(t) represents the CPU usage rate corresponding to the current scaling decision period, CPU(max) represents the highest threshold of the CPU usage rate preset by the system; MEM(t) represents the memory usage rate corresponding to the current scaling decision period, MEM(max) represents the highest threshold of the memory usage rate preset by the system; DB(t) represents the database active connection number corresponding to the current scaling decision period, and DB(max) represents the highest threshold of the database active connection number preset by the system.

[0093] In one embodiment, the stress index determination unit further comprises:

[0094] The first determination sub-unit is configured to perform the following steps: step A11, dividing the current number of work vessels of the system by the maximum number of vessels supported by the system to obtain a vessel load rate between 0 and 1; step A12, dividing the average complexity weight of the current business request by the preset maximum complexity reference value to obtain an operation complexity intensity value between 0 and 1; step A13, performing z times of power operation on the vessel load rate and y times of power operation on the operation complexity intensity value (this step aims to simulate the effect of mutual coupling and amplification of system stress between the number of vessels and the operation complexity); and step A14, multiplying the operation results of the vessel load rate after the power operation and the operation complexity intensity value to obtain a core coupling stress score (which represents the core stress generated by the current work scale and operation difficulty).

[0095] The second determination sub-unit is configured to perform the following steps: step B11, dividing the total amount of business requests per unit time in the predicted future preset period by the peak throughput of the system to obtain a predicted traffic load rate; and step B12, multiplying the predicted traffic load rate by the corresponding weight coefficient x to obtain a predicted traffic stress score.

[0096] The third determination sub-unit is configured to perform the following steps: step C11, dividing the number of work orders in the processing state in the current system by the preset processing order threshold of the system to obtain an order backlog rate; step C12, performing natural logarithm calculation on the sum of 1 and the order backlog rate (this step simulates the effect that the stress caused by the backlog to the system is "marginal decreasing" with the increase of the backlog, that is, the stress caused by the initial backlog is most significant); and step C13, multiplying the logarithm calculation result by the corresponding weight coefficient δ to obtain an order backlog health degree stress score.

[0097] The fourth determining sub-unit is configured to add the core coupling pressure score, the predicted traffic pressure score and the backlog health degree pressure score, and a calculation result is a comprehensive CFS business pressure index (the index is a dimensionless value, which is transmitted to a next stage of an elastic scaling decision-making process for use).

[0098] The model for calculating the comprehensive CFS business pressure index fuses the business pressures in three dimensions through the multiplication coupling and the weighted superposition. First, the ship load rate and the operation complexity are multiplied after being squared, and then the core pressure is added to the weighted predicted traffic pressure and the backlog health degree pressure to form a unified comprehensive pressure index. The model conforms to the actual CFS business. There is an obvious nonlinear amplification relationship between the ship operation amount and the operation difficulty (for example, when there are more ships and the operation is more complex, the pressure increases sharply), and the multiplication term accurately describes this nature. The traffic prediction and the backlog condition as independent pressure sources correct the total pressure in a linear manner, so that the model can capture the core contradiction and take other influencing factors into account, and accurately quantify the complex business scenario.

[0099] The decision rhythm of the elastic scaling control module is defined by the scaling period. At each decision point, the future preset time period in the total amount of business requests per unit time in the future preset time period can be set to be aligned with the next scaling period in time or to contain the next scaling period in the future preset time period.

[0100] In an embodiment, the prediction method of the total amount of business requests per unit time in the future preset time period can adopt an intelligent calculation method combining historical rules and known business plans, which is as follows: first, according to the business calendar, the future preset time period is defined as a continuous time period starting from the estimated arrival time of the next forecast ship to the estimated departure time. Then, from the historical records, find the historical same period data similar to the characteristics of the future preset time period, calculate the number of business requests processed per unit time in the historical period as the benchmark value of the prediction. Then, obtain the total operation amount of all forecast ships in the future preset time period, and compare it with the total operation amount of all ships in the historical same period to calculate an operation amount adjustment coefficient, which reflects the expected change amplitude of the future business scale relative to the historical same period. Finally, multiply the benchmark value and the operation amount adjustment coefficient, and the calculation result is the final prediction value of the total amount of business requests per second in the future preset time period. This method uses the known future business plan to correct the historical rules, so that the prediction result has data support and can reflect the business fluctuation in advance, providing accurate and reliable basis for the elastic scaling decision-making.

[0101] In one embodiment, the base instance determining unit is further configured to perform the following steps:

[0102] Step A21, obtaining the minimum instance number and the maximum instance number preset by the system, and subtracting the minimum instance number from the maximum instance number to obtain a difference value, which is the instance number interval span value available for elastic scheduling;

[0103] Step A22, multiplying the comprehensive CFS service pressure index by the instance number interval span value (the physical meaning is that the service pressure index determines how much proportion should be occupied in the total interval. When the pressure is 0, the increment is 0; when the pressure is 1, the increment is equal to the entire interval), and the product is the instance increment;

[0104] Step A23, adding the instance increment to the minimum instance number preset by the system to obtain a preliminary instance number value; and performing an upward rounding operation on the preliminary instance number value, and the rounded value is the base instance number.

[0105] The above model for calculating the base instance number linearly maps the dimensionless service pressure index to a specific instance number range. The principle is: first, determine the instance number elastic interval allowed by the system, then use the service pressure index to determine the proportion that should be occupied in the interval, and finally add the minimum instance number and take the integer to obtain a base resource planning value. The model realizes a direct and intuitive conversion from service pressure to resource demand. When the pressure is 0, the system maintains the minimum available instance; when the pressure is 1, the system prepares the maximum resource to cope with the extreme load; when the pressure is between 0 and 1, the resource increases smoothly in proportion. This linear mapping relationship is simple, stable, easy to manage and optimize, and provides a clear and reliable baseline for resource allocation.

[0106] In one embodiment, the correction factor determining unit is further configured to perform the following steps:

[0107] Step A31, subtracting the resource pressure target threshold preset by the system from the current system resource pressure index to obtain a system pressure exceeding value; wherein when the system pressure exceeding value is less than 0, the system pressure exceeding value is set to 0 (the purpose of this step is to only care about the case where the pressure exceeds the target value);

[0108] Step A32, dividing the system pressure exceeding value by the resource pressure target threshold to obtain the system pressure overload ratio;

[0109] Step A33, adding 1 to the system pressure overload ratio to obtain the real-time pressure correction factor of the system (if the system pressure does not exceed the target, the correction factor is 1; if the pressure is overloaded, the correction factor is greater than 1, and the more serious the overload, the greater the factor).

[0110] The formula for calculating the real-time pressure correction factor is a feedback control mechanism that generates a correction multiplier by calculating the relative proportion of the system real-time resource pressure exceeding the target threshold (pressure overload ratio). When the system is not overloaded, the factor is 1, and the baseline plan is not changed; when overload occurs, the factor is greater than 1, and the more serious the overload, the greater the correction range. This model provides the system with adaptive fine-tuning capabilities. The business pressure index is a feedforward control based on prediction and business indicators, while this correction factor is a feedback control based on the real running state of the system. The combination of the two ensures that the elastic scaling decision is both forward-looking and able to respond quickly to unexpected situations beyond prediction, enhancing the robustness of the system.

[0111] In one embodiment, the target instance determination unit is further configured to perform the following steps:

[0112] Step A41, multiply the base instance number determined by the base instance determination unit by the real-time pressure correction factor determined by the correction factor determination unit, and round up the product to obtain an integer, which is the preliminary target instance number after real-time load correction;

[0113] Step A42, compare the preliminary target instance number with the minimum instance number preset by the system, and take the larger one as the lower limit of the instance number;

[0114] Step A43, compare the lower limit of the instance number obtained in step A42 with the maximum instance number preset by the system, and take the smaller one as the target number of application server instances N(t+1) to be maintained in the next scaling period;

[0115] The operation unit is further configured to compare N(t+1) with the instance number N(t) of the current scaling period, t representing the number of scaling periods; if N(t+1) > N(t), perform horizontal expansion operation to make the number of application server instances in the next scaling period reach N(t+1); if N(t+1) < N(t), perform horizontal shrinkage operation to make the number of application server instances in the next scaling period reach N(t+1); if they are equal, keep the number of application server instances unchanged.

[0116] The model for calculating N(t+1) above is the final decision and safety boundary constraint step. It multiplies the business-driven base instance number with the real-time pressure correction factor, realizing the fusion of forward-looking planning and real-time feedback. Then, the result is ensured to be an integer by rounding up, and the final number is clamped in the safe range allowed by the system by using the maximum and minimum functions. The model is a reasonable end point of the entire elastic decision chain. Multiplication embodies the comprehensive effect of feedforward and feedback control; rounding up avoids deployment problems caused by incomplete instances and ensures sufficient resources; and interval clamping is a crucial safety measure to prevent unlimited expansion of resources or complete interruption of services due to algorithm or input abnormalities, ensuring the feasibility of operation and the stability of the system.

[0117] Corresponding to the above system, the application provides a CFS warehouse management method based on request shunting and elastic scaling technology, as shown in Figure 2 The method comprises the following steps:

[0118] Step S1, receiving a service request from a client, and analyzing the service request according to a preset classification rule to determine the category to which the service request belongs, the category including a real-time key request, a real-time light request or a non-real-time batch request;

[0119] Step S2, distributing the real-time key request into a core transaction channel for processing, distributing the real-time light request into a fast query channel for processing, and distributing the non-real-time batch request into an asynchronous task queue for caching and scheduling processing;

[0120] Step S3, monitoring resource load indicators of the system, and according to the size relationship between the resource load indicators and a preset threshold value and a CFS service indicator, performing a dynamic horizontal expansion operation, a horizontal contraction operation or keeping the current instance number unchanged on an application server instance in the system;

[0121] Step S4, processing a write operation from the core transaction channel by using a master database, and processing a read operation from the fast query channel by using at least one slave database.

[0122] In one embodiment, the monitoring of the resource load indicators of the system and the performance of the dynamic horizontal expansion operation, the horizontal contraction operation or the keeping of the current instance number unchanged on the application server instance in the system according to the size relationship between the resource load indicators and the preset threshold value and the CFS service indicator comprises:

[0123] determine a core coupling pressure score according to the current number of operating vessels, the maximum number of vessels supported by the system, the current average complexity of requests, and a preset maximum complexity value; determine a predicted traffic pressure score according to a peak throughput of the system and a predicted future request volume; determine a backlog health pressure score according to the current number of pending documents and a document processing threshold of the system; and determine a comprehensive CFS business pressure index according to the core coupling pressure score, the predicted traffic pressure score, and the backlog health pressure score;

[0124] determine a base instance number according to the comprehensive CFS business pressure index, a minimum instance number preset for the system, and a maximum instance number preset for the system;

[0125] determine a pressure overload ratio of the system according to a resource real-time pressure index of the system and a preset system target pressure threshold; and determine a real-time pressure correction factor of the system according to the pressure overload ratio;

[0126] determine a preliminary target instance number according to the base instance number and the real-time pressure correction factor; and determine an instance target number of a next scaling cycle of the system according to the preliminary target instance number and a preset instance number limit;

[0127] perform a corresponding horizontal scaling operation, a horizontal scaling-in operation, or keep the current instance number unchanged on the application server instance of the next scaling cycle of the system according to the instance target number of the next scaling cycle.

[0128] In one embodiment, the determination of the comprehensive CFS business pressure index comprises:

[0129] Step A11, divide the current number of operating vessels of the system by the maximum number of vessels supported by the system to obtain a vessel load rate between 0 and 1;

[0130] Step A12, divide the average complexity weight of the current business request by a preset maximum complexity benchmark to obtain an operation complexity intensity value between 0 and 1;

[0131] Step A13, perform z times of power operation on the vessel load rate and y times of power operation on the operation complexity intensity value;

[0132] Step A14, multiply the operation result of the vessel load rate after the power operation by the operation result of the operation complexity intensity value to obtain a core coupling pressure score;

[0133] Step B11, divide the total amount of business requests per unit time in a predicted future preset time period by the peak throughput of the system to obtain a predicted traffic load rate;

[0134] Step B12, multiply the predicted traffic load rate by its corresponding weight coefficient x to obtain the predicted traffic pressure score;

[0135] Step C11, divide the number of job documents in the current system in the pending state by the system preset processing document threshold to obtain the document backlog rate;

[0136] Step C12, calculate the natural logarithm of the sum of 1 and the document backlog rate;

[0137] Step C13, multiply the logarithm calculation result by its corresponding weight coefficient δ to obtain the backlog health pressure score;

[0138] Step C14, add the core coupling pressure score, the predicted traffic pressure score, and the backlog health pressure score, and the calculation result is the comprehensive CFS business pressure index.

[0139] Wherein, z and y are used to adjust the influence of ship load rate and operation complexity in the coupling effect. When z>1, the increase of the number of ships will be given a higher weight, and slight growth will cause the pressure score to rise significantly; when z<1, the sensitivity of the system to the change of the number of ships decreases. z and y are usually positive real numbers. In practice, they are often set in the interval [0.5, 3.0] for tuning. If the number of ships is considered to be the main pressure source, z>y can be set; if the operation complexity is considered to be the key factor, y>z can be set. x and δ are used to balance the contribution proportion of the predicted traffic pressure score and the backlog health pressure score in the final comprehensive CFS business pressure index; they are usually positive real numbers between 0 and 1, and do not need to strictly satisfy x+δ=1 (because they are independent coefficients of different pressure scores). For example, if the system pays more attention to traffic fluctuations, x can be set to 0.6 and δ can be set to 0.3; if more attention is paid to the backlog of work, the value of δ can be adjusted. The final values of these coefficients are positive real numbers that can be configured according to the actual business scenario, and the specific values are determined through system debugging or historical data fitting.

[0140] The order of steps described in the embodiments of the present application and the drawings is not limited, and can be adjusted according to needs.

[0141] Compared with the prior art, the CFS warehouse management system and method based on request shunting and elastic scaling technology provided by the embodiment of the application can intelligently classify and isolate the massive concurrent requests in the peak period of tidal business through the cooperative work of the request shunting module and the three types of processing channels, ensure that the core transaction is not blocked by batch query or report tasks, and that most of the real-time requests can be quickly responded, effectively solve the problems of slow system response and operation lag, and improve the high-concurrency processing capability and response speed of the system. The elastic scaling control module realizes the prediction and dynamic allocation of resources by fusing the real-time load of the system and the CFS business index, can actively cope with the business peak and prevent the system from being unavailable due to resource depletion, and can automatically release resources in the business flat period, realizes the change from passive hardware upgrade to intelligent elastic scheduling, reduces the operating cost while ensuring stability, realizes intelligent elastic scaling, and guarantees the stability and cost optimization of the system. The application surpasses the basic load balancing strategy, can intelligently distinguish the business attributes and resource consumption degree of the request, routes the request to the appropriate processing channel (such as the core transaction channel to guarantee data consistency, the fast query channel to utilize the cache, and the asynchronous queue to decouple time-consuming tasks), and in the case of limited resources, preferentially guarantees the key business, realizes the optimal scheduling of the request and the fine allocation of resources, and solves the systematic performance bottleneck in the specific scenario of CFS.

[0142] Obviously, those skilled in the art can make various modifications and variations to the application without departing from the spirit and scope of the application. The present disclosure is not limited to the precise structure described above and shown in the drawings, and various modifications and changes can be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims. Thus, if these modifications and variations of the application fall within the scope of the claims of the application and their equivalents, the application also intends to include these modifications and variations.

Claims

1. A CFS warehouse management system based on request routing and elastic scaling technology, characterized in that, include: The request routing module, deployed on the API gateway, is used to receive business requests from clients and analyze the business requests according to preset classification rules to determine the category to which the business requests belong. The categories include real-time critical requests, real-time lightweight requests, or non-real-time batch requests. The processing channel module, connected to the request routing module, is used to receive and process requests routed by the request routing module. The processing channel module includes a core transaction channel for processing real-time critical requests, a fast query channel for processing real-time lightweight requests, and an asynchronous task queue for caching and scheduling non-real-time batch requests. The elastic scaling control module is used to monitor the system's resource load indicators and, based on the relationship between the resource load indicators and preset thresholds, as well as CFS business indicators, dynamically scale up or down the application server instances in the system, or keep the current number of instances unchanged. The core transaction channel and the fast query channel serve as synchronous processing paths, which directly route real-time requests to idle application server instances for immediate processing. The data layer module includes a master database and at least one slave database; the master database is used to process write operations from the core transaction channel, and the slave database is used to process read operations from the fast query channel.

2. The CFS warehouse management system as described in claim 1, characterized in that, The elastic telescopic control module includes: The pressure index determination unit is used to determine the core coupling pressure score based on the current number of operating vessels, the system's maximum supported vessel count, the current average request complexity, and the preset maximum complexity value; determine the predicted flow pressure score based on the system's peak throughput and the predicted future request volume; determine the backlog health pressure score based on the current number of pending documents and the system's document processing threshold; and determine the comprehensive CFS business pressure index based on the core coupling pressure score, the predicted flow pressure score, and the backlog health pressure score. The basic instance determination unit is used to determine the number of basic instances based on the comprehensive CFS business pressure index, the minimum number of instances preset by the system, and the maximum number of instances. The correction factor determination unit is used to determine the system's pressure overload ratio based on the system's real-time resource pressure index and a preset system target pressure threshold; and to determine the system's real-time pressure correction factor based on the pressure overload ratio. The target instance determination unit is used to determine the initial target instance number based on the basic instance number and the real-time pressure correction factor; and to determine the target instance number for the next scaling cycle of the system based on the initial target instance number and the preset instance number limit. The operation unit is used to perform corresponding horizontal scaling operations, horizontal scaling operations, or keep the current number of instances unchanged for the application server instances in the next scaling cycle, based on the target number of instances in the next scaling cycle.

3. The CFS warehouse management system as described in claim 2, characterized in that, The pressure index determination unit further includes: The first determining subunit is used to perform the following steps: Step A11: Divide the current number of operating vessels in the system by the maximum number of vessels supported by the system to obtain a vessel load rate between 0 and 1; Step A12: Divide the average complexity weight of the current business request by the preset maximum complexity benchmark to obtain an operation complexity intensity value between 0 and 1; Step A13: Perform z-fold exponentiation on the vessel load rate and y-fold exponentiation on the operation complexity intensity value; Step A14: Multiply the result of the exponentiation of the vessel load rate by the result of the operation complexity intensity value to obtain the core coupling pressure score; The second determining subunit is used to perform the following steps: Step B11: Divide the total number of service requests per unit time in the predicted future preset time period by the system peak throughput to obtain the predicted traffic load rate; Step B12: Multiply the predicted traffic load rate by its corresponding weight coefficient γ to obtain the predicted traffic pressure score. The third sub-unit is used to perform the following steps: Step C11: Divide the number of job documents in the current system that are in the pending state by the system's preset processing threshold to obtain the backlog rate; Step C12: Calculate the natural logarithm of the sum of step C11 and the backlog rate; Step C13: Multiply the logarithmic result by its corresponding weight coefficient δ to obtain the backlog health pressure score. The fourth determination subunit is used to add the core coupling pressure score, the predicted flow pressure score, and the backlog health pressure score, and the result is the comprehensive CFS business pressure index.

4. The CFS warehouse management system as described in claim 2, characterized in that, The basic instance determination unit is also used to perform the following steps: Step A21: Obtain the system's preset minimum and maximum number of instances. Subtract the minimum number of instances from the maximum number of instances to obtain a difference. This difference is the range of instances available for elastic scheduling. Step A22: Multiply the comprehensive CFS business pressure index by the instance quantity range value, and the multiplier is the instance increment; Step A23: Add the instance increment to the system's preset minimum instance count to obtain a preliminary instance count value; round up the preliminary instance count value, and the rounded value is the base instance count.

5. The CFS warehouse management system as described in claim 2, characterized in that, The correction factor determination unit is further configured to perform the following steps: Step A31: Subtract the system's preset resource pressure target threshold from the current system resource pressure index to obtain the system pressure excess value; where, when the system pressure excess value is less than 0, the system pressure excess value is set to 0; Step A32: Divide the system pressure overload value by the resource pressure target threshold to obtain the system pressure overload ratio; Step A33: Add 1 to the system's pressure overload ratio to obtain the system's real-time pressure correction factor.

6. The CFS warehouse management system as described in claim 2, characterized in that, The target instance determination unit is further configured to perform the following steps: Step A41: Multiply the number of basic instances determined by the basic instance determination unit by the real-time pressure correction factor determined by the correction factor determination unit, and round up the product to obtain an integer, which is the initial target number of instances after real-time load correction. Step A42: Compare the initial target number of instances with the minimum number of instances preset by the system, and take the larger of the two as the lower limit of the number of instances; Step A43: Compare the lower limit of the number of instances obtained in step A42 with the maximum number of instances preset by the system, and take the smaller of the two as the target number N(t+1) of application server instances to be maintained in the next scaling cycle. The operation unit is also used to compare N(t+1) with the number of instances N(t) in the current scaling cycle; if N(t+1) > N(t), then perform a horizontal scaling operation so that the number of application server instances in the next scaling cycle reaches N(t+1); if N(t+1) < N(t), then perform a horizontal scaling down operation so that the number of application server instances in the next scaling cycle reaches N(t+1); if the two are equal, then keep the number of application server instances unchanged.

7. A CFS warehouse management method based on request splitting and elastic scaling technology, characterized in that, include: Receive business requests from clients and analyze the business requests according to preset classification rules to determine the category to which the business requests belong. The categories include real-time critical requests, real-time lightweight requests, or non-real-time batch requests. The real-time critical requests are assigned to the core transaction channel for processing, the real-time lightweight requests are assigned to the fast query channel for processing, and the non-real-time batch requests are assigned to the asynchronous task queue for caching and scheduling. The system monitors the resource load metrics of the system and, based on the relationship between the resource load metrics and preset thresholds, as well as CFS business metrics, performs dynamic horizontal scaling up, horizontal scaling down, or keeps the current number of instances unchanged for the application server instances in the system. Among them, the core transaction channel and the fast query channel serve as synchronous processing paths, which directly route real-time requests to idle application server instances for immediate processing. Write operations from the core transaction channel are handled using the primary database, and read operations from the fast query channel are handled using at least one secondary database.

8. The CFS warehouse management method as described in claim 7, characterized in that, The monitoring system uses resource load metrics, and based on the relationship between these metrics and preset thresholds, as well as CFS service metrics, dynamically scales up or down application server instances in the system, or maintains the current number of instances, including: The core coupling pressure score is determined based on the current number of operating vessels, the system's maximum supported vessel count, the current average request complexity, and the preset maximum complexity value; the predicted traffic pressure score is determined based on the system's peak throughput and the predicted future request volume; the backlog health pressure score is determined based on the current number of pending documents and the system's document processing threshold; and the comprehensive CFS business pressure index is determined based on the core coupling pressure score, the predicted traffic pressure score, and the backlog health pressure score. The basic number of instances is determined based on the comprehensive CFS business pressure index, the minimum number of instances preset by the system, and the maximum number of instances. The system pressure overload ratio is determined based on the system's real-time resource pressure index and the preset system target pressure threshold; the system's real-time pressure correction factor is determined based on the pressure overload ratio. The initial target number of instances is determined based on the base number of instances and the real-time pressure correction factor; the target number of instances for the next scaling cycle of the system is determined based on the initial target number of instances and the preset instance number limit. Based on the target number of instances for the next scaling cycle, perform corresponding horizontal scaling operations, horizontal scaling operations, or keep the current number of instances unchanged for the application server instances in the next scaling cycle of the system.

9. The CFS warehouse management method as described in claim 8, characterized in that, The determination of the comprehensive CFS business stress index includes: Step A11: Divide the current number of operating vessels in the system by the maximum number of vessels that the system can support to obtain a vessel load factor between 0 and 1; Step A12: Divide the average complexity weight of the current business request by the preset maximum complexity baseline to obtain an operation complexity strength value between 0 and 1. Step A13: Perform z-fold power operation on the ship load rate and y-fold power operation on the operation complexity intensity value; Step A14: Multiply the ship load rate calculation result after exponentiation with the operation complexity intensity value calculation result to obtain the core coupling pressure score; Step B11: Divide the predicted total number of business requests per unit time within the predicted future preset time period by the system peak throughput to obtain the predicted traffic load rate; Step B12: Multiply the predicted flow load rate by its corresponding weighting coefficient x to obtain the predicted flow pressure score; Step C11: Divide the number of pending work orders in the current system by the system's preset processing threshold to obtain the backlog rate. Step C12: Calculate the natural logarithm of the sum of 1 and the document backlog rate; Step C13: Multiply the logarithmic calculation result by its corresponding weighting coefficient δ to obtain the backlog health stress score; Step C14: Add the core coupling pressure score, the predicted flow pressure score, and the backlog health pressure score together. The result is the comprehensive CFS business pressure index.

Images