Big data-based api key traffic management method and system

Abstract

The invention belongs to the technical field of api key traffic management, and particularly relates to an api key traffic management method and system based on big data. Through fine management and dynamic adjustment of the user portrait and the request portrait, effective monitoring and optimization of API Key traffic use are realized, risk levels of different users can be accurately assessed through comprehensive consideration of long-term traffic use habits of the user portrait and short-term traffic change trends of the request portrait, and user experience is improved. According to the method, the risk early warning capability of the system is further enhanced by monitoring the flow use condition of the API Key in real time and triggering an alarm mechanism when the flow reaches a risk threshold value, and in addition, the risk early warning capability of the system is further improved. By dynamically adjusting the weight of the historical request success rate, the historical traffic usage and the historical request response time in the user portrait, the traffic resource quota required by the request under each priority sequence can be calculated more accurately, and refined dynamic allocation of traffic resources is realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of API key traffic management, and specifically relates to an API key traffic management method and system based on big data. Background Art

[0002] With the continuous development of Internet technology, the application of API interfaces is becoming more and more extensive. API keys are used as credentials for accessing API interfaces, so it is necessary to effectively manage and control the access traffic of API interfaces. By reasonably managing and controlling the traffic of API keys, the stability and security of API interfaces can be ensured, and problems such as interface crashes or data leaks caused by excessive traffic can be avoided. At the same time, the efficiency of API interface use and user experience can also be improved.

[0003] The API key traffic management method in the prior art is usually relatively simple, and often limits the flow by regularly setting a fixed traffic threshold. This method lacks flexibility and intelligence, and is difficult to dynamically adjust and optimize according to actual traffic usage. This will undoubtedly lead to waste or shortage of traffic resources, thereby affecting the stability of the API interface and user experience. Based on this, this solution provides an API key traffic management method based on big data, aiming to solve the above problems. Summary of the invention

[0004] The purpose of the present invention is to provide an API key traffic management method and system based on big data, which can dynamically adjust the allocation of traffic resources according to historical data in user portraits and request portraits to achieve intelligent traffic management.

[0005] The technical solution adopted by the present invention is as follows: A method for managing API key traffic based on big data, comprising: Collect API request data and store it in a pre-screened database, where the request data includes API identification information, request time, source IP address, request parameters, request path, and business data; Collect user information, and build a user profile and a request profile based on the user information and request data respectively; Formulate a flow limiting strategy based on the user profile and request profile, and perform differentiated flow limiting on different user profiles and request profiles; Differentiate request priorities according to the request profile, and dynamically allocate traffic resources according to the request priorities; Monitor the traffic usage of the API key in real time, and when the traffic reaches the preset risk threshold, trigger the alarm mechanism and increase the monitoring frequency of the API key simultaneously.

[0006] In a preferred embodiment, the step of collecting API request data includes: Get detailed information about API calls, including request method, HTTP status code, response time, and request header information; Preprocessing the request data to remove redundant information and noise data; Build a distributed database and perform distributed storage on the pre-processed request data.

[0007] In a preferred solution, the step of constructing a user profile and a request profile based on the user information and the request data, respectively, comprises: Obtain basic information about users, including registration time, login frequency, usage habits, and historical behavior data; Classify and label user information to form a user feature vector, and construct a user portrait based on the user feature vector; Obtaining user request data and extracting request features from the request data, including the number of requests, request success rate, and business data type; Classifying and labeling the request features to form a request feature vector, and constructing a request profile based on the request feature vector; The user feature vector and the request feature vector are correlated and analyzed to identify potential correlations between user behavior and request features.

[0008] In a preferred solution, the step of performing correlation analysis on the user feature vector and the request feature vector to identify potential correlations between user behavior and request features includes: Obtain the user's registration time and classify the user into new users and old users based on the user's registration time; When the user is a new user, no association analysis is performed on the new user, and the user profile of the new user is directly marked as low risk, and a quota of traffic usage rights is allocated; When the user is an old user, an association rule between the user portrait and the request portrait is constructed, and the matching degree between the behavior pattern of the old user and the request feature is identified according to the association rule; The higher the matching degree between the behavior pattern of the old user and the request feature, the more consistent the behavior pattern of the old user and the request feature.

