Small program high-concurrency request processing method and system

Abstract

The invention provides an applet high-concurrency request processing method and system, and relates to the technical field of computer data. The method comprises the following steps: firstly, receiving a high-concurrency user request from an applet front end to generate request feature information; secondly, inputting the request feature information into a pre-trained shunting model, identifying a service type, and marking a user request according to an obtained identification result to obtain a target request stream; inputting the target request stream into a cache decision module, and processing the target request stream according to a determined cache hierarchy corresponding to the user request to output a cache result; inputting the cache result and a preset system load parameter into a load balancer to generate a resource scheduling instruction; and finally, according to the target request stream, the cache result and the resource scheduling instruction, performing cooperative processing on the user request in the target scene. According to the technical scheme provided by the invention, accurate and efficient processing of user requests and adaptive optimization of system resources in a high-concurrency scene are realized.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method and system for handling high-concurrency requests in a mini-program. Background Technology

[0002] During peak traffic periods such as promotions and holidays, mini-programs will face the challenge of a sudden surge in user requests. These high-concurrency requests are usually diverse in business type and have high real-time requirements. The technical system needs to be able to quickly distinguish and process requests, and efficiently utilize caching and dynamically allocate resources to ensure service stability.

[0003] Currently, the existing technical solution is to use a load balancer combined with a unified distributed cache architecture. The load balancer distributes requests to backend server instances based on simple strategies such as round-robin. All instances share the same distributed cache cluster to query data. The system monitors the overall resource utilization and automatically increases or decreases the number of server instances when the threshold is exceeded.

[0004] However, this solution has obvious shortcomings. Its load balancing strategy fails to differentiate based on the business attributes of the requests, resulting in inaccurate allocation of computing resources. The unified caching architecture lacks hierarchical management, which can easily lead to cache pollution and a decrease in hit rate. At the same time, the scaling mechanism based on overall metrics is not sensitive enough to respond to local bottlenecks caused by specific business or cache failures, and resource adjustments are lagging. Summary of the Invention

[0005] This application provides a method and system for handling high-concurrency requests in mini-programs, which solves the problems of inaccurate request processing, low system resource utilization efficiency, and difficulty in maintaining stable high-performance services in existing technologies under high-concurrency scenarios.

[0006] Firstly, this application provides a method for handling high-concurrency requests in a mini-program, including:

[0007] Receive high-concurrency user requests from the mini-program frontend to generate request feature information, which includes request path, timestamp, and business type;

[0008] The request feature information is input into a pre-trained traffic splitting model, which identifies the service type and marks the user request based on the identification result to obtain the target request flow.

[0009] The target request stream is input into a pre-trained cache decision module, which determines the cache level corresponding to the user request based on the target request stream and the request path, processes it, and outputs the cache result.

[0010] The cached results and preset system load parameters are input to the load balancer, and a resource scheduling instruction is generated based on the number of miss signals in the cached results and the system load parameters.

[0011] Based on the target request stream, the cached results, and the resource scheduling instructions, the user requests in the target scenario are processed collaboratively.

[0012] Optionally, high-concurrency user requests from the mini-program frontend are received to generate request feature information, which includes request path, timestamp, and business type, including:

[0013] Obtain the raw request data stream initiated by the mini-program frontend in the target scenario;

[0014] Extract the Uniform Resource Locator (URL) field contained in the user request from the original request data stream, and use it as the path identifier of the user request;

[0015] Extract the time point data at which the user request is received by the system, and use it as the timestamp of the user request;

[0016] The message of the user request is parsed to determine the business operation category corresponding to the user request, which is used as the business type of the user request;

[0017] The path identifier, timestamp, and service type corresponding to the same user request are combined to generate a request feature record;

[0018] Integrate all user request characteristic records to form request characteristic information.

[0019] Optionally, the request feature information is input into a pre-trained traffic splitting model, which identifies the service type and marks the user request based on the identification result to obtain the target request flow, including:

[0020] The business operation category contained in each request feature record in the request feature information is read through the traffic splitting model;

[0021] The business operation category is matched with the set of predefined rules stored inside the traffic splitting model;

[0022] Based on the matching results, the original user request that generated the request feature record is assigned a corresponding request tag type through the traffic splitting model to obtain the tagged user request.

[0023] All the marked user requests are arranged and aggregated in their original receiving order to form the target request stream.

[0024] Optionally, the target request stream is input to a pre-trained cache decision module, which determines the cache level corresponding to the user request based on the target request stream and the request path, and processes the result to output a cache result, including:

[0025] Read the target request tag and target request path corresponding to each user request in the target request stream;

[0026] Based on the target request tag, the allowed cache level range corresponding to the target request tag is searched in the hierarchical mapping relationship stored in the cache decision module;

[0027] Within the allowed cache levels, the target request path of the user request is compared with the predefined path rules of each cache level to determine the target cache level that the user request matches.

[0028] Based on the target cache level, access the corresponding cache area to obtain the target data corresponding to the user request;

[0029] If the target data is obtained in the cache area, the target data is used as the cache result; if the target data is not obtained, a miss signal is generated as the cache result.

[0030] Optionally, the cached results and preset system load parameters are input to the load balancer, and a resource scheduling instruction is generated based on the number of misses in the cached results and the system load parameters, including:

[0031] Count the total number of miss signals in the cached results received within the preset time window;

[0032] The total number of missed signals is compared with a first preset threshold, the CPU utilization rate in the system load parameters is compared with a second preset threshold, and the memory usage is compared with a third preset threshold.

[0033] Based on the comparison results, the preset resource scheduling rules are triggered;

[0034] Based on the resource scheduling rules, a resource scheduling instruction is generated, wherein the resource scheduling instruction includes the direction and scale of resource adjustment.

[0035] Optionally, based on the resource scheduling rules, a resource scheduling instruction is generated, including:

[0036] Based on the predefined execution actions in the resource scheduling rules, the target resource type to be adjusted is determined, wherein the target resource type includes at least one of the following: number of cache servers, load balancer weight, and number of database connections.

[0037] When the target resource type to be adjusted is the number of cache servers, a first initial instruction is generated according to the predefined adjustment value in the resource scheduling rules;

[0038] When the target resource type to be adjusted is load balancer weight, an initial configuration instruction is generated according to the adjustment direction and adjustment value defined in the resource scheduling rules.

[0039] When the target resource type to be adjusted is the number of database connections, an initial control command is generated according to the adjustment value defined in the resource scheduling rules.

[0040] The first initial instruction, the initial configuration instruction, or the initial control instruction generated for the target resource type to be adjusted are combined to form a resource scheduling instruction.

[0041] Optionally, within the allowed cache levels, the target request path of the user request is compared with the predefined path rules of each cache level to determine the target cache level that matches the user request, including:

[0042] Obtain from the cache decision module the set of path rules associated with each cache level corresponding to the range of allowed cache levels;

[0043] Within the allowed cache levels, the cache levels to be checked are selected sequentially according to a preset order.

[0044] Each path matching pattern is retrieved sequentially from the set of path rules associated with the current cache level to be inspected;

[0045] Perform a string matching operation between the target request path of the user request and the retrieved path matching pattern;

[0046] If the target request path matches the path matching pattern, then the current cache level to be checked is determined as the target cache level.

[0047] If the target request path fails to match any of the path matching patterns in the current cache level, the next cache level is selected as the new current cache level to be checked in the order described above, and the process of retrieving the path matching pattern and performing the matching operation is repeated until the target cache level is determined.

[0048] Secondly, this application provides a high-concurrency request processing system for mini-programs, including:

[0049] The receiving module is used to receive high-concurrency user requests from the front end of the mini program to generate request feature information, which includes request path, timestamp and business type.

[0050] The identification module is used to input the request feature information into a pre-trained traffic splitting model, identify the service type through the traffic splitting model, and mark the user request according to the identification result to obtain the target request flow;

[0051] The output module is used to input the target request stream into the pre-trained cache decision module, determine the cache level corresponding to the user request based on the target request stream and the request path, process it, and output the cache result.

[0052] The generation module is used to input the cached results and preset system load parameters to the load balancer, and generate resource scheduling instructions based on the number of miss signals in the cached results and the system load parameters;

[0053] The processing module is used to collaboratively process user requests during peak traffic scenarios based on the target request stream, the cached results, and the resource scheduling instructions.

[0054] Thirdly, this application provides a computing device, including a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are to be invoked and executed by the processing component to implement a high-concurrency request processing method for a mini-program as described in the first aspect above.

[0055] Fourthly, this application provides a computer storage medium storing a computer program, which, when executed by a computer, implements a method for handling high-concurrency requests in a small program as described in the first aspect.

[0056] This application identifies and marks the business type of user requests through a traffic splitting model, achieving fine-grained differentiation of high-concurrency traffic. This enables subsequent processing to be differentiated based on the inherent business attributes of the requests, overcoming the shortcomings of existing technologies where load balancing strategies are singular and cannot distinguish between request priorities and resource requirements. At the same time, through the cache decision module, based on request marking and request paths, and combined with preset path rules, hierarchical matching can be performed to accurately allocate cache resources, such as memory cache or distributed cache, for requests of different categories and access modes. This effectively avoids the cache pollution problem caused by all request data being mixed and stored in a single cache pool, and improves the cache hit rate and access efficiency of hot data.

[0057] Furthermore, by combining the results of cache processing with real-time system load parameters as the basis for load balancing decisions, the generation of resource scheduling instructions can respond sensitively to the real pressure caused by specific business peaks or cache failures. This dynamic scheduling mechanism based on multi-dimensional feedback can quickly identify and specifically alleviate local system bottlenecks, making up for the shortcomings of traditional solutions that rely solely on overall resource thresholds and are slow and blind in their adjustments. Finally, through the collaborative processing of target request streams, cache results, and resource scheduling instructions, integrated intelligent management and control from request access and cache allocation to resource elastic scaling is achieved in peak traffic scenarios.

[0058] These or other aspects of this application will become more apparent from the description of the following embodiments. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0060] Figure 1 A flowchart of a method for handling high-concurrency requests in a mini-program, as provided in this application, is shown.

[0061] Figure 2 This paper shows a schematic diagram of the structure of a high-concurrency request processing system for mini-programs provided in this application;

[0062] Figure 3 A schematic diagram of the structure of a computing device provided in this application is shown. Detailed Implementation

[0063] To enable those skilled in the art to better understand the present application, the technical solution of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0064] In some of the processes described in the specification, claims, and accompanying drawings of this application, multiple operations appearing in a specific order are included. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not themselves represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

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

[0066] Figure 1 This application provides a flowchart of a method for handling high-concurrency requests in a mini-program, such as... Figure 1 As shown, the method includes:

[0067] Step 101: Receive high-concurrency user requests from the mini-program frontend to generate request feature information, which includes request path, timestamp, and business type.

[0068] Optionally, step 101 may specifically include:

[0069] Step 1011: Obtain the raw request data stream initiated by the mini-program frontend in the target scenario.

[0070] Step 1012: Extract the Uniform Resource Locator (URL) field contained in the user request in the original request data stream, and use it as the path identifier of the user request.

[0071] Step 1013: Extract the time point data when the user request is received by the system, and use it as the timestamp of the user request.

[0072] Step 1014: Parse the message of the user request to determine the business operation category corresponding to the user request, which is the business type of the user request.

[0073] Step 1015: Combine the path identifier, timestamp, and service type corresponding to the same user request to generate a request feature record.

[0074] Step 1016: Integrate the request feature records corresponding to all user requests to form request feature information.

[0075] In this step, high-concurrency user requests refer to a massive number of service requests sent simultaneously by users through the mini-program front-end to the back-end server within a very short time window. This type of request pressure usually occurs in target scenarios such as shopping festivals and flash sales, and is used to test the system's real-time processing and carrying capacity.

[0076] The request path refers to the address of the backend service interface that the user wants to access. It is represented by a network path string and is used to uniquely identify a specific service function, such as querying product details or submitting an order.

[0077] A timestamp is the precise time when a server system receives each user request. It is usually recorded in milliseconds or microseconds and is used to identify the order and specific time of the requests.

[0078] Business type refers to the classification label of the business operation to be performed in the user request, such as whether it is a data query operation or a data modification operation. It is used to distinguish the different requirements of the request on system resource consumption and data consistency. It is obtained by parsing the message content of the request and comparing it with predefined business rules.

[0079] The raw request data stream refers to the collection of continuous request data packets sent from the mini-program frontend directly captured from the network entry point in the target scenario, without any processing. It is the source of the processed data and is used to provide the initial request information, which is obtained through the network listening port.

[0080] The Uniform Resource Locator (URL) field refers to the network address portion of a user request packet that specifies the target of the request. It is usually called a URL and is used to identify the specific network resource or service interface that the user wants to access. It is obtained by parsing the HTTPS request message line.

[0081] The path identifier refers to the core path portion extracted from the Uniform Resource Locator (URL) field of the user request. It removes information such as domain name, port, and parameters, and is used to accurately match the backend service endpoint. It is obtained by performing string splitting and extraction operations on the URL field.

[0082] Point-in-time data refers to the precise point in time at which a user request data packet is fully received and ready for processing, recorded at the operating system kernel or application framework level. It is used to timestamp the request and is obtained by calling a high-precision clock interface when the request is enqueued.

