Risk identification method and device, equipment and storage medium

Abstract

The invention provides a risk identification method and device, equipment and a storage medium, and the method comprises the steps: responding to a risk identification request initiated for a target service request, and determining whether the target service request is marked with a security identifier or not; and under the condition that the target service request is marked with a security identifier, outputting a first risk identification result, the first risk identification result representing the target service request. Wherein the security identifier is labeled when risk prediction is carried out on the target service request and a first risk prediction result is determined, and the first risk prediction result is used for indicating that the target service request is predicted to have no risk. According to the scheme of the invention, on the basis of realizing risk identification for the business request, the access pressure of risk identification on the database can be reduced.

Description

Technical Field

[0001] The present application belongs to the field of risk control technology, and in particular, relates to a risk identification method, device, equipment and storage medium. Background Art

[0002] In the risk control scenario, the database of the business system will store the request records of business requests in real time, and use the "counting" method to limit the users, IPs and devices with high-frequency requests. For example, "intercept users who request more than 1,000 times in 10 minutes" and "verify IPs that request more than 5,000 times in 1 hour".

[0003] Obviously, if the database query request record is accessed every time a business request is initiated, the database will be subjected to a large number of accesses. Therefore, how to reduce the access pressure of the database on the basis of risk identification for business requests is a technical problem to be solved by this application. Summary of the invention

[0004] The purpose of this application is to provide a risk identification method, device, equipment and storage medium, which can reduce the access pressure of the database on the basis of implementing risk identification for business requests.

[0005] In order to achieve the above purpose, the embodiment of the present application is implemented as follows:

[0006] In a first aspect, a risk identification method is provided, comprising:

[0007] In response to a risk identification request initiated for a target business request, determining whether the target business request is marked with a security identifier;

[0008] When the target service request is marked with a security identifier, outputting a first risk identification result, wherein the first risk identification result is used to indicate that the target service request does not have any risk;

[0009] The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined. The first risk prediction result is used to indicate that it is predicted that there is no risk in the target business request.

[0010] In a second aspect, a risk identification device is provided, comprising:

[0011] An identification determination module, configured to respond to a risk identification request initiated for a target business request and determine whether the target business request is marked with a security identification;

[0012] A risk identification module, configured to output a first risk identification result when the target business request is marked with a security identifier, wherein the first risk identification result is used to indicate that there is no risk;

[0013] The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined, and the first risk prediction result is used to indicate that there is no risk.

[0014] In a third aspect, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is used by the processor to execute the method of the first aspect.

[0015] According to a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program implements the method according to the first aspect when executed by a processor.

[0016] This application can regularly predict the risks of target business requests. If it is predicted that there is no risk, the target business request will be marked with a security identifier. When it is necessary to access the database to identify the risks of the target business request, first determine whether the target business request is marked with a security identifier; if it is marked with a security identifier, it means that the target business request will not have risks in the future. At this time, it is chosen not to access the database for verification, but directly output the risk identification result that there is no risk, thereby reducing the burden on the database. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 This is a schematic diagram of the first flow chart of the risk identification method according to an embodiment of the present application.

[0019] Figure 2 A schematic diagram of determining the current cycle in the risk identification method according to an embodiment of the present application.

[0020] Figure 3 A schematic diagram of pre-storing risks for business requests using the risk identification method according to an embodiment of the present application.

[0021] Figure 4 This is a second flow chart of the risk identification method according to an embodiment of the present application.

[0022] Figure 5 This is a third flow chart of the risk identification method according to an embodiment of the present application.

[0023] Figure 6 This is a schematic diagram of a function that reflects the normal distribution probability in the risk identification method of an embodiment of the present application.

[0024] Figure 7 This is a fourth flow chart of the risk identification method according to an embodiment of the present application.

[0025] Figure 8 This is a fifth flow chart of the risk identification method of an embodiment of the present application.

[0026] Fig. 9 Schematic diagram of the structure of the risk identification device of the embodiment of the present application.