[0009] In a preferred solution, the step of formulating a flow limiting strategy based on the user profile and the request profile, and performing differentiated flow limiting on different user profiles and request profiles includes: Obtain the matching degree between the user portrait and the associated portrait, and record it as the first condition parameter; Constructing a sample period, wherein the sample period includes a long-term period and a short-term period, and based on the historical traffic data, respectively calculating the average usage traffic and traffic peak of different user profiles and request profiles in the long-term period, and the traffic growth rate of different user profiles and request profiles in the short-term period; The average usage flow in the long-term period is recorded as the second condition parameter, the flow peak value in the long-term period is recorded as the third condition parameter, and the flow growth rate in the short-term period is recorded as the fourth condition parameter; According to the first condition parameter, the second condition parameter, the third condition parameter and the fourth condition parameter, risk assessment is performed on different user profiles and request profiles to obtain risk assessment values; According to the risk assessment value, user profiles and request profiles are divided into different risk levels, and traffic limits of different users are matched according to the risk levels; The higher the risk level, the lower the matching traffic limit.

[0010] In a preferred solution, the step of distinguishing request priorities according to the request profile and dynamically allocating traffic resources according to the request priorities includes: Obtaining the business data type in the request profile, and determining the importance level of the request according to the business data type; Sorting the importance levels to obtain a request priority sequence; When there are multiple request profiles under the same priority sequence, collect the historical request success rate, historical traffic usage and historical request response time in the user profile; According to the historical request success rate, historical traffic usage and historical request response time, the traffic resource quota required for the request under each priority sequence is calculated, and the traffic resources are dynamically allocated synchronously.

[0011] In a preferred solution, when dynamically allocating traffic resources, the dynamic weights of the historical request success rate, historical traffic usage, and historical request response time in the user profile are obtained, and the specific process is as follows: Obtaining initial weights of historical request success rate, historical traffic usage, and historical request response time in the user profile; Collect the current values ​​of the historical request success rate, historical traffic usage, and historical request response time, as well as the historical average values ​​of the historical request success rate, historical traffic usage, and historical request response time; Calculate the deviation rate between the current value and the historical average value of the historical request success rate, the historical traffic usage, and the historical request response time, and record them as the first adjustment parameter, the second adjustment parameter, and the third adjustment parameter respectively; The initial weights of the historical request success rate, historical traffic usage and historical request response time in the user portrait are adjusted based on the first adjustment parameter, the second adjustment parameter and the third adjustment parameter to obtain the dynamic weights of the historical request success rate, historical traffic usage and historical request response time in the user portrait.

[0012] In a preferred solution, the step of monitoring the traffic usage of the API key in real time, triggering an alarm mechanism when the traffic reaches a preset risk threshold, and simultaneously increasing the monitoring frequency of the API key includes: Get the real-time traffic of the API key and compare it with the preset risk threshold; When the real-time traffic is lower than the risk threshold, it indicates that the traffic usage of the current API key is in a safe state, and the API key is monitored at a normal monitoring frequency; When the real-time traffic exceeds or equals the risk threshold, an alarm mechanism is triggered, an alarm message is generated, and the alarm message is sent to a preset management terminal; Performing a difference operation on the real-time traffic and the risk threshold to obtain a risk difference, and then comparing the risk difference with a preset classification interval to match a corresponding risk level and a monitoring frequency corresponding to the risk level; There are multiple grading intervals, each of which corresponds to a monitoring frequency. The larger the risk difference is, the higher the matching risk level is, and the higher the corresponding monitoring frequency is.

[0013] The present invention also provides an API key traffic management system based on big data, using the above-mentioned API key traffic management method based on big data, including: A data collection module, which is used to collect API request data and store it in a pre-examination database, wherein the request data includes API identification information, request time, source IP address, request parameters, request path and business data; A portrait building module, the portrait building module is used to collect user information, and build a user portrait and a request portrait based on the user information and request data respectively; A flow limiting planning module, which is used to formulate a flow limiting strategy based on the user profile and the request profile, and to perform differentiated flow limiting on different user profiles and request profiles; A resource allocation module, the resource allocation module is used to distinguish request priorities according to the request profile, and dynamically allocate traffic resources according to the request priorities; The monitoring optimization module is used to monitor the traffic usage of the API key in real time, and when the traffic reaches a preset risk threshold, trigger an alarm mechanism and simultaneously increase the monitoring frequency of the API key.

[0014] And, an electronic device, the electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; Among them, the memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the above-mentioned big data-based API key traffic management method.

[0015] The technical effects achieved by the present invention are: The present invention realizes effective monitoring and optimization of API Key traffic usage through refined management and dynamic adjustment of user portraits and request portraits. By comprehensively considering the long-term traffic usage habits of user portraits and the short-term traffic change trends of request portraits, the present invention can accurately assess the risk levels of different users and formulate differentiated flow limiting strategies accordingly, which not only ensures the reasonable allocation of traffic resources, but also improves the stability and security of the system. At the same time, the present invention further enhances the risk warning capability of the system by real-time monitoring of API Key traffic usage and triggering an alarm mechanism when the traffic reaches the risk threshold. In addition, by dynamically adjusting the weights of historical request success rate, historical traffic usage and historical request response time in user portraits, the present invention can more accurately calculate the traffic resource quota required for requests under each priority sequence, thereby realizing refined dynamic allocation of traffic resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a schematic flow chart of the method of the present invention; Figure 2 It is a schematic diagram of the system module of the present invention; Figure 3 It is a schematic diagram of the structure of an electronic device of the present invention. DETAILED DESCRIPTION

