Multistage cache synchronization and management system

Abstract

The invention relates to a multi-level cache synchronization and management system. The multi-level cache synchronization and management system comprises a first-level cache located on the topmost layer, a second-level cache located in the middle and a third-level cache located on the bottommost layer. The first-level caches adopt a Caffeine cache library, and the first-level caches are used as local caches to be bound with application servers one by one and used for caching hotspot data; the second-level cache adopts a distributed cache system Redis and is used for caching data needing to be refreshed in real time; and the third-level cache adopts a database and is used for synchronously storing hotspot data and data needing to be refreshed in real time. According to the invention, the local cache is introduced to reduce the network delay, reduce the pressure of the Redis server, and improve the availability of the system when the Redis is unavailable or has a network problem.

Description

Technical Field

[0001] The present invention relates to the technical field of big data processing, in particular to a multi-level cache synchronization and management system. Background Art

[0002] As the business volume grows, the caching solutions in the existing technology have gone through the following stages:

[0003] Phase 1: Directly query the database without cache;

[0004] Phase 2: Introducing Redis as the cache layer, data synchronization + distributed cache system Redis;

[0005] The third stage: Set up multiple levels of cache in the system, and each level is responsible for different data caching and access tasks.

[0006] In the use of the distributed cache system Redis, especially Redis remote services, there are the following technical problems:

[0007] Redis's remote services require network communication. Under high concurrency, network latency may become a bottleneck, causing response time fluctuations.

[0008] In high-concurrency scenarios, when all requests directly access Redis, Redis may be under a high load, causing performance bottlenecks;

[0009] In extreme cases (such as a Redis cluster failure or network interruption), Redis unavailability will cause the application to be unable to obtain data, affecting user experience and service quality.

[0010] The information disclosed in this background technology section is only intended to deepen the understanding of the overall background technology of the present invention, and should not be regarded as acknowledging or suggesting in any form that the information constitutes the prior art already known to those skilled in the art. Summary of the invention

[0011] In view of the defects existing in the prior art, the purpose of the present invention is to provide a multi-level cache synchronization and management system, which introduces local cache to reduce network delays, alleviate the pressure on Redis servers, and improve the availability of the system when Redis is unavailable or there are network problems.

[0012] In order to achieve the above purpose, the technical solution adopted by the present invention is:

[0013] A multi-level cache synchronization and management system, characterized by comprising:

[0014] The first-level cache is at the top, the second-level cache is in the middle, and the third-level cache is at the bottom;

[0015] The first-level cache uses the Caffeine cache library. The first-level cache is bound to the application server one by one as a local cache and is used to cache hot data.

[0016] The second-level cache uses the distributed cache system Redis to cache data that needs to be refreshed in real time;

[0017] The third-level cache uses a database to synchronously save hot spot data and data that needs to be refreshed in real time.

[0018] On the basis of the above technical solution, when hot data is written into the third-level cache, the cache synchronization module verifies whether the hot data has been written into the first-level cache;

[0019] When data that needs to be refreshed in real time is written into the third-level cache, the cache synchronization module verifies whether the data that needs to be refreshed in real time has been written into the second-level cache.

[0020] Based on the above technical solution, when a consumer requests to obtain hot data, it is first obtained from the first-level cache, and a listener is generated to capture modifications to the hot data. After the modifications take effect, the cache refresh module is triggered to synchronously update the modified content to the first-level cache and the third-level cache.

[0021] Based on the above technical solution, when consumers request data that needs to be refreshed in real time, it is obtained from the second-level cache first, and a listener is generated to capture modifications to hot data. After the modifications take effect, the cache refresh module is triggered to synchronously update the modified content to the second-level cache and the third-level cache.

[0022] Based on the above technical solution, when the data in the first-level cache changes, a refresh message is published through the RocketMQ transaction message, and the application server subscribes to the refresh message and updates the data according to the received refresh message.

[0023] On the basis of the above technical solution, it also includes: a consistency verification module, which is used to record the task queues of each application server in the system. When different application servers process data streams with the same identification code, the consistency verification module reads the local cache of each application server to ensure cache consistency between services;

[0024] When the consistency verification fails, the consistency verification module publishes a refresh message through the RocketMQ transaction message, and the application server subscribes to the refresh message and updates the data according to the received refresh message.

[0025] Based on the above technical solution, the consistency verification module publishes refresh messages through RocketMQ transaction messages, including:

[0026] Global synchronization refresh message, used to trigger all application servers to update data according to the received refresh message;

[0027] The global clear refresh message is used to trigger all application servers to clear the data in the first-level cache according to the received refresh message.

