A server transaction elastic demand calculation method and application system
By acquiring customer agreement and server operation data, analyzing resource consumption trends and allocation, and generating elastic demand parameters, the problems of delayed or over-responsive resource allocation in existing technologies are solved, achieving accurate resource allocation and cost-effectiveness balance.
Patent Information
- Application Number
- CN202510846210.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-24
- Publication Date
- 2025-09-09
- Estimated Expiration
- 2045-06-24
AI Technical Summary
Existing server resource configuration methods rely on fixed capacity planning or simple periodic forecasts, resulting in delayed elastic scaling or over-response, which cannot meet customer needs.
By obtaining customer agreement and server operation data, analyzing resource consumption trends and allocation, determining customer business types and concurrent processing requirements, generating elastic demand parameters, and generating resource allocation recommendations based on these parameters, we avoid violating data protection regulations such as GDPR and ensure data compliance and a high signal-to-noise ratio.
It achieves precise triggering of capacity expansion, balances cost, stability and response speed, avoids the problems of high resource idle rate and capacity expansion delay, and improves the accuracy and efficiency of resource allocation.
Smart Images

Figure CN120353609B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of transaction management, and in particular to a method and application system for calculating elastic demand of server transactions. Background Art
[0002] When configuring server resources, since different businesses have significantly different resource demand patterns, targeted arrangements are required, otherwise customer needs cannot be met.
[0003] Existing methods typically allocate resources based on customer contracts or historical resource usage data. This approach relies on fixed capacity planning or simple periodic forecasts, which is likely to lead to elastic scaling lags or over-responses. Summary of the Invention
[0004] The present application provides a method and application system for calculating elastic demand of server transactions to solve the above problems.
[0005] In a first aspect, the present application provides a method for calculating elastic demand of server transactions, the method comprising:
[0006] Obtaining client agreement and server operation data; analyzing the server operation data to determine operation resource information;
[0007] Analyze the operating resource information to determine resource consumption trends and resource allocation;
[0008] Determine the customer's business type based on the customer agreement;
[0009] Determine concurrent processing requirements based on the customer's business type and resource allocation;
[0010] An elastic demand parameter is generated according to the resource consumption trend and the concurrent processing demand, and a resource configuration suggestion is generated according to the elastic demand parameter.
[0011] Through this solution, customer agreements and server operation data are obtained to avoid violations of data protection regulations such as GDPR. Server operation data is analyzed to determine operation resource information, providing compliant and high signal-to-noise ratio data input for resource trend analysis. Analyzing operation resource information to determine resource consumption trends and resource allocation situations helps eliminate the problem of insufficient ability to recognize complex demand patterns, while reducing the noise misjudgment rate. Based on customer agreements, the customer's business type is determined to avoid misclassification based on a single indicator and improve the accuracy of scenario matching. Based on the customer's business type and resource allocation situation, concurrent processing requirements are determined to avoid insufficient capacity due to expansion delays. Based on resource consumption trends and concurrent processing requirements, elastic demand parameters are generated, and based on the elastic demand parameters, resource configuration recommendations are generated, which helps to accurately trigger expansion and balance cost, stability and response speed.
[0012] Optionally, obtaining server operation data includes:
[0013] Parse the customer agreement to determine the authorization whitelist, desensitization requirements, and service scenario identifiers;
[0014] Determining the data types of the operational data that can be obtained based on the authorization whitelist;
[0015] According to the data type, the desensitization requirements and the service scenario identifier, the existing data is compliant, and the compliant data set is used as the server operation data.
[0016] Through this solution, we parse the customer agreement, determine the authorization whitelist, desensitization requirements and service scenario identifiers, avoid the risk of privacy leakage due to over-scope collection, eliminate the noise interference introduced by the direct exposure of sensitive fields in the original data, ensure that the business feature extraction rules strictly match the customer's actual business type, and eliminate the mismatch of expansion strategies caused by the decoupling of business features and resource requirements. Based on the authorization whitelist, we determine the data type of the available operation data to avoid feature loss or redundant data accumulation due to the ambiguity of the data collection scope. Based on the data type, desensitization requirements and service scenario identifiers, we conduct compliance processing on the existing data, and use the compliant data set as the server operation data, which helps to eliminate the periodic feature extraction deviation caused by the misalignment of the data collection sequence.
[0017] Optionally, determining the customer business type according to the customer agreement includes:
[0018] Based on the service scenario identifier, obtaining a scenario type code;
[0019] Analyze server operation data and determine the API call sequence during operation;
[0020] Determining business operation mode characteristics based on the API call sequence;
[0021] Matching the business operation mode characteristics with the scenario type code;
[0022] Determine the customer's business type based on the matching degree between the scenario type code and the business operation mode characteristics.
[0023] This solution uses service scenario identifiers to obtain scenario type codes, eliminating ambiguity in business type descriptions in protocol text and providing unified input for business feature matching. Analyzing server operation data and determining the API call sequence during operation helps quantify the true trajectory of business operations and capture overlooked high-frequency continuous call combinations. Determining business operation pattern characteristics based on API call sequences helps eliminate feature extraction distortion. Determining the customer's business type based on the degree of match between scenario type codes and business operation pattern characteristics helps achieve the goal of a multi-dimensional decision matrix.
[0024] Optionally, the compliance processing of existing data according to the data type, the desensitization requirement, and the service scenario identifier includes:
[0025] Determining a priority sorting rule for the authorization whitelist according to the service scenario identifier;
[0026] Analyze the desensitization requirements and determine the sensitive field mapping table;
[0027] Establishing a field replacement strategy according to the sensitive field mapping table;
[0028] Filter the existing data according to the data type to obtain available data;
[0029] The authorized fields of the available data are retained according to the priority sorting rules, and the field replacement strategy is applied to process the sensitive data in the available data to complete the compliance processing.
[0030] Through this solution, the priority sorting rules of the authorization whitelist are determined according to the service scenario identifier, which helps to eliminate the problem of feature extraction distortion. Analyzing the desensitization requirements and determining the sensitive field mapping table helps to eliminate the risks of privacy leakage and data noise interference. Based on the sensitive field mapping table, a field replacement strategy is established to achieve a balance between compliance processing and business feature retention. According to the data type, existing data is filtered to obtain available data, and the problems of data redundancy and compliance conflicts are resolved. The authorization fields of the available data are retained according to the priority sorting rules, and the field replacement strategy is applied to process the sensitive data in the available data to complete the compliance processing, achieving the dual goals of privacy protection and business analysis, eliminating the risk of privacy leakage, and improving data consistency through standardized processing.
[0031] Optionally, generating elastic demand parameters according to the resource consumption trend and the concurrent processing requirement includes:
[0032] Decomposing the resource consumption trend based on the timestamp to determine the resource consumption cycle;
[0033] Analyze the concurrent processing requirements and determine resource usage patterns;
[0034] An elastic demand parameter is generated according to the resource consumption cycle and the resource usage pattern.
[0035] This solution decomposes resource consumption trends based on timestamps, identifies resource consumption cycles, and eliminates baseline drift caused by time zone differences or inconsistent sampling intervals. This ensures global comparability of time series analysis and provides standardized input for elastic computing. It analyzes concurrent processing requirements and identifies resource usage patterns, avoiding the drawback of a lack of a dynamic association mechanism between business types and resource usage patterns. It also quantifies the contribution of different scenarios to elastic demand. Based on resource consumption cycles and patterns, elastic demand parameters are generated, helping to eliminate lags and improve forecasting accuracy.
[0036] Optionally, generating a resource configuration suggestion based on the elastic demand parameter includes:
[0037] Analyze the elastic demand parameters to determine the expansion trigger point and expansion mode;
[0038] Generate a resource configuration suggestion based on the expansion trigger point and the expansion mode.
[0039] This solution analyzes elastic demand parameters, determines expansion trigger points and expansion modes, and helps eliminate the problem of missing emergency event detection in extensive expansion trigger points, achieves the goal of business-resource coupling analysis, and avoids misjudgment of business characteristics. Based on the expansion trigger points and expansion modes, resource allocation suggestions are generated.
[0040] Optionally, analyzing the elastic demand parameter to determine the capacity expansion mode includes:
[0041] Based on the customer agreement, obtaining SLA breach cost data; parsing the SLA breach cost data to quantify service interruption tolerance;
[0042] Acquiring real-time resource information; analyzing the real-time resource information to determine availability indicators;
[0043] Analyze the availability index and calculate the resource supply elasticity coefficient;
[0044] Analyze historical bill payment cycles to determine cost sensitivity;
[0045] A capacity expansion mode is determined according to the service interruption tolerance, the resource supply elasticity coefficient, and the cost sensitivity.
[0046] This solution, based on customer agreements, obtains SLA breach cost data, helping to eliminate the lack of decision-making basis caused by ignoring the quantification of SLA breach costs. It analyzes SLA breach cost data, quantifies service interruption tolerance, and eliminates policy swings caused by ambiguous weights of multiple clauses. It obtains real-time resource information to overcome blind spots in expansion decisions caused by the lack of resource supply elasticity coefficients. It analyzes real-time resource information and determines availability indicators, helping to eliminate decision delays caused by unstructured resource status assessments. It analyzes availability indicators, calculates resource supply elasticity coefficients, and compresses multi-dimensional resource status into a single decision parameter, eliminating policy conflicts caused by isolated analysis of multi-dimensional indicators. It analyzes historical bill payment cycles and determines cost sensitivity, helping to overcome inefficient resource reuse strategies. Determining expansion models based on service interruption tolerance, resource supply elasticity coefficients, and cost sensitivity helps achieve the design goals of the multi-dimensional decision matrix.
[0047] Optionally, generating a resource configuration suggestion according to the expansion trigger point and the expansion mode includes:
[0048] Obtain historical capacity expansion records, analyze the historical capacity expansion records based on the capacity expansion trigger point, and determine the capacity expansion response delay time;
[0049] Analyzing the resource consumption trend and determining a countdown to resource exhaustion;
[0050] generating a preventive capacity expansion time window according to a time difference between the capacity expansion response delay time and the resource exhaustion countdown;
[0051] A resource configuration suggestion including a time window identifier is generated according to the preventive capacity expansion time window and the capacity expansion mode.
[0052] Through this solution, historical expansion records are obtained and analyzed based on the expansion trigger points to determine the expansion response delay time, covering delay fluctuations in extreme scenarios and ensuring the robustness of the time window calculation. Resource consumption trends are analyzed to determine the countdown to resource exhaustion, avoiding one-sided decisions caused by a single indicator. Based on the time difference between the expansion response delay time and the resource exhaustion countdown, a preventive expansion time window is generated, which helps to eliminate the problem of emergency expansion cost surges caused by the failure to reserve delay time. Based on the preventive expansion time window and the expansion mode, a resource configuration recommendation containing the time window identifier is generated to ensure the global consistency of the time window strategy with cost sensitivity and service stability requirements.
[0053] Optionally, generating elastic demand parameters according to the resource consumption cycle and the resource usage pattern includes:
[0054] Analyzing the server operation data based on the resource usage pattern to determine a mode switching inducement;
[0055] Analyzing the mode switching inducement and determining the inducement attribute;
[0056] Analyzing the resource consumption cycle according to the inducement attributes to determine the influence weight of each mode switching inducement on the resource usage mode;
[0057] An elastic demand parameter is generated according to the impact weight.
[0058] This solution analyzes server operating data based on resource usage patterns, identifies mode switching triggers, and eliminates prediction distortions caused by a failure to distinguish between business operation characteristics and noise events. Analyzing mode switching triggers and determining their attributes helps eliminate the problem of missing emergency event detection windows due to failure to analyze residual items, thereby improving the accuracy of predictions for expansion trigger points. Based on the attributes of the triggers, the resource consumption cycle is analyzed to determine the weight of each mode switching trigger's impact on resource usage patterns, avoiding resource allocation imbalances caused by single-dimensional decisions. Based on the impact weights, elastic demand parameters are generated, which helps support the generation of a multi-dimensional decision matrix and achieve a balance between cost, stability, and response speed.
[0059] In a second aspect, the present application provides an application system for calculating elastic demand for server transactions, the system comprising:
[0060] A data analysis module is used to obtain client agreement and server operation data; analyze the server operation data and determine operation resource information;
[0061] An information analysis module is used to analyze the operating resource information and determine resource consumption trends and resource allocation conditions;
[0062] A type determination module, configured to determine a customer service type based on the customer agreement;
[0063] A demand determination module, configured to determine concurrent processing requirements based on the customer service type and the resource allocation situation;
[0064] The suggestion generation module is used to generate elastic demand parameters according to the resource consumption trend and the concurrent processing demand, and generate resource configuration suggestions according to the elastic demand parameters.
[0065] Optionally, the elastic demand calculation application system for server transactions also includes a data determination module, which is used to: parse the customer agreement, determine the authorization whitelist, desensitization requirements and service scenario identifier; determine the data type of the available operating data based on the authorization whitelist; perform compliance processing on the existing data based on the data type, the desensitization requirements and the service scenario identifier, and use the data set after compliance processing as the server operating data.
[0066] Optionally, when the type determination module determines the customer business type according to the customer agreement, it is used to: obtain the scenario type code based on the service scenario identifier; analyze the server operation data to determine the API call sequence during the operation process; determine the business operation mode characteristics based on the API call sequence; match the business operation mode characteristics with the scenario type code; and determine the customer business type based on the matching degree between the scenario type code and the business operation mode characteristics.
[0067] Optionally, when the data determination module performs compliance processing on existing data based on the data type, the desensitizing requirements and the service scenario identifier, it is used to: determine the priority sorting rules of the authorization whitelist based on the service scenario identifier; analyze the desensitizing requirements and determine the sensitive field mapping table; establish a field replacement strategy based on the sensitive field mapping table; filter the existing data according to the data type to obtain available data; retain the authorized fields of the available data according to the priority sorting rules, and apply the field replacement strategy to process the sensitive data in the available data to complete the compliance processing.
[0068] Optionally, when the suggestion generation module generates elastic demand parameters based on the resource consumption trend and the concurrent processing requirements, it is used to: decompose the resource consumption trend based on the timestamp to determine the resource consumption cycle; analyze the concurrent processing requirements to determine the resource usage pattern; and generate elastic demand parameters based on the resource consumption cycle and the resource usage pattern.
[0069] Optionally, when the suggestion generation module generates a resource configuration suggestion based on the elastic demand parameter, it is used to: analyze the elastic demand parameter to determine the expansion trigger point and the expansion mode; and generate the resource configuration suggestion based on the expansion trigger point and the expansion mode.
[0070] Optionally, the elastic demand calculation application system for server transactions also includes a pattern determination module, which is used to: obtain SLA breach cost data based on the customer agreement; parse the SLA breach cost data to quantify service interruption tolerance; obtain real-time resource information; analyze the real-time resource information to determine availability indicators; analyze the availability indicators to calculate the resource supply elasticity coefficient; parse historical bill payment cycles to determine cost sensitivity; and determine an expansion pattern based on the service interruption tolerance, the resource supply elasticity coefficient and the cost sensitivity.
[0071] Optionally, when the suggestion generation module generates resource configuration suggestions based on the expansion trigger point and the expansion mode, it is used to: obtain historical expansion records, analyze the historical expansion records based on the expansion trigger point, and determine the expansion response delay time; analyze the resource consumption trend to determine the resource exhaustion countdown; generate a preventive expansion time window based on the time difference between the expansion response delay time and the resource exhaustion countdown; and generate a resource configuration suggestion including a time window identifier based on the preventive expansion time window and the expansion mode.
[0072] Optionally, when the suggestion generation module generates elastic demand parameters based on the resource consumption cycle and the resource usage pattern, it is used to: analyze the server operation data based on the resource usage pattern to determine the mode switching incentive; analyze the mode switching incentive to determine the incentive attributes; analyze the resource consumption cycle based on the incentive attributes to determine the impact weight of each mode switching incentive on the resource usage pattern; and generate elastic demand parameters based on the impact weight. BRIEF DESCRIPTION OF THE DRAWINGS
[0073] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.
[0074] Figure 1 A schematic diagram of an application scenario provided in one embodiment of the present application;
[0075] Figure 2 A flowchart of a method for calculating elastic demand for server transactions provided in one embodiment of the present application;
[0076] Figure 3 A schematic diagram of the structure of an application system for calculating elastic demand for server transactions provided in one embodiment of the present application. DETAILED DESCRIPTION
[0077] To make the purpose, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0078] In this document, the term "and / or" simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document, unless otherwise specified, generally indicates an "or" relationship between the related objects.
[0079] The embodiments of the present application are described in further detail below with reference to the accompanying drawings.
[0080] Existing methods typically allocate resources based on customer contracts or historical resource usage data. This approach relies on fixed capacity planning or simple periodic forecasts, which can lead to high resource idleness, delayed elastic scaling, and over-responsiveness. For example, financial trading systems maintain high-specification server clusters even on non-trading days, resulting in wasted energy and costs.
[0081] Based on this, the present application provides a method and application system for calculating elastic demand for server transactions, which obtains customer agreements and server operation data to avoid violations of data protection regulations such as GDPR. Analyze server operation data, determine operation resource information, and provide compliant and high signal-to-noise ratio data input for resource trend analysis. Analyze operation resource information, determine resource consumption trends and resource allocation situations, which helps to eliminate the problem of insufficient ability to recognize complex demand patterns, while reducing the noise misjudgment rate. According to the customer agreement, determine the customer's business type, avoid misclassification based on a single indicator, and improve the accuracy of scene matching. According to the customer's business type and resource allocation situation, determine the concurrent processing requirements to avoid insufficient capacity due to expansion delays. Generate elastic demand parameters based on resource consumption trends and concurrent processing requirements, and generate resource configuration recommendations based on the elastic demand parameters, which helps to accurately trigger expansion and balance cost, stability and response speed.
[0082] Figure 1 This is a schematic diagram of an application scenario provided by this application. When configuring server resources, the method provided by this application is applied.
[0083] Specifically, the method provided in this application is applied to any server, and the server interacts with the client device, obtains and analyzes the server operation data through the client device, and determines the operation resource information. Analyze the operation resource information, determine the resource consumption trend and resource allocation situation, retrieve the customer agreement from the internal database, and determine the customer business type based on the customer agreement to avoid misclassification based on a single indicator and improve the accuracy of scene matching. Determine the concurrent processing requirements based on the customer business type and resource allocation situation to avoid insufficient capacity due to expansion delays. Generate elastic demand parameters based on resource consumption trends and concurrent processing requirements, and generate resource configuration suggestions based on the elastic demand parameters, which helps to accurately trigger expansion and balance cost, stability and response speed. For specific implementation methods, please refer to the following embodiments.
[0084] Figure 2 This is a flow chart of a method for calculating elastic demand of server transactions provided in one embodiment of the present application. The method of this embodiment can be applied to the servers in the above scenarios. Figure 2 As shown, the method includes:
[0085] S201, obtaining client agreement and server operation data; analyzing server operation data and determining operation resource information;
[0086] A customer agreement can be a contractual document signed between a customer and a cloud service provider.
[0087] Server operation data can be the original logs and monitoring indicators generated during the server operation.
[0088] The operating resource information may be structured data of resource usage status.
[0089] Specifically, the cloud platform API automatically pulls the customer agreement signed by the customer when subscribing to the service, which is stored on the internal server. Simultaneously, the server operation data of the user's device is captured in real time. The scenario type identifier in the customer agreement is parsed to extract the sensitive field mapping table. Then, based on the server operation data, dynamic desensitization is performed according to the authorization whitelist priority rules to determine the operation resource information. First, the fields marked as personally identifiable information in the sensitive field mapping table are encrypted and hashed. Second, the original values of the business feature fields authorized by the whitelist are retained. Finally, compliant operation resource information is generated, including desensitized structured data and metadata tags.
[0090] S202, analyzing operational resource information to determine resource consumption trends and resource allocation;
[0091] The resource consumption trend may be a specific representation of the usage pattern in which the resource is consumed during use.
[0092] The resource allocation status may be a description of the topological state of the current resource pool.
[0093] Specifically, the STL algorithm is used for the operating resource information, and the trend term, cycle term, and residual term are separated through the iterative weighted least squares method; the moving standard deviation curve is calculated for the residual term, and the abnormal interval is marked as a candidate interval for burst traffic; then, the business event feature code defined in the customer agreement is extracted to generate a business event density curve; the business event density curve is dynamically time-warped and aligned with the residual term of resource consumption, and the Pearson correlation coefficient is calculated; thus, the resource consumption trend and resource allocation situation are output.
[0094] S203. Determine the customer's business type based on the customer agreement;
[0095] The customer business type can be a classification label determined based on the business scenario identifier in the customer agreement and the API call characteristics in the server log.
[0096] Specifically, identifier keywords are extracted based on the regular expressions predefined in the agreement template according to the customer agreement; then, synonym conversion is performed on non-standardized expressions; thereby, business scenario identifiers with confidence scores are extracted; then, the sliding window size is set to the SLA indicator collection period defined in the customer agreement, and the call frequency and resource consumption ratio of each API endpoint in the window are counted to generate an operation type heat map; the operation type heat map is normalized to construct API call features with dimensions defined by the agreement; subsequently, a feature fusion matrix is constructed, and when the match between the business scenario identifier and the API call feature is too high, the customer business type is determined.
[0097] S204. Determine concurrent processing requirements based on the customer's business type and resource allocation.
[0098] The concurrent processing requirement can be a target resource specification calculated based on the business type and resource allocation situation.
[0099] Specifically, based on resource allocation, sequence pattern mining is performed on the anonymized API logs to identify high-frequency operation chains. Then, a business type-model mapping rule library is established based on the identifier of the customer's business type. Finally, the impact value of the emergency characteristics is integrated based on the linear superposition model to generate the final concurrent processing demand parameters.
[0100] S205: Generate elastic demand parameters based on resource consumption trends and concurrent processing requirements, and generate resource allocation suggestions based on the elastic demand parameters.
[0101] The elastic demand parameter can be a multi-dimensional quantitative indicator used to generate a capacity expansion strategy.
[0102] Resource allocation suggestions can be expansion decision instructions.
[0103] Specifically, the burst traffic risk level is calculated based on the residual moving standard deviation in the resource consumption trend and the concurrent processing demand. Then, the elastic demand parameter is generated in combination with the SLA breach cost in the customer business type. Subsequently, based on the elastic calculation theory in the dynamic resource scheduling model, the moving standard deviation in time series analysis is used to monitor resource consumption fluctuations, and the resource supply capacity report is generated in combination with the resource reservation strategy in the capacity planning algorithm. Furthermore, a capacity expansion decision matrix is constructed based on the elastic demand parameters, resource supply capacity report, and customer business type. Finally, resource allocation recommendations are output based on the matrix weights.
[0104] Through this solution, customer agreements and server operation data are obtained to avoid violations of data protection regulations such as GDPR. Server operation data is analyzed to determine operation resource information, providing compliant and high signal-to-noise ratio data input for resource trend analysis. Analyzing operation resource information to determine resource consumption trends and resource allocation situations helps eliminate the problem of insufficient ability to recognize complex demand patterns, while reducing the noise misjudgment rate. Based on customer agreements, the customer's business type is determined to avoid misclassification based on a single indicator and improve the accuracy of scenario matching. Based on the customer's business type and resource allocation situation, concurrent processing requirements are determined to avoid insufficient capacity due to expansion delays. Based on resource consumption trends and concurrent processing requirements, elastic demand parameters are generated, and based on the elastic demand parameters, resource configuration recommendations are generated, which helps to accurately trigger expansion and balance cost, stability and response speed.
[0105] In some embodiments, the customer agreement is parsed to determine the authorization whitelist, desensitization requirements, and service scenario identifiers; based on the authorization whitelist, the data type of the available operating data is determined; based on the data type, desensitization requirements, and service scenario identifiers, the existing data is compliant, and the compliant data set is used as the server operating data.
[0106] An authorization whitelist can be a list of server operational data fields that are permitted for collection. Desensitization requirements can be prescribed data privacy protection rules. A service scenario identifier can be a unique code that identifies a customer's business type. Accessible operational data can be a subset of raw server log data filtered according to the authorization whitelist. A data type can be a specific data field category. Existing data can be a collection of unprocessed, initial data from raw server logs. A data set can be a structured data set.
[0107] Specifically, based on the customer agreement, a regular expression is used to match the authorization field marker in the predefined clause template defined by the mapping relationship between the customer's business scenario and the compliance clause, and the authorization whitelist, desensitization requirements and service scenario identifier are extracted according to the authorization field marker. Then, the authorization whitelist is fully compared with the field name of the original server log to filter out the data types that are allowed to be collected in the available operation data. Then, based on the data type, the predefined desensitization rule mapping table is loaded according to the service scenario identifier; then, according to the desensitization requirements, the desensitization operation is performed field by field; then, the desensitized data is checked to see if it retains the business feature field corresponding to the service scenario identifier; finally, the desensitized data is bound to the service scenario identifier to generate server operation data.
[0108] Through this solution, we parse the customer agreement, determine the authorization whitelist, desensitization requirements and service scenario identifiers, avoid the risk of privacy leakage due to over-scope collection, eliminate the noise interference introduced by the direct exposure of sensitive fields in the original data, ensure that the business feature extraction rules strictly match the customer's actual business type, and eliminate the mismatch of expansion strategies caused by the decoupling of business features and resource requirements. Based on the authorization whitelist, we determine the data type of the available operation data to avoid feature loss or redundant data accumulation due to the ambiguity of the data collection scope. Based on the data type, desensitization requirements and service scenario identifiers, we conduct compliance processing on the existing data, and use the compliant data set as the server operation data, which helps to eliminate the periodic feature extraction deviation caused by the misalignment of the data collection sequence.
[0109] In some embodiments, based on the service scenario identifier, a scenario type code is obtained; the server operation data is analyzed to determine the API call sequence during the operation process; based on the API call sequence, the business operation mode characteristics are determined; the business operation mode characteristics are matched with the scenario type code; and based on the matching degree between the scenario type code and the business operation mode characteristics, the customer business type is determined.
[0110] A scenario type code can be a predefined standardized business scenario label. An API call sequence can be a collection of API endpoint call records. Business operation pattern characteristics can be a quantitative feature vector that characterizes the resource demand pattern of a specific business scenario. The matching degree can represent the degree of similarity between the actual business operation pattern characteristics and the standard characteristics corresponding to the scenario type code.
[0111] Specifically, a preset scenario type coding table is constructed based on the abstract classification of common operating modes of business scenarios according to domain ontology, and the service scenario identifier is converted into the corresponding scenario type code. The original log is extracted from the server operation data and sorted by timestamp to generate an API call sequence. A feature vector is generated based on the business feature template associated with the scenario type code; then, the feature matching degree of the API call sequence is calculated to extract the business operation mode features. The cosine similarity algorithm is used to compare the business operation mode feature vector with the standard feature vector corresponding to the scenario type code. Finally, the matching degree weight between the scenario type code and the business operation mode feature is calculated, and a hierarchical decision is made to determine the customer's business type.
[0112] This solution uses service scenario identifiers to obtain scenario type codes, eliminating ambiguity in business type descriptions in protocol text and providing unified input for business feature matching. Analyzing server operation data and determining the API call sequence during operation helps quantify the true trajectory of business operations and capture overlooked high-frequency continuous call combinations. Determining business operation pattern characteristics based on API call sequences helps eliminate feature extraction distortion. Determining the customer's business type based on the degree of match between scenario type codes and business operation pattern characteristics helps achieve the goal of a multi-dimensional decision matrix.
[0113] In some embodiments, based on the service scenario identifier, the priority sorting rules of the authorization whitelist are determined; the desensitization requirements are analyzed to determine the sensitive field mapping table; based on the sensitive field mapping table, a field replacement strategy is established; based on the data type, the existing data is filtered to obtain the available data; the authorization fields of the available data are retained according to the priority sorting rules, and the field replacement strategy is applied to process the sensitive data in the available data to complete the compliance processing.
[0114] Prioritization rules can be a priority list of fields to be retained. A sensitive field mapping table can be a mapping relationship table established based on masking requirements. A field replacement policy can be a specific data processing rule generated based on the sensitive field mapping table. Available data can be compliance candidate data. Authorized fields can be raw data fields. Sensitive data can be fields containing personal privacy, commercial secrets, or data subject to regulatory restrictions.
[0115] Specifically, based on the service scenario identifier, load the predefined scenario-authorization whitelist association table to determine the priority sorting rules for the authorization fields in the current scenario. Then, parse the desensitization requirements in the customer agreement, and build a sensitive field mapping table in combination with industry data compliance standards. Furthermore, based on the sensitive field mapping table, establish field replacement strategies for different data types. Based on the data type, classify and process according to the data storage format to determine the available data: first, extract the target fields according to the authorization whitelist, and hard filter the unauthorized columns; then, scan the text based on the regular expression engine, identify sensitive field patterns, and mark the available data. Finally, retain the authorized fields of the available data according to the priority sorting rules, standardize the format of the retained fields, and apply the field replacement strategy to remove sensitive data; generate an anonymized data set with a version identifier.
[0116] Through this solution, the priority sorting rules of the authorization whitelist are determined according to the service scenario identifier, which helps to eliminate the problem of feature extraction distortion. Analyzing the desensitization requirements and determining the sensitive field mapping table helps to eliminate the risks of privacy leakage and data noise interference. Based on the sensitive field mapping table, a field replacement strategy is established to achieve a balance between compliance processing and business feature retention. According to the data type, existing data is filtered to obtain available data, and the problems of data redundancy and compliance conflicts are resolved. The authorization fields of the available data are retained according to the priority sorting rules, and the field replacement strategy is applied to process the sensitive data in the available data to complete the compliance processing, achieving the dual goals of privacy protection and business analysis, eliminating the risk of privacy leakage, and improving data consistency through standardized processing.
[0117] In some embodiments, based on timestamps, resource consumption trends are decomposed to determine resource consumption cycles; concurrent processing requirements are analyzed to determine resource usage patterns; and elastic demand parameters are generated based on resource consumption cycles and resource usage patterns.
[0118] The resource consumption cycle can be a regular fluctuation feature extracted from the resource consumption trend.
[0119] The resource usage pattern may be a correspondence between business operation characteristics and resource consumption.
[0120] Specifically, resource consumption data is aligned based on a unified timestamp to eliminate time zone differences and sampling interval deviations. The STL decomposition algorithm is then applied to separate the periodic term, trend term, and residual term. The frequency component with the highest energy in the periodic term is detected through Fourier transform and marked as a resource consumption period. The number of concurrent requests, request type distribution, and per-request resource occupancy weight are extracted from the available data. A predefined resource usage pattern template is then loaded based on the service scenario identifier to generate a resource usage pattern. Furthermore, cycle-driven parameters are generated based on the length and amplitude of the resource consumption cycle. Concurrency pattern parameters are then generated based on the resource usage pattern. The cycle-driven parameters and concurrency pattern parameters are then fused according to the scenario weights to generate elastic demand parameters.
[0121] This solution decomposes resource consumption trends based on timestamps, identifies resource consumption cycles, and eliminates baseline drift caused by time zone differences or inconsistent sampling intervals. This ensures global comparability of time series analysis and provides standardized input for elastic computing. It analyzes concurrent processing requirements and identifies resource usage patterns, avoiding the drawback of a lack of a dynamic association mechanism between business types and resource usage patterns. It also quantifies the contribution of different scenarios to elastic demand. Based on resource consumption cycles and patterns, elastic demand parameters are generated, helping to eliminate lags and improve forecasting accuracy.
[0122] In some embodiments, elastic demand parameters are analyzed to determine expansion trigger points and expansion modes; and resource allocation recommendations are generated based on the expansion trigger points and expansion modes.
[0123] The expansion trigger point can be the time point when resource expansion is executed. The expansion mode can be the resource expansion strategy.
[0124] Specifically, the dynamic trigger baseline and preventive trigger time are calculated based on the cycle-driven parameters and concurrent mode parameters in the elastic demand parameters. Then, the trigger baseline is dynamically revised based on the standard deviation of the residual term of the resource consumption trend and the resource pool elasticity coefficient. Subsequently, the SLA breach cost data is analyzed and the breach cost is converted into an expansion urgency weight. Finally, the expansion trigger point is generated by combining the dynamic trigger baseline and the expansion urgency weight.
[0125] Based on the resource usage pattern type and cost sensitivity level in the elasticity demand parameters, predefined decision rules are loaded and matched to the pattern selection rules. The instance startup delay and network bandwidth margin constrained by the elasticity coefficient are then verified. Cost sensitivity is then calculated based on the customer's historical payment cycles and SLA breach cost data. Finally, a scaling pattern is generated by combining the pattern selection rule results, cost sensitivity weights, and elasticity coefficient constraint corrections. The scaling trigger point is broken down into timestamps, trigger conditions, and scenario codes. Based on the scaling pattern, horizontal and vertical scaling parameter sets are injected into the configuration recommendations. Furthermore, the timestamps, trigger conditions, scenario codes, and scaling parameter sets are combined into a structured JSON object. Data desensitization rules are then automatically appended based on the scenario code. Two-factor authentication tags are added to sensitive operations to generate resource configuration recommendations.
[0126] This solution analyzes elastic demand parameters, determines expansion trigger points and expansion modes, and helps eliminate the problem of missing emergency event detection in extensive expansion trigger points, achieves the goal of business-resource coupling analysis, and avoids misjudgment of business characteristics. Based on the expansion trigger points and expansion modes, resource allocation suggestions are generated.
[0127] In some embodiments, based on the customer agreement, SLA breach cost data is obtained; the SLA breach cost data is parsed to quantify service interruption tolerance; real-time resource information is obtained; the real-time resource information is analyzed to determine availability indicators; the availability indicators are analyzed to calculate the resource supply elasticity coefficient; historical bill payment cycles are parsed to determine cost sensitivity; and the expansion mode is determined based on the service interruption tolerance, resource supply elasticity coefficient and cost sensitivity.
[0128] SLA breach cost data can be data on compensation clauses arising from service interruptions, as specified in the customer agreement. Service interruption tolerance can be an indicator used to characterize a customer's tolerance for service interruption risks. Real-time resource information can be real-time resource pool status data. Availability metrics can be quantitative indicators generated by analyzing real-time resource information. Resource supply elasticity coefficients can be dynamic values reflecting the current expansion capacity of a resource pool. Historical bill payment cycles can be payment pattern characteristics reflected in a customer's historical payment records. Cost sensitivity can be a customer's sensitivity to the cost of resource redundancy.
[0129] Specifically, SLA breach cost data is extracted from customer agreements. Based on this SLA breach cost data, the compensation weighting factor is calculated according to the ratio of the maximum compensation amount for a single service interruption to the total contract amount. Then, the time sensitivity level is determined by grading according to the maximum allowable interruption duration. Subsequently, the service interruption tolerance is generated based on the compensation weighting factor and the time sensitivity level. Real-time resource information is obtained through the cloud platform API. The real-time resource information is then normalized to determine the availability index. Based on the availability index, the resource supply elasticity coefficient is generated using the elasticity coefficient calculation formula. The payment cycle type, historical payment on-time rate, and resource release delay tolerance are extracted from the billing database. Then, the cost sensitivity is determined based on the payment model. Based on the service interruption tolerance, resource supply elasticity coefficient, and cost sensitivity, the expansion model is generated according to the decision matrix results.
[0130] This solution, based on customer agreements, obtains SLA breach cost data, helping to eliminate the lack of decision-making basis caused by ignoring the quantification of SLA breach costs. It analyzes SLA breach cost data, quantifies service interruption tolerance, and eliminates policy swings caused by ambiguous weights of multiple clauses. It obtains real-time resource information to overcome blind spots in expansion decisions caused by the lack of resource supply elasticity coefficients. It analyzes real-time resource information and determines availability indicators, helping to eliminate decision delays caused by unstructured resource status assessments. It analyzes availability indicators, calculates resource supply elasticity coefficients, and compresses multi-dimensional resource status into a single decision parameter, eliminating policy conflicts caused by isolated analysis of multi-dimensional indicators. It analyzes historical bill payment cycles and determines cost sensitivity, helping to overcome inefficient resource reuse strategies. Determining expansion models based on service interruption tolerance, resource supply elasticity coefficients, and cost sensitivity helps achieve the design goals of the multi-dimensional decision matrix.
[0131] In some embodiments, historical expansion records are obtained, and based on the expansion trigger point, the historical expansion records are analyzed to determine the expansion response delay time; the resource consumption trend is analyzed to determine the resource exhaustion countdown; based on the time difference between the expansion response delay time and the resource exhaustion countdown, a preventive expansion time window is generated; based on the preventive expansion time window and the expansion mode, a resource configuration suggestion including a time window identifier is generated.
[0132] The historical capacity expansion record may be a structured data set stored in the capacity expansion operation log database, recording the expansion trigger time, expansion effective time, and expansion mode of each capacity expansion operation.
[0133] The expansion response delay time may be a statistic of the time difference between triggering the expansion operation and the time when the new resource instance actually takes effect.
[0134] The resource exhaustion countdown can be a prediction of the remaining time required for a resource pool to be completely exhausted.
[0135] The time difference may be the difference between the resource exhaustion countdown and the capacity expansion response delay time.
[0136] The preventive capacity expansion time window may be a capacity expansion execution time period generated based on the time difference.
[0137] The time window identifier may be a metadata tag attached to the resource configuration suggestion.
[0138] Specifically, the expansion trigger time, expansion effective time, and expansion mode of historical expansion records are extracted from the expansion operation log database. Then, for the historical records of the same expansion mode, the difference between the expansion effective time and the expansion trigger time is calculated to determine the expansion response delay time. Based on the resource consumption trend monitored in real time, a linear regression model is used, with the time series as the independent variable and the resource consumption as the dependent variable. The linear equation is fitted using the least squares method, and the slope is calculated as the resource consumption rate. Then, the countdown to resource exhaustion is predicted based on the current remaining resources. The time difference is calculated based on the expansion response delay time and the resource exhaustion countdown to generate a preventive expansion time window. Based on the expansion mode and the preventive expansion time window, an operation instruction is selected from the preset policy library. Then, the time window metadata is attached to the resource configuration suggestion to generate a resource configuration suggestion containing the time window identifier.
[0139] Through this solution, historical expansion records are obtained and analyzed based on the expansion trigger points to determine the expansion response delay time, covering delay fluctuations in extreme scenarios and ensuring the robustness of the time window calculation. Resource consumption trends are analyzed to determine the countdown to resource exhaustion, avoiding one-sided decisions caused by a single indicator. Based on the time difference between the expansion response delay time and the resource exhaustion countdown, a preventive expansion time window is generated, which helps to eliminate the problem of emergency expansion cost surges caused by the failure to reserve delay time. Based on the preventive expansion time window and the expansion mode, a resource configuration recommendation containing the time window identifier is generated to ensure the global consistency of the time window strategy with cost sensitivity and service stability requirements.
[0140] In some embodiments, based on the resource usage pattern, the server operation data is analyzed to determine the mode switching incentive; the mode switching incentive is analyzed to determine the incentive attributes; based on the incentive attributes, the resource consumption cycle is analyzed to determine the impact weight of each mode switching incentive on the resource usage pattern; based on the impact weight, the elastic demand parameter is generated.
[0141] The mode switching inducement may be an event that associates business operation characteristics with resource consumption characteristics.
[0142] The inducement attribute may be an attribute category divided according to the persistence and predictability of the impact of the mode switching inducement on resource consumption.
[0143] The impact weight may be a normalized value that quantifies the degree of impact of a single mode switching inducement on the resource usage pattern.
[0144] Specifically, extract the API call sequence that is strongly associated with the business scenario from the server operation data; then, based on the scenario type coding table, map the original operation log to a standardized business event identifier; then, collect the resource consumption time series data in real time; then, use the moving average method to eliminate short-term noise and identify the sudden increase or decrease inflection points synchronized with the business events; thereby determining the mode switching inducement. Based on the mode switching inducement, the original data associated with the inducement is dynamically desensitized according to the sensitive field mapping table; thereby determining the inducement attributes. Calculate the standard deviation change rate of the residual term when each mode switching inducement occurs; then, use the variance contribution analysis method to calculate the explanatory power ratio of each mode switching inducement in the resource consumption cycle; thereby determining the influence weight of each mode switching inducement on the resource usage pattern. Furthermore, the expansion urgency coefficient is calculated based on the product of the incentive weight and the resource exhaustion countdown. Then, the preset template is matched according to the incentive type to determine the resource demand increment. If the incentive attribute is external suddenness, a safety redundancy is added to the elasticity parameter. At the same time, if the periodic item associated with the incentive has a downward trend, the resource demand increment is reduced according to the trend slope, thereby generating the final elasticity demand parameter.
[0145] This solution analyzes server operating data based on resource usage patterns, identifies mode switching triggers, and eliminates prediction distortions caused by a failure to distinguish between business operation characteristics and noise events. Analyzing mode switching triggers and determining their attributes helps eliminate the problem of missing emergency event detection windows due to failure to analyze residual items, thereby improving the accuracy of predictions for expansion trigger points. Based on the attributes of the triggers, the resource consumption cycle is analyzed to determine the weight of each mode switching trigger's impact on resource usage patterns, avoiding resource allocation imbalances caused by single-dimensional decisions. Based on the impact weights, elastic demand parameters are generated, which helps support the generation of a multi-dimensional decision matrix and achieve a balance between cost, stability, and response speed.
[0146] Figure 3 A schematic diagram of a server transaction elastic demand calculation application system provided in an embodiment of the present application is shown in FIG. Figure 3 As shown, the server transaction elastic demand calculation application system 300 of this embodiment includes: a data analysis module 301 , an information analysis module 302 , a type determination module 303 , a demand determination module 304 , and a suggestion generation module 305 .
[0147] The data analysis module 301 is used to obtain client agreement and server operation data; analyze the server operation data to determine operation resource information;
[0148] An information analysis module 302 is used to analyze the operating resource information to determine resource consumption trends and resource allocation;
[0149] A type determination module 303 is configured to determine a customer service type based on the customer agreement;
[0150] A demand determination module 304 is configured to determine concurrent processing requirements based on the customer service type and the resource allocation situation;
[0151] The suggestion generating module 305 is configured to generate elastic demand parameters according to the resource consumption trend and the concurrent processing requirement, and generate resource configuration suggestions according to the elastic demand parameters.
[0152] Optionally, the elastic demand calculation application system for server transactions also includes a data determination module 306, which is used to: parse the customer agreement, determine the authorization whitelist, desensitization requirements and service scenario identifier; determine the data type of the available operating data based on the authorization whitelist; perform compliance processing on the existing data based on the data type, the desensitization requirements and the service scenario identifier, and use the data set after compliance processing as the server operating data.
[0153] Optionally, when the type determination module 303 determines the customer business type according to the customer agreement, it is used to: obtain the scenario type code based on the service scenario identifier; analyze the server operation data to determine the API call sequence during the operation process; determine the business operation mode characteristics according to the API call sequence; match the business operation mode characteristics with the scenario type code; and determine the customer business type based on the matching degree between the scenario type code and the business operation mode characteristics.
[0154] Optionally, when the data determination module 306 performs compliance processing on existing data according to the data type, the desensitization requirements and the service scenario identifier, it is used to: determine the priority sorting rules of the authorization whitelist according to the service scenario identifier; analyze the desensitization requirements and determine the sensitive field mapping table; establish a field replacement strategy according to the sensitive field mapping table; filter the existing data according to the data type to obtain available data; retain the authorized fields of the available data according to the priority sorting rules, and apply the field replacement strategy to process the sensitive data in the available data to complete the compliance processing.
[0155] Optionally, when the suggestion generation module 305 generates elastic demand parameters based on the resource consumption trend and the concurrent processing requirements, it is used to: decompose the resource consumption trend based on the timestamp to determine the resource consumption cycle; analyze the concurrent processing requirements to determine the resource usage pattern; and generate elastic demand parameters based on the resource consumption cycle and the resource usage pattern.
[0156] Optionally, when generating resource configuration suggestions based on the elastic demand parameters, the suggestion generation module 305 is used to: analyze the elastic demand parameters to determine expansion trigger points and expansion modes; and generate resource configuration suggestions based on the expansion trigger points and the expansion modes.
[0157] Optionally, the elastic demand calculation application system for server transactions also includes a pattern determination module 307, which is used to: obtain SLA breach cost data based on the customer agreement; parse the SLA breach cost data to quantify service interruption tolerance; obtain real-time resource information; analyze the real-time resource information to determine availability indicators; analyze the availability indicators to calculate the resource supply elasticity coefficient; parse historical bill payment cycles to determine cost sensitivity; and determine an expansion pattern based on the service interruption tolerance, the resource supply elasticity coefficient, and the cost sensitivity.
[0158] Optionally, when the suggestion generation module 305 generates a resource configuration suggestion based on the expansion trigger point and the expansion mode, it is used to: obtain historical expansion records, analyze the historical expansion records based on the expansion trigger point, and determine the expansion response delay time; analyze the resource consumption trend to determine the resource exhaustion countdown; generate a preventive expansion time window based on the time difference between the expansion response delay time and the resource exhaustion countdown; and generate a resource configuration suggestion including a time window identifier based on the preventive expansion time window and the expansion mode.
[0159] Optionally, when the suggestion generation module 305 generates elastic demand parameters based on the resource consumption cycle and the resource usage pattern, it is used to: analyze the server operation data based on the resource usage pattern to determine the mode switching incentive; analyze the mode switching incentive to determine the incentive attributes; analyze the resource consumption cycle based on the incentive attributes to determine the impact weight of each mode switching incentive on the resource usage pattern; and generate elastic demand parameters based on the impact weight.
[0160] The system of this embodiment can be used to execute the method of any of the above embodiments. Its implementation principles and technical effects are similar and will not be described in detail here.
Claims
1. A method for calculating elastic demand of server transactions, characterized in that: include: Obtain customer agreement and server operation data; Analyzing the server operation data to determine operation resource information; Analyze the operating resource information to determine resource consumption trends and resource allocation; Determine the customer's business type based on the customer agreement; Determine concurrent processing requirements based on the customer's business type and resource allocation; generating elastic demand parameters according to the resource consumption trend and the concurrent processing requirements, and generating resource allocation suggestions according to the elastic demand parameters; The obtaining of server operation data includes: Parse the customer agreement to determine the authorization whitelist, desensitization requirements, and service scenario identifiers; Determining the data types of the operational data that can be obtained based on the authorization whitelist; According to the data type, the desensitization requirements and the service scenario identifier, the existing data is compliant, and the compliant data set is used as the server operation data; Determining the customer's business type according to the customer agreement includes: Based on the service scenario identifier, obtaining a scenario type code; Analyze server operation data and determine the API call sequence during operation; Determining business operation mode characteristics based on the API call sequence; Matching the business operation mode feature with the scenario type code; Determine the customer's business type based on the matching degree between the scenario type code and the business operation mode characteristics.
2. The method according to claim 1, characterized in that The compliance processing of the existing data according to the data type, the desensitization requirement and the service scenario identifier includes: Determining a priority sorting rule for the authorization whitelist according to the service scenario identifier; Analyze the desensitization requirements and determine the sensitive field mapping table; Establishing a field replacement strategy according to the sensitive field mapping table; Filter the existing data according to the data type to obtain available data; The authorized fields of the available data are retained according to the priority sorting rules, and the field replacement strategy is applied to process the sensitive data in the available data to complete the compliance processing.
3. The method according to claim 1, characterized in that Generating elastic demand parameters according to the resource consumption trend and the concurrent processing demand includes: Decomposing the resource consumption trend based on the timestamp to determine the resource consumption cycle; Analyze the concurrent processing requirements and determine resource usage patterns; An elastic demand parameter is generated according to the resource consumption cycle and the resource usage pattern.
4. The method according to claim 1, wherein Generating a resource configuration suggestion according to the elastic demand parameter includes: Analyze the elastic demand parameters to determine the expansion trigger point and expansion mode; Generate a resource configuration suggestion based on the expansion trigger point and the expansion mode.
5. The method according to claim 4, characterized in that The analyzing the elastic demand parameters and determining the capacity expansion mode includes: Based on the customer agreement, obtaining SLA breach cost data; parsing the SLA breach cost data to quantify service interruption tolerance; Acquiring real-time resource information; analyzing the real-time resource information to determine availability indicators; Analyze the availability index and calculate the resource supply elasticity coefficient; Analyze historical bill payment cycles to determine cost sensitivity; A capacity expansion mode is determined according to the service interruption tolerance, the resource supply elasticity coefficient, and the cost sensitivity.
6. The method according to claim 4, characterized in that Generating a resource configuration suggestion according to the expansion trigger point and the expansion mode includes: Obtain historical capacity expansion records, analyze the historical capacity expansion records based on the capacity expansion trigger point, and determine the capacity expansion response delay time; Analyzing the resource consumption trend and determining a countdown to resource exhaustion; generating a preventive capacity expansion time window according to a time difference between the capacity expansion response delay time and the resource exhaustion countdown; A resource configuration suggestion including a time window identifier is generated according to the preventive capacity expansion time window and the capacity expansion mode.
7. The method according to claim 3, characterized in that Generating elastic demand parameters according to the resource consumption cycle and the resource usage pattern includes: Analyzing the server operation data based on the resource usage pattern to determine a mode switching inducement; Analyzing the mode switching inducement and determining the inducement attribute; Analyzing the resource consumption cycle according to the inducement attributes to determine the influence weight of each mode switching inducement on the resource usage mode; An elastic demand parameter is generated according to the impact weight.
8. A server transaction elastic demand calculation application system, characterized in that: The method as claimed in any one of claims 1 to 7 comprises: A data analysis module is used to obtain client agreement and server operation data; analyze the server operation data and determine operation resource information; An information analysis module is used to analyze the operating resource information and determine resource consumption trends and resource allocation conditions; A type determination module, configured to determine a customer service type based on the customer agreement; A demand determination module, configured to determine concurrent processing requirements based on the customer service type and the resource allocation situation; a suggestion generation module, configured to generate elastic demand parameters according to the resource consumption trend and the concurrent processing requirement, and generate resource allocation suggestions according to the elastic demand parameters; The server transaction elastic demand calculation application system also includes a data determination module for: parsing the customer agreement to determine an authorization whitelist, desensitization requirements, and a service scenario identifier; determining the data type of the retrievable operation data based on the authorization whitelist; performing compliance processing on the existing data based on the data type, the desensitization requirements, and the service scenario identifier, and using the data set after the compliance processing as the server operation data; When the type determination module determines the customer business type according to the customer agreement, it is used to: obtain the scenario type code based on the service scenario identifier; analyze the server operation data to determine the API call sequence during the operation process; determine the business operation mode characteristics according to the API call sequence; match the business operation mode characteristics with the scenario type code; and determine the customer business type based on the matching degree between the scenario type code and the business operation mode characteristics.
Citation Information
Patent Citations
Method for automatically configuring resources of data center
CN119094335A
Automatic resource matching method and system based on credibility dynamic grading
CN119759550A