Interface request processing method and device

Abstract

The invention provides an interface request processing method and device, and the method comprises the steps: obtaining a user request, analyzing the user request to obtain a dynamic parameter, generating a request identifier based on the dynamic parameter, determining whether the request identifier is unique or not, obtaining a business operation corresponding to the request identifier if the request identifier is unique, and carrying out the processing of the business operation based on a fine-grained distributed lock. And service operation execution is accelerated. Through the technical means of a dynamic weight parameter generation algorithm, a hybrid cache mechanism, a block chain evidence storage and smart contract, a fine-grained distributed lock, machine learning anomaly detection and the like, an efficient, safe and reliable interface repeated request prevention system is constructed, and the system is suitable for high-concurrency and high-security-requirement internet application scenarios.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed system security protection, and in particular to an interface request processing method and device. Background Art

[0002] In distributed systems, the problem of duplicate interface requests is becoming increasingly serious, leading to data redundancy, business logic errors, and wasted system resources. Existing mechanisms for preventing duplicate requests primarily rely on fixed parameter combinations to generate request identifiers. This static generation method can be easily predicted or bypassed by attackers, rendering it ineffective. Furthermore, many solutions rely on a single Redis cache. In extremely high-concurrency scenarios, network latency significantly impacts system response speed and processing power. Furthermore, the lack of integration with blockchain technology to ensure the global uniqueness and tamper-proof nature of request identifiers makes it difficult to ensure data integrity. Currently used distributed locking mechanisms are inefficient, prone to lock contention and resource waste, and reduce system stability. Summary of the Invention

[0003] In order to solve the above technical problems, the present invention is proposed. The embodiments of the present invention provide an interface request processing method and device, which can solve the problems of static parameter generation defects, storage performance bottlenecks, lack of global consistency, etc. in the prior art.

[0004] According to one aspect of the present invention, there is provided a method for processing an interface request, comprising:

[0005] Get user request;

[0006] Parsing the user request to obtain dynamic parameters;

[0007] Based on the dynamic parameters, generate a request identifier;

[0008] Determining whether the request identifier is unique;

[0009] If the request identifier is unique, obtain the business operation corresponding to the request identifier;

[0010] Based on fine-grained distributed locks, the business operations are accelerated.

[0011] In one embodiment, generating a request identifier based on the dynamic parameter includes:

[0012] Get the timestamp corresponding to the user request;

[0013] Determine the source code corresponding to the user request;

[0014] Calculate behavior buckets;

[0015] Calculate frequency buckets;

[0016] Generate random factors;

[0017] Obtaining the serial number requested by the user;

[0018] A request identifier is generated according to the timestamp corresponding to the user request, the source code corresponding to the user request, the behavior bucket, the frequency bucket, the random factor, and the serial number of the user request.

[0019] In one embodiment, accelerating the execution of the business operation based on fine-grained distributed locks includes:

[0020] Create a temporary sequence node in the target path;

[0021] Get all child nodes in the target path;

[0022] Based on the sorting sequence numbers of all the child nodes, determining whether the sequence number of the temporary sequence node is less than a preset sequence number threshold;

[0023] If the sequence number of the temporary sequence node is less than the preset sequence number threshold, a distributed lock is acquired;

[0024] Based on the distributed lock, the business operation is accelerated.

[0025] In one embodiment, the interface request processing method further includes:

[0026] If the sequence number of the temporary sequence node is greater than a preset sequence number threshold, monitoring the previous node of the temporary sequence node;

[0027] If the business operation of monitoring the previous node is completed, the previous node is deleted.

[0028] In one embodiment, before obtaining the service operation corresponding to the request identifier, the interface request processing method further includes:

[0029] Obtaining a memory cache and determining whether the memory cache is greater than a preset cache threshold;

[0030] If the memory cache is larger than a preset cache threshold, obtaining historical cache data;

[0031] If the access time of the historical cache data is greater than a preset time threshold, the historical cache data is deleted and the request identifier is cached.