[0027] Fig.10 A schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] In the risk control scenario, the database of the business system will store the request records of business requests in real time. If the database query request records are accessed every time a business request is initiated, the database will be subject to a large number of accesses. In particular, from the perspective of results, a large part of these accesses are "invalid queries." Here, we take the example of "intercepting users who request more than 1,000 times in 10 minutes." The first 999 database query request records within 10 minutes will not be intercepted and can be regarded as "invalid queries."

[0029] In view of this, the present application aims to propose a risk identification scheme for business requests, which can regularly predict the risks of target business requests. If it is predicted that there is no risk, the target business request is marked with a security identifier. When it is necessary to access the database to identify the risks of the target business request, first determine whether the target business request is marked with a security identifier; if it is marked with a security identifier, it means that the target business request will not have risks in the future. At this time, it is chosen not to access the database for verification, but directly output the risk identification result that there is no risk, thereby reducing the burden on the database caused by the above-mentioned "invalid query".

[0030] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0031] On the one hand, an embodiment of the present application provides a risk identification method. Figure 1 The following is a flow chart of the risk identification method, which includes the following steps:

[0032] S102: In response to a risk identification request initiated for a target business request, determine whether the target business request is marked with a security identifier.

[0033] This embodiment is used to curb high-frequency submitted business requests, where the target business requests are initiated by the same user, or by the same IP, or by the same device. Correspondingly, risk identification refers to determining whether the number of requests for the target business request in the target period (such as the current period) exceeds the preset upper limit of the number of requests. If the number of requests exceeds the preset upper limit of the number of requests, it is determined that the target business request is at risk; if the number of requests does not exceed the preset upper limit of the number of requests, it is determined that the target business request is not at risk.

[0034] In one feasible example, this embodiment uses a sliding time window to determine the current cycle. Figure 2 As shown, assuming that the length of the sliding time window is 3 time periods, the sliding step is 1 time period, when the current sliding time window selects the K-1th, Kth and K+1th time periods, the K-1th, Kth and K+1th time periods belong to the current cycle; afterwards, when the sliding time window moves according to the sliding step, the Kth, K+1th and K+2th time periods are selected, and the Kth, K+1th and K+2th time periods belong to the current cycle. The size of the time period can be 1 day, 2 days, 1 hour, 2 hours, etc., which is not specifically limited here.

[0035] In addition, this embodiment will also periodically perform risk prediction on the target business request based on the request record of the target business request, that is, to predict whether the number of requests for the target business request exceeds the upper limit of the number of requests. If the risk prediction result indicates that there is no risk, the target business request is marked with a security identifier; if the risk prediction result indicates that there is a risk and the target business request is already marked with a security identifier, the security identifier that has been marked on the target business request is cleared. That is, this embodiment uses the security identifier to indicate that the most recent risk prediction result of the target business request does not have a risk.

[0036] The following is an exemplary introduction to the risk prediction method.

[0037] This embodiment can determine the dynamic linear relationship between the number of requests of the target business request and time according to the request record of the target business request, and perform risk prediction on the target business request according to the linear relationship.

[0038] Here, the first risk prediction result is defined as indicating that there is no risk in the predicted target business request, and the second risk prediction result is defined as indicating that there is no risk in the predicted target business request. The linear relationship is defined as: f(x)=ax+b; wherein x represents time, f(x) represents the number of requests for the target business request in the current cycle, a represents the slope, and b represents the intercept.

[0039] It should be understood that the slope a in the linear relationship reflects the changing trend of the request frequency of the target service request, so this embodiment determines the risk prediction result based on the slope a. That is:

[0040] If the slope a of the linear relationship is positive, it means that the request frequency of the target business request shows an increasing trend. At this time, it is further predicted whether the number of requests of the target business request exceeds the preset ratio of the upper limit of the number of requests based on the linear relationship. If the predicted number of requests of the target business request exceeds the preset ratio of the upper limit of the number of requests, it means that the probability of the number of requests of the target business request exceeding the upper limit of the number of requests in the future time period is relatively high, and the second risk prediction result is output at this time; conversely, if the predicted number of requests of the target business request does not exceed the preset ratio of the upper limit of the number of requests, it means that the probability of the number of requests of the target business request exceeding the upper limit of the number of requests in the future time period is relatively low, and the first risk prediction result is output at this time.