[0017] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings.

[0018] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein, and those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0019] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure or characteristic that may be included in at least one implementation of the present invention. The phrase "in a preferred embodiment" that appears in different places in this specification does not refer to the same embodiment, nor is it a separate or selective embodiment that is mutually exclusive with other embodiments.

[0020] See also Figure 1 As shown, the present invention provides an API key traffic management method based on big data, including: S1. Collect API request data and store it in the pre-screened database, where the request data includes API identification information, request time, source IP address, request parameters, request path and business data; In step S1, during the process of managing the api key traffic, the API request data will be automatically collected and stored in a pre-screened database. During this process, the request data will record in detail key information including API identification information, request time, source IP address, request parameters, request path, and related business data, so as to facilitate the subsequent accurate management and analysis of traffic. By storing the request data, a comprehensive data foundation can be established to provide strong data support for subsequent steps such as portrait construction, flow control planning, resource allocation, and monitoring optimization. The step of collecting api request data includes: Get detailed information about API calls, including request method, HTTP status code, response time, and request header information; Preprocess the request data to remove redundant information and noise data; Build a distributed database and perform distributed storage on the pre-processed request data; Specifically, in the process of collecting API request data, first, obtain detailed information on the API interface call, including key data such as request method, HTTP status code, response time, and request header information. Secondly, preprocess the obtained request data in order to improve data quality. Specifically, it is necessary to remove redundant information and noise data to ensure data accuracy and availability. Then, build a distributed database in order to efficiently process and store a large amount of request data. Through distributed storage, the efficiency and reliability of data processing can be improved. Finally, store the preprocessed request data in the distributed database, which not only ensures data security, but also facilitates subsequent data analysis and processing.

[0021] S2. Collect user information, and build a user profile and a request profile based on the user information and request data respectively; In step S2, after the user's request data is collected, user information is also collected, and based on the user information and request data, a user portrait and a request portrait are respectively constructed. The user portrait can reflect the user's usage habits and preferences, while the request portrait can reveal the pattern and characteristics of the API request. The steps of respectively constructing the user portrait and the request portrait based on the user information and request data include: Obtain basic information about users, including registration time, login frequency, usage habits, and historical behavior data; Classify and label user information to form user feature vectors, and build user portraits based on the user feature vectors; Obtain the user's request data and extract request features from the request data, including the number of requests, request success rate, and business data type; Classify and label request features to form request feature vectors, and build request profiles based on the request feature vectors; Perform correlation analysis on the user feature vector and the request feature vector to identify the potential correlation between user behavior and request features; Specifically, in the process of constructing user portraits and request portraits, it is first necessary to obtain the user's basic information, which covers the user's registration time, login frequency, usage habits, and historical behavior data, and then conduct in-depth analysis and processing of the collected user information, and convert the user information into a user feature vector by classification and labeling. This process helps to simplify the user's complex information into an operational data form, thereby constructing an accurate user portrait. Thereafter, the user's request data is obtained, and request features are extracted from it. The request features include the number of requests (number of requests), the request success rate, and the type of business data involved (such as business payment type, business operation type, etc.), and then the extracted request features are further classified and labeled to form a request feature vector, which helps to convert complex request data into a structured form, so as to facilitate the construction of a clear request portrait. In addition, in this implementation, the user feature vector and the request feature vector are also correlated and analyzed, so as to identify the potential correlation between user behavior and request features, thereby providing data support for providing personalized services or product optimization.