[0032] In one embodiment, after caching the request identifier, the interface request processing method further includes:

[0033] Writing the request identifier into persistent storage;

[0034] Based on the detection rules, the persistent storage is detected;

[0035] If the detection result indicates that the persistent storage is available, the request identifier is stored and the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier are stored in the blockchain evidence node.

[0036] In one embodiment, storing the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier in the blockchain evidence storage node includes:

[0037] Determining whether the request identifier is legal;

[0038] If the request identifier is legal, verify the user request corresponding to the request identifier;

[0039] If the user request exists, determining whether the timestamp corresponding to the request identifier matches a preset timestamp threshold;

[0040] If the timestamp corresponding to the request identifier matches a pre-set timestamp threshold, the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier are stored in the blockchain evidence node.

[0041] In one embodiment, the interface request processing method further includes:

[0042] Performing feature extraction on the user request to obtain key features;

[0043] determining whether the key feature is missing a feature;

[0044] If the key feature is not missing, then obtain the abnormal probability corresponding to the user request based on the LSTM model;

[0045] If the abnormal probability is greater than a preset probability threshold, the user request is determined to be an abnormal request and an alarm signal is generated.

[0046] In one embodiment, after determining that the user request is an abnormal request and generating an alarm signal, the interface request processing method further includes:

[0047] Get multiple user requests;

[0048] Dividing the plurality of user requests into a training set and a validation set;

[0049] Based on the training set, the LSTM model is trained to obtain an output value;

[0050] Calculating a loss value based on the output value and the validation set;

[0051] Based on the loss value, the LSTM model is updated.

[0052] According to another aspect of the present invention, there is provided an interface request processing device, comprising:

[0053] Request acquisition module, used to obtain user requests;

[0054] A parsing module, configured to parse the user request to obtain dynamic parameters;

[0055] A generating module, configured to generate a request identifier based on the dynamic parameters;

[0056] A determination module, configured to determine whether the request identifier is unique;

[0057] An operation acquisition module, configured to acquire the business operation corresponding to the request identifier if the request identifier is unique;

[0058] The acceleration module is used to accelerate the execution of the business operation based on fine-grained distributed locks.

[0059] The interface request processing method and device provided by the present invention include: obtaining a user request, parsing the user request to obtain dynamic parameters, generating a request identifier based on the dynamic parameters, determining whether the request identifier is unique, and if so, obtaining the business operation corresponding to the request identifier; and accelerating the execution of the business operation based on fine-grained distributed locks. By utilizing a dynamic weight parameter generation algorithm, a hybrid caching mechanism, blockchain evidence storage and smart contracts, fine-grained distributed locks, and machine learning anomaly detection, an efficient, secure, and reliable system for preventing duplicate interface requests is constructed, suitable for high-concurrency, high-security internet application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.

[0061] Figure 1 It is a flowchart of an interface request processing method provided by an exemplary embodiment of the present invention.

[0062] Figure 2 It is a flowchart of a method for accelerating business operations provided by an exemplary embodiment of the present invention.

[0063] Figure 3 It is a flowchart of storing a request identifier provided by an exemplary embodiment of the present invention.

[0064] Figure 4 It is a flowchart of a storage method for storing business types in a blockchain evidence node provided by an exemplary embodiment of the present invention.

[0065] Figure 5 It is a flowchart of an alarm method provided by an exemplary embodiment of the present invention.

[0066] Figure 6 It is a flowchart of an interface request processing method provided by another exemplary embodiment of the present invention.

[0067] Figure 7 It is a structural diagram of an interface request processing device provided by an exemplary embodiment of the present invention.

[0068] Figure 8 is a structural diagram of an electronic device provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0069] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0070] Figure 1 It is a flowchart of an interface request processing method provided by an exemplary embodiment of the present invention.

[0071] like Figure 1 As shown, the interface request processing method includes:

[0072] Step 110: Obtain user request.

[0073] Step 120: Parse the user request to obtain dynamic parameters.