[0041] If the slope a of the linear relationship is negative, it means that the request frequency of the target business request shows a downward trend, and the probability that the number of target business requests exceeds the upper limit of the number of requests in the future time period is small. At this time, the first risk prediction result is output.

[0042] For ease of understanding, let's take the example of predicting that a target business request has risks. Figure 3 , Figure 3 (a) is a schematic diagram of the slope changing with time, where the target point corresponds to the time of the current cycle. Based on the above, if the slope of the target point is positive, it means that the request frequency of the target business request is increasing, reflecting the explosive growth trend of the number of target business requests; at this time, the linear relationship corresponding to the target point is as follows Figure 3 (b). Figure 3 The linear relationship shown in (b) shows intuitively that the number of target business requests exceeds the preset proportion (80%) of the upper limit of the number of requests in the remaining future time of the current cycle, and the second risk prediction result is output at this time.

[0043] It should be understood that the preset ratio is set in this embodiment to leave a certain margin of error for risk prediction. As long as the predicted number of requests exceeds the preset ratio of the upper limit of the number of requests, it can be determined that the predicted target business request has a risk. In practical applications, the upper limit of the number of requests and the preset ratio can be flexibly set according to actual needs, and no specific limitation is made here. However, it should be noted that if the preset ratio is a fixed value, such as 90%, when the upper limit of the number of requests is 100, as long as the predicted number of requests is close to 90 times, it is determined that there is a risk, that is, there is a margin of error of 10 times; when the upper limit of the number of requests is 1000, as long as the predicted number of requests is close to 900 times, it is determined that there is a risk, that is, there is a margin of error of 100 times. It can be seen that the larger the upper limit of the number of requests, the larger the margin of error for risk prediction, and too large a margin of error will lead to overly conservative risk prediction. To avoid this problem, this embodiment can set the preset ratio and the upper limit of the number of requests to be positively correlated, so that the preset ratio can be adaptively adjusted through the upper limit of the number of requests of the business request.

[0044] As an example, the functional relationship between the upper limit of the number of requests and the preset ratio is defined as: Among them, m represents the upper limit of the number of requests; j(m) represents the preset ratio; c and d represent coefficients, d is greater than or equal to 1, and c is flexibly set according to the value of d to ensure that j(m) is in a reasonable range.

[0045] In the above functional relationship, the larger the upper limit of the number of requests, the larger the corresponding preset ratio j(m), so that the fault tolerance space will not increase significantly with the increase of the upper limit of the number of requests. For example, when the upper limit of the number of requests is 10, the preset ratio is 70% and the fault tolerance space is 3; when the upper limit of the number of requests is 100, the preset ratio is 90% and the fault tolerance space is 10.

[0046] To this end, this embodiment can apply the above functional relationship to adaptively configure corresponding preset ratios for different service requests without manual intervention.

[0047] The above is an introduction to the principle of risk prediction. In practical applications, this embodiment determines when to perform risk prediction on the target risk request based on actual needs, and this specification does not make specific limitations. In one feasible example, risk prediction can be performed every time the target business request is initiated a certain number of times, such as performing risk prediction once every 10 times the target business request is initiated, performing risk prediction every 20 times the target business request is initiated, etc.; in another feasible example, risk prediction can be performed when the number of times the target business request is initiated in the current cycle reaches a certain proportion of the upper limit of the number of requests, such as performing risk prediction when the number of requests of the target business request reaches 60%, 65% and 70% of the upper limit of the number of requests, respectively.

[0048] Furthermore, based on the above, this embodiment uses the database of the business system to count and store the request records of all business requests (including target business requests) in real time to support risk prediction and risk identification. In addition, a cache space is further configured for the database to preheat the database data, namely:

[0049] If the cache space does not store the request record of the target service request, refer to Figure 4 As shown, based on the request records of the target business requests stored in the database, a risk prediction is performed on the target business request to update the risk prediction result; then, it is determined whether there is a risk in the updated risk prediction result; if there is no risk in the updated risk prediction result (the first risk prediction result), the target business request is marked with a security identifier, and the request records of the target business request stored in the database are synchronized to the cache space.