[0028] On the basis of the above technical solution, it also includes: a client cache control module, which is used to provide a cache read and write API interface, and perform cache query, update or clear operations through the API interface.

[0029] The multi-level cache synchronization and management system described in the present invention has the following beneficial effects:

[0030] 1. Introduce local cache to reduce network latency and relieve the pressure on the Redis server. The local cache has extremely fast access speed and can return data almost instantly, further reducing the response time of requests;

[0031] 2. Hot data can be saved in local cache to reduce the number of requests to Redis and relieve its pressure;

[0032] 3. Local cache can provide a certain degree of fault tolerance. When Redis is unavailable or there is a network problem, the application can still obtain some data from the local cache and maintain a certain quality of service. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The present invention has the following accompanying drawings:

[0034] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0035] Figure 1 System architecture diagram of embodiment 1 of a multi-level cache synchronization and management system described in the present invention.

[0036] Figure 2 System architecture diagram of embodiment 2 of a multi-level cache synchronization and management system described in the present invention. DETAILED DESCRIPTION

[0037] The present invention is further described in detail below in conjunction with the accompanying drawings. The detailed description is an explanation made in conjunction with the exemplary embodiments of the present invention, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0038] like Figure 1 As shown, a multi-level cache synchronization and management system described in the present invention includes:

[0039] The first-level cache is at the top, the second-level cache is in the middle, and the third-level cache is at the bottom;

[0040] The first-level cache uses the Caffeine cache library. The first-level cache is bound to the application server one by one as a local cache and is used to cache hot data.

[0041] The second-level cache uses the distributed cache system Redis to cache data that needs to be refreshed in real time;

[0042] The third-level cache uses a database to synchronously save hot spot data and data that needs to be refreshed in real time.

[0043] This embodiment proposes a multi-level cache synchronization and management system, which aims to optimize data access speed and consistency. The system consists of three levels of cache:

[0044] First-level cache: Use the Caffeine cache library as a local cache bound to the application server. It is mainly responsible for caching hot data to reduce the access pressure on the backend storage and improve the data access speed. By caching hot data in the first-level cache, direct access to the database is reduced, thereby improving the overall performance of the system.

[0045] The first-level cache ensures the timeliness of cached data by supporting automatic expiration and automatic refresh mechanisms;

[0046] Second-level cache: The distributed cache system Redis is used to cache data that needs to be refreshed in real time to ensure the real-time and consistency of data. The design of the distributed cache system allows the system to be easily expanded to cope with the growing amount of data and user requests.

[0047] The third-level cache is based on the database and is used to synchronously save hot data and data that needs to be refreshed in real time to ensure data persistence and integrity. The real-time refresh mechanism of the second-level cache ensures data consistency, while the synchronization mechanism of the third-level cache ensures data persistence.

[0048] Exemplarily, when the system starts, hot data is preloaded into the first-level cache to reduce the cache miss rate after startup;

[0049] For example, according to actual business needs, you can consider dynamically adjusting the cache invalidation strategy;

[0050] On the basis of the above technical solution, when hot data is written into the third-level cache, the cache synchronization module verifies whether the hot data has been written into the first-level cache;

[0051] When data that needs to be refreshed in real time is written into the third-level cache, the cache synchronization module verifies whether the data that needs to be refreshed in real time has been written into the second-level cache.

[0052] By adding a verification mechanism to the cache synchronization module when writing data to the third-level cache, the consistency and real-time nature of the data can be ensured. Specifically, when hot data is written to the third-level cache, the system will verify whether the data has been updated to the first-level cache; similarly, for data that needs to be refreshed in real time, when writing to the third-level cache, the system will verify whether they have been updated to the second-level cache. The verification mechanism ensures data consistency between cache levels and prevents data islands. For hot data and real-time refresh data, different cache invalidation strategies, such as LRU, timestamp, etc., can be set to optimize the use of cache space. A monitoring mechanism for the cache system can also be established to monitor key indicators such as cache hit rate and response time in real time, and to promptly alarm when anomalies occur. During data update operations, message queues are used to manage update requests, which can asynchronously process data synchronization and improve system throughput and stability.

[0053] Based on the above technical solution, Figure 2 As shown, when a consumer requests to obtain hot data, it is first obtained from the first-level cache, and a listener is generated to capture modifications to the hot data. After the modification takes effect, the cache refresh module is triggered to synchronously update the modified content to the first-level cache and the third-level cache.

