Data multi-level cache collaborative acceleration method and system
By employing a multi-level caching scheme with intelligent scheduling and collaborative optimization, the system dynamically calculates data popularity values and selects caching levels, thus solving the problem of unreasonable competition for cache resources in existing technologies. This improves cache hit rate and system throughput, reduces access latency and storage costs, and enhances stability and consistency in high-concurrency environments.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 山东数字人科技股份有限公司
- Filing Date
- 2026-01-30
- Publication Date
- 2026-05-12
AI Technical Summary
Existing multi-level caching solutions fail to fully consider the differences in data access frequency, size, and timeliness, resulting in unreasonable competition for cache resources between high-frequency small data and low-frequency big data. Furthermore, they lack efficient consistency synchronization mechanisms, making it difficult to meet the access requirements of high concurrency, low latency, and large capacity.
Through intelligent scheduling and collaborative optimization, the system dynamically calculates data popularity values, selects caching levels based on popularity values, adopts an asynchronous synchronization mechanism based on version control for data updates, and introduces cross-level cache data migration and collaborative cleanup operations to build a multi-level cache collaborative acceleration system.
Significantly improve cache hit rate and system throughput, reduce access latency and storage costs, enhance stability and data consistency under high concurrency, and achieve refined management and cost optimization of storage resources.
Smart Images