[0022] Secondly, the steps of performing correlation analysis on the user feature vector and the request feature vector to identify the potential correlation between the user behavior and the request features include: Obtain the user's registration time and classify the user into new users and old users based on the user's registration time; If the user is a new user, no association analysis will be performed on the new user, and the new user's user profile will be directly marked as low risk, and a quota of traffic usage rights will be allocated; When the user is an old user, an association rule is constructed between the user profile and the request profile, and the matching degree between the old user's behavior pattern and the request characteristics is identified based on the association rule; Among them, the higher the matching degree between the old user's behavior pattern and the request characteristics, the more consistent the old user's behavior pattern and the request characteristics are; In the above, when analyzing the association between the user feature vector and the request feature vector, the user's registration time information is first obtained, and then the user is divided into two categories: new users and old users based on this time information. For individuals identified as new users, the association analysis step is not performed, but the user profile of the new user is directly marked as low risk, and a fixed traffic usage permission is assigned to them. For individuals identified as old users, a detailed user profile is constructed, and association rules are established between the request profile. The establishment of association rules is specifically to conduct in-depth mining and analysis of the user's historical behavior and request data through machine learning algorithms to find out the potential connection and rules between user behavior and request features, so as to more accurately predict the user's future request trends and needs. At the same time, according to the association rules, the matching degree between the behavior patterns of old users and the request characteristics can be identified. For example, the association rule can be "if the historical behavior of an old user frequently calls a certain API interface, and the call success rate is high, then the user profile of this old user is highly associated with the request profile of the API interface". Through such association rules, the usage preferences and request patterns of old users can be more detailed, thereby providing a more accurate decision-making basis for subsequent flow control planning, resource allocation, and monitoring optimization. In addition, in this process, if it is found that the matching degree between the behavior patterns of old users and the request characteristics is high, this usually means that there is a high similarity and consistency between the behavior patterns of old users and the request characteristics.

[0023] S3. Formulate a flow control strategy based on user profiles and request profiles, and perform differentiated flow control for different user profiles and request profiles; In step S3, the system will formulate corresponding flow limiting strategies based on the constructed user portraits and request portraits. Through these strategies, differentiated flow limiting can be performed on different user portraits and request portraits, thereby optimizing resource utilization efficiency while ensuring service quality. The flow limiting strategies are formulated based on user portraits and request portraits, and the steps of differentiated flow limiting for different user portraits and request portraits include: Obtain the matching degree between the user portrait and the associated portrait, and record it as the first condition parameter; Construct a sample period, where the sample period includes a long-term period and a short-term period, and based on the historical traffic data, calculate the average usage traffic and traffic peak of different user profiles and request profiles in the long-term period, as well as the traffic growth rate of different user profiles and request profiles in the short-term period; The average usage flow in the long-term period is recorded as the second condition parameter, the flow peak value in the long-term period is recorded as the third condition parameter, and the flow growth rate in the short-term period is recorded as the fourth condition parameter; According to the first condition parameter, the second condition parameter, the third condition parameter and the fourth condition parameter, risk assessment is performed on different user portraits and request portraits to obtain risk assessment values; Based on the risk assessment value, user profiles and request profiles are divided into different risk levels, and traffic limits for different users are matched based on the risk levels; Among them, the higher the risk level, the lower the matching traffic limit; Specifically, in order to effectively manage network traffic and ensure the stable operation of the service, the matching degree between the user portrait and the associated portrait is first obtained, and this matching degree is recorded as the first condition parameter. Then a sample period is constructed, which includes both long-term and short-term periods. Based on historical traffic data, the average usage traffic and traffic peak of different user portraits and request portraits in the long-term period are calculated respectively, and the traffic growth rate in the short-term period is also calculated. Then, the average usage traffic in the long-term period is recorded as the second condition parameter, the traffic peak in the long-term period is recorded as the third condition parameter, and the traffic growth rate in the short-term period is recorded as the fourth condition parameter. Thereafter, according to the first condition parameter, the second condition parameter, the third condition parameter and the fourth condition parameter, a detailed risk assessment is performed on different user portraits and request portraits to obtain a risk assessment value, wherein the calculation function of the risk assessment value is: , where represents the risk assessment value, , , and Respectively represent the weight factors of the first condition parameter, the second condition parameter, the third condition parameter and the fourth condition parameter, , , and They represent the first condition parameter, the second condition parameter, the third condition parameter and the fourth condition parameter respectively. According to the obtained risk assessment value, the user profile and the request profile will be divided into different risk levels. According to the risk level, the traffic limit of different users will be matched. Specifically, the higher the risk level, the greater the potential risk of the user or request. Therefore, a lower traffic limit will be matched to ensure the stability and fairness of the overall service. For example, for user profiles and request profiles with higher risk assessment values, more stringent flow limiting measures will be taken, such as reducing their traffic limit, increasing the frequency of traffic inspection, etc., to prevent potential abuse or abnormal traffic from impacting the system. At the same time, the traffic limit of each user profile and request profile will be dynamically adjusted according to historical data and real-time traffic conditions. The dynamic adjustment mechanism can ensure that when facing sudden traffic or changes in user behavior, it can respond quickly to maintain the stability and reliability of the service. In addition, the user profile and request profile will be updated and optimized regularly to reflect the latest changes in user behavior and request characteristics. This continuous update and optimization can ensure the accuracy and effectiveness of the flow limiting strategy, thereby providing users with a better service experience.