[0074] In this embodiment of the present invention, key information and dynamic parameters are extracted from the request sent by the user so that the system can understand and process the user's needs. During the parsing process, the server identifies dynamic parameters (including request source, frequency, historical behavior, business type, etc.) and converts this information into structured data to facilitate subsequent business logic processing.

[0075] Step 130: Generate a request identifier based on the dynamic parameters.

[0076] In an embodiment of the present invention, step 120 may include the following steps:

[0077] Step 131: Obtain the timestamp corresponding to the user request.

[0078] Step 132: Determine the source code corresponding to the user request.

[0079] Step 133: Calculate behavior buckets.

[0080] In this embodiment of the present invention, the target user corresponding to the user request is obtained, and the target user's gambling winning behavior score is obtained. The behavior score represents the system's historical score of the target user during their use of the system. Based on the behavior score, the target user's level is determined. Based on the target user's level, a behavior bucket is obtained. For example, if the behavior score is 7.2, the target user can be determined to be a VIP user based on the behavior score, and the behavior bucket selected is V.

[0081] Step 134: Calculate frequency buckets.

[0082] In this embodiment of the present invention, the request frequency corresponding to the user request is obtained. The request frequency level is determined, and frequency buckets are obtained based on the request frequency level. For example, if the request frequency is 85 times / minute, 85 times / minute corresponds to medium frequency, and the frequency bucket is M.

[0083] Among them, High Frequency: High Frequency, Medium Frequency: Medium Frequency, Low Frequency: Low Frequency. High Frequency corresponds to 100-90 beats / minute, Medium Frequency corresponds to 90-80 beats / minute, and Low Frequency corresponds to 80-0 beats / minute.

[0084] Step 135: Generate random factors.

[0085] In the embodiment of the present invention, a random factor is randomly generated, for example, a hexadecimal serial number (6d) may be randomly generated.

[0086] Step 136: Obtain the serial number requested by the user.

[0087] In an embodiment of the present invention, the number of times a user request is issued is determined, for example, the 42nd user request within the current millisecond.

[0088] Step 137: Generate a request identifier according to the timestamp corresponding to the user request, the source code corresponding to the user request, the behavior bucket, the frequency bucket, the random factor, and the serial number of the user request.

[0089] In an embodiment of the present invention, multi-dimensional dynamic parameters (including request source, frequency, historical behavior, business type, etc.) are used to generate a unique request identifier, and the parameter combination is optimized in real time through a machine learning model, so that the request identifier has unpredictable and anti-counterfeiting capabilities.

[0090] Step 140: Determine whether the request identifier is unique.

[0091] Step 150: If the request identifier is unique, obtain the business operation corresponding to the request identifier.

[0092] Step 160: Accelerate the execution of business operations based on fine-grained distributed locks.

[0093] In this embodiment, the present invention implements fine-grained distributed locks based on ZooKeeper, refining the lock granularity to a single business operation type, reducing lock contention, and improving system stability. Fine-grained distributed locks are used to control concurrent requests, refining the lock granularity to a single business operation type, improving the system's concurrent processing capabilities and ensuring stable operation in a high-concurrency environment.

[0094] The interface request processing method provided by the present invention includes: obtaining a user request, parsing the user request to obtain dynamic parameters, generating a request identifier based on the dynamic parameters, determining whether the request identifier is unique, and if so, obtaining the business operation corresponding to the request identifier; and accelerating the execution of the business operation based on fine-grained distributed locks. By utilizing a dynamic weight parameter generation algorithm, a hybrid caching mechanism, blockchain evidence storage and smart contracts, fine-grained distributed locks, and machine learning anomaly detection, an efficient, secure, and reliable system for preventing duplicate interface requests is constructed, suitable for high-concurrency, high-security internet application scenarios.

