Intelligent caching method and device based on self-adaptive caching strategy

Abstract

The invention provides an intelligent caching method and device based on a self-adaptive caching strategy, and the method comprises the steps: collecting an access event flow of each caching key in real time through a sensing probe embedded in a caching client, the event flow comprising Key, operation type, timestamp, request source, hit state and response time; running a streaming processing engine at a client based on an access event stream, and calculating indexes such as instantaneous QPS, continuous miss times and short-term access frequency by adopting a sliding time window; a calculation result is input into a rule engine for online matching, a decision instruction for a single Key is generated, and the decision instruction comprises distributed mutual exclusion lock addition, local TTL dynamic adjustment and read-write mode switching; a decision instruction is directly executed in a client memory through a strategy executor, and nanosecond strategy effectiveness is achieved; and finally, collecting system feedback data after strategy execution, inputting the system feedback data into a machine learning module for online learning, and dynamically optimizing a rule threshold value or recommending a new strategy.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an intelligent caching method and apparatus based on an adaptive caching strategy. Background Technology

[0002] Caching technology, as a core supporting component in distributed system architecture, is widely used in the field of data access optimization for internet businesses. With the popularization of cloud computing and microservice architecture, caching systems have evolved from traditional static configuration schemes (such as Redis's LRU algorithm and Memcached's fixed TTL mechanism) to dynamic policy management systems based on rule engines. Specifically, this technology system constructs a complete closed loop from data collection (such as Prometheus exporter), rule matching (such as the Drools engine), to policy execution (such as the CONFIG SET command) through the collaborative operation of monitoring agents, rule engines, and caching clients. Among them, the rule engine implements policy adjustment through predefined IF-THEN logic, but its essence is still a periodic feedback mechanism based on external monitoring metrics.

[0003] However, existing dynamic cache management methods directly employ polling-based metric collection mechanisms, failing to achieve real-time event-driven awareness. This can lead to significant policy response delays (typically on the order of seconds) or, due to coarse-grained control (supporting only key prefix-level or global policies), an inability to accurately identify abnormal access patterns for individual hot keys (such as product_123). Specifically, existing systems make decisions by periodically pulling aggregated metrics (such as average QPS), which has three key drawbacks: First, the lag issue makes it unable to cope with sudden surges in traffic (such as a sudden jump in QPS during a flash sale). Firstly, it easily leads to cache breakdown; secondly, the rule base requires continuous manual maintenance and lacks the ability to learn autonomously about business models (e.g., it cannot dynamically optimize thresholds). Third, the insufficient reliability of collaboration between multiple components (monitoring system, rule engine, configuration center) increases the system failure rate. These limitations are particularly prominent in business scenarios with high concurrency and low latency requirements, directly affecting the stability of database load and the overall system reliability. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose an intelligent caching method based on an adaptive caching strategy.

[0006] The second objective of this invention is to propose an intelligent caching device based on an adaptive caching strategy.

[0007] The third objective of this invention is to provide an electronic device.

[0008] The fourth objective of this invention is to provide a computer-readable storage medium.

[0009] The fifth objective of this invention is to provide a computer program product.

[0010] To achieve the above objectives, a first aspect of this invention proposes an intelligent caching method based on an adaptive caching strategy, comprising: S1, collecting access event streams for each cache key in real time using a perception probe embedded in the cache client, wherein the access event stream includes Key, operation type, timestamp, request source, hit status, and response time; S2, running a streaming processing engine within the client based on the access event stream, and calculating access metrics for each Key in real time using a sliding time window, wherein the access metrics include instantaneous QPS, number of consecutive misses, and short-term access frequency; S3, inputting the real-time calculated access metrics into a rule engine for online matching, generating decision instructions for a single Key, wherein the decision instructions include distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching; S4, executing the decision instructions directly in the client's memory through a policy executor, achieving nanosecond-level policy effectiveness without calling external interfaces; S5, collecting system state changes after policy execution to form feedback data, inputting the feedback data into a machine learning module for online learning, dynamically optimizing threshold parameters in the rules, or recommending new decision rules.

[0011] In one embodiment of the present invention, the real-time acquisition of access event streams for each cache key through the perception probe embedded in the cache client further includes: S11, using AOP or bytecode enhancement technology to non-intrusively intercept cache API calls and generate a structured event object containing Key, operation type, timestamp, request source, hit status, and response time; S12, publishing the structured event object to the message bus inside the client in real time to ensure low-latency transmission and processing of the event stream.

[0012] In one embodiment of the present invention, the step of running a streaming processing engine within the client based on the access event stream further includes: S21, configuring the sliding time window to an adjustable millisecond or second-level time granularity, wherein the time window includes a dual-window structure of the most recent 1 second and 5 seconds; S22, calculating access metrics, including instantaneous QPS, in real time for each Key within the sliding time window. Number of consecutive misses and short-term access frequency .

[0013] In one embodiment of the present invention, the step of inputting the real-time calculated access metrics into the rule engine for online matching further includes: S31, dynamically loading and updating the rule base, wherein the rule is defined as IF Real-time metrics in the stream processing engine meet the conditions THEN Trigger Action S32, the rule engine, is based on decision instructions for distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching, and uses a predefined policy mapping table. Translate instructions into specific execution logic.

[0014] In one embodiment of the present invention, the step of directly executing the decision instruction in the client memory via the policy executor further includes: S41, when the decision instruction is attached to a distributed mutex lock, using Redisson or a similar framework to lock the get request for the target key, and the lock holding time... With sliding window time Synchronization; S42, when the decision instruction is a read-write mode switch, switch the target key's cache mode from Cache-Aside to Write-Behind via a local memory queue. Asynchronous data persistence.

[0015] In one embodiment of the present invention, the method further includes: dynamically adjusting the configuration parameters of the sliding time window based on the optimization results of the machine learning module. Or update the threshold in the rule base. To adapt to real-time changes in business scenarios.