[0024] S4. Differentiate the request priorities based on the request profiles and dynamically allocate traffic resources based on the request priorities; In step S4, after the request profile is output, the priority of the request is distinguished according to the request profile. According to the priority of the request, traffic resources can be dynamically allocated to ensure that high-priority requests can obtain sufficient resources, while low-priority requests are appropriately restricted when resources are tight. The steps of distinguishing the priority of the request according to the request profile and dynamically allocating traffic resources according to the request priority include: Obtain the business data type in the request profile and determine the importance level of the request based on the business data type; Sort the importance levels to obtain a request priority sequence; When there are multiple request profiles under the same priority sequence, collect the historical request success rate, historical traffic usage, and historical request response time in the user profile; Calculate the traffic resource quota required for requests in each priority sequence based on historical request success rate, historical traffic usage, and historical request response time, and dynamically allocate traffic resources simultaneously; Specifically, when dynamically allocating traffic resources according to request priority, first, obtain the business data type information contained in the request profile, and judge the importance level of each request according to the characteristics and importance of different business data types. Here, taking online shopping as an example, the importance level of payment requests is usually higher than that of browsing product pages or other requests, because payment requests are directly related to the transaction completion and satisfaction of users. After the business data type of the request profile is determined, the importance levels of all requests can be systematically sorted to form an orderly request priority sequence. It is also necessary to further clarify that when there are multiple request profiles under the same priority sequence, key data such as historical request success rate, historical traffic usage, and historical request response time in each user profile are further collected. Then, based on the collected historical request success rate, historical traffic usage, and historical request response time, the traffic resource quota required for the request under each priority sequence is comprehensively calculated to ensure the rationality and efficiency of resource allocation. Finally, after calculating the traffic resource quota required for each request, the traffic resources are dynamically allocated synchronously to ensure that each request can obtain corresponding resource support according to its priority and actual needs, thereby optimizing the overall network traffic management and user experience.

[0025] Secondly, when dynamically allocating traffic resources, the dynamic weights of the historical request success rate, historical traffic usage, and historical request response time in the user profile are obtained. The specific process is as follows: Get the initial weights of the historical request success rate, historical traffic usage, and historical request response time in the user profile; Collect the current values ​​of historical request success rate, historical traffic usage, and historical request response time, as well as the historical average values ​​of historical request success rate, historical traffic usage, and historical request response time; Calculate the deviation rate between the current value and the historical average value of the historical request success rate, the historical traffic usage, and the historical request response time, and record them as the first adjustment parameter, the second adjustment parameter, and the third adjustment parameter respectively; The initial weights of the historical request success rate, the historical traffic usage, and the historical request response time in the user portrait are adjusted according to the first adjustment parameter, the second adjustment parameter, and the third adjustment parameter to obtain the dynamic weights of the historical request success rate, the historical traffic usage, and the historical request response time in the user portrait; Specifically, in the process of dynamic allocation of traffic resources, in order to more accurately optimize the resource allocation strategy, we first obtain the key indicators contained in the user portrait, namely the initial weights of the historical request success rate, historical traffic usage and historical request response time. This step is the basis of the entire dynamic allocation mechanism, ensuring that the starting data for subsequent calculations is accurate. Next, real-time data collection will be carried out, including obtaining the values ​​of the historical request success rate, historical traffic usage and historical request response time at the current moment, and extracting their historical average values. The data collection in this link is for subsequent comparative analysis to find the difference between the current value and the historical average value. After the data collection is completed, the calculation stage will be entered. The specific operation is to calculate the difference between the current value of the historical request success rate, historical traffic usage and historical request response time and their respective historical average values. The deviation rate of the historical request success rate is recorded as the first adjustment parameter, the deviation rate of the historical traffic usage is recorded as the second adjustment parameter, and the deviation rate of the historical request response time is recorded as the third adjustment parameter, and this is used as the prerequisite for subsequent weight adjustment. After that, the initial weights of the historical request success rate, historical traffic usage, and historical request response time in the user portrait can be finely adjusted based on the first adjustment parameter, the second adjustment parameter, and the third adjustment parameter. Through this dynamic adjustment mechanism, the dynamic weights of the three key indicators in the user portrait are finally obtained, where the adjustment formula of the dynamic weight is: , where Indicates adjustment of transition value. ( =1, 2, 3) represents the initial weights of historical request success rate, historical traffic usage, and historical request response time. represents the first adjustment parameter, the second adjustment parameter and the third adjustment parameter, and then the output adjustment transition value is input into the dynamic weight output function ( , where =1, 2, 3 represent the dynamic weights of historical request success rate, historical traffic usage and historical request response time), the dynamic weights of historical request success rate, historical traffic usage and historical request response time can be obtained. Taking the initial weight values ​​of historical request success rate, historical traffic usage and historical request response time as 0.5.0.2, 0.3, the first adjustment parameter as 0.1, the second adjustment parameter as 0.2, and the third adjustment parameter as 0.05 as an example, the specific adjusted transition value is: dynamic weight of historical request success rate = 0.5 + (0.5*0.1)=0.55, the dynamic weight of historical traffic usage = 0.2+(0.2*0.2)=0.24, the dynamic weight of historical request response time = 0.3+(0.3*0.05)=0.315. After the dynamic weight adjustment is completed, the adjusted dynamic weight can be used as the basis for the subsequent calculation of the traffic resource quota required for requests under each priority sequence. In this way, the allocation of traffic resources can be more scientific and reasonable, which can better meet the actual needs of users and improve the overall service quality and user experience.