[0095] Figure 2 FIG. 1 is a flow chart of a method for accelerating business operations provided by an exemplary embodiment of the present invention. Figure 2 As shown, step 160 can be specifically implemented as follows: creating a temporary sequence node in the target path; obtaining all child nodes in the target path; determining whether the sequence number of the temporary sequence node is less than a preset sequence number threshold based on the sorting sequence numbers of all child nodes; if the sequence number of the temporary sequence node is less than the preset sequence number threshold, obtaining a distributed lock; and accelerating the execution of business operations based on the distributed lock.

[0096] In an embodiment of the present invention, in a distributed system, a temporary sequence node can be created in the target path to ensure the orderly execution of tasks. The system obtains all child nodes in the target path and determines whether the sequence number of the temporary sequence node is less than a preset sequence number threshold based on their sequence numbers. If the sequence number of the temporary sequence node is less than the threshold, the system acquires a distributed lock, thereby accelerating subsequent business operations. For example, in a task scheduling system, assuming that the target path is " / tasks", a temporary sequence node " / tasks / 000000001" is created. If the sequence number of the temporary sequence node is the smallest, the system acquires a distributed lock and quickly executes resource allocation and calculations related to the task, thereby improving overall processing efficiency.

[0097] In one embodiment, if the sequence number of the temporary sequence node is greater than a preset sequence number threshold, the previous node of the temporary sequence node is monitored; if the business operation of monitoring the previous node is completed, the previous node is deleted.

[0098] In an embodiment of the present invention, if the sequence number of a temporary sequence node is greater than a preset sequence number threshold, the system will start monitoring the previous node of the temporary sequence node. When the business operation of the monitored previous node is completed, the system will automatically delete the previous node to release resources and clean up the environment. For example, in a distributed task processing system, suppose the sequence number of the temporary sequence node is "000000005" and the preset threshold is "000000004". At this time, the system will monitor " / tasks / 000000004". Once the task corresponding to the node is completed, the system will delete " / tasks / 000000004" so that subsequent tasks can proceed smoothly. This mechanism ensures the orderliness of tasks and the efficiency of resource management.

[0099] Figure 3 FIG. 1 is a flow chart of a storage request identifier provided by an exemplary embodiment of the present invention. Figure 3 As shown, the interface request processing method can be specifically implemented as follows: obtaining the memory cache and determining whether the memory cache is greater than a preset cache threshold; if the memory cache is greater than the preset cache threshold, obtaining the historical cache data; if the access time of the historical cache data is greater than the preset time threshold, deleting the historical cache data and caching the request identifier.

[0100] In an embodiment of the present invention, when managing the memory cache, the system obtains the current memory cache and checks whether its size exceeds a preset cache threshold. If the current cache is larger than the threshold, the system will further obtain historical cache data and check whether the access time of these data exceeds the preset time threshold. If the access time of the historical cache data exceeds the threshold, the system will delete these expired historical cache data and cache the new request identifier for subsequent use. For example, the size of the memory cache is 150MB, and the preset threshold is 100MB. At this time, the system obtains the historical cache data and finds that the last access time of some records has exceeded the preset time threshold of 30 minutes, so it deletes these expired data and caches the current user's request identifier to optimize subsequent request processing and improve system performance.

[0101] In one embodiment, the interface request processing method can be specifically implemented as follows: writing the request identifier into persistent storage; detecting the persistent storage based on detection rules; if the detection result indicates that the persistent storage is available, storing the request identifier and storing the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier in the blockchain evidence node.

[0102] In an embodiment of the present invention, when processing a request identifier, the system writes the request identifier into persistent storage. Then, based on preset detection rules, the system detects the availability of persistent storage. If the detection result shows that persistent storage is available, the system will store the request identifier, and at the same time store the request identifier, the corresponding timestamp, and the corresponding business type together in the blockchain's evidence node to ensure the security and non-tamperability of the data. For example, in an online trading platform, after the user submits an order, the system writes the order ID (as a request identifier) ​​to the database and detects the availability of the database. After confirming that the database is operating normally, the system not only saves the order ID, but also records the order creation time and business type (such as "purchase"), and then stores this information in the blockchain for future auditing and tracing to ensure the transparency and authenticity of the transaction.