[0083] Business operation category refers to a specific type of request that is classified by analyzing the intent and nature of the operation, such as placing an order and making payment, browsing products, updating personal information, etc. It is used to characterize the core business logic of the request and is obtained by parsing the characteristic information in the interface definition, message header or payload of the request and mapping it to a predefined classification system.

[0084] A request feature record refers to a structured data record that encapsulates the three feature attributes of a single user request: its corresponding path identifier, timestamp, and business operation category. This record is used to fully characterize the features of a request.

[0085] Request feature information refers to a set or list of request feature records corresponding to all received user requests within a unit of time. It reflects the overall feature profile of the request flow within the current time period and is used as input for downstream processing modules.

[0086] In this step, the raw network packets received by the server's network card are first captured and reassembled using network listening and protocol parsing techniques. Specifically, the network protocol stack in the server's operating kernel, such as the TCP / IP protocol stack, is responsible for receiving network packets from the mini-program's front end, sorting, deduplicating, and assembling these packets according to the Transmission Control Protocol (TCP) specification to restore complete application layer protocol data units. Simultaneously, the request receiving program reads these restored HTTP or HTTPS protocol messages from the protocol stack's receive buffer by calling the socket interface, thus obtaining a continuous and structured raw request data stream. Secondly, each independent request message in the raw request data stream is processed using string parsing techniques. Each request message is read sequentially, its starting line is located, and the starting line is parsed using a string splitting function to identify and extract the complete Uniform Resource Locator (URL) field, which includes the protocol, path, and parameters. Subsequently, the URL field is further processed by removing query parameters and fragment identifiers, and stripping the protocol header, host address, and port information to obtain a clean string representing the core interface address. This string is the path identifier for the request.

[0087] Then, a clock-based technique is used to time-stamp the currently processed request. The instant the processing thread begins parsing the request message, it calls a high-precision time acquisition function provided by the operation settings, such as `System.nanoTime` in Java. This function directly reads the current count value of the real-time clock maintained by the kernel and records the returned nanosecond or millisecond precision value as the time point data of the request, which is subsequently formatted into a standard timestamp. Next, rule matching and feature mapping techniques are used to determine the business category of the request. The current request message is deeply parsed, including identifying its HTTP method, reading specific header fields, and analyzing the semantics of its path identifier. A predefined business rule mapping table is maintained, with the request method + path pattern combination or specific header field value as the key and the business category as the value. The parsing result of the current request is compared item by item with this business rule mapping table. When the request characteristics match the key of a certain rule, the corresponding business category definition, such as transaction order placement or information query, is extracted as the business operation category of the request, i.e., the final determined business type.

[0088] Then, data encapsulation technology is used to aggregate the generated discrete features into a complete record. First, an object instance is created, which contains three attribute fields: path identifier, timestamp, and business type. Then, the path identifier string corresponding to this request, the timestamp value converted from the time point data, and the parsed business operation category label are assigned to the corresponding attribute fields of the object instance. This data instance, which contains three elements and has a clear structure, is the request feature record describing this single request. Finally, queue management and batch processing technology are used to integrate all independent records into batch data, which serves as a thread-safe memory queue. When a request feature record is generated, it is inserted into the tail of the memory queue. An independent counter monitors the status of the memory queue. When a preset time window or record quantity threshold is reached, the task will read all records in the memory queue at once and convert them into a data set in the form of a list or array. This data set containing all request features in the current period is the final output request feature information for downstream module processing.

[0089] For example, at the start of a large-scale promotional event hosted by e-commerce platform A, a massive number of users simultaneously click the "buy" or "search" button through its mini-program. First, users X, Y, and Z's devices send requests to platform A's server almost simultaneously. The receiving program on the server listens for these massive influx of network connections and successfully acquires the raw request data stream composed of these requests. Next, it processes user X's request, extracting the complete network address field from the request message and parsing out the core service interface path, such as the path representing order submission. This path string is saved as the path identifier for user X's request. Then, it calls a high-precision clock interface to record the current time, accurate to milliseconds, as the timestamp of user X's request. Next, it parses the request header and path, matching them against an internal business rule mapping table to determine that this is a transaction order type business operation, thus determining its business type. Finally, it combines the request's path identifier, timestamp, and the transaction order business type to generate a feature record representing user X's request.

[0090] Next, the same process is used to process user Y's request. Assuming user Y is querying a product, the interface path for the product query is extracted as the path identifier, the arrival time of the request is recorded as a timestamp, and the business type is determined to be a product query according to the matching rules, thereby generating a request feature record for user Y. Similarly, a corresponding record is generated for user Z's request, and in a very short time, corresponding request feature records are generated for tens of thousands of concurrent requests. Finally, all these records generated in a short period of time are collected and packaged into a complete data set, which is the request feature information at the current moment.

[0091] This step transforms the received raw high-concurrency request stream into structured request feature information. This request feature information integrates key features such as the path, time, and business type of each request, providing an accurate and parsable data foundation for subsequent differentiated intelligent processing and enabling precise feature characterization of massive requests.

[0092] Step 102: Input the request feature information into the pre-trained traffic splitting model, identify the service type through the traffic splitting model, and mark the user request according to the identification result to obtain the target request flow.

[0093] Optionally, step 102 may specifically include:

[0094] Step 1021: Read the business operation category contained in each request feature record in the request feature information through the traffic splitting model.

[0095] Step 1022: Match the business operation category with the predefined rule set stored inside the traffic splitting model.

[0096] Step 1023: Based on the matching results, assign a corresponding request tag type to the original user request that generated the request feature record through the traffic splitting model to obtain the tagged user request.

[0097] Step 1024: Arrange and aggregate all the marked user requests in the original receiving order to form the target request stream.

[0098] In this step, the pre-trained traffic splitting model refers to a computer program module that has completed learning and parameter optimization using historical request data. It has mastered the ability to identify the business affiliation of a request from its characteristics and is used to automatically identify and classify the business type of the real-time incoming request feature information. It is obtained by training the model on historical data using machine learning algorithms.

[0099] The target request stream refers to an ordered sequence of user requests that have been processed by the splitting model and marked with specific tags. It maintains the original order of the requests, but each request carries additional information indicating its processing priority, which is used to guide the differentiated processing of subsequent caching and resource scheduling stages. It is obtained by sequentially aggregating the marked user requests.

[0100] A predefined rule set refers to a set of explicit judgment criteria and classification items stored within the traffic splitting model. It defines which request tag type should correspond to different business operation categories and serves as the direct basis for the model to perform matching and decision-making. It is obtained either manually or extracted from training data.

[0101] Original user request allocation refers to an action performed by the traffic splitting model, which is to assign a corresponding tag to the initial, unprocessed user request that generates a certain request feature record. This action establishes the association between the feature record, the original request, and the processing tag.