[0026] S5. Monitor the traffic usage of the API key in real time, and trigger an alarm mechanism when the traffic reaches the preset risk threshold, and simultaneously increase the monitoring frequency of the API key; In step S5, real-time monitoring of the traffic usage of the API key is crucial to ensuring system security and stability. In this embodiment, the traffic usage of the API key is monitored in real time. Once it is detected that the traffic usage reaches a preset risk threshold, an alarm mechanism is triggered to promptly notify the management personnel. At the same time, in order to more accurately control the risk, the monitoring frequency of the API key is also increased synchronously to quickly respond to possible traffic anomalies. The steps of real-time monitoring of the traffic usage of the API key, triggering an alarm mechanism when the traffic reaches a preset risk threshold, and synchronously increasing the monitoring frequency of the API key include: Get the real-time traffic of the API key and compare it with the preset risk threshold; When the real-time traffic is lower than the risk threshold, it indicates that the traffic usage of the current API key is in a safe state, and the API key is monitored at a normal frequency; When the real-time traffic exceeds or equals the risk threshold, the alarm mechanism is triggered, an alarm message is generated, and the alarm message is sent to the preset management terminal; Perform difference calculation on real-time traffic and risk threshold to obtain risk difference, then compare the risk difference with the preset classification interval to match the corresponding risk level and the monitoring frequency corresponding to the risk level; There are multiple grading intervals, each of which corresponds to a monitoring frequency. The larger the risk difference, the higher the matching risk level, and the higher the corresponding monitoring frequency. Specifically, when monitoring the traffic usage of the API key in real time, first obtain the real-time traffic data of the API key, and compare and analyze it with the preset risk threshold in detail. When the real-time traffic data is lower than the preset risk threshold, it indicates that the current traffic usage of the API key is in a relatively safe state. At this time, the normal monitoring frequency will be maintained, and the API key will continue to be monitored routinely to ensure the stability and security of its usage. However, when the real-time traffic data exceeds or equals the preset risk threshold, the alarm mechanism will be triggered immediately, and detailed alarm information will be generated. The alarm information will be sent to the preset management end in time so that the relevant management personnel can quickly take countermeasures. In addition, the real-time traffic and the risk threshold will be accurately calculated to obtain a specific risk difference. Then, this risk difference will be compared with the preset multiple classification intervals one by one, so as to match the corresponding risk level and the monitoring frequency corresponding to the risk level. It is worth noting that the classification interval is set with multiple different levels, each of which corresponds to a specific monitoring frequency, and the larger the risk difference, the higher the risk level matched. Correspondingly, the corresponding monitoring frequency will also increase accordingly to ensure that the API can be monitored more closely in high-risk situations. The usage of keys can prevent potential security risks.

[0027] See also Figure 2 , an API key traffic management system based on big data, using the above-mentioned API key traffic management method based on big data, including: Data collection module: The data collection module is used to collect API request data and store it in the pre-examination database, where the request data includes API identification information, request time, source IP address, request parameters, request path and business data; A portrait building module, which is used to collect user information and build a user portrait and a request portrait based on the user information and request data respectively; The flow limiting planning module is used to formulate flow limiting strategies based on user profiles and request profiles, and to perform differentiated flow limiting for different user profiles and request profiles; Resource allocation module, which is used to distinguish request priorities based on request profiles and dynamically allocate traffic resources based on request priorities; The monitoring optimization module is used to monitor the traffic usage of the API key in real time, and trigger the alarm mechanism when the traffic reaches the preset risk threshold, and simultaneously increase the monitoring frequency of the API key.