[0054] Based on the above technical solution, Figure 2 As shown, when a consumer requests data that needs to be refreshed in real time, it is obtained from the second-level cache first, and a listener is generated to capture changes to hot data. After the changes take effect, the cache refresh module is triggered to synchronously update the modified content to the second-level cache and the third-level cache.

[0055] Based on the above technical solution, when the data in the first-level cache changes, a refresh message is published through the RocketMQ transaction message, and the application server subscribes to the refresh message and updates the data according to the received refresh message.

[0056] In this embodiment, when the data in the first-level cache changes, the system publishes transaction messages through RocketMQ, and the application server subscribes to these messages and updates the data accordingly. The use of RocketMQ transaction messages ensures that the data changes in the first-level cache can be reliably synchronized to the application server, improving data consistency; RocketMQ's transaction message mechanism ensures reliable message delivery, and even in the event of network failure or system abnormality, it can ensure the final consistency of data.

[0057] On the basis of the above technical solution, it also includes: a consistency verification module, which is used to record the task queues of each application server in the system. When different application servers process data streams with the same identification code, the consistency verification module reads the local cache of each application server to ensure cache consistency between services;

[0058] When the consistency verification fails, the consistency verification module publishes a refresh message through the RocketMQ transaction message, and the application server subscribes to the refresh message and updates the data according to the received refresh message.

[0059] Based on the above technical solution, the consistency verification module publishes refresh messages through RocketMQ transaction messages, including:

[0060] Global synchronization refresh message, used to trigger all application servers to update data according to the received refresh message;

[0061] The global clear refresh message is used to trigger all application servers to clear the data in the first-level cache according to the received refresh message.

[0062] On the basis of the above technical solution, it also includes: a client cache control module, which is used to provide a cache read and write API interface, and perform cache query, update or clear operations through the API interface.

[0063] The contents not described in detail in this specification belong to the prior art known to professional and technical personnel in this field.

[0064] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by those skilled in the art based on the contents disclosed by the present invention should be included in the protection scope recorded in the claims.

Claims

1. A multi-level cache synchronization and management system, characterized in that: include: The first-level cache is at the top, the second-level cache is in the middle, and the third-level cache is at the bottom; The first-level cache uses the Caffeine cache library. The first-level cache is bound to the application server one by one as a local cache and is used to cache hot data. The second-level cache uses the distributed cache system Redis to cache data that needs to be refreshed in real time; The third-level cache uses a database to synchronously save hot spot data and data that needs to be refreshed in real time.

2. A multi-level cache synchronization and management system as claimed in claim 1, characterized in that: When hot data is written into the third-level cache, the cache synchronization module verifies whether the hot data has been written into the first-level cache; When data that needs to be refreshed in real time is written into the third-level cache, the cache synchronization module verifies whether the data that needs to be refreshed in real time has been written into the second-level cache.

3. A multi-level cache synchronization and management system as claimed in claim 1, characterized in that: When consumers request to obtain hot data, they will first obtain it from the first-level cache, and generate a listener to capture the changes to the hot data. After the changes take effect, the cache refresh module will be triggered to synchronously update the modified content to the first-level cache and the third-level cache.

4. A multi-level cache synchronization and management system as claimed in claim 1, characterized in that: When consumers request data that needs to be refreshed in real time, they will first obtain it from the second-level cache and generate a listener to capture changes to hot data. After the changes take effect, the cache refresh module will be triggered to synchronously update the modified content to the second-level cache and the third-level cache.

5. A multi-level cache synchronization and management system as claimed in claim 1, characterized in that: When the data in the first-level cache changes, a refresh message is published through RocketMQ transaction messages, and the application server subscribes to the refresh message and updates the data based on the received refresh message.

6. A multi-level cache synchronization and management system as claimed in claim 1, characterized in that: Also includes: The consistency verification module is used to record the task queues of each application server in the system. When different application servers process data streams with the same identification code, the consistency verification module reads the local cache of each application server to ensure cache consistency between services. When the consistency verification fails, the consistency verification module publishes a refresh message through the RocketMQ transaction message, and the application server subscribes to the refresh message and updates the data according to the received refresh message.

7. A multi-level cache synchronization and management system as claimed in claim 6, characterized in that: The consistency verification module publishes refresh messages through RocketMQ transaction messages, including: Global synchronization refresh message, used to trigger all application servers to update data according to the received refresh message; The global clear refresh message is used to trigger all application servers to clear the data in the first-level cache according to the received refresh message.

8. A multi-level cache synchronization and management system as claimed in claim 1, characterized in that: Also includes: The client cache control module is used to provide a cache read and write API interface, and perform cache query, update or clear operations through the API interface.

Images