[0103] Among them, the availability judgment of persistent storage needs to be achieved through layered detection to ensure that data can be read and written safely. Detect the network connectivity corresponding to the user request, which includes detecting the IP port. If the delay of the IP port is less than the preset delay threshold and there is no packet loss, it is determined that the network connectivity corresponding to the user request is normal. The preset delay threshold can be 50 milliseconds. At the same time, detect the service process status corresponding to the user request, which includes, if the continuous running time of the key process corresponding to the user request is greater than the first preset time threshold, then determine that the service process status corresponding to the user request is normal. The first preset time threshold can be 5 minutes. At the same time, detect the disk space corresponding to the user request, which includes, if the remaining space of the disk space is greater than the preset capacity threshold of the total capacity, then determine that the disk space corresponding to the user request is normal. The preset capacity threshold can be 20%. At the same time, detect the read and write delay corresponding to the user request, which includes, if the average read and write delay corresponding to the user request is less than the second preset time threshold, then determine that the user's read and write IO throughput is normal. The second preset time threshold can be 10 milliseconds.

[0104] The present invention stores request identifiers through a hybrid cache mechanism, combines memory cache with persistent storage, and introduces a cache preheating mechanism, which effectively reduces the server load and reduces the consumption of system resources by repeated requests.

[0105] In addition, to load high-frequency request identifiers, the present invention also performs cache preheating. This is the process of proactively loading hot data into the cache before system startup or traffic surges, to avoid performance drops caused by cold starts. The current time period is determined. If the current time period matches a preset time period, the high-frequency request identifier is loaded. The preset time period is 2:00 AM to 4:00 AM.

[0106] Figure 4 This is a flowchart of a method for storing business types in a blockchain evidence storage node provided by an exemplary embodiment of the present invention. Figure 4 As shown, the interface request processing method can be specifically implemented as follows: determining whether the request identifier is legal; if the request identifier is legal, verifying the user request corresponding to the request identifier; if the user request exists, determining whether the timestamp corresponding to the request identifier matches a preset timestamp threshold; if the timestamp corresponding to the request identifier matches the preset timestamp threshold, storing the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier in the blockchain evidence node.

[0107] In an embodiment of the present invention, the present invention first confirms whether the request identifier is legal. If it is legal, the user request corresponding to the request identifier will be verified to ensure that the request exists. After confirming the existence of the user request, the system will check whether the timestamp corresponding to the request identifier matches the preset timestamp threshold. If the timestamps match, the system will store the request identifier, timestamp and corresponding business type in the blockchain's evidence node to ensure the security and immutability of the data. For example, in a payment system, when a user initiates a payment request, the system first verifies whether the payment request identifier (such as "payment ID") is legal. If the verification is successful, the system will check whether the payment request exists and confirm whether its timestamp is within the preset valid time range (for example, within 5 minutes). If the conditions are met, the system will store the payment ID, request time and business type (such as "payment") in the blockchain for subsequent audit and verification to ensure the validity and transparency of the transaction.

[0108] Figure 5 FIG. 1 is a flow chart of an alarm method provided by an exemplary embodiment of the present invention. Figure 5 As shown, the interface request processing method can be specifically implemented as follows: extracting features from the user request to obtain key features; determining whether the key features are missing features; if the key features are not missing features, obtaining the abnormality probability corresponding to the user request based on the LSTM model; if the abnormality probability is greater than a preset probability threshold, determining that the user request is an abnormal request and generating an alarm signal.