Figure CN122019412A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data caching acceleration technology, specifically a multi-level caching collaborative acceleration method and system based on heterogeneous storage hierarchy and scheduling. Background Technology
[0002] With the rapid development of precision medicine and digital pathology, the amount of data generated by a single biomedical specimen is growing exponentially, and it faces the triple challenges of high concurrency, low latency, and large capacity access in scenarios such as scientific research collaboration, AI training, and remote diagnosis. Traditional single-caching architectures, such as pure memory caching, are limited by physical capacity and cost; distributed caching is subject to network latency and single point of failure risks; and local file caching has low retrieval efficiency, all of which are difficult to meet the performance requirements of the above complex scenarios.
[0003] While multi-level caching solutions exist in existing technologies, they typically employ fixed hierarchical access orders and static scheduling strategies, failing to adequately consider differences in data access frequency, size, and timeliness. This leads to unreasonable competition for cache resources between high-frequency, small-data and low-frequency, large-data scenarios. Furthermore, the lack of efficient consistency synchronization mechanisms between multi-level caches often relies on full updates, resulting in significant redundant I / O overhead. Simultaneously, existing solutions lack elastic scaling and intelligent scheduling capabilities when facing dynamic changes in access patterns and sudden traffic surges, making them prone to cache breakdown and cascading failures, ultimately resulting in suboptimal overall cache efficiency and resource utilization.
[0004] Therefore, there is an urgent need for a multi-level caching acceleration method and system that can deeply integrate heterogeneous storage media and has intelligent scheduling and dynamic coordination capabilities, so as to achieve the optimal balance between storage cost and access efficiency while ensuring high performance and high availability. Summary of the Invention
[0005] The purpose of this invention is to provide a multi-level cache collaborative acceleration method and system based on heterogeneous storage hierarchy and scheduling. Through intelligent scheduling and collaborative optimization, it significantly improves cache hit rate and system throughput, reduces access latency and storage costs, and enhances stability and data consistency under high concurrency.
[0006] To achieve the above objectives, the present invention employs the following technical solution: On the one hand, the present invention provides a method for collaborative acceleration of multi-level data caching, comprising the following steps: Obtain access characteristic information of the data to be accessed; Based on the access feature information, the popularity value of the data to be accessed is calculated; Based on the popularity value and the preset popularity threshold range, the cache level that the data to be accessed should be accessed first is determined. The cache level includes high-speed memory cache, distributed shared cache and local file cache. If the data to be accessed is found in the specified cache level, then the data to be accessed is returned and its access record is updated. If a cache miss occurs, the optimal query path is selected based on the pre-built access path decision model, and a query is initiated at the next cache level until a cache miss occurs or the lowest cache level is reached. If the data is still not found in the lowest-level cache, it is loaded from persistent storage and written to all cache levels. During data access, cross-level cached data migration is dynamically triggered based on real-time changes in data popularity, and collaborative cleanup operations are performed on each cache level. When data is updated, an asynchronous synchronization mechanism based on version control is used to synchronize the updated content to each cache level step by step.
[0007] Preferably, the popularity value of the data to be accessed is calculated based on the access feature information, specifically as follows: Construct and maintain a sliding time window with a fixed time length to count the number of real-time accesses of the data within the sliding time window; Obtain the historical cumulative access count of the data to be accessed, and apply an exponential decay function to perform a weighted calculation on the historical cumulative access count, wherein the decay coefficient of the exponential decay function is dynamically set according to the access pattern of the data type. The byte size of the data to be accessed is converted into a standardized storage cost factor, which is inversely proportional to the data size. The proportion of the remaining valid time for extracting the data to be accessed to the initial valid time is used as a timeliness factor; The real-time access count, the historical access count after exponential decay weighting, the standardized storage cost factor, and the timeliness factor are normalized to obtain the corresponding feature values. Based on preset initial weight coefficients and real-time analysis results of current system load and data access patterns, the weights of each feature value are dynamically adjusted. The adjustment process adopts an online learning algorithm based on gradient descent. Based on the dynamically adjusted weights, the normalized feature values are linearly weighted and summed to calculate the overall popularity value of the data. The comprehensive popularity value is input into a neural network-based calibration model for post-processing to eliminate popularity bias under different data access modes, and the final dynamic popularity value is output.
[0008] Preferably, the caching level is determined based on the popularity value, including: If the popularity value reaches the first threshold, it is determined to be high-popularity data and high-speed memory cache is accessed first. If the popularity value reaches the second threshold but is lower than the first threshold, it is determined to be medium-hot data and the distributed shared cache is accessed first. If the popularity value is lower than the second threshold, it is determined to be low-population data, and local file cache is accessed first. The popularity threshold is dynamically adjusted based on historical access patterns using a machine learning model.
[0009] Preferably, the machine learning model is an LSTM prediction model trained based on historical access sequences, used to dynamically adjust the first threshold and the second threshold according to the access trend.
[0010] Preferably, the optimal query path is selected based on a pre-built access path decision model, including: Construct a routing table with access latency, data popularity, and hierarchical load as decision factors; Predict the optimal cache access path using a decision model based on predefined rules and real-time weights; Based on the prediction results, dynamically select whether to skip intermediate cache levels for querying.
[0011] Preferably, the collaborative cleanup operation includes: Calculate the cleanup priority score based on the real-time popularity value of the data and the storage cost; Data to be cleaned is sorted in ascending order of priority score; Based on the current usage rate of each cache level and the preset cleanup ratio, perform tiered cleanup: clean up 15%-25% of the excess portion of the high-speed memory cache, clean up 25%-35% of the distributed shared cache, and clean up 35%-45% of the local file cache.
[0012] Preferably, a cache preloading step is also included: Predict hot data within a specified future time period based on time series analysis models; When the system load is below a set threshold, the predicted hot data will be asynchronously preloaded into a high-speed memory cache or a distributed shared cache.
[0013] On the other hand, the present invention also provides a multi-level data caching collaborative acceleration system for implementing the multi-level data caching collaborative acceleration method described above, comprising: The configuration management module is used to dynamically enable or disable caching at each level, and to set the capacity limit, expiration time and connection parameters for each caching level; The intelligent scheduling module is used to acquire data access characteristics, calculate popularity values, and select cache access paths based on popularity values; The routing optimization module is used to build and execute access path decision models to optimize the order of cross-level queries; The heterogeneous storage module includes a high-speed memory cache unit, a distributed shared cache unit, and a local file cache unit, which are used to store data with different frequencies of use. The consistency guarantee module is used to achieve asynchronous data synchronization between multi-level caches based on version control protocols; The elastic management module is used to monitor the usage rate of caches at all levels, dynamically adjust the cleanup threshold and capacity allocation, and perform collaborative cleanup. The prediction preloading module is used to predict hot data based on machine learning models and trigger cache preloading operations.
[0014] Preferably, the high-speed memory cache unit adopts a dual-mode eviction strategy that supports both absolute and relative expiration; the distributed shared cache unit uses an asynchronous notification mechanism based on version control to synchronously update the local cache unit; and the local file cache unit uses a two-level directory structure based on hash mapping to organize cache files.
[0015] Preferably, it also includes a high-concurrency protection module for: When hot data access is detected, a mutex lock is enabled, and a lock wait time limit is set; Add a random offset to the expiration time of cached data; Perform automatic failover when a cache node fails.
[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. Significantly improve caching efficiency and access performance: This invention uses a dynamic hierarchical scheduling mechanism based on data popularity to ensure that data with high access frequency resides in the high-speed storage layer first, effectively improving cache hit rate, significantly reducing data access latency, and improving the overall throughput of the system.
[0017] 2. Enhance system adaptability and intelligence: This invention introduces a dynamically adjustable heat calculation model and access path decision mechanism, enabling the system to automatically optimize data layout and query routing based on real-time access patterns, adapting to diverse and changing business scenarios.
[0018] 3. Achieve refined management and cost optimization of storage resources: This invention achieves the best balance between performance and cost by using differentiated storage strategies and flexible capacity control to ensure high performance while making reasonable use of storage media at all levels, avoiding resource idleness or over-allocation.
[0019] 4. Ensure system stability and reliability under high concurrency: This invention has a built-in cache breakdown and avalanche protection mechanism, supports automatic fault switching and asynchronous consistency synchronization, and ensures that the system can still maintain high availability and data consistency when there is a sudden traffic surge or node anomaly.
[0020] 5. Supports flexible expansion and wide applicability: The system architecture of this invention is modularly designed, allowing users to configure caching levels and strategies as needed, and can be adapted to various high-concurrency, low-latency data service scenarios such as biomedical big data, cloud computing, and edge computing. Attached Figure Description
[0021] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the system structure of the present invention. Detailed Implementation
[0022] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be understood that after reading the teachings of this invention, those skilled in the art can make various alterations or modifications to the invention, and these equivalent forms also fall within the scope defined in this application.
[0023] In this invention, terms such as "upper," "lower," "left," "right," "front," "back," "vertical," "horizontal," "side," and "bottom" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are used only to facilitate the description of the structural relationships of the various components or elements of this invention and do not specifically refer to any component or element in this invention. They should not be construed as limiting the invention.
[0024] Example 1: like Figure 1 As shown, this embodiment provides a method for collaborative acceleration of multi-level data caching, including the following steps: Obtain access characteristic information of the data to be accessed; Calculate the popularity value of the data to be accessed based on access feature information; Based on the popularity value and the preset popularity threshold range, the cache level that the data to be accessed should be accessed first is determined. The cache levels include high-speed memory cache, distributed shared cache and local file cache. If the data to be accessed is found in the specified cache level, then the data to be accessed is returned and its access record is updated. If a cache miss occurs, the optimal query path is selected based on the pre-built access path decision model, and a query is initiated at the next cache level until a cache miss occurs or the lowest cache level is reached. If the data is still not found in the lowest-level cache, it is loaded from persistent storage and written to all cache levels. During data access, cross-level cached data migration is dynamically triggered based on real-time changes in data popularity, and collaborative cleanup operations are performed on each cache level. When data is updated, an asynchronous synchronization mechanism based on version control is used to synchronize the updated content to each cache level step by step.
[0025] like Figure 2 As shown, this embodiment also provides a multi-level data caching collaborative acceleration system for implementing the multi-level data caching collaborative acceleration method as described in any one of claims 1-7, characterized in that it includes: The configuration management module is used to dynamically enable or disable caching at each level, and to set the capacity limit, expiration time and connection parameters for each caching level; The intelligent scheduling module is used to acquire data access characteristics, calculate popularity values, and select cache access paths based on popularity values; The routing optimization module is used to build and execute access path decision models to optimize the order of cross-level queries; The heterogeneous storage module includes a high-speed memory cache unit, a distributed shared cache unit, and a local file cache unit, which are used to store data with different frequencies of use. The consistency guarantee module is used to achieve asynchronous data synchronization between multi-level caches based on version control protocols; The elastic management module is used to monitor the usage rate of caches at all levels, dynamically adjust the cleanup threshold and capacity allocation, and perform collaborative cleanup. The prediction preloading module is used to predict hot data based on machine learning models and trigger cache preloading operations. High-concurrency protection module, used for: When hot data access is detected, a mutex lock is enabled, and a lock wait time limit is set; Add a random offset to the expiration time of cached data; Perform automatic failover when a cache node fails; Among them, the high-speed memory cache unit adopts a dual-mode eviction strategy that supports both absolute expiration and relative expiration; The distributed shared cache unit adopts an improved MESI consistency protocol and is synchronously updated to the local cache unit through an asynchronous notification mechanism; The local file cache unit uses a two-level directory structure based on hash mapping to organize cache files.
[0026] This embodiment uses the efficient access to three-dimensional reconstructed specimen models in the biomedical field as a specific application scenario to provide a detailed description of the above methods and systems.
[0027] 1. System initialization and configuration: When the system starts, the configuration management module initializes the cache at all levels according to preset policies: Level 1 cache (high-speed memory cache): The initial capacity is set to 0, a pre-allocation mechanism is adopted, the maximum capacity is configured to 4GB, and the eviction policy is set to support both absolute expiration (TTL=30 minutes) and relative expiration (20 minutes after the last access). Second-level cache (Redis distributed cache): Enable connection pool optimization, set the minimum number of idle connections to 5, the maximum number of concurrent connections to 50, the capacity limit to 10GB, and use the volatile-lru eviction policy for model data; Three-level cache (local file cache): The root directory is set to / cache / models / , and a two-level hash directory structure is adopted (the first two digits of the MD5 value of the key are used as the first-level subdirectory, and the 3rd and 4th digits are used as the second-level subdirectory). The total capacity limit is configurable (e.g., set to 200GB), and the number of files in a single directory is configurable (e.g., 1000).
[0028] 2. Implementation of dynamic heat calculation and intelligent scheduling: When a user requests access to a 3D model (key: specimen_001_3d_model), the system executes the following procedure: Step 1: Access Feature Collection and Popularity Calculation: The data feature recognition module collects the access characteristics of this key in real time: Access frequency T: Statistically calculated using a sliding time window (window size = 5 minutes), the number of accesses within the current window is 15. Data size S: The model file size is 850MB; Timeliness: The initial TTL for this data is 24 hours, and the remaining TTL is 18 hours; Access pattern: This data shows a "read-heavy, write-light" characteristic over the past hour (read-write ratio = 20:1); The heat calculation engine performs fusion calculations: (1) Sliding window statistics: Current window access frequency (Assuming the window can record a maximum of 50 times); (2) Exponential decay weighting: The historical cumulative number of visits is weighted by a decay coefficient. Weighting: ; (3) Storage cost factor: ; (4) Timeliness factor: ; (5) Dynamic weight adjustment: When the system detects that the current period is a peak business period, it automatically adjusts the weight coefficients: (Frequency weighting increase) (Size weight) (Timeliness weight); (6) Linear weighted calculation: ; (7) Neural network calibration: Input a pre-trained 3-layer fully connected network (trained based on historical access patterns), output calibrated popularity values. ; Step 2: Intelligent scheduling decision: Preset heat threshold: (High fever) (Medium heat); because The data was determined to be of medium heat capacity. The scheduling decision engine decides to prioritize accessing the second-level cache (Redis) and set a flag. If a cache hit occurs, the data will be asynchronously preheated to the first-level cache. Step 3: Route optimization execution: The routing optimization module queries the pre-built routing decision table and finds that in past accesses of this type of 3D model data, if the second-level cache is hit, the latency of direct return (average 8ms) is lower than that of the "second-level → first-level → return" path (average 12ms). When the second-level cache is hit, the data is returned directly, and the first-level cache is updated asynchronously, instead of synchronously waiting for the first-level cache to be updated.
[0029] 3. Multi-level cache query and data loading process: Step 4: Cache level query: (1) Based on the scheduling decision, first query the second-level cache (Redis); (2) Redis cache hit, return model data; (3) The asynchronous synchronous thread starts immediately and writes the data to the first-level cache (memory); (4) Return data to the client and record that the second-level cache was hit during this access; Step 5: Handling cache misses (simulated scenario): If the L2 cache is not hit, the process continues: (1) Query the three-level cache (local files); (2) The file system finds the cache file at the path / cache / models / 8f / 3c / specimen_001_3d_model.bin; (3) Load the file into memory, and simultaneously: write to the second-level cache (Redis); asynchronously write to the first-level cache; update the popularity value (this access will increase the popularity of this data). (4) If the three-level cache is still not hit, the original model file is loaded from the underlying object storage, which takes about 2-3 seconds. After loading, it is written to all three-level caches at the same time.
[0030] 4. Implementation of consistency guarantee mechanism: When the model data is updated (e.g., researchers upload a new version of the 3D reconstruction results): (1) The system maintains an integer version number for each cache entry, and the version number is incremented when updating; (2) Asynchronous and synchronous: First, update the master data in persistent storage; then update the first-level cache, marking the old version data as "to be invalidated"; asynchronous threads update the second-level and third-level caches in sequence; if synchronization fails, enter the retry queue, with the retry strategy as follows: wait 100ms for the first retry, 300ms for the second, and 900ms for the third. (3) Read consistency check: When the client reads, it carries the version number obtained last time. If it does not match the version number in the cache, the cache update process is triggered.
[0031] 5. Collaborative cleanup and flexible management: The system performs a cache status assessment and cleanup every 5 minutes. Step 6: Monitoring Indicator Collection: Level 1 cache utilization: 78% (close to the threshold of 80%); Level 2 cache utilization: 65%; Level 3 cache utilization: 45%; Hit rate at each level: Level 1 85%, Level 2 70%, Level 3 40%; Step 7: Dynamic cleanup execution: (1) Cleanup priority calculation: Calculate for all entries in the first-level cache: ; Storage cost coefficients: Level 1 cache is 3.0 (maximum), Level 2 is 2.0, and Level 3 is 1.0; (2) Layered proportion cleanup: Level 1 cache: Clean up the 20% of entries with the lowest priority (usage rate drops from 78% to 62%). Second-level cache: Clean up the 30% of entries with the lowest priority; Level 3 cache: Clean up the 40% of entries with the lowest priority and merge fragmented files; (3) Flexible capacity adjustment: If the L1 cache hit rate is consistently above 80%, its capacity limit will be automatically adjusted from 4GB to 5GB. The secondary cache connection pool is dynamically adjusted based on the number of concurrent connections: with a current concurrency of 35, the maximum number of connections will be adjusted from 50 to 60.
[0032] 6. Preloading mechanism implementation: The system performs predictive preloading during off-peak hours at night: Step 8: Hotspot Prediction: The predictive preloading module uses an LSTM time series model to analyze historical access patterns; Hotspot models that predict the period from 9:00 to 11:00 the following day include: specimen_001_3d_model, specimen_005_3d_model, etc. The prediction confidence level is 82%; Step 9: Asynchronous preloading: (1) Start the preloading task when the system load is below 20% at 3:00 AM; (2) Load the five predicted hot spot models from the third-level cache or persistent storage to the second-level cache; (3) Three of the most popular models (with a predicted access probability greater than 90%) are additionally loaded into the first-level cache; (4) The preloading process uses rate limiting to avoid affecting normal service. 7. High concurrency protection mechanism: When a sudden surge of concurrent requests accesses the same hotspot model: Step 10: Penetration of Protection: The first request that fails acquires the distributed lock (Redis Lock) with a timeout of 100ms; other concurrent requests wait for the lock to be released or fail quickly and return a downgraded result; once the data is loaded, the lock is released immediately and the cache is updated. Step 11: Avalanche Protection: The expiration time of all cached entries is increased by a random offset of ±10%; when a large number of caches expire at the same time, an alert is triggered and automatic cleanup is paused; when a secondary cache node fails, it automatically switches to a backup node within 5 seconds.
[0033] Example 2: This embodiment uses interactive browsing of digital pathology panoramic scan image sequences as an application scenario. In this scenario, users need to quickly browse thousands of high-resolution pathology slide images, and the image sequences have strong spatial and temporal locality access characteristics.
[0034] 1. Scene characteristics and customized configuration: Data characteristics: A single slice of image is typically between several KB and several MB in size; a complete sequence can contain tens of millions of images. Access patterns: Users typically browse in spatial order (adjacent areas) or chronological order (continuous slices); The system is specially configured as follows: Level 1 cache: 8GB capacity (increased to accommodate more adjacent images); Spatial locality optimization enabled; Preloaded adjacent images: 3; Second-level cache: 20GB capacity; uses Redis Hash to store image sequence metadata; uses protobuf compression serialization with a compression ratio of approximately 40%. The directory structure is as follows: / cache / slides / {slide_id} / {z_level} / {tile_x}_{tile_y}.jpg; Maintain an index file for each sequence to speed up localization; The index file is: Maintain a B+ tree index file for each sequence.
[0035] 2. Implementation of intelligent scheduling and route optimization Step 1: Access Pattern Recognition When a user begins browsing the slide_2023_001 sequence: The data feature recognition module detected a serialized access pattern: continuous access. Adjacent coordinate images of layers; The access was identified as having strong spatial locality (adjacent coordinate images were accessed within 15 seconds). Step 2: Optimization of Dynamic Heat Calculation: For serialized access, the heat calculation uses special optimizations: ; in, Calculated based on spatial / temporal proximity of the most recent 10 visits; As a local weight, the current scene is set to 0.4; the current image popularity in the sequence is 0.65, and the popularity of adjacent images is 0.52. Step 3: Intelligent Routing Decision: The routing optimization module makes decisions based on predefined locality rules (e.g., loading image files with adjacent coordinates based on the currently accessed layer and coordinates). In an actual request, the system dynamically determines the range of adjacent files that need to be preloaded based on parameters such as the input view coordinates.
[0036] 3. Multi-level caching collaborative workflow: Step 4: Image sequence access process: The user requested the image slide_2023_001 / z5 / 100_150.jpg: (1) Heat calculation: The data was determined to be high-temperature data. (2) Prioritize querying the first-level cache (85% hit rate); (3) If no match is found, query the second-level cache (Redis Hash structure, quickly locate by slide_id and z_level). (4) The second-level cache returns image data, and at the same time updates the first-level cache and asynchronously loads three adjacent images (100_151), (101_150), and (101_151) into the first-level cache; Step 5: Optimize sequence metadata caching: Sequence metadata (image coordinate list, resolution information) is cached separately; Metadata popularity is calculated using different weights (with a higher weight for timeliness); When metadata is updated, all cache nodes are notified via a publish / subscribe mechanism.
[0037] 4. Special mechanism for consistency assurance: Step 6: Partial Update Synchronization: When the metadata of a pathological image (such as coordinate list, resolution) is updated: (1) Meta-information data (such as JSON format) is stored independently of image file data; (2) Only metadata data is synchronized during the update, without triggering the complete image cache invalidation; (3) Version number mechanism: Image file version and metadata version are maintained independently; (4) The client can independently obtain image files and the latest metadata; Step 7: Batch sequence update: When the entire sequence is rescanned: (1) Generate a new sequence ID: slide_2023_001_v2; (2) Old sequence cache data is marked as "historical version" and a shorter TTL (1 hour) is set. (3) New sequences are cached according to the normal procedure; (4) Ensure that both versions are accessible during the transition period.
[0038] 5. Optimization of collaborative cleanup strategy: Step 8: Cleanup based on access patterns: For image sequence data, the cleaning strategy is specially designed: (1) Sequence integrity protection: All images in the same sequence are either cleaned up or all are retained; (2) Recently used sequence protection: Complete sequences accessed within the last hour will not be cleaned up, even if some images have low heat. (3) Adjustment of the tiered cleanup ratio: Level 1 cache: 15% cleaned (lower than usual, to protect sequence integrity); Level 2 cache: 25% cleaned; Level 3 cache: 30% cleaned.
[0039] Step 9: Defragmentation and Optimization: Regularly clean up image files in the L3 cache: (1) Perform fragment merging once every 24 hours; (2) Merge small files (less than 10MB) into large blocks (128MB each); (3) Maintain an independent block index file to accelerate the localization of small images.
[0040] 6. Deep optimization of the preloading mechanism: Step 10: Prediction based on browsing behavior: (1) User behavior analysis: Record user browsing path, dwell time, and zoom level; (2) LSTM prediction model: Input the last 20 operations and predict the 5 regions that may be visited next; (3) Confidence threshold: Preloading is only performed when the prediction confidence is >75%; Step 11: Tiered preloading strategy: Based on prediction confidence and image level (resolution level): High confidence (greater than 90%) plus base level (z=0): preloaded into the first-level cache; Medium confidence (75-90%) plus base level: preloaded into the second-level cache; High confidence level plus level of detail ( ): Only preloaded to the level 3 cache.
[0041] 7. Performance monitoring and flexible adjustment: Step 12: Real-time monitoring metrics: Key system monitoring metrics: Request latency P99: Level 1 cache less than 1ms, Level 2 cache less than 10ms, Level 3 cache less than 50ms; Sequence browsing completion time: decreased from an average of 12.3 seconds to 4.8 seconds; Cache hit rate: Overall improved from 58% to 89%; Memory utilization: Stable within the optimal range of 70-75%; Step 13: Dynamic parameter adjustment: Automatic adjustment based on monitoring data: (1) When the L1 cache hit rate is consistently greater than 90%, gradually increase its capacity (increase by 10% each time). (2) When a large number of serialization accesses are detected, the "adjacent preload count" parameter is automatically increased; (3) Dynamically adjust the parameters of the secondary cache connection pool according to changes in network latency. The above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.
Claims
1. A method for collaborative acceleration of multi-level data caching, characterized in that, Includes the following steps: Obtain access characteristic information of the data to be accessed; Based on the access feature information, the popularity value of the data to be accessed is calculated; Based on the popularity value and the preset popularity threshold range, the cache level that the data to be accessed should be accessed first is determined. The cache level includes high-speed memory cache, distributed shared cache and local file cache. If the data to be accessed is found in the specified cache level, then the data to be accessed is returned and its access record is updated. If a cache miss occurs, the optimal query path is selected based on the pre-built access path decision model, and a query is initiated at the next cache level until a cache miss occurs or the lowest cache level is reached. If the data is still not found in the lowest-level cache, it is loaded from persistent storage and written to all cache levels. During data access, cross-level cached data migration is dynamically triggered based on real-time changes in data popularity, and collaborative cleanup operations are performed on each cache level. When data is updated, an asynchronous synchronization mechanism based on version control is used to synchronize the updated content to each cache level step by step.
2. The data multi-level caching collaborative acceleration method according to claim 1, characterized in that, Based on the access feature information, the popularity value of the data to be accessed is calculated as follows: Construct and maintain a sliding time window with a fixed time length to count the number of real-time accesses of the data within the sliding time window; Obtain the historical cumulative access count of the data to be accessed, and apply an exponential decay function to perform a weighted calculation on the historical cumulative access count, wherein the decay coefficient of the exponential decay function is dynamically set according to the access pattern of the data type. The byte size of the data to be accessed is converted into a standardized storage cost factor, which is inversely proportional to the data size. The proportion of the remaining valid time for extracting the data to be accessed to the initial valid time is used as a timeliness factor; The real-time access count, the historical access count after exponential decay weighting, the standardized storage cost factor, and the timeliness factor are normalized to obtain the corresponding feature values. Based on preset initial weight coefficients and real-time analysis results of current system load and data access patterns, the weights of each feature value are dynamically adjusted. The adjustment process adopts an online learning algorithm based on gradient descent. Based on the dynamically adjusted weights, the normalized feature values are linearly weighted and summed to calculate the overall popularity value of the data. The comprehensive popularity value is input into a neural network-based calibration model for post-processing to eliminate popularity bias under different data access modes, and the final dynamic popularity value is output.
3. The data multi-level caching collaborative acceleration method according to claim 2, characterized in that, The cache level is determined based on the popularity value, including: If the popularity value reaches the first threshold, it is determined to be high-popularity data and high-speed memory cache is accessed first. If the popularity value reaches the second threshold but is lower than the first threshold, it is determined to be medium-hot data and the distributed shared cache is accessed first. If the popularity value is lower than the second threshold, it is determined to be low-population data, and local file cache is accessed first. The popularity threshold is dynamically adjusted based on historical access patterns using a machine learning model.
4. The data multi-level caching collaborative acceleration method according to claim 3, characterized in that, The machine learning model is an LSTM prediction model trained based on historical access sequences, which is used to dynamically adjust the first threshold and the second threshold according to the access trend.
5. The data multi-level caching collaborative acceleration method according to claim 1, characterized in that, The optimal query path is selected based on a pre-built access path decision model, including: Construct a routing table with access latency, data popularity, and hierarchical load as decision factors; Predict the optimal cache access path using a decision model based on predefined rules and real-time weights; Based on the prediction results, dynamically select whether to skip intermediate cache levels for querying.
6. The data multi-level caching collaborative acceleration method according to claim 1, characterized in that, Collaborative cleanup operations include: Calculate the cleanup priority score based on the real-time popularity value of the data and the storage cost; Data to be cleaned is sorted in ascending order of priority score; Based on the current usage rate of each cache level and the preset cleanup ratio, perform tiered cleanup: clean up 15%-25% of the excess portion of the high-speed memory cache, clean up 25%-35% of the distributed shared cache, and clean up 35%-45% of the local file cache.
7. The data multi-level caching collaborative acceleration method according to claim 1, characterized in that, It also includes a cache preloading step: Predict hot data within a specified future time period based on time series analysis models; When the system load is below a set threshold, the predicted hot data will be asynchronously preloaded into a high-speed memory cache or a distributed shared cache.
8. A multi-level data caching collaborative acceleration system, used to implement the multi-level data caching collaborative acceleration method as described in any one of claims 1-7, characterized in that, include: The configuration management module is used to dynamically enable or disable caching at each level, and to set the capacity limit, expiration time and connection parameters for each caching level; The intelligent scheduling module is used to acquire data access characteristics, calculate popularity values, and select cache access paths based on popularity values; The routing optimization module is used to build and execute access path decision models to optimize the order of cross-level queries; The heterogeneous storage module includes a high-speed memory cache unit, a distributed shared cache unit, and a local file cache unit, which are used to store data with different frequencies of use. The consistency guarantee module is used to achieve asynchronous data synchronization between multi-level caches based on version control protocols; The elastic management module is used to monitor the usage rate of caches at all levels, dynamically adjust the cleanup threshold and capacity allocation, and perform collaborative cleanup. The prediction preloading module is used to predict hot data based on machine learning models and trigger cache preloading operations.
9. A multi-level data caching collaborative acceleration system according to claim 8, characterized in that, The high-speed memory cache unit adopts a dual-mode eviction strategy that supports both absolute and relative expiration; the distributed shared cache unit uses an asynchronous notification mechanism based on version control to synchronously update the local cache unit. The local file caching unit organizes cached files using a two-level directory structure based on hash mapping.
10. A multi-level data caching collaborative acceleration system according to claim 8, characterized in that, It also includes a high-concurrency protection module, used for: When hot data access is detected, a mutex lock is enabled, and a lock wait time limit is set; Add a random offset to the expiration time of cached data; Perform automatic failover when a cache node fails.