[0016] To achieve the above objectives, a second aspect of the present invention proposes an intelligent caching device based on an adaptive caching strategy, comprising: an access event stream acquisition module, used to collect access event streams for each cache key in real time through a sensing probe embedded in the cache client, wherein the access event stream includes Key, operation type, timestamp, request source, hit status, and response time; and a streaming processing module, used to run a streaming processing engine within the client based on the access event stream, and to calculate access metrics for each Key in real time using a sliding time window, wherein the access metrics include instantaneous QPS and the number of consecutive misses. and short-term access frequency The rule engine matching module is used to input the real-time calculated access metrics into the rule engine for online matching, generating decision instructions for a single key. These decision instructions include distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching. The policy execution module is used to directly execute the decision instructions in the client's memory via a policy executor, achieving nanosecond-level policy effectiveness without calling external interfaces. The machine learning optimization module is used to collect system state changes after policy execution to form feedback data, inputting this feedback data into the machine learning module for online learning, dynamically optimizing threshold parameters in the rules, or recommending new decision rules.

[0017] To achieve the above objectives, a third aspect of the present invention provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of the first aspects.

[0018] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of the first aspects.

[0019] To achieve the above objectives, a fifth aspect of the present invention provides a computer program product that, when executed by a processor, implements the method described in any one of the first aspects.

[0020] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: they can achieve millisecond-level response and single-key-level precise control, significantly improve the real-time performance, adaptability and reliability of the caching system, effectively alleviate database pressure and reduce operation and maintenance complexity.

[0021] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of an embodiment of the intelligent caching method based on an adaptive caching strategy according to the present invention; Figure 2 This is a schematic diagram of the structure of an intelligent caching device based on an adaptive caching strategy according to an embodiment of the present invention. Detailed Implementation

[0023] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0024] Figure 1 This is a flowchart of an intelligent caching method based on an adaptive caching strategy according to an embodiment of the present invention.

[0025] like Figure 1 As shown, the intelligent caching method based on an adaptive caching strategy includes the following steps: S1, the access event stream of each cache key is collected in real time through the perception probe embedded in the cache client. The access event stream includes Key, operation type, timestamp, request source, whether it hits, and response time.

[0026] Specifically, in some implementations, the real-time collection of access event streams for each cache key through a perception probe embedded in the cache client is a fundamental step in the adaptive strategy adjustment of the intelligent caching system of this invention. This step is technically implemented based on Aspect-Oriented Programming (AOP) or bytecode enhancement techniques, non-intrusively intercepting all caching APIs (such as get, set, delete, etc.) in the application, thereby achieving fine-grained monitoring of cache access behavior without modifying the business code.

[0027] In terms of specific operation, the sensing probe generates a structured access event object each time a cache operation occurs. This object contains the following key fields: Key (cache key identifier), operation type (e.g., GET, SET, DEL), timestamp (accurate to milliseconds or nanoseconds), request source (e.g., client IP, service module identifier), hit / miss indicator, and response time (time elapsed from request to response). These events are published in real-time to the message bus within the cache client in the form of a stream for subsequent processing by the streaming analysis module.

[0028] At the parameter level, the event stream is collected at a frequency consistent with the processing frequency of cached requests, typically in the millisecond range or even lower, ensuring data real-time performance. The timestamp field uses a unified system time base (such as UTC time) to support cross-node event alignment and aggregation analysis. The response time collection accuracy should be no less than 1 millisecond to meet the requirements for accurate evaluation of cache performance. Furthermore, the request source field supports multi-dimensional identification such as IP address, service name, and thread ID, facilitating subsequent access pattern analysis and anomaly tracing.

[0029] In application scenarios, this step is widely applicable to high-concurrency, distributed caching systems, especially in business scenarios such as e-commerce, social media, and content distribution, where caching performance and stability are critical. By collecting key-level access events in real time, the system can quickly identify abnormal behaviors such as hot keys, cache penetration, and cache avalanches, providing data support for subsequent streaming analysis and strategy decisions.

[0030] The technical value of this step lies in its transformation from the traditional external monitoring system's periodic retrieval of aggregated metrics (such as QPS) to the client-side, real-time collection of atomic events. Through key-level event stream collection, the system achieves millisecond-level perception capabilities, providing high-precision, low-latency data input for subsequent real-time analysis and decision-making. This is a crucial starting point for building an adaptive caching strategy closed loop.

[0031] Furthermore, S1 includes: S11 uses AOP or bytecode enhancement technology to non-intrusively intercept cached API calls and generate structured event objects containing key, operation type, timestamp, request source, hit status, and response time.

[0032] Specifically, in this invention, step one, "using AOP or bytecode enhancement technology to non-intrusively intercept cache API calls and generate a structured event object containing the key, operation type, timestamp, request source, hit status, and response time," is the fundamental step in implementing the adaptive caching strategy of the entire system. This step achieves fine-grained, real-time collection of cache access behavior without modifying the original business code by embedding a lightweight sensor probe in the cache client.

[0033] In some implementations, awareness probes employ Aspect-Oriented Programming (AOP) or Bytecode Enhancement techniques to intercept commonly used APIs (such as get, set, delete, etc.) in cache clients. AOP, by defining aspects and pointcuts, inserts custom logic before and after method calls, thereby recording call context information. Bytecode Enhancement, on the other hand, dynamically modifies bytecode during class loading to insert event collection logic, making it suitable for scenarios with higher performance requirements. Both methods achieve non-intrusive data collection, ensuring system compatibility and ease of deployment.

[0034] The event objects generated in this step are structured data containing the following key fields: Key (cache key name), operation type (e.g., READ, WRITE, DELETE), timestamp (accurate to milliseconds or nanoseconds), request source (e.g., service name, IP address, thread ID), hit / miss indicator, and response time (time elapsed from the start of the call to the return result, in milliseconds). These fields provide raw data support for subsequent streaming analysis and decision-making, and are particularly important in scenarios such as hot key identification and cache penetration detection.

[0035] Furthermore, the frequency and granularity of event object collection determine the system's ability to perceive caching behavior. In this invention, event collection latency is controlled at the nanosecond level, ensuring millisecond-level real-time performance. Simultaneously, the event stream throughput needs to support high-concurrency scenarios, typically requiring a processing capacity of over 10,000 events per second to accommodate the cache access frequency of large-scale distributed systems.