[0102] Request tag type refers to the category label used to distinguish user requests in terms of processing priority, resource requirements, or data consistency requirements, such as high-priority transaction type or low-priority query type. It is used to quickly identify the processing strategy of the request in subsequent processing and is obtained by mapping the business operation category with a predefined set of rules.

[0103] A tagged user request refers to the original, unprocessed user request. After being processed by the traffic splitting model, it is a new request object with a specific request tag type attached. It contains all the data of the original request and adds tag information to represent a classified unit to be processed.

[0104] In this step, the request feature information received by the traffic splitting model is first processed through data traversal and field extraction techniques. The traffic splitting model program iterates through each request feature record in the data set of request feature information. For each record, the business operation category text or code stored in the field named "business type" in its data structure is directly read. This reading operation extracts the business intent contained in each record, preparing input data for matching judgment. Secondly, the business operation category read by the traffic splitting model is compared with a predefined set of rules stored inside the model through rule engine matching technology. This set of rules usually exists in the form of a list of key-value pairs or a decision tree. The currently read business operation category is used as the query key to search in the rule set. The search process is deterministic, that is, it searches for rule entries that are completely equivalent to the category or satisfy the inclusion relationship. For example, the rule set may contain entries such as "transaction order" corresponding to tag A, "product query" corresponding to tag B, etc. This is a search mapping process.

[0105] Next, using tag mapping and request association techniques, decisions are made based on the matching results. When a matching rule is found, the request tag type defined in the rule entry, such as transaction type T1 or query type Q1, is determined as the tag assigned to the current request. Then, the flow-splitting model needs to associate this tag back to the original request. Since the request feature record is extracted and generated from the original user request, the two are associated through a unique request ID. Using this ID, the corresponding original user request object temporarily stored in memory is found, and the determined request tag type is written into the specific attribute field of the object. After this writing operation is completed, the original user request is transformed into a tagged user request. Finally, using sequential buffering and stream reassembly techniques, all processed tagged user requests are aggregated into the final output stream, maintaining a buffer sorted by the original reception time of the requests. Whenever a request is tagged, it is placed in this buffer at its corresponding time position. A separate output thread or process retrieves the requests from the buffer in chronological order and outputs them sequentially, forming a continuous and stable data stream. This data stream is the target request stream, which contains all the tagged requests and maintains their original arrival order.

[0106] For example, following the specific implementation of the previous step, e-commerce platform A first generates request feature information containing tens of thousands of request feature records of users X, Y, Z, etc., and inputs it into a pre-trained traffic splitting model; secondly, the traffic splitting model starts working, first reading the request feature record of user X and extracting the business operation category of transaction order placement; then it searches in its internal predefined rule set, which stipulates that all business operations of the transaction order placement category should be marked as transactional-high priority; then, according to the matching result, this transactional-high priority request label type is associated with and written into the original user request initially initiated by user X through a unique request ID, thereby obtaining the labeled user request X;

[0107] Then, the records for user Y are processed, the product query category is extracted, and a query-standard priority label is assigned to it based on the rule set. This completes the labeling of user Y's original request. Similarly, user Z's request will also be assigned a corresponding label based on its business type. In a very short time, the traffic splitting model completes the labeling of all tens of thousands of requests. Finally, according to the initial time order in which these requests were received, all the labeled user requests of users X, Y, Z, etc., are arranged in sequence to form an ordered flow sequence, namely the target request stream, which is used as the input of the subsequent caching decision module.

[0108] This step uses a traffic splitting model to automatically identify and match request characteristics, assigning a clear processing label to each high-concurrency user request. This transforms the disordered torrent of requests into an ordered stream of target requests with priority indicators. This achieves preliminary intelligent classification of massive concurrent requests, providing a direct decision-making basis for differentiated and refined processing in subsequent stages, and improving the accuracy and intent targeting of request routing and resource allocation as a whole.

[0109] Step 103: Input the target request stream into the pre-trained cache decision module, determine the cache level corresponding to the user request based on the target request stream and the request path, and process it to output the cache result.

[0110] Optionally, step 103 may specifically include:

[0111] Step 1031: Read the target request tag and target request path corresponding to each user request in the target request stream.

[0112] Step 1032: Based on the target request tag, search for the allowed cache level range corresponding to the target request tag in the hierarchical mapping relationship stored in the cache decision module.

[0113] Step 1033: Within the allowed cache levels, compare the target request path of the user request with the predefined path rules of each cache level to determine the target cache level that the user request matches.

[0114] Optionally, step 1033 may include the following steps: obtaining from the cache decision module a set of path rules associated with each cache level corresponding to the allowed cache level range; within the allowed cache level range, sequentially selecting the current cache level to be checked in a preset order; sequentially retrieving each path matching pattern from the set of path rules associated with the current cache level to be checked; performing a string matching operation between the target request path of the user request and the retrieved path matching patterns; if the target request path matches the path matching pattern successfully, then determining the current cache level to be checked as the target cache level; if the target request path does not match any of the path matching patterns of the current cache level, then selecting the next cache level as the new current cache level to be checked in the order, and repeating the process of retrieving path matching patterns and performing matching operations until the target cache level is determined.

[0115] Step 1034: According to the target cache level, access the corresponding cache area to obtain the target data corresponding to the user request.

[0116] Step 1035: If the target data is obtained in the cache area, the target data is used as the cache result; if the target data is not obtained, a miss signal is generated as the cache result.

[0117] In this step, the pre-trained cache decision module refers to an intelligent decision-making program that has completed parameter tuning through historical access patterns and data characteristics. It has mastered the strategy of allocating appropriate cache locations according to the attributes of requests. It is used to automatically decide which level of cache each request in the input target request stream should access. It is trained on historical cache access logs using a decision model.

[0118] Caching tiers refer to different levels of temporary data storage areas in an architecture, based on read / write speed, storage capacity, and physical location. Examples include the first-level cache located in server memory and the second-level cache located on a separate cache server. These tiers are used to store data in a tiered manner to balance access speed and storage cost. They are divided and deployed through architectural design.

[0119] The cache result refers to the output generated by the cache decision module after processing a user request. It is either the specific data content successfully retrieved from the cache, or a specific signal indicating that the data is not in the cache. It is used as a stage processing result of the request and passed on to the next step.

[0120] The hierarchical mapping relationship refers to a configuration table or mapping function stored inside the cache decision module, which defines which cache levels different request tag types are allowed to access. It is used to initially limit the cache range that can be queried based on the request tag, and is obtained through manual strategy configuration or learning from training data.

[0121] The allowed cache level range refers to the set of one or more cache levels that a user request with a specific request tag is allowed to attempt to query after querying according to the hierarchy mapping relationship. This set serves as the search space for subsequent path matching operations.