[0050] When the cache space stores the request record of the target business request, refer to Figure 5 As shown, based on the request records of the target business requests stored in the cache space, a risk prediction is performed on the target business request to update the risk prediction result; then, it is determined whether there is a risk in the updated risk prediction result; if there is a risk in the updated risk prediction result (the second risk prediction result), the security identifier marked on the target business request and the request record stored in the cache space for the target business request are cleared.

[0051] Based on the above design:

[0052] At the beginning, risk prediction is performed through the request records of the target business requests stored in the database. Once it is predicted that the target business request will not have risks in the future, the target business request will be marked with a security identifier, and the request records of the target business requests stored in the database will be synchronized to the cache space. Under the effect of the security identifier, for risk identification requests for target business requests, the default risk identification result that the target business request does not have risks is provided, thereby reducing access to the database; at the same time, subsequent risk prediction of the target business request is prioritized based on the request records of the target business request stored in the cache space, which also reduces access to the database.

[0053] In the subsequent stage, once the cache space predicts that the target business request has risks in the current cycle (approaching or exceeding the upper limit of the number of requests), the security identifier marked by the target business request and the request record of the target business request stored in the cache space are cleared. Without the role of the security identifier, for the risk identification request of the target business request, the request record of the target business request stored in real time in the database is used to complete the risk identification, so as to avoid omissions; at the same time, it returns to the beginning stage of risk prediction through the request record of the target business request stored in the database, forming a logical closed loop.

[0054] It should be noted that the request records of the cache space are synchronized from the database, so the cache space lags slightly behind the database. For example, the number of requests for the target business request can be counted as 100 times from the cache space, but the number of requests for the target business request can be counted as 120 times from the database. This lag in the cache space will lead to a blind spot problem of "when the cache space predicts that there is no risk in the target business request, it can be predicted through the database that there is a risk in the target business request." However, based on the foregoing, this embodiment uses a preset ratio of whether the upper limit of the number of requests is exceeded as a condition for predicting whether there is a risk. The setting of the preset ratio can predict the risk of the target business request with a certain margin in advance, which just solves the "blind spot" problem caused by the lag in the cache space.

[0055] S104: When the target business request is marked with a security identifier, a first risk identification result is output, where the first risk identification result is used to indicate that the target business request does not have any risk.

[0056] The security identifier of this embodiment is used to indicate that the most recent risk prediction result of the target business request does not contain any risk.

[0057] After receiving the risk identification request, if the target business request is marked with a security flag, it means that in the current cycle, the target business request will not exceed the upper limit of the number of requests immediately according to the current trend. At this time, the first risk identification result can be directly output without accessing the database, thereby reducing the pressure on the database.

[0058] In addition, after receiving the risk identification request, if the target business request is not marked with a security logo, it means that in the current cycle, the target business request may soon or has exceeded the upper limit of the number of requests according to the current trend. At this time, query the database for the real-time request record of the target business request to determine whether the number of requests of the target business request exceeds the upper limit of the number of requests in the current cycle. If the number of requests of the target business request does not exceed the upper limit of the number of requests in the current cycle, the first risk identification result (used to indicate that there is no risk) is output; if the number of requests of the target business request exceeds the upper limit of the number of requests in the current cycle, the second risk identification result (used to indicate that there is a risk) is output.

[0059] Based on the above content, it can be known that the method of this embodiment predicts the risk of the target business request based on the request record of the target business request. Among them, when the cache space of the database stores the request record of the target business request, the request record in the cache space is queried first to predict the risk of the target business request; if the cache space does not store the request record of the target business request, the database will be queried to predict the risk of the target business request, that is, the access pressure of the risk prediction on the database is shared by the cache space. On the basis of the above, a security identifier is further introduced to characterize that the most recent risk prediction result of the target business request does not have a risk. When it is necessary to perform risk control on the target business request, if the target business request is currently marked with a security identifier, it means that there is no risk in the near future time. At this time, the risk identification result that the target business request does not have a risk can be directly output; if the target business request is not currently marked with a security identifier, it means that there may be a risk or there is already a risk in the near future time. At this time, the database is selected to determine the risk identification result of the target business request. It can be seen that the method of this embodiment will access the database only when the target business request is not stored in the cache space and risk prediction of the target business request is required, and when the target business request is not marked with a security identifier. On the basis of realizing risk identification for the target business request, the burden on the database is greatly reduced.