[0109] In an embodiment of the present invention, when processing a user request, the system first performs feature extraction to obtain key features of the request. Next, the system determines whether any of these key features are missing. If the key features are complete and present, the system uses a long short-term memory (LSTM) model to calculate the anomaly probability corresponding to the user request. If the calculated anomaly probability exceeds a preset probability threshold, the system determines the request as abnormal and generates a corresponding alarm signal for further security review and processing. For example, in an online banking system, when a user initiates a transaction request, the system extracts features such as the transaction amount, time, and location. If these features are complete, the system uses an LSTM model to analyze historical data and calculate the anomaly probability of the transaction. If this probability exceeds a preset threshold (e.g., 0.8), the system marks the transaction as suspicious and triggers an alarm. By using a machine learning model to detect abnormal request patterns in real time, employing an LSTM network structure to analyze the time series features of requests in real time, and continuously optimizing the model through an online learning mechanism, the accuracy and real-time performance of anomaly detection are improved, thereby enhancing the system's response speed. Furthermore, by avoiding duplicate requests and malicious attacks, the system's stable operation is ensured, improving user satisfaction and user experience. The LSTM (Long Short-Term Memory) model is a special type of recurrent neural network (RNN) used to process and predict time series data or sequence data.

[0110] In one embodiment, the interface request processing method can be specifically implemented as follows: obtaining multiple user requests; dividing the multiple user requests into a training set and a validation set; training the LSTM model based on the training set to obtain an output value; calculating a loss value based on the output value and the validation set; and updating the LSTM model based on the loss value.

[0111] In an embodiment of the present invention, when processing multiple user requests, the system first divides these requests into a training set and a validation set for model training and evaluation. Based on the training set, the system trains the LSTM model to obtain the corresponding output value. During the training process, the system uses the validation set to calculate the loss value of the model to evaluate the performance of the model. If the loss value does not meet the preset optimization standard, the system will update the LSTM model based on the calculated loss value to improve its accuracy and robustness. In order to achieve incremental training, the system can set a regular training time, such as every hour or every time a new request is received, and use the new user request data to continue training the model. This incremental training method can not only continuously optimize the model, but also adapt to changes in user behavior, ensuring that the model always maintains a high level of prediction accuracy and real-time performance.

[0112] Figure 6FIG. 1 is a flow chart of an interface request processing method provided by another exemplary embodiment of the present invention. Figure 6 As shown in the figure, user request parsing: After the client sends a request, the system receives and parses the request, extracts dynamic parameters, and generates a unique request identifier. Request identifier uniqueness verification: The system checks whether the generated request identifier is unique. If so, it proceeds to the next step. Cache management: The system retrieves the in-memory cache and determines whether it exceeds a preset threshold. If so, it checks the access time of historical cached data. If expired, it deletes and caches a new request identifier, then writes the request identifier to persistent storage. Persistent storage detection and blockchain evidence storage: The system checks the availability of persistent storage based on rules. If available, it stores the request identifier, along with its timestamp and transaction type, in a blockchain evidence node and verifies the legitimacy of the request identifier. Sequence node creation and distributed locks: A temporary sequence node is created in the target path, all child nodes are retrieved, and the sequence number is determined to be less than a preset threshold. If so, a distributed lock is acquired to accelerate business operations. Otherwise, the business operations of the previous node are monitored and, upon completion, the previous node is deleted. Anomaly detection: Feature extraction is performed on user requests to determine whether key features are missing. If not, an anomaly probability is calculated using an LSTM model. If the anomaly probability exceeds the preset threshold, the request is identified as abnormal and an alarm signal is generated. Model training and updating: The system obtains multiple user requests, divides them into training and validation sets, trains the LSTM model using the training set, calculates the output value and loss value, and updates the LSTM model based on the loss value.

[0113] Figure 7 FIG. 1 is a schematic diagram of the structure of an interface request processing device provided by an exemplary embodiment of the present invention. Figure 7 As shown, the interface request processing device includes: a request acquisition module 201, used to obtain user requests; a parsing module 202, used to parse the user requests to obtain dynamic parameters; a generation module 203, used to generate a request identifier based on the dynamic parameters; a determination module 204, used to determine whether the request identifier is unique; an operation acquisition module 205, used to obtain the business operation corresponding to the request identifier if the request identifier is unique; an acceleration module 206, used to accelerate the execution of the business operation based on fine-grained distributed locks.