[0122] Predefined path rules refer to a set of judgment criteria pre-set for each cache level to determine whether a request path is suitable for using the cache level. They are usually represented as a set of path patterns containing wildcards to achieve fine-grained matching between request paths and cache levels.

[0123] The target cache level refers to the specific cache level that is most suitable for handling a particular user request within the allowed cache levels, determined by path rule matching. This level is used to clarify the specific target location for the data query in this request.

[0124] A path rule set refers to a collection of predefined path rules bound to a certain cache level. Each cache level corresponds to a path rule set, which is used to manage the request path patterns served by that level.

[0125] A path matching pattern refers to a specific rule in a set of path rules. It is usually a string template containing wildcards that describes a class of request paths that match the pattern. String matching technology is used to determine whether a specific request path conforms to the pattern.

[0126] Target data refers to the specific business data content that the user requests, such as product information, user details, or page fragments. It is the target of cache query operations and is used to directly form the response content returned to the user. It is obtained by querying the database or a calculated cache area.

[0127] A miss signal is a standardized indication signal generated when the target data is not found in the cache area. It is used to clearly inform subsequent processes that the cache query has failed and that they need to switch to other data sources. It is obtained by detecting that the cache query result is empty.

[0128] In this step, the cache decision module first parses the input target request stream using streaming processing and field reading technology. The cache decision module sequentially reads each user request object in the target request stream, and directly extracts the attribute value named "request tag" by accessing the attributes stored internally by the object, thus obtaining the target request tag of the target request stream. At the same time, it extracts the attribute value named "request path" from the associated metadata, thus obtaining the target request path of the target request stream. These two key attributes are retrieved synchronously as the basic input for subsequent decisions. Next, the extracted target request tag is processed using key-value pair query technology. The hierarchical mapping relationship stored internally is regarded as a dictionary data structure, where the key is the possible request tag type and the value is a list of cache level numbers that the target request tag is allowed to access. The target request tag is used as the search key to perform a search operation in this dictionary. When the search is successful, the list of cache level numbers corresponding to the target request tag is obtained. This list is defined as the range of cache levels that the current request is allowed to access.

[0129] Then, the hierarchical rule matching stage begins to determine the final target cache level. First, based on the range of allowed cache levels, the path rule set corresponding to each level is loaded from the module configuration library. Then, according to the preset priority order, such as starting from the L1 cache with the lowest access latency, the target request path string of the current request is matched with each path matching pattern in the path rule set of the currently selected level using regular expression matching or wildcard matching. The matching operation is performed one by one. Once the target request path is found to match the rule defined by a certain path matching pattern, the subsequent matching of the current level is immediately terminated, and the cache level being checked is recorded as the target cache level. If all patterns of the current level do not match, the next allowed cache level is selected in sequence, and the above matching process is repeated until a match is found or all allowed levels are traversed.

[0130] After determining the target cache level, data retrieval is performed through caching protocol invocation technology. Based on the type of the target cache level, an appropriate cache client is selected, such as a client driver connecting to Memcached or Redis. The unique identifier of the user request or the hashed key is used as the query parameter, and the cache client sends a data retrieval command to the physical storage area corresponding to the target cache level. Finally, the response returned by the cache client is received through result discrimination and encapsulation technology. If the response contains a valid data payload, this data is parsed and encapsulated into the target data, which is used as the cache result of this request. If the response indicates that the key does not exist or returns a null value, a predefined, uniquely identified miss signal instance is generated, and this signal is used as the cache result of this request.

[0131] For example, following the specific implementation of the previous step, firstly, the target request stream containing user X, Y, Z, and other tagged requests from e-commerce platform A is sent to the pre-trained cache decision module; secondly, the request from user X is processed. The module reads that user X's request is tagged as transactional-high priority, and the request path is the order submission interface path. Based on this tagged request, the module queries the internal layer mapping dictionary and learns that this tagged request is only allowed to access the L2-distributed transaction cache; therefore, it directly matches the order interface path in the path rule set of this layer and succeeds, thus the L2-distributed transaction cache is determined as the target cache layer; then, the distributed cache client queries the relevant data of the order, successfully obtaining the inventory status, and uses this data as the cache result.

[0132] Then, the request from user Y is processed. It is read that the request is marked as query-standard priority, and the path is the product query interface. The mapping dictionary is consulted, revealing that this request allows access to both the L1-local hotspot cache and the L2-public data cache. The path rules of the L1 layer are then checked, and it is found that the product query path does not conform to any of its patterns. The rules of the L2 layer are then checked, and a match is found. Therefore, the L2-public data cache is determined as the target cache level. Next, the product details are queried from the public cache. Since it is a popular product, the data is successfully returned and used as a cached result. Finally, for user Z's request to query a less popular product, after matching the L2 level, no data is found, so a miss signal is generated as its cached result.

[0133] This step uses intelligent mapping and rule matching from the cache decision module to accurately assign the most suitable cache level to each categorized request and execute queries; it achieves fine-grained routing for cache access of high-concurrency requests, improves the overall utilization efficiency and response speed of cache resources, and provides clear cache status feedback to downstream requests.

[0134] Step 104: Input the cached results and preset system load parameters into the load balancer, and generate resource scheduling instructions based on the number of miss signals in the cached results and the system load parameters.

[0135] Optionally, step 104 may specifically include:

[0136] Step 1041: Count the total number of missed signals in the cached results received within the preset time window.

[0137] Step 1042: Compare the total number of missed signals with a first preset threshold, compare the CPU utilization rate in the system load parameters with a second preset threshold, and compare the memory usage with a third preset threshold.

[0138] Step 1043: Based on the comparison results, trigger the preset resource scheduling rules.

[0139] Step 1044: Based on the resource scheduling rules, generate resource scheduling instructions, wherein the resource scheduling instructions include the direction and scale of resource adjustment.

[0140] Optionally, step 1044 may include the following steps: determining the target resource type to be adjusted according to the predefined execution actions in the resource scheduling rules, wherein the target resource type includes at least one of the number of cache servers, load balancer weight, and number of database connections; when the target resource type to be adjusted is the number of cache servers, generating a first initial instruction according to the predefined adjustment value in the resource scheduling rules; when the target resource type to be adjusted is the load balancer weight, generating an initial configuration instruction according to the adjustment direction and adjustment value defined in the resource scheduling rules; when the target resource type to be adjusted is the number of database connections, generating an initial control instruction according to the adjustment value defined in the resource scheduling rules; and aggregating the first initial instruction, the initial configuration instruction, or the initial control instruction generated for the target resource type to be adjusted to form a resource scheduling instruction.

[0141] In this step, the preset system load parameters refer to a predefined set of indicators used to measure the current workload and resource consumption of the computing system, such as the CPU's workload and memory usage. These parameters are used to quantitatively describe the real-time health status and performance bottlenecks of the system and are collected periodically by system monitoring tools.

