A hotspot-oriented high-concurrency read-write strong consistency dynamic hierarchical cache implementation method
Patent Information
- Application Number
- CN202610465815.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-09
- Publication Date
- 2026-08-21
AI Technical Summary
[0005]为了改进上述现有技术的缺陷，本发明的目的在于提供一种面向热点高并发读写的强一致动态分级缓存实现方法，解决传统缓存架构热点识别不准、并发更新冲突、缓存与数据库数据不一致、响应时延偏高的问题，最终实现热点动态识别、无锁原子更新、缓存强一致同步、分级高效读取，在保证强一致性的前提下显著提升高并发读写性能
[0029](1)热点动态精准管理：采用滑动窗口实时计算热度，动态识别热点并预加载常驻，L1缓存命中率显著提升，缓存资源利用率最大化；
Smart Images
Figure CN122614906A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of distributed system caching technology, and in particular to a strongly consistent dynamic hierarchical caching implementation method for high-concurrency read and write operations, which is suitable for business scenarios that have high requirements for both data consistency and access response speed, such as high-concurrency flash sales, inventory deduction, account balance changes, and access to hot content. Background Technology
[0002] In high-concurrency distributed systems, caching is a core technical means to alleviate database pressure and improve system response speed. With the surge in internet business traffic, high-concurrency read and write scenarios for hot data frequently occur, and traditional caching architectures face multiple technical challenges: First, hot data identification relies on static configuration and cannot be dynamically adjusted according to real-time access traffic, resulting in non-hot data occupying cache resources and a low cache hit rate for hot data; Second, when multiple nodes update concurrently, data inconsistency is prone to occur between the database and the cache. Traditional delayed double-delete and asynchronous update strategies have obvious time windows, causing dirty reads and phantom reads, and failing to meet strong consistency requirements; Third, multi-level cache collaboration efficiency is low, read paths are not optimized hierarchically, local cache and distributed cache linkage is insufficient, and overall response latency is high; Fourth, there is a lack of a unified consistency and performance quantification monitoring mechanism, making it impossible to intuitively evaluate cache consistency status and system service capabilities.
[0003] Existing caching technologies suffer from the following main drawbacks: First, hot data is managed statically without employing a sliding window real-time calculation model, making it impossible to accurately capture instantaneous hotspots, and preloading and persistent strategies are lagging. Second, concurrent update control largely relies on pessimistic locking or distributed locks, leading to intense lock contention and reduced system throughput, and version number optimistic locking is not used to achieve lock-free atomic updates. Third, cache synchronization often uses asynchronous delayed tasks, resulting in a time lag between database transaction commits and cache updates, a large inconsistency window, and difficulty in guaranteeing strong consistency. Finally, the read process is not strictly hierarchically divided into local memory, distributed cache, and database, the cache missing backfill mechanism is imperfect, and performance improvement is limited.
[0004] The difficulty in balancing strong consistency and high concurrency performance is a core pain point in the current caching field. There is an urgent need for a dynamic hierarchical caching implementation method that can dynamically identify hotspots, atomically control updates, synchronize caches in real time, optimize reads in a tiered manner, and support quantitative monitoring. Summary of the Invention
[0005] To overcome the shortcomings of existing technologies, the present invention aims to provide a strongly consistent dynamic hierarchical cache implementation method for high-concurrency read and write operations, addressing the problems of inaccurate hotspot identification, concurrent update conflicts, inconsistencies between cache and database data, and high response latency in traditional cache architectures. Ultimately, it achieves dynamic hotspot identification, lock-free atomic updates, strong cache consistency synchronization, and hierarchical efficient reading, significantly improving high-concurrency read and write performance while ensuring strong consistency. Its main steps include:
[0006] S1. Construct a two-level cache architecture: Initialize L1 local memory cache and L2 distributed cache, maintain a hot data statistics mechanism, configure a version number field for each cached data, and form a multi-level cache hierarchical structure.
[0007] S2. Dynamic identification of hot data: Calculate the data popularity score in real time based on the access traffic per unit time, and determine whether it is hot data according to the popularity score and preset threshold. For hot data that meets the conditions, implement preloading and resident strategies.
[0008] S3. Atomic update control based on version number optimistic locking: When receiving a data write request, first read the current data version number in the database, and carry the version number for comparison and verification when performing database update operation. Only when the version number matches will the update be performed and a new version number be generated.
[0009] S4. Cache synchronization update mechanism: After the database transaction is committed, the updated data and the new version number are immediately written to the L1 local cache and L2 distributed cache. Asynchronous delayed tasks are not used to avoid data inconsistency caused by time difference between the cache and the database.
[0010] S5. Tiered Reading and Missing Data Filling: When a read request is received, the data is queried in the order of L1 cache, L2 cache, and database. If the L1 cache misses but the L2 cache hits, the data is filled back into the L1 cache to improve the efficiency of subsequent accesses.
[0011] S6. Real-time monitoring of consistency and performance indicators: The system internal modules statistically analyze cache hit rate, average response time and number of dirty reads to form quantitative indicators for system performance monitoring and consistency evaluation.
[0012] In step S1, the L1 cache uses a local memory cache, the L2 cache uses a distributed cache, and the version number uses a long integer auto-incrementing sequence.
[0013] In step S2, the data popularity score uses a sliding window counting model, and the calculation formula is as follows:
[0014]
[0015] Among them, H i(t) represents the total number of times data i is accessed within the time window w; tw is the starting position of the sliding window, used to limit the popularity calculation to only cover the most recent w access requests, excluding historical expired access data, and ensuring the real-time nature of the popularity score; req k The data identifier for the k-th request; id i H is the unique ID of the i-th data; I is an indicator function that takes the value 1 when a match is found, and 0 otherwise; when H i When (t)≥θ, data i is identified as hot data and loaded into the L1 cache, where θ is the preset hot data identification threshold.
[0016] In step S3, the logic for determining the success of the version number optimistic lock update satisfies the following relationship:
[0017]
[0018] Among them, V db V represents the current storage version number of the database. req To include the version number in the write request; when P success When the value is 0, a concurrent update conflict is determined, and retry or rollback logic is executed.
[0019] In step S4, the cache inconsistency time window W under the synchronization update strategy is... sync satisfy:
[0020] W sync =T cache_update -T db_commit ≈0
[0021] Among them, T db_commit T is the time when the database transaction is committed and completed. cache_update The update execution time is cached; this time window is much smaller than the inconsistency window of the traditional delayed double-delete strategy, thus significantly reducing the risk of dirty reads.
[0022] In step S5, the overall average response time model of the system is as follows:
[0023] T avg =P L1 ·T mem +(1-P L1 )·(T L2 +T net )+P miss ·T db
[0024] Among them, P L1 T represents the L1 cache hit rate. mem For memory access time, T L2 For the time consumed by distributed cache access, T net For network transmission time, Pmiss T represents the total cache miss rate. db Database query time; in scenarios with concentrated hotspots, P L1 Approaching 1, the average response time is brought close to the memory access speed.
[0025] In step S6, the dirty read rate is calculated using the following formula:
[0026]
[0027] Among them, V resp The version number of the response data; V latest C is the latest version number of the database. count (V resp <V latest Total represents the number of requests that returned data versions that were later than the latest version. requests The total number of requests; when R dirty When = 0, the system reaches a strongly consistent state.
[0028] The advantages of this invention compared to the prior art are mainly reflected in:
[0029] (1) Dynamic and precise management of hotspots: The sliding window is used to calculate the heat in real time, dynamically identify hotspots and preload them to be resident, significantly improving the L1 cache hit rate and maximizing the utilization of cache resources.
[0030] (2) Strong consistency guarantee: Version number optimistic locking realizes lock-free atomic update. After the database transaction is committed, the two-level cache is refreshed synchronously, and the inconsistency time window approaches 0, effectively avoiding dirty reads.
[0031] (3) High-concurrency performance optimization: hierarchical reading and missing backfilling optimize the access path, the average response time is close to the memory access speed, lock-free updates reduce lock contention, and the overall system response efficiency is higher;
[0032] (4) Quantifiable monitoring and maintenance: Provides quantitative indicators such as cache hit rate, response time, and dirty read rate, which can intuitively evaluate the system consistency status and service performance, and facilitate system optimization.
[0033] In summary, this invention provides a dynamic hierarchical caching implementation method that combines a two-level caching architecture, dynamic hotspot identification, optimistic version locking, synchronous cache updates, hierarchical read-and-fill, and quantitative monitoring. This method effectively solves problems such as data inconsistency, weak hotspot handling, and large response fluctuations in traditional caching schemes. It improves system concurrency and access speed while ensuring strong consistency, demonstrating strong engineering practicality and broad application prospects. Attached Figure Description
[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the embodiments will be briefly introduced below.
[0035] Figure 1 This is an overall flowchart of the method of the present invention;
[0036] Figure 2 This is a schematic diagram of the two-level caching architecture and data flow of the method of the present invention;
[0037] Figure 3 This is a schematic diagram of the optimistic locking update control process for the version number of the method of the present invention; Detailed Implementation
[0038] Example 1:
[0039] See Figure 1 The present invention provides a method for implementing a strongly consistent dynamic hierarchical cache for high-concurrency read and write operations in response to hotspots, comprising the following steps:
[0040] S1. Construct a two-level cache architecture: Initialize L1 local memory cache and L2 distributed cache, maintain a hot data statistics mechanism, configure a version number field for each cached data, and form a multi-level cache hierarchical structure.
[0041] S2. Dynamic identification of hot data: Calculate the data popularity score in real time based on the access traffic per unit time, and determine whether it is hot data according to the popularity score and preset threshold. For hot data that meets the conditions, implement preloading and resident strategies.
[0042] S3. Atomic update control based on version number optimistic locking: When receiving a data write request, first read the current data version number in the database, and carry the version number for comparison and verification when performing database update operation. Only when the version number matches will the update be performed and a new version number be generated.
[0043] S4. Cache synchronization update mechanism: After the database transaction is committed, the updated data and the new version number are immediately written to the L1 local cache and L2 distributed cache. Asynchronous delayed tasks are not used to avoid data inconsistency caused by time difference between the cache and the database.
[0044] S5. Tiered Reading and Missing Data Filling: When a read request is received, the data is queried in the order of L1 cache, L2 cache, and database. If the L1 cache misses but the L2 cache hits, the data is filled back into the L1 cache to improve the efficiency of subsequent accesses.
[0045] S6. Real-time monitoring of consistency and performance indicators: The system internal modules statistically analyze cache hit rate, average response time and number of dirty reads to form quantitative indicators for system performance monitoring and consistency evaluation.
[0046] In this embodiment, the specific implementation process of step S1 is as follows:
[0047] S1.1 Initialize L1 local memory cache, configure maximum capacity of 1000 entries and expiration time of 300 seconds;
[0048] S1.2, L2 distributed cache configuration: maximum memory 2GB, expiration time 300 seconds;
[0049] S1.3 Add a version field to the product table in the database. The version field is of type BIGINT and its initial value is 0. It is incremented by 1 with each update.
[0050] S1.4 Build a hotspot statistics module to record the access frequency of each data item.
[0051] In this embodiment, the specific implementation process of step S2 is as follows:
[0052] S2.1 Set the sliding window size w = 10 seconds and the hotspot threshold θ = 100 times / 10 seconds. Use a sliding window counting model to calculate data popularity in real time.
[0053]
[0054] Where I is an indicator function. The system counts the popularity every second. When a certain data is accessed ≥100 times within 10 seconds, it is determined to be hot data. It is immediately preloaded from the database to the L1 cache and set with high priority to avoid being eliminated by the LRU policy.
[0055] S2.2 Parameter basis: w = 10 seconds is the typical hotspot duration of e-commerce flash sale scenarios, θ = 100 times is set based on the distribution characteristics of the top 20 products carrying 90% of the traffic under 1000 concurrent users.
[0056] In this embodiment, in step S3, when a write request is received, the current version number V is first retrieved from the database. db Write the request and include the version number V. req Verify the version number when performing a database update:
[0057]
[0058] If the versions match, the data is updated and the version number is incremented by 1. If the versions do not match, a concurrency conflict is determined, and the business layer performs a retry or rollback.
[0059] In this embodiment, the specific implementation process of step S4 is as follows:
[0060] S4.1 After a database transaction is successfully committed, instead of using asynchronous delayed tasks, the new data and new version number are immediately written synchronously to the L1 cache and L2 distributed cache before executing subsequent business logic.
[0061] S4.2 The cache update time is almost synchronized with the transaction commit time, and the inconsistency time window is ≈0. Compared with the traditional delayed double delete strategy, it significantly reduces the risk of dirty reads.
[0062] In this embodiment, in step S5, the read requests are executed in the following order:
[0063] S5.1. Prioritize querying the L1 local cache; if a match is found, return the result directly.
[0064] S5.2 If L1 is not hit, query the L2 distributed cache; if it is hit, return the data and synchronously populate L1 with the data.
[0065] If S5.3 and L2 cache misses, the database is queried, the result is returned, and the data is written to both L2 and L1. This backfilling mechanism improves the L1 cache hit rate for subsequent hot accesses.
[0066] In this embodiment, in step S6, three indicators are statistically analyzed in real time: L1 cache hit rate, average response time, and dirty read rate. The average response time and dirty read rate are calculated according to the formula described in the invention to achieve quantitative monitoring of system performance and consistency.
[0067] This embodiment uses a mixed scenario of 1000 concurrent read / write operations for a comparative experiment. The control group uses distributed caching + delayed double deletion, while the experimental group uses the method of this invention. The experimental results are shown in Table 1.
[0068] Table 1. Performance and Consistency Comparison under 1000 Concurrency
[0069]
[0070] As shown in Table 1, the method of this invention significantly reduces the dirty read rate and optimizes the average response time and long-tail latency in a 1000-concurrency hotspot read / write scenario. The decrease in throughput is a reasonable engineering cost to ensure strong consistency, which is completely acceptable in consistency-priority scenarios such as flash sales, inventory deductions, and account balance changes, and can be compensated for through cluster expansion and hotspot sharding. The experimental results and metric comparisons show that the consistency and performance of the method of this invention are superior to traditional mainstream caching solutions, and can meet the requirements of strong consistency and low latency in high-concurrency hotspot scenarios.
Claims
1. A method for implementing a strongly consistent dynamic hierarchical cache for high-concurrency read and write operations with hot spots, characterized in that, Includes the following steps: S1. Construct a two-level cache architecture: Initialize L1 local memory cache and L2 distributed cache, maintain a hot data statistics mechanism, configure a version number field for each cached data, and form a multi-level cache hierarchical structure. S2. Dynamic identification of hot data: Calculate the data popularity score in real time based on the access traffic per unit time, and determine whether it is hot data according to the popularity score and preset threshold. For hot data that meets the conditions, implement preloading and resident strategies. S3. Atomic update control based on version number optimistic locking: When receiving a data write request, first read the current data version number in the database, and carry the version number for comparison and verification when performing database update operation. Only when the version number matches will the update be performed and a new version number be generated. S4. Cache synchronization update mechanism: After the database transaction is committed, the updated data and the new version number are immediately written to the L1 local cache and L2 distributed cache. Asynchronous delayed tasks are not used to avoid data inconsistency caused by time difference between the cache and the database. S5. Tiered Reading and Missing Data Filling: When a read request is received, the data is queried in the order of L1 cache, L2 cache, and database. If the L1 cache misses but the L2 cache hits, the data is filled back into the L1 cache to improve the efficiency of subsequent accesses. S6. Real-time monitoring of consistency and performance indicators: The system internal modules statistically analyze cache hit rate, average response time and number of dirty reads to form quantitative indicators for system performance monitoring and consistency evaluation.
2. The method according to claim 1, characterized in that, In step S2, the data popularity score uses a sliding window counting model, and the calculation formula is as follows: Among them, H i (t) represents the total number of visits to data i within the time window w; tw is the starting position of the sliding window, used to limit the popularity calculation to only cover the most recent w access requests, excluding historical expired access data, and ensuring the real-time nature of the popularity score; req k The data identifier for the k-th request; id i H is the unique ID of the i-th data; I is an indicator function that takes the value 1 when a match is found, and 0 otherwise; when H i When (t)≥θ, the data f is identified as hot data and loaded into the L1 cache, where θ is the preset hot data identification threshold.
3. The method according to claim 1, characterized in that, The logic for determining the success of the version number optimistic lock update in step S3 satisfies the following relationship: Among them, V db V represents the current storage version number of the database. req To include the version number in the write request; when P success When the value is 0, a concurrent update conflict is determined, and retry or rollback logic is executed.
4. The method according to claim 1, characterized in that, In step S4, the cache inconsistency time window W under the synchronous update strategy sync satisfy: W sync =T cache_update -T db_commit ≈0 Among them, T db_commit T is the time when the database transaction is committed and completed. cache_update This is to determine the execution time of the cache update; this time window is much smaller than the inconsistency window W of the traditional delayed double-delete strategy. delayed =T delay +T retwork This significantly reduces the risk of dirty reading.
5. The method according to claim 1, characterized in that, The overall average response time model of the system is as follows: T avg =P L1 ·T mem +(1-P L1 )·(T L2 +T net )+P miss ·T db Among them, P L1 T represents the L1 cache hit rate. mem For memory access time, T L2 For the time consumed by distributed cache access, T net For network transmission time, P miss T represents the total cache miss rate. db Database query time; in scenarios with concentrated hotspots, P L1 Approaching 1, the average response time is brought close to the memory access speed.
6. The method according to claim 1, characterized in that, The dirty read rate calculation formula in step S6 is: Among them, V resp The version number of the response data; V latest C is the latest version number of the database. count (V resp <V latest Total represents the number of requests that returned data versions that were later than the latest version. requests The total number of requests; when R dirty When = 0, the system reaches a strongly consistent state.
7. The method according to claim 1, characterized in that, The L1 cache uses Caffeine's local memory cache, the L2 cache uses Redis's distributed cache, and the version number uses a long integer auto-incrementing sequence.
8. The method according to claim 1, characterized in that, This method is suitable for business scenarios that have high requirements for both data consistency and access response speed, such as high-concurrency flash sales, inventory deduction, account balance changes, and access to hot content.