[0036] This step acts as the "data source" in the entire technical solution, providing the streaming analysis decision-maker with real-time, fine-grained access event streams, which is a prerequisite for implementing key-level adaptive strategies. Compared to existing technologies that rely on external monitoring systems to periodically pull aggregated metrics, this invention significantly improves the timeliness and accuracy of data by directly collecting atomic events of each request within the client, laying a solid foundation for subsequent real-time decision-making and strategy execution.

[0037] S12, the structured event object is published to the client's internal message bus in real time to ensure low-latency transmission and processing of the event stream.

[0038] Specifically, in some implementations, publishing structured event objects to the client's internal message bus in real time is a key step in achieving low-latency event processing in the method of this invention. This step involves embedding a lightweight awareness probe in the caching client to non-intrusively intercept and generate events for each cached API call (such as get, set, etc.). Event objects typically contain fine-grained information across multiple dimensions, such as the access key, operation type, timestamp, request source, hit status, and response time. Their structure can be represented as follows:

[0039] in, This is the timestamp of the event, typically with a precision in milliseconds. This indicates the response time of the caching operation and is used to evaluate system performance. These event objects are immediately published to the client's internal message bus after generation to enable real-time transmission and processing of the event stream.

[0040] In terms of implementation, message buses typically employ memory queues or publish / subscribe mechanisms from event-driven architectures (EDA) to ensure events are delivered between components with minimal latency. In this invention, the message bus throughput needs to support the processing of thousands to tens of thousands of events per second, with latency controlled within a specified range. Within a certain range, to meet the requirement of millisecond-level response. The design of the message bus should follow the principles of lightweight, loose coupling, and high concurrency, and can be implemented based on such as Disruptor, Reactor, or a self-developed high-performance queue.

[0041] In practical applications, this step runs within the caching client of the distributed system, without relying on external message middleware, thus avoiding the uncertainties and delays caused by network transmission. Its role is to provide high-quality, low-latency data input for subsequent streaming analysis and real-time decision-making, forming the foundation for key-level fine-grained control and policy closed-loop optimization. Through this mechanism, the system can immediately perform situational awareness and policy triggering after an event occurs, significantly improving the response speed and stability of the caching system.

[0042] S2, based on the access event stream, a streaming processing engine runs inside the client, and a sliding time window is used to calculate the access metrics for each key in real time. The access metrics include instantaneous QPS, number of consecutive misses, and short-term access frequency.

[0043] Specifically, in some implementations, the step of "running a streaming processing engine inside the client based on the access event stream and using a sliding time window to calculate the access metrics for each key in real time" is a core component of realizing the adaptive capability of the intelligent caching system. This step, by deploying a lightweight streaming processing engine inside the caching client, performs online analysis on the real-time collected access event stream, thereby providing accurate and low-latency access metric data for subsequent strategy decisions.

[0044] At the technical implementation level, the streaming engine receives access event streams from the sensing probes. Each event includes fields such as Key, operation type (e.g., GET, SET), timestamp, hit status, and response time. The engine performs real-time statistics on access behavior for each Key based on a sliding time window. The length and step size of the sliding window can be configured according to business needs; for example, a window length of 1 second and a step size of 200 milliseconds can ensure sensitive capture of instantaneous traffic changes. Within each window period, the engine calculates three key access metrics: instantaneous QPS (Queries Per Second), consecutive miss count, and short-term access frequency.

[0045] The instantaneous QPS is calculated as follows: within the current window, the number of GET requests for a specific key is counted, using the following formula: ,in For Key The number of requests within the window. The window duration is in seconds. Consecutive misses are counted using a counter that increments during consecutive misses and resets to zero upon a hit. Short-term access frequency is the total number of accesses to the Key within the window, used to identify potential hotspot access patterns.

[0046] At the parameter level, the configuration of the sliding window directly affects the system's response speed and resource consumption. A shorter window length results in a faster response to sudden traffic spikes, but may increase computational overhead; a smaller sliding step size allows for more frequent metric updates, helping to capture access trends more precisely. In practical deployments, it is recommended to set the window length to 1 second and the step size to 200 milliseconds to achieve a balance between real-time performance and stability.

[0047] At the application level, this step is suitable for high-concurrency, dynamically changing distributed caching systems, such as e-commerce product detail pages and social platform user information caching. In these scenarios, the access patterns of hot keys may change drastically within a short period of time, making it difficult for traditional caching strategies based on fixed TTLs or global rules to respond in a timely manner. By performing streaming computation within the client, the system can identify hot keys or abnormal access behavior within milliseconds and immediately trigger protection strategies, such as locking, circuit breaking, or switching read / write modes, thereby effectively preventing cache breakdown, cache avalanche, and other problems.

[0048] From a technical perspective, this step enables real-time, fine-grained monitoring of cache access behavior, providing high-quality data support for subsequent strategy decisions. Compared to existing technologies that rely on external monitoring systems to periodically pull aggregated metrics, this invention significantly reduces data collection and processing latency by performing streaming processing within the client, improving system response speed and stability. Furthermore, this step maintains access metrics independently for each key, avoiding information loss caused by global statistics and enhancing the accuracy and adaptability of the strategy.

[0049] Furthermore, S2 includes: S21, configure the sliding time window to an adjustable millisecond or second-level time granularity, wherein the time window includes a dual-window structure of the most recent 1 second and 5 seconds.

[0050] Specifically, in the "streaming computation and real-time analysis" step of this invention, configuring the sliding time window to an adjustable millisecond or second-level time granularity is a key technical step to achieve real-time, fine-grained analysis of cache access behavior. This step dynamically aggregates and calculates access events for each cache key by setting a dual-window structure (the most recent 1 second and 5 seconds) in the streaming analysis decision-maker, thereby providing accurate time-series indicators for subsequent hotspot identification and strategy decision-making.