[0142] A resource scheduling instruction is an instruction generated by the load balancer that contains specific operation commands, explicitly requiring the addition, reduction, or reconfiguration of a certain type of resource. It is used to directly drive the cloud computing platform to perform elastic resource adjustments and is obtained by triggering resource scheduling rules after analyzing cache results and system load parameters.

[0143] The first preset threshold is a critical value set for the number of miss signals allowed within a time window. It is used to determine whether the cache pressure exceeds normal expectations and is determined through historical performance analysis and experience.

[0144] The second preset threshold refers to a percentage critical point set for the utilization rate of the central processing unit, used to determine whether CPU computing resources have become strained. It is obtained through capacity planning and performance baseline setting.

[0145] CPU utilization refers to the percentage of time the CPU spends executing effective computing tasks within a specific time period. It is used to characterize the busyness of the core computing components and is obtained by reading performance counters provided by the kernel.

[0146] Memory usage refers to the physical memory capacity currently occupied by operating and running programs. It is usually expressed in bytes or as a percentage of total memory and is used to characterize the scarcity of temporary data storage space. It can be obtained through the operating system's memory management interface.

[0147] The third preset threshold refers to a percentage or absolute value threshold set for memory usage, used to determine whether memory resources are about to be exhausted. It is obtained through capacity planning and safety reservation settings.

[0148] Resource scheduling rules refer to a predefined series of condition-action logic pairs. The condition part consists of a combination of the comparison results of the above items, while the action part defines the resource adjustment measures to be taken when the conditions are met. This is used to automatically convert monitoring indicators into operation and maintenance actions, which are obtained through operation and maintenance strategy configuration.

[0149] The direction of resource adjustment refers to the basic operation type of resource adjustment contained in the resource scheduling instruction, that is, whether to increase or decrease resources, to clarify the trend of resource changes, and is obtained from the triggered resource scheduling rules.

[0150] The adjustment scale refers to the specific number or magnitude of resource adjustments specified in the resource scheduling instruction, such as adding 2 servers or increasing the weight by 10%. It is used to quantify the resource adjustment operation and is parsed from the triggered resource scheduling rules.

[0151] The target resource type to be adjusted refers to the specific resource category that needs to be adjusted according to the resource scheduling rule. It is used to clarify the target of the instruction and is obtained from the execution action defined in the triggered resource scheduling rule.

[0152] The number of cache servers refers to the total number of virtual or physical server instances currently running in the system that provide caching services. It is a common type of target resource to be adjusted to scale up or down the overall processing capacity of the cache service cluster. The current number can be obtained by querying the cloud platform or container orchestration platform.

[0153] Load balancer weight refers to the numerical value assigned to a backend server or group of servers in a load balancer to determine the proportion of traffic it receives. It is a common type of target resource to be adjusted, used to fine-tune traffic distribution without changing the number of servers, and is obtained by reading the load balancer configuration.

[0154] Database connection count refers to the maximum number of active connections to the database that are allowed to exist simultaneously in the database connection pool. It is a common target resource type to be adjusted to control the concurrent access pressure of the database and is obtained by querying the database connection pool configuration.

[0155] Predefined adjustment values ​​refer to the amount of resource change that is pre-defined in the resource scheduling rules for each execution action, such as adding 1 unit or reducing 5 connections. These values ​​are used to generate specific, executable scheduling parameters and are directly read from the resource scheduling rules.

[0156] The first initial instruction refers to the rule generated when the target resource type to be adjusted is the number of cache servers, and is used to control the cache resource pool to create new cache servers or release existing cache servers.

[0157] The initial configuration command refers to the rule generated when the target resource type to be adjusted is load balancer weight, and is used to modify the traffic weight allocated to the specified server cluster in the load balancer.

[0158] The initial control command refers to the command generated according to rules when the target resource type to be adjusted is the number of database connections, and is used to adjust the maximum allowed number of connections in the database connection pool.

[0159] In this step, the continuously input cached result stream is first monitored and aggregated using a sliding window counter technique. The load balancer maintains a time window, for example, a 5-second moving time window, continuously receiving cached results from upstream. Each time a cached result is received, its content is checked. If a cached result is identified as a miss signal, an atomic increment operation is performed on the counter corresponding to the current time window. Simultaneously, a background thread periodically slides this time window and retrieves the final value of the counter from the previously slid-out time window; this value represents the total number of miss signals received within the preset time window. Secondly, the load balancer uses parallel threshold comparison technology to evaluate multiple monitoring metrics in real time, synchronously obtaining the latest system load parameters from the system monitoring component, primarily CPU utilization and memory usage. Then, it starts... Three parallel comparison operations are performed: the total number of missed signals obtained in the first step is compared with a first preset threshold; the CPU utilization is compared with a second preset threshold; and the memory usage is compared with a third preset threshold. These comparison operations use simple greater than, less than, or equal to numerical judgments and each outputs a Boolean value. Then, through rule engine query technology, the comparison results are transformed into specific operation decisions. The load balancer internally stores a preset resource scheduling rule base, and each rule has a unique trigger condition. This trigger condition is usually designed as a logical combination of the above Boolean value comparison results. The three Boolean value comparison results generated in the current period are matched with the trigger conditions of each rule in the rule base. Whenever a rule whose trigger conditions are all met is found, it is determined that the resource scheduling rule is triggered.

[0160] Then, using instruction template rendering technology, specific operation instructions are generated. Based on the triggered resource scheduling rules, the defined execution actions are read. The execution actions explicitly specify the type of target resource to be adjusted, such as the number of cache servers, and provide the direction of resource adjustment and predefined adjustment values. Depending on the target resource type, the corresponding instruction template is selected. For example, for the number of cache servers, the cloud platform's application programming interface is called to generate a first initial instruction draft, which includes the direction of expansion or contraction and the specific number of servers to be added or removed. Similarly, for the load balancer weight or the number of database connections, corresponding initial configuration instructions or initial control instruction drafts are generated. Finally, through instruction aggregation and encapsulation technology, the final issueable resource scheduling instructions are formed. In some cases, multiple rules may be triggered simultaneously, involving adjustments to multiple resource types. All initial instruction drafts generated for this period, including the first initial instruction, initial configuration instructions, and initial control instructions, are collected into an instruction list. Then, necessary metadata, such as timestamps and trigger rule IDs, is added to this instruction list, and it is encapsulated into a complete, structured resource scheduling instruction data packet, which is sent to the executor module responsible for executing resource adjustments.