[0060] It can be seen that this embodiment, when identifying risks for target business requests, decides whether to access the database based on the security identifier. Therefore, a non-cached hard disk space can be used to record in real time whether the target business request is marked with a security identifier. Even if the cache space loses the request record of the target business request due to a machine restart, it is possible to determine whether to access the database based on whether the hard disk space records the security identifier. In the subsequent process, it is also possible to use the risk prediction mechanism of the database to decide whether to re-synchronize the request record of the target business request to the cache space. In other words, data loss in the cache space will not affect the entire solution.

[0061] It should be understood that the method of this embodiment can be applied to other service requests in the service system. That is, the database and cache space will also store request records of other service requests except the target service request.

[0062] On the basis of the above, taking into account the problem of cache space lag, this embodiment can also randomly extract a portion of business requests from the cache space periodically based on preset rules (such as selecting business requests that account for 10% of the total traffic in the cache space) to re-predict risks based on the request records stored in real time in the database, thereby correcting the security identification of these randomly extracted business requests based on the re-determined risk prediction results.

[0063] Here, the target business request is taken as an example. When the randomly selected business request includes the target business request, the risk prediction result of the target business request can be updated based on the request record of the target business request stored in real time in the database. If there is a risk in the updated risk prediction result (the second risk prediction result), the security identification of the target business request and its corresponding request record in the cache space are cleared to avoid the security identification being retained and misleading the subsequent risk identification.

[0064] It should be noted that, in this embodiment, whenever a request record of a business request is queried from the database to re-perform risk prediction, as long as the risk prediction result of the business request indicates that there is no risk (the first risk prediction result), the request record of the business request queried from the database can be synchronously updated to the cache space. In actual applications, there may be too few request records for certain business requests in the cache space, resulting in the slope of the linear relationship cannot be determined or the determined slope is inaccurate. For business requests with too few request records in these cache spaces (for example, less than 3 request records), the probability of them being randomly selected for re-risk prediction can be appropriately increased, so as to replenish the request records of the cache space through the database as soon as possible.

[0065] As an exemplary introduction, this embodiment can determine the probability of each business request being randomly selected through the normal distribution probability of the request records of each business request stored in the cache space; that is, the normal distribution probability of any business request is negatively correlated with the number of request records of the business request in the cache space. Afterwards, at least one business request is randomly selected from each business request according to the normal distribution probability to re-update the risk prediction result through the database.

[0066] Here, considering that two points determine a straight line of a linear relationship, the straight line determined by three points is more accurate, and the function of the normal distribution probability can be defined as: Where p represents the number of request records, and o(p) represents the normal distribution probability.

[0067] The function graph of the above normal distribution probability is as follows Figure 6 As shown. For any business request, when the number of request records is between 1 and 3, the corresponding normal distribution probability is significantly higher than that in other intervals. After the number of request records is greater than 3, the corresponding normal distribution probability drops rapidly and approaches a certain value. In other words, taking the normal distribution probability as the probability of random extraction, business requests with only 1 to 3 request records in the cache space can be randomly extracted with a greater probability. After the number of requests continues to increase, its probability is basically the same as that of other business requests with more than 3 request records.

[0068] It should be noted that this embodiment can also be combined with other mechanisms for random sampling to avoid the random sampling method being too limited, and no further examples will be given here.

[0069] The method of this embodiment is introduced below in combination with actual application scenarios.

[0070] In this application scenario, the business system configures an open source search engine (Elastic Search, ES) database to count and store the request records of each user's business requests in real time. Correspondingly, redis is the message queue where ES stores database preheating data, which is the cache space in this article.

[0071] Assume that the business system divides business requests by user, that is, each user corresponds to a business request. Here, the business request initiated by the target user is defined as the target business request. When the target user initiates the target business request, the corresponding process of the business system is as follows: Figure 7 As shown, including:

[0072] 1. Receive a risk identification request submitted by a terminal device for a target business request.

[0073] The target service request is initiated by a target user of the terminal device.

[0074] 2. Determine whether the target service request is currently marked with a security token; if yes, execute step 3; if no, execute step 3'.