[0051] In some implementations, the sliding time window employs a **time-driven streaming model**, where each window is updated with a fixed time granularity (e.g., 100ms, 500ms, 1s, etc.). The window update frequency is determined by system configuration parameters. Control, usually set This ensures a rapid response to sudden changes in traffic. Each key's access event, after entering the streaming engine, is categorized into two sliding windows: one for the most recent second... The other is the window of the most recent 5 seconds ( The window's sliding step size can be configured as follows: ,For example This is to achieve high-frequency indicator updates.

[0052] Specifically, the streaming engine is based on the timestamp field in the event stream. For each key, access requests are counted and analyzed within a time window. For example, for a key... During the time window Within this context, its query rate per second (QPS) is calculated as follows:

[0053] in, Key In time interval The number of visits within. Similarly, in Within the window, calculate the average QPS or miss rate over 5 seconds to identify short- to medium-term trends.

[0054] This dual-window architecture offers multi-dimensional analysis capabilities: a 1-second window captures sudden surges in traffic, while a 5-second window identifies persistent hotspots or abnormal access patterns. By combining metrics from both windows, the system can more accurately distinguish between sudden requests and genuine hotspots, avoiding misjudgments and over-response.

[0055] In practical applications, this step is suitable for distributed caching scenarios with high concurrency and high real-time requirements, such as e-commerce flash sales, real-time recommendations, and high-frequency transactions. By embedding streaming processing capabilities in the client, the system can perform real-time analysis of access behavior locally without relying on external monitoring systems, significantly reducing decision latency and improving system response speed and stability.

[0056] In summary, this step, through a flexibly configurable sliding time window, enables millisecond-level and key-level dynamic analysis of cache access behavior, providing a solid data foundation for subsequent real-time strategy decisions. It is one of the core supporting technologies for achieving high real-time performance and fine-grained cache management in this invention.

[0057] S22 calculates access metrics in real time for each Key within a sliding time window, including instantaneous QPS. Number of consecutive misses and short-term access frequency .

[0058] Specifically, in the method of this invention, step two, "streaming computation and real-time analysis," is one of the core components for implementing the intelligent caching strategy. This step embeds a lightweight streaming processing engine into the caching client to process the access event stream collected in step one in real time, calculating access metrics for each key within a sliding time window, including instantaneous QPS. Number of consecutive misses and short-term access frequency This provides accurate and low-latency data support for subsequent decision-making.

[0059] At the technical implementation level, the streaming engine adopts a sliding window mechanism based on time windows, with the window size... Configurable, typically set to 1 second or 5 seconds to adapt to the real-time requirements of different business scenarios. After each key's access event enters the engine, it is sorted by timestamp and assigned to the corresponding window. The engine maintains a time-based queue structure to record the number of times each key is accessed within a window. The metric value is dynamically updated based on the window sliding frequency (e.g., once every 100 milliseconds). Instantaneous QPS The ratio of the number of accesses within a window to the window duration is used to measure the real-time access intensity of the Key.

[0060] Number of consecutive misses Implemented using a counter mechanism, the counter increments whenever a key is not found in the cache, and resets if there are consecutive cache misses. This metric is used to identify potential cache penetration risks or cache invalidation hotspots. Short-term access frequency. It is based on access count statistics within a smaller time window (such as 100ms) to capture sudden traffic or abnormal access behavior.

[0061] Regarding parameter settings, the size of the sliding window The sliding frequency, QPS threshold, and miss count threshold can all be dynamically adjusted according to the characteristics of the business load. For example, in high-concurrency scenarios, the window can be set to 1 second and the sliding frequency to 200ms to improve response sensitivity.

[0062] This step, deployed internally within the caching client in practical applications, eliminates the need for external monitoring systems, significantly reducing system latency and coupling. Its purpose is to provide real-time, fine-grained key-level access characteristics for subsequent rule matching and policy execution, forming a crucial foundation for achieving millisecond-level hotspot identification and response. Through this step, the system can quickly detect changes in key access status, providing data support for the generation and execution of adaptive policies, thereby effectively improving the stability and resource utilization of the caching system.

[0063] S3, input the real-time calculated access metrics into the rule engine for online matching, and generate decision instructions for a single key. The decision instructions include attaching a distributed mutex lock, dynamically modifying the local TTL, and switching between read and write modes.

[0064] Specifically, in some implementations, inputting real-time calculated access metrics into a rule engine for online matching to generate decision instructions for individual keys is one of the core steps in achieving fine-grained cache control in this invention. This step is technically implemented based on dynamic metrics output by the streaming engine. Through the rule engine's real-time matching mechanism, it quickly identifies hot keys or abnormal access behaviors and generates corresponding control instructions, such as attaching distributed mutex locks, dynamically modifying local TTL, and switching read / write modes.

[0065] At the technical implementation level, the rule engine adopts an event-driven online matching approach, tightly integrated with the streaming analytics engine. Rules are defined in IF-THEN format, for example: IF key = "product_123" AND QPS>1000 THEN decision = "HOTKEY_PROTECTION". Upon receiving real-time metrics for each key (such as QPS, consecutive misses, access latency, etc.), the rule engine immediately performs condition matching in memory, without waiting for external polling or batch processing. This mechanism supports millisecond-level response, ensuring that protection policies are triggered as soon as a hot key shows an abnormal access trend.

[0066] At the parameter level, the matching conditions of a rule engine are typically based on statistical metrics within a sliding time window. For example, QPS is calculated based on a sliding window of the most recent 1 second or 5 seconds, and the window size can be configured. To adapt to the response needs of different business scenarios. The formula for calculating the miss rate is: ,in For Key The number of misses within the window. This represents the total number of visits. The rules engine supports dynamic loading and hot updates, allowing operations personnel or machine learning modules to adjust rule thresholds in real time based on feedback data.

[0067] At the application level, this step is widely applicable to distributed caching systems with high concurrency and sudden surges in hot topics, such as e-commerce flash sales, news hot topic recommendations, and real-time ranking lists. When the access volume of a certain key surges in a short period of time, the rule engine can immediately generate decision instructions, such as attaching a mutex lock to prevent cache breakdown, dynamically shortening its local TTL to accelerate expiration, or switching to write-behind mode to reduce database pressure. All operations are completed locally on the cache client without interaction with external systems, thus ensuring low latency and high reliability.