[0161] For example, following the specific implementation of the previous step, firstly, e-commerce platform A continuously generates cache results, including miss signals generated when user Z requests unpopular products, while CPU utilization and memory usage are monitored in real time; secondly, within a certain 5-second time window, the load balancer detects a large number of miss signals, exceeding a first preset threshold, and monitoring shows that CPU utilization also exceeds a second preset threshold, but memory usage remains within a safe range; then, the combination of these three comparison results—excessive miss count, excessive CPU usage, and normal memory usage—precisely triggers a preset resource scheduling rule. This resource scheduling rule is defined as having high cache miss counts and high CPU load, and its execution action is to increase the number of cache servers by 2 and tilt the load balancer weight towards the cache cluster by 5%.

[0162] Therefore, based on this rule, the load balancer generates two initial instructions: one is a first initial instruction to request two additional cache servers from the cloud platform; the other is an initial configuration instruction to adjust the load balancer configuration to direct more traffic to the cache service. Finally, these two initial instructions are packaged into a resource scheduling instruction and sent to the automated operation and maintenance platform for execution. If subsequent monitoring finds that the database connection pool has become a bottleneck, it may trigger another rule to generate an initial control instruction to adjust the number of database connections.

[0163] This step uses a load balancer to analyze cache failure signals and real-time system load, automatically triggering preset rules and generating precise resource scheduling instructions. This achieves an automated closed loop from performance monitoring to resource adjustment, enabling dynamic and targeted allocation of key resources based on actual pressure, thereby improving resource utilization efficiency and system adaptability under high concurrency.

[0164] Step 105: Based on the target request stream, the cached result, and the resource scheduling instruction, perform collaborative processing on the user request in the target scenario.

[0165] In this step, the input target request stream and cached results are first paired and preprocessed using stream association and state binding techniques, while maintaining an internal processing context. Each user request marked in the target request stream is read sequentially. For each user request, based on its unique request identifier, a search is performed in the simultaneously received cached result stream to locate the corresponding cached result. This pairing operation associates the user's original request intent with its query status in the cache system. The system judges the cached result based on its content: if the cached result is target data, this data is packaged with the user request to form a final processing request with the existing data; if the cached result is a cache miss signal, only the user request itself, along with its marker and path, is packaged into a final processing request and marked as requiring backend processing. Secondly, conditional routing and asynchronous processing are used... The distribution technology sends different final processing requests to appropriate processing nodes. For final processing requests marked as requiring backend processing, the built-in routing table is queried based on the request tag type provided by the user request. This routing table defines which backend business processor cluster should be sent to different types of requests. Requests are asynchronously distributed to the specified backend business processors through message queues or remote procedure calls. Meanwhile, for final processing requests for which target data is already in the cache, this distribution step is skipped, and the response assembly stage is entered directly. During this process, resource scheduling instructions from upstream are monitored in real time. Once a valid resource scheduling instruction is received, it is immediately forwarded to the corresponding resource executor in the system. For example, the instruction to expand the cache server is sent to the cloud platform controller, and the instruction to adjust the weight is sent to the configuration management interface of the load balancer. This step realizes parallel processing and scheduling.

[0166] Then, for the dispatched requests, asynchronous callbacks and result aggregation techniques are used to collect backend processing results. A callback waiting item is maintained for each dispatched request. When the backend business processor completes the calculation, it returns the processing result to the collaborative processing module. When the collaborative processing module receives the result, it matches it with the corresponding waiting item. For requests that were previously cached, the target data itself is considered as the result of this request. Finally, through response assembly and streaming write-back techniques, the final response is generated and returned. The obtained results, whether from cached target data or from the processing results of the backend business processor, are encapsulated in a data format that the mini-program frontend can recognize, such as encapsulating it into a JSON object, to form the final response data. Then, through the network connection corresponding to the source of the user request, the final response data is streamed back to the mini-program frontend, completing the entire processing loop of this request.

[0167] For example, following the specific implementation of the previous step, firstly, the collaborative processing module of e-commerce platform A simultaneously receives the target request stream, the cached result stream, and a resource scheduling instruction requesting the addition of a cache server; secondly, collaborative processing begins. For user X's request, it is found that the cached result already contains order inventory data, so this data is directly packaged and prepared as part of the response; then, for user Y's request, the cached result already contains product details data, so it is also directly packaged; for user Z's request, the cached result is a miss signal, so user Z's request to query unpopular products is routed to the backend processor cluster that specializes in handling product queries based on its query type flag;

[0168] Meanwhile, the resource scheduling instructions for the two newly added cache servers are immediately sent to the cloud management platform for execution. After calculating user Z's request, the backend processor returns the details of the less popular products to the collaborative processing module. Finally, the collaborative processing module assembles user X's order inventory data, user Y's popular product details data, and user Z's less popular product details data into three complete response formats, and accurately returns them to the mini-program frontends of the three users through their respective network connections. Throughout the process, the new cache servers are quietly expanding in the background to cope with the potentially continuous high cache miss pressure.

[0169] This step integrates the target request stream, cached results, and resource scheduling instructions through the collaborative processing module to achieve closed-loop collaborative processing. This ensures extremely fast response to cache hit requests and accurate backend processing of cache miss requests, and drives dynamic resource optimization. Ultimately, it achieves stable, efficient, and resource-adaptive request processing capabilities in high-concurrency scenarios.

[0170] Figure 2 This application provides a schematic diagram of the structure of a high-concurrency request processing system for mini-programs, such as... Figure 2As shown, the system includes:

[0171] The receiving module 21 is used to receive high-concurrency user requests from the front end of the mini program to generate request feature information, which includes request path, timestamp and business type.

[0172] The identification module 22 is used to input the request feature information into a pre-trained traffic splitting model, identify the service type through the traffic splitting model, and mark the user request according to the identification result to obtain the target request flow;

[0173] Output module 23 is used to input the target request stream to a pre-trained cache decision module, determine the cache level corresponding to the user request based on the target request stream and the request path, process it, and output the cache result.

[0174] The generation module 24 is used to input the cached results and preset system load parameters to the load balancer, and generate resource scheduling instructions based on the number of miss signals in the cached results and the system load parameters.

[0175] Processing module 25 is used to collaboratively process user requests during peak traffic scenarios based on the target request stream, the cached results, and the resource scheduling instructions.

[0176] Figure 2 The aforementioned high-concurrency request processing system for mini-programs can execute... Figure 1 The implementation principle and technical effects of the high-concurrency request processing method for mini-programs described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit performs operations in the high-concurrency request processing system for mini-programs described in the above embodiments have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0177] In one possible design, Figure 2 The high-concurrency request processing system for a mini-program shown in the embodiment can be implemented as a computing device, such as... Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32;

[0178] The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are invoked and executed by the processing component 32.

[0179] The processing component 32 is used for the above Figure 1 The embodiment describes a method for handling high-concurrency requests in a mini-program.

[0180] The processing component 32 may include one or more processors to execute computer instructions to complete all or part of the steps in the above-described method. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method.