[0114] In one embodiment, the generation module 203 can be specifically configured to: obtain the timestamp corresponding to the user request; determine the source code corresponding to the user request; calculate the behavior bucket; calculate the frequency bucket; generate a random factor; obtain the serial number of the user request; generate a request identifier based on the timestamp corresponding to the user request, the source code corresponding to the user request, the behavior bucket, the frequency bucket, the random factor, and the serial number of the user request.

[0115] In one embodiment, the acceleration module 206 can be specifically configured as follows: creating a temporary sequence node in the target path; obtaining all child nodes in the target path; determining whether the sequence number of the temporary sequence node is less than a preset sequence number threshold based on the sorting sequence numbers of all child nodes; if the sequence number of the temporary sequence node is less than the preset sequence number threshold, obtaining a distributed lock; and accelerating the execution of the business operation based on the distributed lock.

[0116] In one embodiment, the interface request processing device can be specifically configured as follows: if the sequence number of the temporary sequence node is greater than a preset sequence number threshold, then monitor the previous node of the temporary sequence node; if the business operation of monitoring the previous node is completed, then delete the previous node.

[0117] In one embodiment, before operating the acquisition module 205, the interface request processing device can be specifically configured to: obtain the memory cache and determine whether the memory cache is greater than a preset cache threshold; if the memory cache is greater than the preset cache threshold, obtain the historical cache data; if the access time of the historical cache data is greater than the preset time threshold, delete the historical cache data and cache the request identifier.

[0118] In one embodiment, the interface request processing device can be specifically configured to: write the request identifier into persistent storage; based on the detection rules, detect the persistent storage; if the detection result indicates that the persistent storage is available, store the request identifier and store the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier in the blockchain evidence node.

[0119] In one embodiment, the interface request processing device can be specifically configured to: determine whether the request identifier is legal; if the request identifier is legal, verify the user request corresponding to the request identifier; if the user request exists, determine whether the timestamp corresponding to the request identifier matches a preset timestamp threshold; if the timestamp corresponding to the request identifier matches the preset timestamp threshold, store the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier in the blockchain evidence node.

[0120] In one embodiment, the interface request processing device can be specifically configured as follows: performing feature extraction on the user request to obtain key features; determining whether the key features are missing features; if the key features are not missing features, obtaining the abnormality probability corresponding to the user request based on the LSTM model; if the abnormality probability is greater than a preset probability threshold, determining that the user request is an abnormal request and generating an alarm signal.

[0121] In one embodiment, the interface request processing device can be specifically configured to: obtain multiple user requests; divide the multiple user requests into a training set and a validation set; train the LSTM model based on the training set to obtain an output value; calculate a loss value based on the output value and the validation set; and update the LSTM model based on the loss value.

[0122] Figure 8 1 shows a block diagram of an electronic device according to an embodiment of the present application.

[0123] like Figure 8 As shown, the electronic device 10 includes one or more processors 11 and a memory 12.

[0124] The processor 11 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.

[0125] The memory 12 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may include, for example, read-only memory (ROM), a hard disk, a flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 11 may execute the program instructions to implement the interface request processing method of each embodiment of the present application described above and / or other desired functions. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0126] In one example, the electronic device 10 may further include an input device 13 and an output device 14 , and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0127] When the electronic device 10 is a stand-alone device, the input device 13 may be a communication network connector, configured to receive collected input signals from the first device and the second device.

[0128] In addition, the input device 13 may also include, for example, a keyboard, a mouse, and the like.

[0129] The output device 14 can output various information to the outside, including determined distance information, direction information, etc. The output device 14 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0130] Of course, to simplify, Figure 8 Only some of the components related to the present application in the electronic device 10 are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, the electronic device 10 may further include any other appropriate components according to specific application scenarios.