[0068] From a technical perspective, this step significantly improves the response speed and control precision of the caching system. By tightly integrating rule matching with streaming analysis, the system can complete the closed loop from perception to decision-making within nanoseconds, avoiding the latency issues caused by the separation of external monitoring and rule engines in traditional solutions. Simultaneously, this step supports key-level policy control, effectively preventing global policies from interfering with normal business operations, and improving the utilization of cache resources and system stability.

[0069] Furthermore, S3 includes: S31, Dynamically load and update the rule base, the rule is defined as IF Real-time metrics in the stream processing engine meet the conditions THEN Trigger Action For example, IF key "product_123" AND THENdecision "HOTKEY_PROTECTION".

[0070] Specifically, the step of "dynamically loading and updating the rule base" is one of the core mechanisms for implementing adaptive policy adjustment in the intelligent caching system of this invention. Its technical implementation is based on the rule engine module within the streaming analysis decision-maker. By defining rules in the form of "IF <real-time metric in the streaming engine meets the condition> THEN <trigger action>", real-time response and policy control of cache access behavior are achieved.

[0071] In some implementations, the rule base is stored locally or in a remote configuration center as a structured configuration file (such as YAML, JSON, or a custom DSL). The rule engine supports a hot reload mechanism, enabling dynamic updates to rule content without service interruption. Specifically, when the configuration center detects a change in the rule file, it pushes the updated content to the rule engine module in the cached client via a lightweight communication protocol (such as gRPC, HTTP long polling, or WebSocket). Upon receiving the update, the rule engine first performs syntax validation and semantic parsing to ensure that the new rule conforms to preset format specifications (such as field completeness and conditional logic validity), and then loads the rule into a rule matching table in memory for subsequent real-time decision-making.

[0072] At the parameter level, the condition part of the rule usually includes judgments on access metrics for a single key, such as instantaneous QPS (Queries Per Second) threshold, consecutive misses, access latency distribution, etc. For example, the rule can be defined as: IF key = "product_123" AND THEN decision = "HOTKEY_PROTECTION". Wherein, This indicates the request frequency of the current key within a sliding time window (e.g., 1 second or 5 seconds). This window is maintained by the stream processing engine and supports dynamic configuration. The execution actions of the rule include, but are not limited to, setting hotspot protection, switching caching modes, and marking null values, which are specifically implemented by the policy executor.

[0073] In practical applications, this step can be deployed in high-concurrency, dynamic internet business systems, such as e-commerce flash sales, recommendation systems, and real-time search. By dynamically loading rules, the system can quickly respond to adjustments in business strategies, such as preloading hotspot protection rules before the start of a promotional activity or temporarily activating a circuit breaker mechanism in the event of a sudden failure, thereby improving the elasticity and stability of the caching system.

[0074] In terms of technical effectiveness, this step enables real-time rule updates and accurate matching, effectively solving the problems of traditional rule engines relying on manual maintenance and having slow response times. By tightly integrating the rule engine with the stream processing engine, the system can complete rule matching and policy triggering within a millisecond-level time window, significantly improving the adaptability and execution efficiency of the caching strategy.

[0075] S32, the rule engine, is based on decision instructions for distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching, and utilizes a predefined policy mapping table. Translate instructions into specific execution logic.

[0076] Specifically, in the steps of this invention, the rule engine, based on decision instructions for distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching, uses a predefined policy mapping table. Transforming instructions into specific execution logic is the core step in achieving adaptive control of an intelligent caching system.

[0077] At the technical implementation level, the rule engine runs within the streaming analytics decision-maker. Its input consists of real-time metrics (such as QPS, miss rate, and access frequency) calculated by the streaming engine for each key within a sliding time window, and its output is specific policy control instructions. (Policy mapping table) It is a structured mapping table, in the form of: ,For example Upon receiving a decision instruction, the rules engine immediately searches... The corresponding execution logic is then injected into the policy executor's processing flow. Because the rule engine and stream processing engine are tightly coupled, and the policy mapping table is loaded into local memory, this process can be completed in microseconds, significantly outperforming traditional second-level response mechanisms based on external configuration centers.

[0078] At the parameter and metric level, the strategy mapping table Decision instructions in a program typically include a key matching pattern (such as a regular expression) and a triggering condition (such as...). Parameters such as the type of action to be performed (e.g., locking, TTL modification, mode switching) can be used. For example, the protection policy for a specific key can be defined as: IF THEN ,in The preset QPS threshold is typically determined based on the characteristics of the service load. Dynamic configuration within the specified range. TTL modifications are made via... Implementation, in which The maximum TTL limit set for the system is usually 100%. Second.

[0079] At the application level, this step is widely used in distributed systems with high concurrency and frequent changes in hot data, such as e-commerce flash sales, real-time recommendations, and online payments. In these scenarios, the system needs to respond to access behavior of specific keys at the millisecond level. For example, when a sudden increase in QPS is detected for a key on a product details page, a mutex lock is immediately attached to prevent cache breakdown, or the TTL is dynamically shortened to accelerate cache rebuilding when consecutive cache misses are detected.

[0080] From a technical perspective, this is achieved by mapping decision instructions to strategy tables. In combination, this invention achieves end-to-end low-latency closed-loop control from perception to execution. This step not only improves the real-time performance and accuracy of policy execution, but also significantly enhances the system's adaptability and resource utilization through key-level policy mapping, providing crucial support for building a highly reliable, low-latency intelligent caching system.

[0081] S4, the decision instructions are executed directly in the client's memory through the policy executor, without the need to call external interfaces to achieve nanosecond-level policy effectiveness.

[0082] Specifically, in this invention, the direct execution of decision instructions by the policy executor in the client's memory is one of the core steps to achieve nanosecond-level policy activation. This step is technically implemented based on a local policy mapping mechanism on the client, eliminating the need for external interfaces or remote configuration centers, thereby significantly reducing policy execution latency and improving the system's real-time responsiveness.