[0028] In the above, the main function of the data collection module is to collect API request data and store these data in a pre-set database. Specifically, the request data covers multiple key information, including API identification information, specific time of the request, source IP address, parameters carried by the request, request path and related business data, etc. The main responsibility of the portrait construction module is to collect detailed information of users, and based on these user information and previously collected request data, build user portraits and request portraits respectively. The construction of user portraits and request portraits is to have a more comprehensive understanding of user behavior and request characteristics, and provide data support for the subsequent formulation of flow limiting strategies. The role of the flow limiting planning module is to formulate corresponding flow limiting strategies based on the user portraits and request portraits that have been constructed. Specifically, differentiated flow limiting processing will be performed according to the characteristics of different user portraits and request portraits to ensure the reasonable allocation and use of system resources. The function of the resource allocation module is to distinguish the priority of requests according to the request portraits, and dynamically allocate traffic resources according to these priorities. In this way, it can ensure that high-priority requests can obtain more resource support, thereby improving the overall performance and user experience of the system. The monitoring optimization module is responsible for real-time monitoring of the API The traffic usage of the API Key will be monitored. Once the traffic reaches the preset risk threshold, the alarm mechanism will be triggered immediately to remind the administrator to take corresponding measures. At the same time, the monitoring frequency of the API Key will be increased to detect and deal with potential risk issues in a more timely manner.

[0029] See also Figure 3 , an electronic device, the electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; Among them, the memory stores a computer program that can be executed by at least one processor, and the computer program is executed by at least one processor so that the at least one processor can execute the above-mentioned API key traffic management method based on big data.

[0030] The processor of the electronic device can be a central processing unit (CPU), a graphics processing unit (GPU) or a digital signal processor (DSP), etc. The memory can include a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash) or a hard disk, etc. In the specific implementation, the processor executes the computer program stored in the memory to realize the function of the API Key traffic management method based on big data. It is worth noting that the electronic device can be a server, a personal computer, a smart phone, a tablet computer and other types of computing devices, as long as it has a corresponding processor and memory and can run the above-mentioned computer program. In this way, the API Key traffic management method based on big data can be widely used in various electronic devices, thereby further improving the efficiency and accuracy of API Key traffic management. In addition, the electronic device can also include an operator, an input device and an output device. The operator can provide operation support for the processor. The input device can include a keyboard, a mouse, etc., for receiving user input instructions, and the output device can include a display, a printer, etc., for displaying processing results or printing related documents.

[0031] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, device, article or method including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, device, article or method. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the presence of other identical elements in the process, device, article or method including the element.

[0032] The above is only a preferred embodiment of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications should also be considered as the protection scope of the present invention. The structures, devices and operating methods not specifically described and explained in the present invention shall be implemented according to the conventional means in the art unless otherwise specified and limited.

Claims

1. A method for managing API key traffic based on big data, characterized by: include: Collect API request data and store it in a pre-screened database, where the request data includes API identification information, request time, source IP address, request parameters, request path, and business data; Collect user information, and build a user profile and a request profile based on the user information and request data respectively; Formulate a flow limiting strategy based on the user profile and request profile, and perform differentiated flow limiting on different user profiles and request profiles; Differentiate request priorities according to the request profile, and dynamically allocate traffic resources according to the request priorities; Monitor the traffic usage of the API key in real time, and when the traffic reaches the preset risk threshold, trigger the alarm mechanism and increase the monitoring frequency of the API key simultaneously.

2. According to the big data-based API key traffic management method of claim 1, it is characterized by: The step of collecting API request data includes: Get detailed information about API calls, including request method, HTTP status code, response time, and request header information; Preprocessing the request data to remove redundant information and noise data; Build a distributed database and perform distributed storage on the pre-processed request data.

3. According to the big data-based API key traffic management method of claim 1, it is characterized by: The step of respectively constructing a user portrait and a request portrait based on the user information and the request data comprises: Obtain basic information about users, including registration time, login frequency, usage habits, and historical behavior data; Classify and label user information to form a user feature vector, and construct a user portrait based on the user feature vector; Obtaining user request data and extracting request features from the request data, including the number of requests, request success rate, and business data type; Classifying and labeling the request features to form a request feature vector, and constructing a request profile based on the request feature vector; The user feature vector and the request feature vector are correlated and analyzed to identify potential correlations between user behavior and request features.

4. According to the big data-based API key traffic management method of claim 1, it is characterized by: The step of performing correlation analysis on the user feature vector and the request feature vector to identify potential correlation between user behavior and request features includes: Get the user's registration time and classify the user into new users and old users based on the user's registration time; When the user is a new user, no association analysis is performed on the new user, and the user profile of the new user is directly marked as low risk, and a quota of traffic usage rights is allocated; When the user is an old user, an association rule between the user portrait and the request portrait is constructed, and the matching degree between the behavior pattern of the old user and the request feature is identified according to the association rule; The higher the matching degree between the behavior pattern of the old user and the request feature, the more consistent the behavior pattern of the old user and the request feature.