[0075] 3. Directly feed back to the terminal device the risk identification result that there is no risk in this target business request.

[0076] 3'. Query the database for the request record of the target business request in the current cycle to determine the risk identification result of the target business request (there may be a risk or there may not be a risk), and feed back the risk identification result to the terminal device.

[0077] In this application scenario, if the risk identification result received by the terminal device of the target user indicates that there is a risk, all subsequent target service requests initiated by the target user in the current cycle are intercepted.

[0078] Here, it is assumed that the target business request is marked with a token and the risk identification result does not contain any risk. Figure 8 As shown, further comprising:

[0079] 1. Randomly extract some business requests (including target business requests) from the cache space.

[0080] 2. Query the database for the request records of the target business request in the current cycle to make a risk prediction for the remaining future time of the target business request in the current cycle.

[0081] It should be noted that in this step, the database will also be queried for other randomly selected business requests in the current cycle to perform risk prediction, which will not be detailed here one by one.

[0082] 3. According to the risk prediction result, determine whether the target business request is predicted to have risks; if yes, execute step 4'; if no, execute step 4;

[0083] 4'. Clear the token requested by the target business and the request record of the target business stored in the cache space.

[0084] 4. Synchronize the request record of the target business request queried from the database to the cache space; then, assuming that the target business request is randomly extracted from the cache space, continue to execute:

[0085] 5. Query the cache space again for the request record of the target business request to perform risk prediction on the target business request.

[0086] 6. Based on the latest risk prediction result, determine whether the target business request is predicted to have risks; if yes, execute step 7'; if no, execute step 7.

[0087] 7'. Clear the token of the target business request and the request record of the target business in the cache space.

[0088] 7. Synchronize the request record of the target business request most recently queried from the database to the cache space.

[0089] The above application scenarios are exemplary introductions to the method of this embodiment. As other feasible solutions, after determining that the target service request has risks through risk identification, the terminal device can also handle it by verifying the user, reducing user permissions, etc., which will not be described one by one in this article.

[0090] It has been verified in practice that the solution of this application scenario can reduce nearly 60% of "invalid query" requests for the database, greatly improving the access pressure of the database.

[0091] Corresponds to Figure 1 In addition to the method shown, another embodiment of the present application also provides a risk identification device. Fig. 9 : is a schematic diagram of the structure of the risk identification device 900, comprising:

[0092] The identification determination module 910 is used to determine whether the target business request is marked with a security identification in response to a risk identification request initiated for the target business request.

[0093] The risk identification module 920 is used to output a first risk identification result when the target business request is marked with a security identifier, wherein the first risk identification result is used to indicate that there is no risk in the target business request.

[0094] The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined. The first risk prediction result is used to indicate that it is predicted that there is no risk in the target business request.

[0095] The device of this embodiment regularly predicts the risk of the target business request, and if it is predicted that there is no risk, the target business request is marked with a security identifier. When it is necessary to access the database to identify the risk of the target business request, it is first determined whether the target business request is marked with a security identifier; if it is marked with a security identifier, it means that the target business request will not have any risk in the future. At this time, it is chosen not to access the database for verification, but directly output the risk identification result that there is no risk, thereby reducing the burden on the database.

[0096] Optionally, the risk identification module 920 of this embodiment is also used to: when the cache space of the database does not store the request record of the target business request, perform risk prediction on the target business request based on the request record of the target business request stored in the database; if the risk prediction result is the first risk prediction result, synchronize the request record of the target business request stored in the database to the cache space.

[0097] Optionally, the risk identification module 920 of this embodiment is also used to: if the risk prediction result is a second risk prediction result, clear the security identifier marked by the target business request and the request record of the target business request stored in the cache space; the second risk prediction result is used to indicate that the target business request is predicted to have a risk.

[0098] Optionally, the risk identification module 920 performs risk prediction on the target business request, including: determining the linear relationship between the number of requests of the target business request and time based on the request record of the target business request; when the slope of the linear relationship is positive, predicting whether the number of requests of the target business request exceeds a preset proportion of an upper limit of the number of requests based on the linear relationship; if the number of requests of the target business request does not exceed the preset proportion of the upper limit of the number of requests, outputting the first risk prediction result; if the number of requests of the target business request exceeds the preset proportion of the upper limit of the number of requests, outputting the second risk prediction result.