[0083] In some implementations, the policy executor is an embedded module within the cache client. Its core function is to translate control instructions from the streaming analytics decision-maker (such as HOTKEY_PROTECTION, CACHE_NULL, SWITCH_TO_WRITE_BEHIND, etc.) into specific cache control behaviors on the fly. This module maintains a policy mapping table, which maps each decision instruction to a set of predefined execution logic. For example, when a HOTKEY_PROTECTION instruction is received, the policy executor attaches a distributed mutex lock to subsequent get requests for that key to prevent cache breakdown; when a CACHE_NULL instruction is received, a "null value" flag is inserted into the local cache, and a short TTL (such as 500ms) is set to prevent invalid requests from penetrating to the database.

[0084] This step is executed entirely within the client's memory, without requiring calls to external interfaces (such as Redis's CONFIG SET or a remote configuration center), thus avoiding latency caused by network communication. In practical applications, the policy executor achieves immediate response to commands through a state machine or policy engine in memory, with execution latency controllable in the nanosecond (ns) range, far superior to the millisecond (ms) response speed of existing technologies that rely on external interfaces.

[0085] Furthermore, this step plays a crucial role in the system. It not only ensures the immediate effectiveness of the policy but also enhances the system's autonomy and reliability. Because policy execution does not depend on external services, the system can maintain policy continuity and consistency even if some nodes experience communication failures in a distributed environment. In addition, this mechanism supports fine-grained control over individual keys, avoiding the side effects that may result from global policy adjustments, thereby improving the utilization efficiency of cache resources and the stability of the system.

[0086] In summary, this step, through a localized, zero-latency policy execution mechanism, enables real-time response and precise control of caching policies. This is a significant innovation of the present invention in improving the adaptive capabilities of the caching system and reducing architectural complexity.

[0087] Furthermore, S4 includes: S41, when the decision instruction is to attach a distributed mutex lock, Redisson or a similar framework is used to lock the get request for the target key, and the lock holding time is specified. With sliding window time synchronous.

[0088] Specifically, when the decision instruction is to attach a distributed mutex lock, the system uses Redisson or a similar framework to lock the get request for the target key, and the lock holding time is specified. With sliding window time Synchronization. This step is a key component in implementing the hot key protection mechanism in this invention. Its technical implementation is based on the atomic control of distributed locks and the dynamic awareness of time windows, ensuring orderly scheduling of access to specific keys in high-concurrency scenarios and preventing cache breakdown and database overload.

[0089] At the technical implementation level, when the streaming analytics decision-maker identifies the access frequency (e.g., QPS) of a certain key within the current sliding window... When the threshold is exceeded, a HOTKEY_PROTECTION decision instruction is generated. Upon receiving this instruction, the policy executor immediately attaches a distributed mutex lock to subsequent get requests for that key. Redisson, as a Java client supporting Redis, provides a Redis-based distributed lock implementation, which relies on Redis's SETNX command and Lua scripts to ensure the atomicity of lock acquisition and release. Lock holding time... It is usually set to the sliding window time. Same, for example ,but This ensures that the lock's lifecycle is consistent with the evaluation cycle of access behavior within the window, thereby avoiding control deviations caused by locks being released too early or expired too late.

[0090] At the parameter level, lock holding time With sliding window time These are two key time parameters in the system, and their synchronized settings ensure the timeliness and consistency of the strategy. In addition, lock reentrancy and wait timeout are also important. The fairness policy of the lock (such as whether to enable FairLock) is also a configurable item, and is usually... Set as This is to avoid prolonged request blocking. Redisson's RLock interface supports flexible configuration of these parameters to meet the performance and consistency requirements of different business scenarios.

[0091] At the application level, this step is suitable for scenarios involving high-concurrency reading of frequently accessed keys, such as e-commerce flash sales, real-time rankings, and high-frequency query interfaces. By implementing lock attachment at the client level, access control for frequently accessed keys can be achieved without intrusive modifications to the cache server, effectively reducing database load and improving system stability.

[0092] The technical advantage of this step is that by dynamically attaching mutex locks at the key level, the system can respond to hot access within milliseconds, avoiding cache penetration and database avalanche. Simultaneously, the lock holding time is synchronized with the sliding window, ensuring the dynamic adaptability of the strategy and avoiding control failures caused by the mismatch between lock lifecycle and access patterns in traditional solutions. This mechanism improves the robustness of the caching system while significantly reducing the system's reliance on manual rule configuration and enhancing its adaptive capabilities.

[0093] S42, when the decision instruction is a read-write mode switch, the cache mode of the target key is switched from Cache-Aside to Write-Behind via a local memory queue. Asynchronous data persistence.

[0094] Specifically, when the decision instruction is a read-write mode switch, the system switches the target key's caching mode from Cache-Aside to Write-Behind and uses a local memory queue. Asynchronous data persistence is implemented. This step is one of the core mechanisms for dynamically adjusting caching behavior in this invention, and it has significant performance optimization and system stability improvement effects.

[0095] At the technical implementation level, after receiving the SWITCH_TO_WRITE_BEHIND instruction generated by the streaming analysis decision-maker, the Policy Executor immediately switches the access behavior of the key within the cache client. In Cache-Aside mode, write operations are directly written to the cache and then asynchronously or periodically refreshed to persistent storage; while in Write-Behind mode, write operations are first written to the local memory queue. The policy switching process is then asynchronously batch-submitted to persistent storage (such as a database or distributed storage system) via a background thread. This switching process is implemented through a policy mapping table, eliminating the need for interaction with the cache server and thus ensuring the immediacy and low latency of the policy switching.

[0096] At the parameter level, local memory queue Parameters such as capacity, refresh interval, and maximum backlog time can be configured according to business needs. For example, the maximum queue capacity can be set to... 1 record, refresh interval ms, maximum tolerable delay ms. These parameters directly affect the system's throughput and data consistency guarantee level. In Write-Behind mode, the system can tolerate a certain degree of data write latency, thereby reducing the direct write pressure on persistent storage and improving overall response speed.