[0181] Storage component 31 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0182] Of course, computing devices may also include other components, such as input / output interfaces, display components, communication components, etc.

[0183] Input / output interfaces provide interfaces between processing components and peripheral interface modules, which can be output devices, input devices, etc.

[0184] The communication components are configured to facilitate wired or wireless communication between computing devices and other devices.

[0185] The computing device can be a physical device or an elastic computing host provided by a cloud computing platform. In this case, the computing device can refer to a cloud server, and the aforementioned processing components, storage components, etc., can be basic server resources rented or purchased from the cloud computing platform.

[0186] This application also provides a computer storage medium storing a computer program, which, when executed by a computer, can perform the above-described functions. Figure 1 The embodiment shown is a method for handling high-concurrency requests in a mini-program.

[0187] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0188] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0189] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0190] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for handling high-concurrency requests in a mini-program, characterized in that, include: Receive high-concurrency user requests from the mini-program frontend to generate request feature information, which includes request path, timestamp, and business type; The request feature information is input into a pre-trained traffic splitting model, which identifies the service type and marks the user request based on the identification result to obtain the target request flow. The target request stream is input into a pre-trained cache decision module, which determines the cache level corresponding to the user request based on the target request stream and the request path, processes it, and outputs the cache result. The cached results and preset system load parameters are input to the load balancer, and a resource scheduling instruction is generated based on the number of miss signals in the cached results and the system load parameters. Based on the target request stream, the cached results, and the resource scheduling instructions, the user requests in the target scenario are processed collaboratively.

2. The method according to claim 1, characterized in that, Receive high-concurrency user requests from the mini-program frontend to generate request feature information, which includes request path, timestamp, and business type, including: Obtain the raw request data stream initiated by the mini-program frontend in the target scenario; Extract the Uniform Resource Locator (URL) field contained in the user request from the original request data stream, and use it as the path identifier of the user request; Extract the time point data at which the user request is received by the system, and use it as the timestamp of the user request; The message of the user request is parsed to determine the business operation category corresponding to the user request, which is used as the business type of the user request; The path identifier, timestamp, and service type corresponding to the same user request are combined to generate a request feature record; Integrate all user request characteristic records to form request characteristic information.

3. The method according to claim 1, characterized in that, The request feature information is input into a pre-trained traffic splitting model. The traffic splitting model identifies the service type and marks the user request based on the identification result to obtain the target request flow, including: The business operation category contained in each request feature record in the request feature information is read through the traffic splitting model; The business operation category is matched with the set of predefined rules stored inside the traffic splitting model; Based on the matching results, the original user request that generated the request feature record is assigned a corresponding request tag type through the traffic splitting model to obtain the tagged user request. All the marked user requests are arranged and aggregated in their original receiving order to form the target request stream.

4. The method according to claim 1, characterized in that, The target request stream is input into a pre-trained cache decision module. Based on the target request stream and the request path, the cache level corresponding to the user request is determined and processed to output the cache result, including: Read the target request tag and target request path corresponding to each user request in the target request stream; Based on the target request tag, the allowed cache level range corresponding to the target request tag is searched in the hierarchical mapping relationship stored in the cache decision module; Within the allowed cache levels, the target request path of the user request is compared with the predefined path rules of each cache level to determine the target cache level that the user request matches. Based on the target cache level, access the corresponding cache area to obtain the target data corresponding to the user request; If the target data is obtained in the cache area, the target data is used as the cache result; if the target data is not obtained, a miss signal is generated as the cache result.

5. The method according to claim 1, characterized in that, The cached results and preset system load parameters are then input to the load balancer. Based on the number of misses in the cached results and the system load parameters, a resource scheduling instruction is generated, including: Count the total number of miss signals in the cached results received within the preset time window; The total number of missed signals is compared with a first preset threshold, the CPU utilization rate in the system load parameters is compared with a second preset threshold, and the memory usage is compared with a third preset threshold. Based on the comparison results, the preset resource scheduling rules are triggered; Based on the resource scheduling rules, a resource scheduling instruction is generated, wherein the resource scheduling instruction includes the direction and scale of resource adjustment.

6. The method according to claim 5, characterized in that, Based on the aforementioned resource scheduling rules, resource scheduling instructions are generated, including: Based on the predefined execution actions in the resource scheduling rules, the target resource type to be adjusted is determined, wherein the target resource type includes at least one of the following: number of cache servers, load balancer weight, and number of database connections. When the target resource type to be adjusted is the number of cache servers, a first initial instruction is generated according to the predefined adjustment value in the resource scheduling rules; When the target resource type to be adjusted is load balancer weight, an initial configuration instruction is generated according to the adjustment direction and adjustment value defined in the resource scheduling rules. When the target resource type to be adjusted is the number of database connections, an initial control command is generated according to the adjustment value defined in the resource scheduling rules. The first initial instruction, the initial configuration instruction, or the initial control instruction generated for the target resource type to be adjusted are combined to form a resource scheduling instruction.

7. The method according to claim 4, characterized in that, Within the allowed cache levels, the target request path of the user request is compared with the predefined path rules of each cache level to determine the target cache level that matches the user request, including: Obtain from the cache decision module the set of path rules associated with each cache level corresponding to the range of allowed cache levels; Within the allowed cache levels, the cache levels to be checked are selected sequentially according to a preset order. Each path matching pattern is retrieved sequentially from the set of path rules associated with the current cache level to be inspected; Perform a string matching operation between the target request path of the user request and the retrieved path matching pattern; If the target request path matches the path matching pattern, then the current cache level to be checked is determined as the target cache level. If the target request path fails to match any of the path matching patterns in the current cache level, the next cache level is selected as the new current cache level to be checked in the order described above, and the process of retrieving the path matching pattern and performing the matching operation is repeated until the target cache level is determined.

8. A high-concurrency request processing system for WeChat Mini Programs, characterized in that, include: The receiving module is used to receive high-concurrency user requests from the front end of the mini program to generate request feature information, which includes request path, timestamp and business type. The identification module is used to input the request feature information into a pre-trained traffic splitting model, identify the service type through the traffic splitting model, and mark the user request according to the identification result to obtain the target request flow; The output module is used to input the target request stream into the pre-trained cache decision module, determine the cache level corresponding to the user request based on the target request stream and the request path, process it, and output the cache result. The generation module is used to input the cached results and preset system load parameters to the load balancer, and generate resource scheduling instructions based on the number of miss signals in the cached results and the system load parameters; The processing module is used to collaboratively process user requests during peak traffic scenarios based on the target request stream, the cached results, and the resource scheduling instructions.

9. A computing device, characterized in that, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement a high-concurrency request processing method for a mini-program as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The device stores a computer program, which, when executed by a computer, implements a method for handling high-concurrency requests in a small program as described in any one of claims 1 to 7.

Images