[0131] The computer program product may be written in any combination of one or more programming languages ​​to implement the program code for performing the operations of the embodiments of the present application, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0132] The computer-readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can, for example, include but is not limited to a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0133] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. An interface request processing method, characterized in that: include: Get user request; Parsing the user request to obtain dynamic parameters; Based on the dynamic parameters, generate a request identifier; Determining whether the request identifier is unique; If the request identifier is unique, obtain the business operation corresponding to the request identifier; Based on fine-grained distributed locks, the business operations are accelerated.

2. The interface request processing method according to claim 1, characterized in that: The generating a request identifier based on the dynamic parameter includes: Get the timestamp corresponding to the user request; Determine the source code corresponding to the user request; Calculate behavior buckets; Calculate frequency buckets; Generate random factors; Obtaining the serial number requested by the user; A request identifier is generated according to the timestamp corresponding to the user request, the source code corresponding to the user request, the behavior bucket, the frequency bucket, the random factor, and the serial number of the user request.

3. The interface request processing method according to claim 1, characterized in that: Accelerating the execution of the business operation based on fine-grained distributed locks includes: Create a temporary sequence node in the target path; Get all child nodes in the target path; Based on the sorting sequence numbers of all the child nodes, determining whether the sequence number of the temporary sequence node is less than a preset sequence number threshold; If the sequence number of the temporary sequence node is less than the preset sequence number threshold, a distributed lock is acquired; Based on the distributed lock, the business operation is accelerated.

4. The interface request processing method according to claim 3, characterized in that: Also includes: If the sequence number of the temporary sequence node is greater than a preset sequence number threshold, monitoring the previous node of the temporary sequence node; If the business operation of monitoring the previous node is completed, the previous node is deleted.

5. The interface request processing method according to claim 1, wherein: Before obtaining the business operation corresponding to the request identifier, the method further includes: Obtaining a memory cache and determining whether the memory cache is greater than a preset cache threshold; If the memory cache is larger than a preset cache threshold, obtaining historical cache data; If the access time of the historical cache data is greater than a preset time threshold, the historical cache data is deleted and the request identifier is cached.

6. The interface request processing method according to claim 5, characterized in that: After caching the request identifier, the method further includes: Writing the request identifier into persistent storage; Based on the detection rules, the persistent storage is detected; If the detection result indicates that the persistent storage is available, the request identifier is stored and the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier are stored in the blockchain evidence node.

7. The interface request processing method according to claim 6, characterized in that: The storing of the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier in the blockchain evidence storage node includes: Determining whether the request identifier is legal; If the request identifier is legal, verify the user request corresponding to the request identifier; If the user request exists, determining whether the timestamp corresponding to the request identifier matches a preset timestamp threshold; If the timestamp corresponding to the request identifier matches a pre-set timestamp threshold, the request identifier, the timestamp corresponding to the request identifier, and the business type corresponding to the request identifier are stored in the blockchain evidence node.

8. The interface request processing method according to claim 1, characterized in that: Also includes: Performing feature extraction on the user request to obtain key features; determining whether the key feature is missing a feature; If the key feature is not missing, then obtain the abnormal probability corresponding to the user request based on the LSTM model; If the abnormal probability is greater than a preset probability threshold, the user request is determined to be an abnormal request and an alarm signal is generated.

9. The interface request processing method according to claim 8, characterized in that: After determining that the user request is an abnormal request and generating an alarm signal, the method further includes: Get multiple user requests; Dividing the plurality of user requests into a training set and a validation set; Based on the training set, the LSTM model is trained to obtain an output value; Calculating a loss value based on the output value and the validation set; Based on the loss value, the LSTM model is updated.

10. An interface request processing device, characterized in that: include: Request acquisition module, used to obtain user requests; A parsing module, configured to parse the user request to obtain dynamic parameters; A generating module, configured to generate a request identifier based on the dynamic parameters; A determination module, configured to determine whether the request identifier is unique; An operation acquisition module, configured to acquire the business operation corresponding to the request identifier if the request identifier is unique; The acceleration module is used to accelerate the execution of the business operation based on fine-grained distributed locks.

Images