[0097] At the application level, this step is suitable for business scenarios with high concurrency writes and low consistency tolerance, such as e-commerce flash sales, real-time log recording, and user behavior tracking. When the system detects a significant increase in the write frequency of a certain key, or when the database load approaches a threshold, it can automatically switch to Write-Behind mode to alleviate backend storage pressure while maintaining high availability and low latency response of the cache.

[0098] From a technical perspective, this step significantly reduces the coupling between caching and persistent storage through localized strategy execution and asynchronous persistence mechanisms, thereby improving the system's throughput and fault tolerance. Furthermore, since strategy switching occurs in client memory without external calls, the system boasts higher reliability and lower operational complexity. This mechanism provides crucial support for achieving key-level, millisecond-level, adaptive caching strategy switching in this invention and is a vital component in building a closed-loop control system for intelligent caching.

[0099] S5. Collect system state changes after strategy execution to form feedback data, input the feedback data into the machine learning module for online learning, dynamically optimize the threshold parameters in the rules or recommend new decision rules.

[0100] Specifically, in this invention, the step of "collecting system state changes after strategy execution to form feedback data, inputting the feedback data into a machine learning module for online learning, and dynamically optimizing threshold parameters in the rules or recommending new decision rules" is the core link in achieving system adaptive optimization. This step, by constructing a closed-loop feedback mechanism, enables the caching system to have the ability to continuously learn and self-evolve, thereby significantly improving the intelligence level of the strategy and the system's operating efficiency.

[0101] At the technical implementation level, the collection of feedback data relies on the continuous monitoring of cache access behavior by a sensor probe. This probe, through AOP or bytecode enhancement techniques, non-intrusively intercepts API calls from cache clients, generating structured access event objects. Each event object contains fields such as Key, Operation Type, Timestamp, Request Duration, and Hits. After the strategy is executed, changes in system state (such as database load, cache hit rate, and request latency) are recorded in real time and included as part of the feedback data, which is then transmitted back to the machine learning module in the streaming analytics decision-maker via the internal message bus.

[0102] The machine learning module employs online learning algorithms, continuously receiving feedback data and updating the model. Its inputs include decision instructions (such as HOTKEY_PROTECTION and CACHE_NULL) and their post-execution performance metrics (such as the decrease in database load and the increase in cache hit rate). The model automatically adjusts threshold parameters in the rules (such as the QPS threshold) by evaluating changes in system performance before and after policy execution. Optimized to Alternatively, new rules may be recommended (e.g., IF key_qps>800 AND db_load>60% THEN switch_to_write_behind).

[0103] At the parameter level, the frequency of feedback data collection should be consistent with the processing frequency of the event stream, typically in the millisecond range. The update cycle of the machine learning module can be configured to be once every 10 seconds to once per minute, depending on the business's requirements for strategy stability. The model evaluation function can be defined as... ,in Indicates the first Database load values ​​within a time window To evaluate the window length.

[0104] At the application level, this step is suitable for high-concurrency, dynamically changing internet business scenarios, such as e-commerce flash sales, news trending topics, and social media topic explosions. In these scenarios, the system needs to quickly respond to sudden surges in access to hot keywords and continuously optimize strategies through feedback mechanisms to minimize database pressure and improve cache hit rate.

[0105] The technical advantage of this step lies in the fact that, by introducing a feedback-driven online learning mechanism, the system can break free from its dependence on manual rules and achieve dynamic optimization and autonomous evolution of strategies. Compared to existing static automation solutions based on rule engines, this invention significantly improves the system's adaptability and intelligence level, providing crucial support for building a highly reliable, low-latency intelligent caching system.

[0106] The intelligent caching method based on adaptive caching strategy in this invention can achieve millisecond-level real-time response and fine-grained caching strategy control at the individual key level, effectively improving the adaptive capability and reliability of the caching system and reducing the dependence on manual rule configuration.

[0107] Furthermore, embodiments of the present invention also support dynamically adjusting the configuration parameters of the sliding time window based on the optimization results of the machine learning module. Or update the threshold in the rule base. To adapt to real-time changes in business scenarios.

[0108] Specifically, in some implementations, the configuration parameters of the sliding time window are dynamically adjusted based on the optimization results of the machine learning module. Or update the threshold in the rule base. This is one of the key steps in implementing the adaptive caching strategy in this invention. This step combines strategy decision-making with a feedback mechanism to form a closed-loop control, thereby improving the real-time response capability and intelligence level of the caching system.

[0109] At the technical implementation level, this step relies on the machine learning module in the streaming analytics decision maker to model and evaluate the effectiveness of historical decisions. Specifically, the machine learning module receives access event streams collected by perception probes, as well as system feedback data after policy executor execution (such as database load changes, cache hit rate fluctuations, request latency, etc.), and trains an online learning model based on this data. The model can employ techniques such as incremental learning or reinforcement learning to update the data in real time. and The optimal estimate. For example, when the system detects that the QPS of a certain key is consistently higher than the current threshold but no policy is triggered, the model will infer that the current threshold setting is too high and thus suggest lowering it. To improve the sensitivity of the strategy.

[0110] In terms of parameter metrics, sliding time window Configurations are typically set in milliseconds or seconds, for example. This indicates that the system updates the access statistics within the window once per second. The value can be dynamically adjusted according to the business scenario, and the initial value can be set to... This indicates that a hotspot protection policy is triggered when the number of requests per second for a key exceeds this value. The machine learning module continuously optimizes these parameters based on feedback data to adapt to dynamic changes in business load.

[0111] At the application level, this step is suitable for distributed systems with high concurrency and varied access patterns, such as e-commerce flash sales, real-time comment caching on live streaming platforms, and caching of trending content on social networks. In these scenarios, business traffic is characterized by sudden and unpredictable events, making it difficult for traditional static thresholds and fixed window configurations to respond in a timely manner. This invention, through a dynamic adjustment mechanism, enables the system to adaptively identify hot keywords and take protective measures, thereby effectively avoiding problems such as cache breakdown and cache avalanche.