[0099] Optionally, the risk identification module 920 of this embodiment is also used to: when the target business request is not marked with a security identifier, determine whether the target business request exceeds the upper limit of the number of requests in the current cycle based on the request record of the target business request stored in the database; if the target business request exceeds the upper limit of the number of requests within the target cycle, output a first risk identification result; if the target business request does not exceed the upper limit of the number of requests within the target cycle, output a second risk identification result; the second risk identification result is used to indicate that the target business request is at risk.

[0100] Optionally, the preset ratio is positively correlated with the upper limit of the number of requests.

[0101] Optionally, the risk identification module 920 of this embodiment is also used to: extract at least one business request in the cache space based on preset rules; and perform risk prediction on at least one business request based on the request record of the at least one business request stored in the database.

[0102] Optionally, the risk identification module 920 extracts at least one business request from the cache space based on preset rules, including: determining the normal distribution probability of each business request based on the request records of each business request stored in the cache space; wherein the normal distribution probability of any business request is negatively correlated with the number of request records of the business request in the cache space; and extracting at least one business request from each business request according to the normal distribution probability.

[0103] It should be understood that the risk identification device of this embodiment can be used as Figure 1 The execution subject of the method shown can thus realize the Figure 1 The steps and functions of the method shown are not repeated here for illustration because the principles are the same.

[0104] In the case of configuring the database and cache space, the device of this embodiment can perform risk prediction on the target business request based on the request record of the target business request. Among them, when the cache space of the database stores the request record of the target business request, the request record in the cache space is queried first to perform risk prediction on the target business request; if the cache space does not store the request record of the target business request, the database will be queried to perform risk prediction on the target business request, that is, the access pressure of risk prediction on the database is shared by the cache space. On the basis of the above, a security identifier is further introduced to characterize that the most recent risk prediction result of the target business request does not have risk. When it is necessary to perform risk control on the target business request, if the target business request is currently marked with a security identifier, it means that there is no risk in the near future time. At this time, the risk identification result that the target business request does not have risk can be directly output; if the target business request is not currently marked with a security identifier, it means that there may be risks or there are risks in the near future time. At this time, the database is selected to determine the risk identification result of the target business request. It can be seen that the method of this embodiment will access the database only when the target business request is not stored in the cache space and risk prediction of the target business request is required, and when the target business request is not marked with a security identifier. On the basis of realizing risk identification for the target business request, the burden on the database is greatly reduced.

[0105] Fig.10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig.10 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0106] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0107] The memory is used to store the computer program. Specifically, the computer program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides the computer program to the processor.

[0108] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming the above-mentioned Fig. 9 Correspondingly, the processor executes the program stored in the memory and is specifically used to perform the following operations:

[0109] In response to a risk identification request initiated for a target service request, it is determined whether the target service request is marked with a security identifier.

[0110] In the case where the target service request is marked with a security identifier, a first risk identification result is output, where the first risk identification result is used to indicate that there is no risk in the target service request.

[0111] The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined. The first risk prediction result is used to indicate that it is predicted that there is no risk in the target business request.

[0112] The electronic device of this embodiment regularly predicts the risk of the target business request, and if it is predicted that there is no risk, the target business request is marked with a security identifier. When it is necessary to access the database to identify the risk of the target business request, it is first determined whether the target business request is marked with a security identifier; if it is marked with a security identifier, it means that the target business request will not have any risk in the future. At this time, it is chosen not to access the database for verification, but directly output the risk identification result that there is no risk, thereby reducing the burden on the database.

[0113] It should be understood that the electronic device of this embodiment can be used as Figure 1 The execution subject of the method shown can thus realize the Figure 1 The steps and functions of the method shown.

[0114] The risk identification method disclosed in the above-mentioned embodiment as shown in this specification can be applied to a processor and implemented by the processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0115] Of course, in addition to software implementation, the electronic device of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0116] In addition, the present application also provides a computer-readable storage medium, which stores one or more computer programs, wherein the one or more computer programs include instructions. When the instructions are executed by a portable electronic device including multiple application programs, the portable electronic device can execute Figure 1 The steps of the method shown include:

[0117] In response to a risk identification request initiated for a target service request, it is determined whether the target service request is marked with a security identifier.

[0118] In the case where the target service request is marked with a security identifier, a first risk identification result is output, where the first risk identification result is used to indicate that there is no risk in the target service request.

[0119] The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined. The first risk prediction result is used to indicate that it is predicted that there is no risk in the target business request.

[0120] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0121] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0122] The above are only embodiments of this specification and are not intended to limit this specification. For those skilled in the art, this specification may be subject to various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims of this specification. In addition, all other embodiments obtained by ordinary technicians in this field without creative work shall fall within the scope of protection of this document.

Claims

1. A risk identification method, characterized in that: include: In response to a risk identification request initiated for a target business request, determining whether the target business request is marked with a security identifier; When the target service request is marked with a security identifier, outputting a first risk identification result, wherein the first risk identification result is used to indicate that the target service request does not have any risk; The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined. The first risk prediction result is used to indicate that it is predicted that there is no risk in the target business request.

2. The method according to claim 1, characterized in that Also includes: In a case where the cache space of the database does not store the request record of the target service request, performing risk prediction on the target service request based on the request record of the target service request stored in the database; If the risk prediction result is the first risk prediction result, the request record of the target business request stored in the database is synchronized to the cache space.

3. The method according to claim 1 or 2, characterized in that: Also includes: In a case where the cache space stores a request record of the target service request, performing risk prediction on the target service request based on the request record of the target service request stored in the cache space; If the risk prediction result is the second risk prediction result, clearing the security identifier marked by the target business request and the request record of the target business request stored in the cache space; The second risk prediction result is used to indicate that it is predicted that there is a risk in the target business request.

4. The method according to claim 3, characterized in that: The risk prediction of the target business request includes: Determine, based on the request record of the target service request, a linear relationship between the number of requests of the target service request and time; In the case where the slope of the linear relationship is positive, predicting whether the number of requests for the target service request exceeds a preset proportion of an upper limit of the number of requests based on the linear relationship; If the number of requests for the target business request does not exceed the preset ratio of the upper limit of the number of requests, outputting the first risk prediction result; If the number of requests for the target business request exceeds a preset proportion of the upper limit of the number of requests, the second risk prediction result is output.

5. The method according to claim 4, characterized in that: Also includes: In the case where the target service request is not marked with a security identifier, determining whether the target service request exceeds the upper limit of the number of requests within a target period based on the request record of the target service request stored in the database; If the target business request exceeds the upper limit of the number of requests within the target period, outputting a first risk identification result; If the target business request does not exceed the upper limit of the number of requests within the target period, outputting a second risk identification result; The second risk identification result is used to indicate that there is a risk in the target service request.

6. The method according to claim 4 or 5, characterized in that: The preset ratio is positively correlated with the upper limit of the number of requests.

7. The method according to claim 3, characterized in that: The method further comprises: Extract business requests from the cache space based on preset rules; Determine, according to the business request, a request record of the business request stored in the database; Based on the request record of the business request, risk prediction is performed on the business request.

8. The method according to claim 7, characterized in that The extracting the service request from the cache space based on the preset rule includes: Determine the normal distribution probability of the business request based on the request records of the business request stored in the cache space; wherein the normal distribution probability of the business request is negatively correlated with the number of request records of the business request in the cache space; According to the normal distribution probability, a service request is extracted from the cache space.

9. A risk identification device, characterized in that: An identification determination module, configured to respond to a risk identification request initiated for a target business request and determine whether the target business request is marked with a security identification; A risk identification module, configured to output a first risk identification result when the target business request is marked with a security identifier, wherein the first risk identification result is used to indicate that there is no risk; The security identifier is marked when risk prediction is performed on the target business request and a first risk prediction result is determined, and the first risk prediction result is used to indicate that there is no risk.

10. An electronic device, characterized in that: include: A memory for storing one or more computer programs; a processor for loading the one or more computer programs to execute the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, wherein one or more computer programs are stored on the computer-readable storage medium, characterized in that: When the one or more computer programs are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images