Lightweight placeholder method and device for data cache penetration defense
By using lightweight placeholder markers and dynamic strategy adjustments, the resource waste and backend load issues caused by cache penetration are resolved, achieving fine-grained cache defense and improving system stability and defense effectiveness.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TIANJIN URBAN PLANNING & DESIGN INST CO LTD
- Filing Date
- 2026-06-30
- Publication Date
- 2026-07-31
AI Technical Summary
Existing technologies for addressing cache penetration issues suffer from wasted cache space, surges in backend load, and abuse of malicious requests. They lack fine-grained defense mechanisms and cannot effectively distinguish between normal erroneous queries and high-frequency malicious probes.
It employs lightweight placeholder identifiers and dynamic policy adjustments. By generating lightweight placeholder identifiers and combining access frequency and user risk factors, it dynamically adjusts expiration time and the number of placeholders to achieve fine-grained management and prevent the abuse of cache resources.
It effectively resists cache penetration attacks, reduces backend database load, improves system stability, avoids resource waste, achieves fine-grained defense, and forms an adaptive closed-loop defense mechanism.
Smart Images
Figure CN122489613A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of information technology, and in particular relates to a lightweight placeholder method and device for data cache penetration defense. Background Technology
[0002] With the widespread application of large-scale distributed systems such as trusted data spaces, data caching layers have become a core component for ensuring high-performance system responses. However, when dealing with a large number of query requests for non-existent data, cache penetration becomes increasingly prominent: requests bypass the cache and are forwarded directly to the backend database, causing a surge in load, service response delays, and even being crafted into malicious requests to launch attacks, seriously affecting system stability and data security.
[0003] Currently, the industry commonly uses two conventional methods to address the cache penetration problem: caching empty objects and using Bloom filters. However, both have significant limitations. Caching empty objects is relatively simple to implement. When data is not found, the null value is directly written to the cache and a fixed expiration time is set, which can block duplicate requests in the short term. However, this method cannot distinguish between normal erroneous queries and high-frequency malicious probe requests, which can easily lead to wasted cache space. Moreover, the fixed expiration strategy is difficult to deal with continuous attacks, and malicious requests can still penetrate the cache and reach the backend after expiration.
[0004] Bloom filters pre-load existing data identifiers and, upon receiving a request, first check if the data exists; if not, they are rejected. However, they consume a large amount of memory, require synchronous updates when new data is added, have high maintenance costs, and inherently have a false positive rate.
[0005] More importantly, both of these methods lack user-level access frequency statistics and risk identification capabilities, and do not limit the number of slots a single user can occupy. In high-concurrency malicious probing scenarios, issues such as cache resource abuse and backend load fluctuations can still occur. The overall protection mechanism is relatively crude and cannot form a refined and adaptive defense loop. Summary of the Invention
[0006] This invention proposes a lightweight placeholder method and device for data cache penetration defense. It designs a lightweight, implementable, closed-loop self-consistent cache placeholder defense mechanism that balances defense effectiveness and system performance, and solves the problems of cache penetration, malicious request abuse, and cache resource waste.
[0007] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A lightweight placeholder method for data cache penetration defense includes: S1. Intercept the data query request and determine the existence of the data. If the data does not exist, proceed to step 2 and execute the placeholder defense. S2. Generate a lightweight placeholder for data query requests where the data does not exist, and configure core basic parameters, including a basic expiration time. Single user basic placeholder limit Time window; S3. Based on the time window, the access frequency F of the data query request is statistically analyzed in real time; based on the initiating user's historical behavior, a weighted scoring method is used to quantify and generate the initiating user's risk coefficient. ; S4. Based on the access frequency F and the risk coefficient of the initiating user... The expiration time T of the placeholder identifier is dynamically adjusted. ; S5. Based on the risk coefficient of the initiating user. Dynamically adjust the number of placeholders for the initiating user. , ; S6. Periodically scan the placeholder identifiers in the cache, update the access count and risk coefficient of the initiating user for each placeholder identifier in real time, and clean up placeholder identifiers that have exceeded the expiration time T. S7. Real-time anomaly monitoring and emergency response for indicators including the number of visits to placeholder markers.
[0008] Furthermore, the interception of data query requests and determination of data existence described in step S1 includes: First, the data query request is lightly intercepted. The cache layer is checked to see if there is a valid cache corresponding to the data requested by the request. If the cache layer has valid data, the data is returned directly. If the cache layer does not have the corresponding data, the request is forwarded to the backend database to check if the data actually exists. If the data exists in the database, the data is written to the cache and an expiration time is set, and the data is returned. If the data does not exist in the database either, the existence of the data is determined as non-existent.
[0009] Furthermore, the lightweight placeholder identifier mentioned in step S2 is a single-byte or multi-byte placeholder or an empty structure without any fields.
[0010] Furthermore, step S3, which involves initiating user history behavior, includes three dimensions: malicious request records, permission level records, and access compliance records. The malicious request records are extracted from system audit logs, request interception logs, and placeholder over-limit records. The permission level records are read directly from the user center / permission system. The access compliance records are obtained from behavior logs, including records of request parameter verification, access frequency statistics, IP anomalies, and access time periods.
[0011] Furthermore, step S3, which quantifies and generates the risk coefficient for the initiating user, includes: Each of the three dimensions is quantified and scored, with a binary classification of scores [0, 1]. Weights are assigned to each of the three dimensions, satisfying a weight normalization constraint. The scores of the three dimensions are then weighted and summed to obtain the risk coefficient for the initiating user. .
[0012] Furthermore, in step S4, if the initiating user's risk coefficient... If the value is 0, then the expiration time T of the placeholder identifier is directly set to 0. .
[0013] Furthermore, the expiration time T of the placeholder marker in step S4 shall not exceed [a certain value]. .
[0014] Furthermore, in step S5, the number of placeholder identifiers for each initiating user is counted in real time. ,when ≥ In such cases, subsequent data query requests from the initiating user will be rejected outright, and the user's behavior will be recorded in the behavior log to increase the user's risk level. .
[0015] Furthermore, the real-time anomaly monitoring and emergency response described in step S7 includes: If the proportion of cache penetration traffic exceeds a preset threshold, the base expiration time of all placeholder markers will be automatically increased. ; If a single user triggers the placeholder identifier limit multiple times within a short period of time, they are identified as a malicious user, their query privileges are temporarily restricted, and an audit log is recorded for subsequent tracing. The backend database load exceeds the warning threshold, so all data query requests from users with a risk factor greater than 0 are closed.
[0016] In another aspect, the present invention also proposes a lightweight placeholder device for data cache penetration defense, comprising: Interception module: Intercepts data query requests, determines the existence of data, and if the data does not exist, enters the placeholder module to perform placeholder defense; Placeholder module: Generates a lightweight placeholder identifier for data query requests where the data does not exist, and configures core basic parameters, including a basic expiration time. Single user basic placeholder limit Time window; Data quantification module: Based on the time window, it statistically analyzes the access frequency F of the data query requests in real time; based on the initiating user's historical behavior, it uses a weighted scoring method to quantify and generate the initiating user's risk coefficient. ; The reservation time adjustment module adjusts the time based on the access frequency F and the risk coefficient of the initiating user. The expiration time T of the placeholder identifier is dynamically adjusted. ; Identifier quantity adjustment module: Based on the risk coefficient of the initiating user Dynamically adjust the number of placeholders for the initiating user. , ; Update module: Periodically scans placeholders in the cache, updates the access count and risk coefficient of the initiating user for each placeholder in real time, and cleans up placeholders that have exceeded the expiration time T. Monitoring and Response Module: Real-time anomaly monitoring and emergency response for indicators including the number of visits to placeholder markers.
[0017] Compared with the prior art, the present invention has the following beneficial effects: This invention effectively resists cache penetration attacks, significantly reduces the load of invalid queries on the backend database, and improves system stability through lightweight cache placeholders and dynamic strategy adjustments. The placeholder time and number of placeholder identifiers are dynamically adjusted using formula calculations, enabling long-term interception of malicious requests and rapid release of normal queries, avoiding resource waste and insufficient protection issues caused by fixed expiration policies. By jointly calculating user risk coefficients and access frequency, it can accurately distinguish between normal false queries and high-frequency malicious probes, achieving refined management. Simultaneously, the limit on the number of placeholders per user prevents the abuse of cache resources, and the automatic background cleanup mechanism ensures efficient use of cache space. The overall solution is lightweight and non-intrusive, deployable without modifying the existing architecture, forming a complete and reliable security defense loop while ensuring query efficiency in trusted data spaces, and possesses strong practicality and scalability. Attached Figure Description
[0018] Figure 1 This is a flowchart of Embodiment 1 of the present invention.
[0019] Figure 2 This is a schematic diagram of the structure of Embodiment 2 of the present invention. Detailed Implementation
[0020] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.
[0021] To make the purpose and features of this invention patent more apparent and understandable, the invention will be further described below in conjunction with the accompanying drawings and specific embodiments.
[0022] Example 1: This embodiment addresses the issues of cache penetration, malicious request abuse, and cache resource waste by designing a lightweight placeholder method for data cache penetration defense, such as... Figure 1 As shown, it includes: Step 1: Request interception and data existence determination.
[0023] When a user initiates a data query request, the request is first lightly intercepted. Lightweight interception means that before the database query is actually executed, the cache layer is first checked to see if there is a valid cache corresponding to the data. The valid cache includes normal data cache and placeholder identifier.
[0024] If valid data exists in the cache layer, return the data directly and end the process; if no corresponding data exists in the cache layer, forward the request to the backend database to check if the data actually exists.
[0025] If the data exists in the backend database, the retrieved data is written to the cache with a regular expiration time, and the data is returned; if the data does not exist in the backend database, the placeholder defense process is started, and step 2 is executed.
[0026] Step 2: Lightweight placeholder generation and basic configuration.
[0027] For data query requests that do not exist in the backend database, instead of directly returning a traditional null value, a lightweight placeholder is generated. The lightweight placeholder is not real data and is only used to intercept duplicate requests. It can be a single-byte or multi-byte placeholder, or an empty structure without any fields, etc.
[0028] The lightweight placeholder identifier used in this embodiment will have its expiration time dynamically adjusted in subsequent steps based on access frequency and user risk, and the number of placeholders per user will be limited. It can distinguish between normal false queries and malicious probes, automatically clean up, and provide adaptive protection without wasting cache resources.
[0029] While generating a lightweight placeholder identifier, core basic parameters are configured to provide a benchmark for subsequent dynamic adjustments. These core basic parameters include: Basic expiration time : A fixed baseline value is preset, for example, it can be preset to 30 seconds, as the initial expiration time of the placeholder mark, to ensure that repeated requests are blocked by the cache in a short period of time, while avoiding long-term occupation of cache resources; Single user basic placeholder limit : Preset the maximum number of placeholders that a single user can generate. For example, it can be preset to 5 to prevent a single user from maliciously generating a large number of placeholders and abusing the cache. Time window : Preset the time window for statistical request frequency. For example, it can be preset to 60 seconds, which is used to determine whether the request is a high-frequency malicious request.
[0030] Step 3: Calculate request frequency and user risk factor.
[0031] The system tracks the frequency of this query request and the risk level of the initiating user in real time, quantifying this information through formulas to provide data support for dynamically adjusting the placement strategy. 3.1 Access frequency calculation: Statistical time window Within, the total number of times this query request was made. Calculate the access frequency F per unit time: ; The value of F ranges from 0 to +∞. The larger F is, the more frequently the query request is accessed, and the higher the probability of malicious probing. 3.2 Calculation of User Risk Coefficient: Based on user historical behavior (including three dimensions: malicious request records, permission level records, and access compliance records), a user risk coefficient is quantitatively generated. , The value range is 0~1. =0 indicates that the user is risk-free and is a normal user; =1 indicates that the user is high-risk and suspected of being a malicious user.
[0032] in: (1) Malicious request records: extracted from system audit logs, request interception logs, and placeholder over-limit records.
[0033] (2) Permission level: The identity, role and authorization level of the initiating user are directly read from the user center / permission system.
[0034] (3) Access compliance: obtained from behavior logs such as request parameter verification, access frequency statistics, IP anomalies, and access time periods.
[0035] Three dimensions to quantify and generate risk coefficients The process of (0~1) includes: Using a weighted scoring method, each of the three dimensions is scored individually, and each behavior is converted into a binary classification with a score of [0, 1], such as: (1) Malicious request score S1: If there is no malicious request record, the score of this dimension is 0; if there is a malicious request record or multiple malicious request records, the score of this dimension is 1.
[0036] (2) Permission Score S2: If the initiating user has a high permission level, the score for this dimension is 0; if the user has low permission / anonymous, the score for this dimension is 1. The high permission level refers to the permission system granting the user a wide range of high-level operation authorizations, such as batch query, full data access, configuration modification, backend management, and multiple interfaces without frequency restrictions, and the level of trust is higher.
[0037] (3) Access compliance score S3: If all accesses recorded in the behavior log are compliant, the score for this dimension is 0. If there are abnormal accesses or illegal parameters, the score for this dimension is 1.
[0038] Assign non-negative weights to the three evaluation dimensions respectively. ; The three weights satisfy the weight normalization constraint. ; Weighted summation for calculating risk coefficient : The resulting value is ultimately limited to between 0 and 1, serving as the risk coefficient for the initiating user.
[0039] Step 4: Dynamically adjust the expiration time of the placeholder marker.
[0040] Based on the access frequency F and risk coefficient calculated in step 3 The expiration time T of the placeholder flag is dynamically adjusted to achieve long-term interception of high-frequency malicious requests and short-term interception of normal erroneous queries, thus avoiding waste of cache resources. T= ×(1+F)× ; For high-frequency requests from ordinary high-risk users, the expiration time T is dynamically adapted according to this formula to balance the interception effect and cache utilization.
[0041] If it's a normal erroneous query, F is relatively small. =0, then T= It maintains a basic expiration time, automatically expires after a short period of interception, and does not occupy cache resources.
[0042] If it is a high-frequency malicious request (F is large), If the value is relatively high, then T has a preset upper limit, which can not exceed a maximum of [a certain value]. ×5 enables long-term interception of malicious requests, reducing pressure on the backend database.
[0043] Step 5: Control and interception of single-user slot usage.
[0044] To prevent a single user from maliciously generating a large number of placeholder identifiers and consuming cache resources, the system counts the current number of placeholder identifiers for each user in real time. And calculate the user's allowed space limit using the formula: = ×(1- ); when < When this happens, the user is allowed to generate a new placeholder identifier, and the dynamic expiration time configuration in step 4 is executed; when ≥ In such cases, subsequent invalid data query requests from the user will be rejected outright, and the user's behavior will be recorded to increase the user's risk level. If abuse continues, temporary rate limiting or an alarm will be triggered.
[0045] Step 6: Clear placeholder markers and update status.
[0046] The system background periodically scans placeholder markers in the cache and performs two core operations to ensure controllable cache resources and a closed-loop defense mechanism: Expiration cleanup: Automatically clean up placeholders that have exceeded their expiration time T, freeing up cache space and preventing invalid placeholders from occupying resources for a long time; Status Update: Update the access count and user risk coefficient of each placeholder in real time. If there are no repeated requests for a placeholder before it expires, the expiration time will be appropriately shortened when the placeholder for the next query is generated. If there are still high-frequency requests, the expiration time will be maintained or extended.
[0047] Step 7: Anomaly Monitoring and Emergency Response.
[0048] The system monitors metrics such as cache penetration traffic, placeholder generation count, and backend database load in real time. It automatically triggers an emergency response when the following anomalies occur: (1) If the proportion of cache penetration traffic exceeds the preset threshold (e.g., 10%), the base expiration time of all placeholder markers will be automatically increased. Enhance the interception effect; (2) If a single user triggers the placeholder limit multiple times in a short period of time, the user is identified as a malicious user, and their query privileges are temporarily restricted. An audit log is also recorded for subsequent tracing. (3) If the backend database load exceeds the warning threshold, invalid query requests from low-risk users will be temporarily blocked to ensure the normal operation of core business.
[0049] The method described in this embodiment can effectively resist cache penetration attacks, significantly reduce the load of invalid queries on the backend database, and improve system stability through lightweight cache placeholders and dynamic strategy adjustments.
[0050] Example 2: This embodiment proposes a lightweight placeholder device for data cache penetration defense, such as... Figure 2 As shown, it includes: Interception module: Intercepts data query requests, determines the existence of data, and if the data does not exist, enters the placeholder module to perform placeholder defense; Placeholder module: Generates a lightweight placeholder identifier for data query requests where the data does not exist, and configures core basic parameters, including a basic expiration time. Single user basic placeholder limit Time window; Data quantification module: Based on the time window, it statistically analyzes the access frequency F of the data query requests in real time; based on the initiating user's historical behavior, it uses a weighted scoring method to quantify and generate the initiating user's risk coefficient. ; The reservation time adjustment module adjusts the time based on the access frequency F and the risk coefficient of the initiating user. The expiration time T of the placeholder identifier is dynamically adjusted. ; Identifier quantity adjustment module: Based on the risk coefficient of the initiating user Dynamically adjust the number of placeholders for the initiating user. , ; Update module: Periodically scans placeholders in the cache, updates the access count and risk coefficient of the initiating user for each placeholder in real time, and cleans up placeholders that have exceeded the expiration time T. Monitoring and Response Module: Real-time anomaly monitoring and emergency response for indicators including the number of visits to placeholder markers.
[0051] The interception module's function of intercepting data query requests and determining the existence of data includes: First, the data query request is lightly intercepted. The cache layer is checked to see if there is a valid cache corresponding to the data requested by the request. If the cache layer has valid data, the data is returned directly. If the cache layer does not have the corresponding data, the request is forwarded to the backend database to check if the data actually exists. If the data exists in the database, the data is written to the cache and an expiration time is set, and the data is returned. If the data does not exist in the database either, the existence of the data is determined as non-existent.
[0052] The lightweight placeholder identifier in the placeholder module is a single-byte or multi-byte placeholder or an empty structure without any fields.
[0053] The placeholder module's initiating user history behavior includes three dimensions: malicious request records, permission level records, and access compliance records. The malicious request records are extracted from system audit logs, request interception logs, and placeholder over-limit records. The permission level records are read directly from the user center / permission system. The access compliance records are obtained from behavior logs, including records of request parameter verification, access frequency statistics, IP anomalies, and access time periods.
[0054] The data quantification module generates the risk coefficient for the initiating user, including: Each of the three dimensions is quantified and scored, with a binary classification of scores [0, 1]. Weights are assigned to each of the three dimensions, satisfying a weight normalization constraint. The scores of the three dimensions are then weighted and summed to obtain the risk coefficient for the initiating user. .
[0055] If the risk factor of the initiating user is in the reservation time adjustment module If the value is 0, then the expiration time T of the placeholder identifier is directly set to 0. .
[0056] The expiration time T of the placeholder identifier in the placeholder time adjustment module shall not exceed a maximum of .
[0057] The identifier quantity adjustment module provides real-time statistics on the current number of placeholder identifiers for each initiating user. ,when ≥ In such cases, subsequent data query requests from the initiating user will be rejected outright, and the user's behavior will be recorded in the behavior log to increase the user's risk level. .
[0058] The real-time anomaly monitoring and emergency response described in the monitoring and response module include: If the proportion of cache penetration traffic exceeds a preset threshold, the base expiration time of all placeholder markers will be automatically increased. ; If a single user triggers the placeholder identifier limit multiple times within a short period of time, they are identified as a malicious user, their query privileges are temporarily restricted, and an audit log is recorded for subsequent tracing. The backend database load exceeds the warning threshold, so all data query requests from users with a risk factor greater than 0 are closed.
[0059] The lightweight placeholder device for data cache penetration defense proposed in this embodiment can achieve the lightweight placeholder method for data cache penetration defense described in Embodiment 1, and has the same technical effect.
[0060] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A lightweight placeholder method for data cache penetration defense, characterized in that, include: S1. Intercept the data query request and determine the existence of the data. If the data does not exist, proceed to step 2 and execute the placeholder defense. S2. Generate a lightweight placeholder for data query requests where the data does not exist, and configure core basic parameters, including a basic expiration time. Single user basic placeholder limit Time window; S3. Based on the time window, the access frequency F of the data query request is statistically analyzed in real time; based on the initiating user's historical behavior, a weighted scoring method is used to quantify and generate the initiating user's risk coefficient. ; S4. Based on the access frequency F and the risk coefficient of the initiating user... The expiration time T of the placeholder identifier is dynamically adjusted. ; S5. Based on the risk coefficient of the initiating user. Dynamically adjust the number of placeholders for the initiating user. , ; S6. Periodically scan the placeholder identifiers in the cache, update the access count and risk coefficient of the initiating user for each placeholder identifier in real time, and clean up placeholder identifiers that have exceeded the expiration time T. S7. Real-time anomaly monitoring and emergency response for indicators including the number of visits to placeholder markers.
2. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, Step S1, which involves intercepting data query requests and determining the existence of data, includes: First, the data query request is lightly intercepted. The cache layer is checked to see if there is a valid cache corresponding to the data requested by the request. If the cache layer has valid data, the data is returned directly. If the cache layer does not have the corresponding data, the request is forwarded to the backend database to check if the data actually exists. If the data exists in the database, the data is written to the cache and an expiration time is set, and the data is returned. If the data does not exist in the database either, the existence of the data is determined as non-existent.
3. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, The lightweight placeholder identifier mentioned in step S2 is a single-byte or multi-byte placeholder or an empty structure without any fields.
4. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, Step S3, which involves initiating user history behavior, includes three dimensions: malicious request records, permission level records, and access compliance records. The malicious request records are extracted from system audit logs, request interception logs, and placeholder over-limit records. The permission level records are read directly from the user center / permission system. The access compliance records are obtained from behavior logs, including records of request parameter verification, access frequency statistics, IP anomalies, and access time periods.
5. The lightweight placeholder method for data cache penetration defense according to claim 4, characterized in that, Step S3, which involves quantifying and generating the risk coefficient for the initiating user, includes: Each of the three dimensions is quantified and scored, with a binary classification of scores [0, 1]. Weights are assigned to each of the three dimensions, satisfying a weight normalization constraint. The scores of the three dimensions are then weighted and summed to obtain the risk coefficient for the initiating user. .
6. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, If the risk coefficient of the initiating user is in step S4 If the value is 0, then the expiration time T of the placeholder identifier is directly set to 0. .
7. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, The expiration time T of the placeholder marker in step S4 shall not exceed [a maximum of 1]. .
8. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, In step S5, the current number of placeholder identifiers for each initiating user is counted in real time. ,when ≥ In such cases, subsequent data query requests from the initiating user will be rejected outright, and the user's behavior will be recorded in the behavior log to increase the user's risk level. .
9. The lightweight placeholder method for data cache penetration defense according to claim 1, characterized in that, Step S7, the real-time anomaly monitoring and emergency response, includes: If the proportion of cache penetration traffic exceeds a preset threshold, the base expiration time of all placeholder markers will be automatically increased. ; If a single user triggers the placeholder identifier limit multiple times within a short period of time, they are identified as a malicious user, their query privileges are temporarily restricted, and an audit log is recorded for subsequent tracing. The backend database load exceeds the warning threshold, so all data query requests from users with a risk factor greater than 0 are closed.
10. A lightweight placeholder device for data cache penetration defense, characterized in that, include: Interception module: Intercepts data query requests, determines the existence of data, and if the data does not exist, enters the placeholder module to perform placeholder defense; Placeholder module: Generates a lightweight placeholder identifier for data query requests where the data does not exist, and configures core basic parameters, including a basic expiration time. Single user basic placeholder limit Time window; Data quantification module: Based on the time window, it statistically analyzes the access frequency F of the data query requests in real time; based on the initiating user's historical behavior, it uses a weighted scoring method to quantify and generate the initiating user's risk coefficient. ; The reservation time adjustment module adjusts the time based on the access frequency F and the risk coefficient of the initiating user. The expiration time T of the placeholder identifier is dynamically adjusted. ; Identifier quantity adjustment module: Based on the risk coefficient of the initiating user Dynamically adjust the number of placeholders for the initiating user. , ; Update module: Periodically scans placeholders in the cache, updates the access count and risk coefficient of the initiating user for each placeholder in real time, and cleans up placeholders that have exceeded the expiration time T. Monitoring and Response Module: Real-time anomaly monitoring and emergency response for indicators including the number of visits to placeholder markers.