[0112] From a technical perspective, this step significantly enhances the adaptability and intelligence of the caching system. Through continuous feedback and optimization of the strategy execution effect via the machine learning module, the system can automatically adjust key parameters without manual intervention, achieving more accurate hotspot identification and response. Furthermore, this mechanism enhances the system's robustness, enabling it to maintain stable operation when facing unknown or drastically changing business models, thereby improving the overall system performance and reliability.

[0113] To achieve the above embodiments, the present invention also proposes an intelligent caching device based on an adaptive caching strategy. Figure 2 This is a schematic diagram of a smart caching device based on an adaptive caching strategy, provided as an embodiment of the present invention. Figure 2 As shown, the device includes: The access event stream acquisition module 100 is used to collect the access event stream of each cache key in real time through the perception probe embedded in the cache client. The access event stream includes Key, operation type, timestamp, request source, whether it hits, and response time. The streaming processing module 200 is used to run a streaming processing engine inside the client based on the access event stream, and to calculate the access metrics for each key in real time using a sliding time window. The access metrics include instantaneous QPS and the number of consecutive misses. and short-term access frequency ; The rule engine matching module 300 is used to input the real-time calculated access metrics into the rule engine for online matching and generate decision instructions for a single key. The decision instructions include distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching. The strategy execution module 400 is used to directly execute the decision instructions in the client's memory through the strategy executor, without calling external interfaces to achieve nanosecond-level policy effectiveness; The machine learning optimization module 500 is used to collect system state changes after strategy execution to form feedback data, and input the feedback data into the machine learning module for online learning to dynamically optimize the threshold parameters in the rules or recommend new decision rules.

[0114] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0115] To implement the above embodiments, the present invention also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0116] To implement the above embodiments, the present invention also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0117] To implement the above embodiments, the present invention also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0118] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0119] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0120] This invention is intended to provide implementation schemes for users to selectively prevent the use or access to personal information data. That is, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information can be de-identified to protect user privacy.

[0121] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0122] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0123] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of the invention pertain.

[0124] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0125] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0126] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0127] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0128] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

[0129] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0130] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A smart caching method based on an adaptive caching strategy, characterized in that, Includes the following steps: S1, the access event stream of each cache key is collected in real time through the perception probe embedded in the cache client. The access event stream includes Key, operation type, timestamp, request source, whether it hits and response time; S2, Based on the access event stream, a streaming processing engine runs inside the client and uses a sliding time window to calculate the access metrics for each Key in real time. The access metrics include instantaneous QPS, number of consecutive misses, and short-term access frequency. S3, input the real-time calculated access metrics into the rule engine for online matching, and generate decision instructions for a single key. The decision instructions include distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching. S4, the decision instructions are executed directly in the client's memory through the policy executor, without calling external interfaces to achieve nanosecond-level policy effectiveness; S5. Collect system state changes after strategy execution to form feedback data, input the feedback data into the machine learning module for online learning, dynamically optimize the threshold parameters in the rules or recommend new decision rules.

2. The method as described in claim 1, characterized in that, The method of collecting access event streams for each cache key in real time through the perception probe embedded in the cache client also includes: S11 uses AOP or bytecode enhancement technology to non-intrusively intercept cached API calls and generate structured event objects containing key, operation type, timestamp, request source, hit status, and response time. S12, the structured event object is published to the client's internal message bus in real time to ensure low-latency transmission and processing of the event stream.

3. The method as described in claim 1, characterized in that, The streaming processing engine running inside the client based on the access event stream also includes: S21, configure the sliding time window to an adjustable millisecond or second-level time granularity, wherein the time window includes a dual-window structure of the most recent 1 second and 5 seconds; S22 calculates access metrics in real time for each Key within a sliding time window, including instantaneous QPS. Number of consecutive misses and short-term access frequency .

4. The method as described in claim 1, characterized in that, The step of inputting the real-time calculated access metrics into the rule engine for online matching also includes: S31, Dynamically load and update the rule base, the rule is defined as IF Real-time metrics in the stream processing engine meet the conditions THEN Trigger Action ; S32, the rule engine, is based on decision instructions for distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching, and utilizes a predefined policy mapping table. Translate instructions into specific execution logic.

5. The method as described in claim 1, characterized in that, The step of directly executing the decision instructions in the client's memory via the policy executor also includes: S41, when the decision instruction is to attach a distributed mutex lock, Redisson or a similar framework is used to lock the get request for the target key, and the lock holding time is specified. With sliding window time synchronous; S42, when the decision instruction is a read-write mode switch, the cache mode of the target key is switched from Cache-Aside to Write-Behind via a local memory queue. Asynchronous data persistence.

6. The method as described in claim 1, characterized in that, Also includes: Based on the optimization results of the machine learning module, the configuration parameters of the sliding time window are dynamically adjusted. Or update the threshold in the rule base. To adapt to real-time changes in business scenarios.

7. An intelligent caching device based on an adaptive caching strategy, characterized in that, include: The access event stream acquisition module is used to collect the access event stream of each cache key in real time through the perception probe embedded in the cache client. The access event stream includes Key, operation type, timestamp, request source, whether it hits, and response time. The streaming processing module is used to run a streaming processing engine inside the client based on the access event stream. It uses a sliding time window to calculate the access metrics for each key in real time. The access metrics include instantaneous QPS and the number of consecutive misses. and short-term access frequency ; The rule engine matching module is used to input the real-time calculated access metrics into the rule engine for online matching and generate decision instructions for a single key. The decision instructions include distributed mutex lock attachment, local TTL dynamic modification, and read / write mode switching. The strategy execution module is used to directly execute the decision instructions in the client's memory through the strategy executor, without calling external interfaces to achieve nanosecond-level strategy effectiveness; The machine learning optimization module is used to collect system state changes after strategy execution to form feedback data. The feedback data is then input into the machine learning module for online learning to dynamically optimize threshold parameters in the rules or recommend new decision rules.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-6.

Images