5. According to the big data-based API key traffic management method of claim 4, it is characterized by: The step of formulating a flow limiting strategy based on the user portrait and the request portrait and performing differentiated flow limiting on different user portraits and request portraits includes: Obtain the matching degree between the user portrait and the associated portrait, and record it as the first condition parameter; Constructing a sample period, wherein the sample period includes a long-term period and a short-term period, and based on the historical traffic data, respectively calculating the average usage traffic and traffic peak of different user profiles and request profiles in the long-term period, and the traffic growth rate of different user profiles and request profiles in the short-term period; The average usage flow in the long-term period is recorded as the second condition parameter, the flow peak value in the long-term period is recorded as the third condition parameter, and the flow growth rate in the short-term period is recorded as the fourth condition parameter; According to the first condition parameter, the second condition parameter, the third condition parameter and the fourth condition parameter, risk assessment is performed on different user profiles and request profiles to obtain risk assessment values; According to the risk assessment value, user profiles and request profiles are divided into different risk levels, and traffic limits of different users are matched according to the risk levels; The higher the risk level, the lower the matching traffic limit.

6. According to the big data-based API key traffic management method of claim 1, it is characterized by: The step of distinguishing request priorities according to the request profile and dynamically allocating traffic resources according to the request priorities includes: Obtaining the business data type in the request profile, and determining the importance level of the request according to the business data type; Sorting the importance levels to obtain a request priority sequence; When there are multiple request profiles under the same priority sequence, collect the historical request success rate, historical traffic usage and historical request response time in the user profile; According to the historical request success rate, historical traffic usage and historical request response time, the traffic resource quota required for the request under each priority sequence is calculated, and the traffic resources are dynamically allocated synchronously.

7. The method for managing API key traffic based on big data according to claim 6 is characterized by: When dynamically allocating traffic resources, the dynamic weights of the historical request success rate, historical traffic usage, and historical request response time in the user profile are obtained. The specific process is as follows: Obtaining initial weights of historical request success rate, historical traffic usage, and historical request response time in the user profile; Collect the current values ​​of the historical request success rate, historical traffic usage, and historical request response time, as well as the historical average values ​​of the historical request success rate, historical traffic usage, and historical request response time; Calculate the deviation rate between the current value and the historical average value of the historical request success rate, the historical traffic usage, and the historical request response time, and record them as the first adjustment parameter, the second adjustment parameter, and the third adjustment parameter respectively; The initial weights of the historical request success rate, historical traffic usage and historical request response time in the user portrait are adjusted based on the first adjustment parameter, the second adjustment parameter and the third adjustment parameter to obtain the dynamic weights of the historical request success rate, historical traffic usage and historical request response time in the user portrait.

8. The method for managing API key traffic based on big data according to claim 1, characterized in that: The step of monitoring the traffic usage of the API key in real time, triggering an alarm mechanism when the traffic reaches a preset risk threshold, and simultaneously increasing the monitoring frequency of the API key includes: Get the real-time traffic of the API key and compare it with the preset risk threshold; When the real-time traffic is lower than the risk threshold, it indicates that the traffic usage of the current API key is in a safe state, and the API key is monitored at a normal monitoring frequency; When the real-time traffic exceeds or equals the risk threshold, an alarm mechanism is triggered, an alarm message is generated, and the alarm message is sent to a preset management terminal; Performing a difference operation on the real-time traffic and the risk threshold to obtain a risk difference, and then comparing the risk difference with a preset classification interval to match a corresponding risk level and a monitoring frequency corresponding to the risk level; There are multiple grading intervals, each of which corresponds to a monitoring frequency. The larger the risk difference is, the higher the matching risk level is, and the higher the corresponding monitoring frequency is.

9. An API key traffic management system based on big data, characterized by: The method for managing API key traffic based on big data according to any one of claims 1 to 8 comprises: A data collection module, which is used to collect API request data and store it in a pre-examination database, wherein the request data includes API identification information, request time, source IP address, request parameters, request path and business data; A portrait building module, the portrait building module is used to collect user information, and build a user portrait and a request portrait based on the user information and request data respectively; A flow limiting planning module, which is used to formulate a flow limiting strategy based on the user profile and the request profile, and to perform differentiated flow limiting on different user profiles and request profiles; A resource allocation module, the resource allocation module is used to distinguish request priorities according to the request profile, and dynamically allocate traffic resources according to the request priorities; The monitoring optimization module is used to monitor the traffic usage of the API key in real time, and when the traffic reaches a preset risk threshold, trigger an alarm mechanism and simultaneously increase the monitoring frequency of the API key.

10. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively coupled to the at least one processor; Wherein, the memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the big data-based API key traffic management method described in any one of claims 1 to 8.

Images