Data caching system and method, electronic equipment and medium

Abstract

The invention provides a data caching system and method, electronic equipment and a medium, in the system, hierarchical storage is performed according to data interaction frequency, data with access times greater than a preset first threshold value in unit time is stored in a local caching module, an in-process caching mechanism and an ordered key value pair structure are utilized to realize rapid reading and writing, and the data caching efficiency is improved. Data with the interaction frequency between a preset first threshold value and a preset second threshold value are stored by Redis, and the access request with relatively low frequency is processed through a distributed cache mechanism, so that the cache pressure of the access request is reduced. The cache management module dynamically coordinates the interaction between the two-stage cache and the database according to the data storage condition, when a client initiates a data cache instruction, the client preferentially queries from the local cache module and accesses the Redis only when the local cache module is not hit, and if the local cache module is still not hit, the database carries out the bottom, so that the situation that the Redis is too high in load due to high-frequency access is avoided, and the service life of the Redis is prolonged. Therefore, the cache pressure is effectively relieved, and the use experience of a mobile phone terminal user is improved.

Description

Technical Field

[0001] This application relates to the field of data caching technology, and in particular to a data caching system, method, electronic device, and medium. Background Technology

[0002] Currently, mobile caching technologies typically rely on the mainstream Redis caching tool. Redis is an open-source, high-performance key-value store database, commonly used for caching, message queues, distributed locks, etc. When a mobile app requests data from the database, its caching mechanism reduces the access pressure on the database from multiple mobile devices, thereby improving app response speed. Therefore, current mobile caching mechanisms primarily utilize Redis. However, even though Redis can significantly reduce database access pressure, excessive user traffic can still lead to excessive caching pressure on Redis, resulting in low data retrieval efficiency and negatively impacting the user experience on mobile devices. Summary of the Invention

[0003] To address the aforementioned issues and reduce the caching pressure on Redis in data caching, this application provides a data caching system, method, electronic device, and medium.

[0004] The embodiments of this application disclose the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a data caching system applied to a server, the system comprising: a local caching module, a remote caching module, a cache management module, and a database;

[0006] The local cache module is used to store data with an interaction frequency greater than a preset first threshold. The local cache module adopts an in-process caching mechanism and implements data storage based on an ordered key-value pair structure. The interaction frequency is the number of times the client accesses the data per unit time.

[0007] The remote caching module is used to store data whose interaction frequency is less than the preset first threshold and greater than the preset second threshold, and the remote caching module adopts a distributed caching mechanism and uses Redis as the caching component; the preset first threshold is greater than the preset second threshold;

[0008] The database is used to store data that has missed the local cache module and the remote cache module;

[0009] The cache management module is used to determine a caching strategy based on the data caching instructions from the client and the data storage conditions of the local cache module and the remote cache module, and to coordinate the data interaction between the local cache module, the remote cache module and the database through the caching strategy in order to execute the data caching task indicated by the data caching instructions.

[0010] The data access priority of the local cache module is higher than that of the remote cache module.

[0011] In one possible implementation, the cache management module includes: a data interaction unit, which is specifically used for:

[0012] Determine the data query identifier corresponding to the data caching instruction;

[0013] Based on the data query identifier, determine whether there is target data associated with the data query identifier in the local cache module;

[0014] If it is determined that the target data exists in the local cache module, the target data is fed back to the client through the local cache module;

[0015] If it is determined that the target data does not exist in the local cache module, the existence of the target data in the remote cache module is determined based on the data query identifier.

[0016] If the target data is stored in the remote cache module, the target data stored in the remote cache module is written into the local cache module, and the target data is fed back to the client through the local cache module.

[0017] In one possible implementation, the data interaction unit is further configured to:

[0018] If the target data does not exist in the remote cache module, the target data associated with the target data is obtained through the database, and the target data source is synchronized to the local cache module and the remote cache module.

[0019] The target data source is fed back to the client through the local caching module.

[0020] In one possible implementation, the system further includes a cache update module, which is specifically used for:

[0021] In the Redis instance, key-value pairs and their expiration times are set to determine whether the key-value pairs can be successfully set in the Redis instance; the key-value pairs are distributed locks.

[0022] If the key-value pair is successfully set in Redis, the data source is retrieved from the database, and the remote cache module is updated based on the data source.

[0023] If the key-value pair fails to be set in Redis, the cache update process is aborted.

[0024] In one possible implementation, the system further includes: a cache interface module and an abstract cache implementation module;

[0025] The cache interface module inherits the Closeable interface and is used to release cache resources and define cache operation methods. The cache operation methods include: data acquisition, data storage, data deletion, and cache result encapsulation.

[0026] The abstract cache implementation module is an abstract subclass of the cache interface module, used to provide caching logic for data, and the caching logic is implemented through a memory cache subclass and a remote cache subclass.

[0027] In one possible implementation, the system further includes: a cache statistics module; the cache statistics module is specifically used for:

[0028] The system records the cache hit count, cache miss count, and data access frequency for each of the local cache module and the remote module. The cache hit count is the number of times the target data associated with the data query identifier exists within the module. The cache miss count is the number of times the target data associated with the data query identifier does not exist within the module.

[0029] The caching strategy is optimized based on the cache hit count, cache miss count, and data access frequency for the local caching module and the remote caching module, respectively.

[0030] Secondly, this application provides a data caching method applied to a server, the server comprising: a local caching module, a remote caching module, and a database; wherein, the local caching module is used to store data with an interaction frequency greater than a preset first threshold, and the local caching module adopts an in-process caching mechanism and implements data storage based on an ordered key-value pair structure; wherein, the interaction frequency is the number of times the client accesses the data per unit time.

[0031] The remote caching module is used to store data whose interaction frequency is less than the preset first threshold and greater than the preset second threshold, and the remote caching module adopts a distributed caching mechanism and uses Redis as the caching component; the preset first threshold is greater than the preset second threshold;

[0032] The database is used to store data that has missed the local cache module and the remote cache module;

[0033] The method includes:

[0034] Based on the data caching instructions from the client and the data storage conditions of the local caching module and the remote caching module respectively, a caching strategy is determined, and the data interaction between the local caching module, the remote caching module and the database is coordinated through the caching strategy to execute the data caching task indicated by the data caching instructions;

[0035] The data access priority of the local cache module is higher than that of the remote cache module.

[0036] In one possible implementation, determining a caching strategy based on data caching instructions from the client and the data storage conditions of the local caching module and the remote caching module, and coordinating data interactions between the local caching module, the remote caching module, and the database through the caching strategy to execute the data caching task indicated by the data caching instructions, includes:

[0037] Determine the data query identifier corresponding to the data caching instruction;

[0038] Based on the data query identifier, determine whether there is target data associated with the data query identifier in the local cache module;

[0039] If it is determined that the target data exists in the local cache module, the target data is fed back to the client through the local cache module;

[0040] If it is determined that the target data does not exist in the local cache module, the existence of the target data in the remote cache module is determined based on the data query identifier.

[0041] If the target data is stored in the remote cache module, the target data stored in the remote cache module is written into the local cache module, and the target data is fed back to the client through the local cache module.

[0042] Thirdly, embodiments of this application provide an electronic device, the device including: a processor, a memory, and a system bus;

[0043] The processor and the memory are connected via the system bus;

[0044] The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform any of the possible data caching methods in the second aspect.

[0045] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the possible data caching methods in the second aspect.

[0046] Compared to existing technologies, this application has the following advantages: This application provides a data caching system, method, electronic device, and medium. The system includes a local caching module, a remote caching module, a cache management module, and a database. The local caching module stores data with an interaction frequency greater than a preset first threshold, and employs an in-process caching mechanism based on an ordered key-value pair structure for data storage. The interaction frequency is the number of times a client accesses data per unit time. The remote caching module stores data with an interaction frequency less than the preset first threshold but greater than a preset second threshold, and employs a distributed caching mechanism. Redis is used as the caching component; the preset first threshold is greater than the preset second threshold; the database is used to store data that misses the local cache module and the remote cache module; the cache management module is used to determine the caching strategy based on the data caching instructions from the client and the data storage status of the local cache module and the remote cache module, and coordinate the data interaction between the local cache module, the remote cache module, and the database through the caching strategy to execute the data caching task indicated by the data caching instructions; wherein, the data access priority of the local cache module is greater than the data access priority of the remote cache module. In the system provided in this embodiment, hierarchical storage is performed according to the data interaction frequency. High-frequency data with access frequency greater than the preset first threshold per unit time is stored in the local cache module, and fast read and write are achieved using an in-process caching mechanism and an ordered key-value pair structure, avoiding direct impact of high-frequency access on Redis. Medium and low-frequency data with interaction frequency between the preset first threshold and the second threshold are stored in Redis, and relatively low-frequency access requests are handled through a distributed caching mechanism, thereby reducing the caching pressure on Redis. Furthermore, the cache management module dynamically coordinates the interaction between the two-level cache and the database based on data storage conditions. When a client initiates a data caching command, it prioritizes querying the local cache module, only accessing Redis if the local cache fails. If Redis also fails, the database takes over, and the retrieved data is synchronized to both-level caches, forming an efficient data access path. This hierarchical processing significantly reduces the frequency of direct access to Redis in high-concurrency scenarios, lowers latency and resource consumption caused by network interactions, and prevents Redis from becoming overloaded due to high-frequency access, thereby effectively alleviating its caching pressure and improving the user experience on mobile devices. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram of the structure of a data caching system provided in an embodiment of this application;

[0049] Figure 2 A flowchart illustrating the execution logic of a data interaction unit provided in an embodiment of this application;

[0050] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and accompanying drawings. It should be particularly noted that the embodiments described in this application are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0052] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0053] As described earlier, the current caching mechanism for mobile devices is mainly implemented through Redis. However, even though Redis can significantly reduce the access pressure on the database, when the user access volume is too large, it will still put too much caching pressure on Redis, resulting in low data reading efficiency and affecting the user experience of mobile users.

[0054] Based on this, embodiments of this application provide a data caching system, method, electronic device, and medium. The system includes a local caching module, a remote caching module, a cache management module, and a database. The local caching module stores data with an interaction frequency greater than a preset first threshold, and employs an in-process caching mechanism based on an ordered key-value pair structure for data storage; the interaction frequency is the number of times a client accesses data per unit time. The remote caching module stores data with an interaction frequency less than the preset first threshold but greater than a preset second threshold, and employs a distributed caching mechanism using Redis as a caching component; the preset first threshold is greater than the preset second threshold. The database stores data that misses both the local and remote caching modules. The cache management module determines a caching strategy based on data caching instructions from the client and the data storage status of the local and remote caching modules, and coordinates data interactions between the local caching module, the remote caching module, and the database through the caching strategy to execute the data caching task indicated by the data caching instructions; wherein the data access priority of the local caching module is greater than the data access priority of the remote caching module. In the system provided in this embodiment, data is stored in a tiered manner based on the frequency of data interaction. High-frequency data, whose access frequency exceeds a preset first threshold per unit time, is stored in the local cache module. In-process caching mechanisms and ordered key-value pairs are used to achieve fast read and write operations, preventing high-frequency access from directly impacting Redis. Medium- and low-frequency data, with interaction frequencies between the preset first and second thresholds, are stored in Redis. A distributed caching mechanism handles relatively infrequent access requests, thereby reducing Redis's caching pressure. Furthermore, the cache management module dynamically coordinates the interaction between the two-level cache and the database based on data storage conditions. When a client initiates a data caching command, it prioritizes querying the local cache module. Only if the local cache fails to find the data will it access Redis. If Redis also fails to find the data, the database takes over, and the retrieved data is synchronized to both levels of cache, forming an efficient data access path. This tiered processing method significantly reduces the frequency of direct access to Redis in high-concurrency scenarios, reduces latency and resource consumption caused by network interactions, and prevents Redis from becoming overloaded due to high-frequency access, thus effectively alleviating its caching pressure and improving the user experience on mobile devices.

[0055] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0056] See Figure 1 This figure is a schematic diagram of the structure of a data caching system provided in an embodiment of this application. The data caching system provided in this embodiment is applied to the server side, and the user's mobile APP acts as the client side. When the APP has a data caching requirement, the mobile APP sends a data caching instruction to the server side, and responds to the data caching instruction through the data caching system set up on the server side in this embodiment. During periods of high data access demand, multiple users may simultaneously send data caching instructions to the server side. Therefore, relying solely on Redis to handle caching tasks will lead to high Redis cache pressure, thereby affecting the normal operation of the data caching system.

[0057] Specifically, the data caching system in this embodiment includes the following modules: local caching module 100, remote caching module 200, database 300, and cache management module 400. The execution functions of each module will be described in turn.

[0058] The local cache module 100 is used to store data with an interaction frequency greater than a preset first threshold. The local cache module adopts an in-process caching mechanism and implements data storage based on an ordered key-value pair structure. The interaction frequency is the number of times the client accesses the data per unit time.

[0059] The local caching module is designed to handle the most frequently accessed data, enabling extremely fast responses to high-frequency access through targeted technical design. Specifically, this module stores data accessed by clients more than a preset first threshold within a given time period. This type of data is often critical resources relied upon by users for high-frequency operations (such as core business queries and frequently used configuration information), requiring extremely high access speeds. Furthermore, the local caching module employs an in-process caching mechanism, meaning it exists as part of the server-side application process, with data stored directly in the application's memory space, eliminating the need for network requests or cross-process communication, significantly reducing latency and overhead. The module also uses an ordered key-value pair structure for data storage. This structure not only ensures fast data retrieval (directly locating data via keys) but also supports cache eviction strategies by maintaining the order of keys (e.g., sorting by access time or frequency). For example, when cache space is insufficient, low-frequency data at the end of the ordered structure can be easily removed, ensuring that high-frequency data remains in memory and maintaining cache efficiency.

[0060] On the other hand, the ordered key-value pair structure of the local cache module provides a flexible operational foundation for data management. Unlike remote cache modules, which require network interaction for access, the in-process caching mechanism ensures that read and write operations of the local module are almost unaffected by network latency, enabling responses within nanoseconds. This is particularly suitable for handling high-frequency access requests in high-concurrency scenarios. When a client initiates a data request, the cache management module prioritizes querying the local cache module. If the data exists, it is returned directly, avoiding unnecessary access to the remote cache and database. If the local cache fails to find the data, the remote cache module is then searched, and if a remote cache hit occurs, the data is synchronized to the local cache. This allows potentially frequently accessed data to be pre-loaded into a faster storage tier, forming a virtuous cycle of "local priority—remote supplementation." This design not only alleviates the pressure on Redis through tiered storage but also improves the efficiency of high-frequency data access from the underlying architecture through the combination of in-process storage and an ordered structure. This ensures that the server can achieve optimal data response with minimal resource consumption when facing a large number of data caching requests, laying the foundation for the high-performance operation of the entire data caching system.

[0061] The remote caching module 200 is used to store data whose interaction frequency is less than the preset first threshold and greater than the preset second threshold, and the remote caching module adopts a distributed caching mechanism and uses Redis as the caching component; the preset first threshold is greater than the preset second threshold.

[0062] The remote caching module acts as an intermediary layer connecting the local cache and the database. Its function is to store "mid-frequency data" whose interaction frequency falls between a preset first threshold and a second threshold. While the access frequency of this type of data is lower than the high-frequency data stored in the local cache, it is still higher than the low-frequency data that relies entirely on database queries. Directly processing this data with the database would increase its processing load, while including it entirely in the local cache would lead to memory resource constraints due to the large data volume. The remote caching module employs a distributed caching mechanism, using Redis as its core component. Leveraging Redis's high-performance key-value storage, cluster scalability, and rich data structures, it achieves efficient management of mid-frequency data. The distributed caching mechanism allows the remote caching module to horizontally scale nodes to handle high-concurrency access demands, avoiding single-node performance bottlenecks. Simultaneously, strategies such as data sharding and replica redundancy improve system availability and fault tolerance, ensuring stable operation under large-scale client access scenarios.

[0063] Furthermore, the tiered storage mechanism built by the remote and local caching modules, combined with Redis's features, brings the following synergistic value: First, by using preset dual thresholds to achieve automatic data distribution, it ensures that data with different access frequencies enters the most suitable storage tier, avoiding resource waste (such as storing low-frequency data in a high-performance cache) or performance bottlenecks (such as increasing network latency by squeezing high-frequency data into a distributed cache). Second, the distributed caching mechanism, combined with Redis's pipelining and batch operation functions, can reduce the number of network interactions in high-concurrency scenarios, reduce communication overhead, and improve overall throughput. Third, with the help of Redis's expiration policies and eviction mechanisms (such as LRU and LFU), the remote caching module can automatically clean up medium-frequency data that has not been accessed for a long time, freeing up memory resources and ensuring storage efficiency. This design not only leverages Redis's technical advantages in distributed scenarios but also, through hierarchical cooperation with the local caching module, constructs a caching architecture of "local fast response—remote distributed expansion—database persistence as a backup." This allows the system to achieve an optimal balance between performance and resources through intelligent scheduling between layers when facing diverse data access needs. Ultimately, the remote caching module not only undertakes the heavy responsibility of storing mid-frequency data but also alleviates its own pressure through reasonable architectural design. Together with the local caching module, it forms the core support for efficient server-side data caching, providing users with a stable and fast data access experience.

[0064] The database 300 is used to store data that has failed to hit the local cache module and the remote cache module.

[0065] As the ultimate data source and persistent storage carrier of the entire data storage system, the database internally stores data that misses local and remote cache modules. This type of missed data typically includes low-frequency data accessed below a preset second threshold (such as historical logs, non-core business configurations, etc.), new data accessed for the first time, or old data removed due to cache eviction policies. While these data lack high-frequency or medium-frequency access characteristics, they are fundamental to the system's data integrity and business continuity. Leveraging its persistent storage capabilities, strong consistency guarantees, and support for complex data operations (such as transaction processing, join queries, and batch updates), the database ensures that all data can still be reliably accessed after passing through the cache layer, preventing data loss or service interruptions due to cache misses. Unlike the rapid in-process response of local caching and the distributed, efficient processing of remote caching, the database prioritizes permanent data storage and integrity constraints. Through a collaborative model of "pre-cache filtering—database backing up," the three elements ensure efficient access and high-reliability operation of the entire data caching system.

[0066] The cache management module 400 is used to determine a caching strategy based on the data caching instructions from the client and the data storage conditions corresponding to the local cache module and the remote cache module, and to coordinate the data interaction between the local cache module, the remote cache module and the database through the caching strategy in order to execute the data caching task indicated by the data caching instructions.

[0067] The data access priority of the local cache module is higher than that of the remote cache module.

[0068] The cache management module coordinates data interaction among the local cache module, remote cache module, and database by dynamically formulating and executing caching strategies, ensuring that client data caching commands are executed via the optimal path. The module's operational logic revolves around "data access priority" and "storage status awareness." First, it prioritizes data access from the local cache module over the remote cache module. This means that when a client initiates a data request, the cache management module will first trigger the query process from the local cache, only switching to the remote cache if the local cache fails, and ultimately accessing the database if both fail. Simultaneously, the module monitors the storage status of both local and remote caches in real time (e.g., capacity usage, data hit rate, access latency), and dynamically adjusts the caching strategy based on specific client commands (including data read, write, update, and eviction operations). For example, it automatically updates preset thresholds based on data interaction frequency, optimizes cache eviction rules, or temporarily adjusts cache loading strategies in high-concurrency scenarios to avoid system overload. This combination of "priority rules" and "real-time status awareness" allows the cache management module to accurately match the access characteristics of different data, improving data response speed while avoiding resource waste.

[0069] Specifically, the execution logic of the cache management module is implemented by the data interaction unit within the module. Next, the execution flow of the data interaction unit will be introduced with reference to the accompanying drawings of a specific embodiment.

[0070] See Figure 2 The figure is a flowchart illustrating the execution logic of a data interaction unit according to an embodiment of this application, specifically including the following steps:

[0071] S101: Determine the data query identifier corresponding to the data caching instruction;

[0072] S102: Based on the data query identifier, determine whether the target data associated with the data query identifier exists in the local cache module;

[0073] S103: If it is determined that the target data exists in the local cache module, the target data is fed back to the client through the local cache module;

[0074] S104: If it is determined that the target data does not exist in the local cache module, determine whether the target data exists in the remote cache module based on the data query identifier;

[0075] S105: If the target data exists in the remote cache module, the target data stored in the remote cache module is written to the local cache module, and the target data is fed back to the client through the local cache module.

[0076] S106: If the target data does not exist in the remote cache module, the target data associated with the target data is obtained from the database, and the target data source is synchronized to the local cache module and the remote cache module.

[0077] S107: The target data source is fed back to the client through the local caching module.

[0078] The execution logic of the data interaction unit revolves around the hierarchical matching of data query identifiers and the connection with the cache hierarchy. It aims to achieve efficient data retrieval and dynamic optimization of cache resources through a layered filtering mechanism. The process begins with parsing the query identifier corresponding to the data cache instruction. This step establishes an "identity index" for data access, ensuring that subsequent steps can accurately locate the target data. Next, S102 to S103 form the first layer of filtering. The data interaction unit first searches the local cache module based on the data query identifier. The local cache carries the most frequently interacted data. If the target data exists (i.e., a local hit), the data is directly fed back to the client via S103. This direct intra-process interaction avoids network latency, achieving microsecond-level response and maximizing the high-speed access advantage of the local cache. If the local cache misses (triggered by S104), the process enters the second layer of filtering and switches to querying the remote cache module. This design follows the hierarchical collaboration principle of "decreasing priority and increasing capacity." As a carrier of mid-frequency data, the remote cache's distributed architecture can handle larger-scale data storage and concurrent access. If S105 confirms that the target data exists remotely, the data interaction unit will write the data in the remote cache to the local cache module, and the local cache module will feed the data back to the client. This satisfies the client's immediate needs and prepares for possible high-frequency access in the future, forming an optimized mechanism of "one remote hit, subsequent local access." This reflects the caching system's dynamic learning ability for data access patterns.

[0079] Furthermore, when both levels of cache fail (triggered by S106), the process enters the final data fallback stage, which involves retrieving the target data source from the database. At this point, the key for the data interaction unit is not only to complete the response to the current data request, but more importantly, to execute the "cache pre-filling" strategy: when triggered by S106, the data source returned by the database is synchronized to both the local and remote cache modules. This operation has a dual significance. On the one hand, it establishes "cache preheating" for potential subsequent repeated accesses, preventing the same data from penetrating to the database when accessed again, thus reducing the pressure on the underlying storage from the source. On the other hand, by writing data to both levels of cache simultaneously, an "initial calibration" of the data access frequency is established—if the access frequency of this data subsequently increases to a preset first threshold, its retention in the local cache will be more stable; if it remains in the mid-frequency range, it will continue to be carried by the remote cache; if it remains low-frequency, it will be gradually removed through the cache eviction mechanism, forming a closed loop of "dynamic migration" of data in the three-level storage system.

[0080] Essentially, the data caching process executed by the data interaction unit is not merely an ordered series of steps, but a concrete implementation of the scheduling capabilities of the entire caching system. Through hierarchical matching of query identifiers, it achieves precise data location across different storage levels. Dynamic filling after a cache hit enables on-demand allocation of storage resources. Collaborative filtering across three levels achieves an optimal balance between system performance and resource consumption. In high-concurrency distributed systems, this process design effectively addresses the issue of varying data access frequencies, allowing high-frequency data to be processed more quickly, mid-frequency data to be efficiently cached, and low-frequency data to receive a reliability safety net. Ultimately, it constructs a data access architecture that combines responsiveness, scalability, and fault tolerance.

[0081] In one possible implementation, the system of this embodiment further includes a cache update module, which is specifically used to perform the following three steps:

[0082] Step 1: Set the key-value pair and its expiration time in the Redis to determine whether the key-value pair can be successfully set in the Redis; the key-value pair is a distributed lock.

[0083] Step 2: If the key-value pair is successfully set in Redis, then retrieve the data source from the database and update the cache of the remote cache module based on the data source;

[0084] Step 3: If the key-value pair fails to be set in Redis, the cache update process is aborted.

[0085] The cache update module aims to maintain data consistency between the remote cache module and the database in a distributed environment. Its core function is to leverage Redis distributed locks to achieve fine-grained control over cache update operations, fundamentally mitigating the risks of resource contention and data inconsistency in concurrent scenarios. The execution logic of the cache module revolves around the atomicity control of distributed locks and the orderly guarantee of update operations. Step one, as the starting point of the process, requires setting a specific key-value pair as a distributed lock in Redis and configuring a reasonable expiration time. This step essentially establishes a globally unique "operation access credential" in the distributed cluster. The key of the key-value pair typically uses a unique identifier strongly related to the cache to be updated (such as the business data primary key or cache group identifier), while the value contains a unique identifier for the current service instance (such as a UUID) for subsequent security verification. The expiration time setting needs to precisely balance operation time and fault tolerance requirements. It must be greater than the estimated time for database queries and cache updates to prevent premature lock expiration, while also setting a reasonable upper limit (such as 10-30 seconds) to prevent permanent lock occupation in abnormal scenarios. Redis's SET key value NX EX atomic command ensures that the lock creation operation has the dual characteristics of "execute only if the key does not exist" and "accompanying an expiration time". This atomic operation is the foundation of the entire mechanism and completely avoids the deadlock risk caused by the non-atomic "acquiring the lock" and "setting the expiration time" in traditional distributed locks.

[0086] After the lock setting operation in step one is completed, the process enters the branch judgment phase. If the key-value pair is successfully set in Redis (i.e., the current instance acquires the distributed lock), the update logic in step two is triggered. At this point, the instance obtains unique update privileges, first retrieving the latest data source from the database, and then performing a precise update on the remote cache module based on the data source. It's important to note that this "cache update" is not a simple overwrite write, but rather employs a differentiated strategy based on data characteristics. For frequently accessed core data, the local cache module may be notified asynchronously to synchronize data (if the data exists in the local cache) while the remote cache is being updated. For low-frequency data, only the remote cache is updated and a version number is marked for subsequent data verification. This tiered update strategy ensures data consistency while avoiding memory pressure caused by frequent writes to the local cache.

[0087] If lock setting fails (i.e., step one returns failure, indicating that another instance already holds a valid lock), the fault-tolerance logic in step three is immediately executed—the current cache update process is aborted to avoid concurrent conflicts caused by multiple instances operating on the database and cache simultaneously. At this point, instances that have not acquired the lock typically handle the situation in two ways: first, they retry according to a preset strategy (such as an exponential backoff algorithm) until they acquire the lock and execute the update; second, they switch to a "passive awareness" mode, waiting for the instance holding the lock to complete the update, and then obtaining the latest data through a cache invalidation mechanism or by subscribing to change notifications. This design effectively avoids network storms caused by a large number of instances simultaneously competing for the lock, keeping the concurrency of update operations within a controllable range.

[0088] In one possible implementation, the system in this embodiment further includes a cache interface module and an abstract cache implementation module. The cache interface module inherits the Closeable interface and is used to release cache resources and define cache operation methods. The cache operation methods include: data acquisition, data storage, data deletion, and cache result encapsulation.

[0089] The abstract cache implementation module is an abstract subclass of the cache interface module, used to provide caching logic for data, and the caching logic is implemented through a memory cache subclass and a remote cache subclass.

[0090] The modular design of the cache interface and the abstract cache implementation module proposed in this embodiment are essentially for building a scalable and maintainable cache system. Its core idea is to unify the operation specifications through interface definition, encapsulate common logic with the help of abstract classes, and finally achieve a cache architecture that is "unaware of upper-layer calls and replaceable at the lower-layer level".

[0091] First, let's look at the cache interface module. Its design, which inherits from the Closeable interface, reflects the rigor of resource management. In the caching system, whether it's a memory-level local cache or a distributed remote cache, it involves the occupation of resources such as connection pools and memory space. By implementing the close() method, it ensures that related resources are released when the system is shut down or the cache module is rebuilt, avoiding system risks caused by memory leaks or connection remnants. More importantly, this interface defines core operation methods such as data retrieval (get), data storage (put), data deletion (delete), and cache result encapsulation (wrapResult). These methods constitute the connection between the upper-layer business and the caching system. The data retrieval method supports precise location of cached data based on key values, the data storage method allows defining parameters such as expiration time and storage strategy, the data deletion method supports single-key deletion or batch eviction, and the cache result encapsulation method uniformly converts raw data from different sources (such as database query results and remote service return values) into a format that the caching system can recognize, shielding the differences in the underlying data structure. This interface-level abstraction eliminates the need for the business layer to concern itself with the specific implementation of the cache (whether it's a local Map or a Redis cluster). Data interaction can be completed simply by calling the interface, fundamentally decoupling business logic from the cache implementation.

[0092] The abstract cache implementation module, as an abstract subclass of the cache interface, serves to build a middleware architecture where common logic is decentralized and differentiated implementations are decentralized. This module encapsulates the common logic of cache operations, such as naming conventions for cache keys (to avoid key conflicts), basic exception handling mechanisms (e.g., circuit breaking strategies when cache connections fail), and cache result validation logic (determining whether data is valid or expired). Extracting this common logic avoids code duplication and improves development efficiency. Regarding the differentiated implementations of in-memory and remote caches, the abstract class uses abstract methods to defer the specific logic to subclasses: in-memory cache subclasses (e.g., local cache based on ConcurrentHashMap) need to implement fast memory read / write logic, focusing on capacity control and eviction strategies (e.g., the LRU algorithm); remote cache subclasses (e.g., Redis client implementations) need to handle network connections, serialization / deserialization, distributed locks, etc., focusing on high availability and data consistency. In this way, different types of cache implementations can both follow a unified operating specification and leverage their respective technical characteristics. The in-memory cache subclass takes advantage of the low latency of in-process storage to handle high-frequency data, while the remote cache subclass uses a distributed architecture to handle large-scale data storage and cross-instance sharing. The two complement each other through the link of abstract classes.

[0093] From a system architecture perspective, this design offers three key benefits: First, standardized interfaces enable upper-layer business logic to call different types of caches in a unified manner. For example, by combining in-memory cache subclasses and remote cache subclasses to achieve a "local + remote" two-level cache architecture, the business layer only needs to make one interface call, and the underlying layer can automatically complete the collaborative operation of multiple cache levels. Second, the existence of abstract classes reduces the cost of integrating new cache types. When new cache components (such as Couchbase and Ehcache) need to be supported, only a new subclass needs to be created to implement the abstract methods, without modifying the upper-layer interfaces and business logic, which conforms to the "open / closed principle." Third, the design of the cache result encapsulation method solves the problem of heterogeneous data formats. Whether it is a ResultSet returned by the database or a JSON object returned by a remote service, it can be converted into a unified cache value type through the encapsulation method, ensuring compatibility of data from different sources within the cache system. Furthermore, the layered design of the interface module and the abstract implementation module also reserves a wealth of hooks for the expansion of the caching function—for example, reserving strategy parameters in the data storage method to allow dynamic configuration of cache expiration time and read / write strategies, or integrating cache penetration protection logic (such as null value caching and Bloom filter verification) in the data acquisition method. These extension points enable the entire caching system to evolve flexibly with changes in business needs.

[0094] In one possible implementation, the system in this embodiment further includes a cache statistics module; the cache statistics module is specifically used to perform the following two steps:

[0095] Step 1: Record the cache hit count, cache miss count, and data access frequency for the local cache module and the remote module respectively; the cache hit count is the number of times the target data associated with the data query identifier exists in the module; the cache miss count is the number of times the target data associated with the data query identifier does not exist in the module.

[0096] Step 2: Optimize the caching strategy based on the cache hit count, cache miss count, and data access frequency corresponding to the local caching module and the remote module, respectively.

[0097] The cache statistics module in this system serves to provide a quantitative basis for dynamic adjustments to the caching strategy by collecting detailed data on the operational status of local and remote caching modules. Specifically, starting from the module's execution logic, step one, the data collection stage, is designed around the core performance indicators of the caching system. Cache hit counts directly reflect the caching module's ability to intercept data access requests—a high hit rate in the local cache means that frequently accessed data is efficiently handled, reducing reliance on remote networks or databases; the hit count in the remote cache reflects the coverage efficiency of mid-frequency data in the distributed storage layer. The number of misses, as a reverse indicator of hit counts, records scenarios where the cache misses occur. A continuously rising number of misses may indicate problems such as an unreasonable cache expiration strategy, untimely migration of hot data, or unsynchronized changes in the underlying data source. The statistics on data access frequency (usually calculated by time windows, such as minutes or hours) provide a dynamic benchmark for identifying the hotness or coldness of data. High-frequency access data should be prioritized for retention in the fast storage layer (such as the local cache), while low-frequency data can be gradually phased out or migrated to lower-cost storage media. It is worth noting that this module performs independent statistics on local and remote modules. This is precisely because it takes into account the essential differences between the two in terms of storage characteristics (local memory vs. remote distributed storage), access latency (nanoseconds vs. milliseconds), and capacity limitations (in-process space vs. cluster expansion capacity). This hierarchical statistical mechanism lays the data foundation for subsequent optimization of differentiated strategies.

[0098] Step two, strategy optimization, involves translating the collected statistical data into specific tuning actions. For example, if the number of hits in the local cache continues to decrease while the number of misses increases, the system may determine that the current local cache capacity is insufficient or that hot data has not been effectively identified. This triggers a "dynamic expansion" or "forced retention of hot data" strategy, adjusting the maximum capacity threshold of the local cache or marking the Top N high-frequency data as "permanently valid" based on access frequency to ensure that core data is always kept at the fastest access level. For the remote cache module, if statistics show that the access frequency of a certain type of data is lower than a preset threshold but the number of misses is high, it may mean that the storage cost (such as memory usage) and benefits (hit efficiency) of this data in the remote cache are not matched. In this case, the system will initiate a "low-frequency data degradation strategy," which migrates the data from the remote cache to the database or a lower-cost storage layer and increases its eviction priority in cache eviction algorithms (such as LRU and LFU), freeing up valuable remote cache space for more valuable data. Furthermore, access frequency data can be used to guide cache preheating strategies. Before peak business periods, high-frequency data lists based on historical statistics can be pre-loaded into local and remote caches to avoid cache penetration issues during cold starts. More in-depth optimization may involve cross-module collaborative adjustments. For example, when remote cache invalidation occurs concentrated in a specific time period (such as the daily early morning batch data update period), the system can automatically optimize the cache update tasks for that period in conjunction with the timeout of the distributed lock to avoid conflicts between update operations and high-concurrency access.

[0099] This application provides a data caching system, method, electronic device, and medium. The system includes a local caching module, a remote caching module, a cache management module, and a database. The local caching module stores data with an interaction frequency greater than a preset first threshold, employing an in-process caching mechanism and an ordered key-value pair structure for data storage; the interaction frequency is the number of times a client accesses data per unit time. The remote caching module stores data with an interaction frequency less than the preset first threshold but greater than a preset second threshold, employing a distributed caching mechanism and using Redis as the caching component; the preset first threshold is greater than the preset second threshold. The database stores data that misses both the local and remote caching modules. The cache management module determines a caching strategy based on data caching instructions from the client and the data storage status of the local and remote caching modules, and coordinates data interactions between the local, remote, and database modules through the caching strategy to execute the data caching task indicated by the data caching instructions; wherein the data access priority of the local caching module is greater than the data access priority of the remote caching module. In the system provided in this embodiment, data is stored in a tiered manner based on the frequency of data interaction. High-frequency data, whose access frequency exceeds a preset first threshold per unit time, is stored in the local cache module. In-process caching mechanisms and ordered key-value pairs are used to achieve fast read and write operations, preventing high-frequency access from directly impacting Redis. Medium- and low-frequency data, with interaction frequencies between the preset first and second thresholds, are stored in Redis. A distributed caching mechanism handles relatively infrequent access requests, thereby reducing Redis's caching pressure. Furthermore, the cache management module dynamically coordinates the interaction between the two-level cache and the database based on data storage conditions. When a client initiates a data caching command, it prioritizes querying the local cache module. Only if the local cache fails to find the data will it access Redis. If Redis also fails to find the data, the database takes over, and the retrieved data is synchronized to both levels of cache, forming an efficient data access path. This tiered processing method significantly reduces the frequency of direct access to Redis in high-concurrency scenarios, reduces latency and resource consumption caused by network interactions, and prevents Redis from becoming overloaded due to high-frequency access, thus effectively alleviating its caching pressure and improving the user experience on mobile devices.

[0100] The following describes a data caching method provided by an embodiment of this application. The data caching method described below can be referred to in correspondence with the data caching system described above.

[0101] This application provides a data caching method applied to a server, the server comprising: a local caching module, a remote caching module, and a database; wherein, the local caching module is used to store data with an interaction frequency greater than a preset first threshold, and the local caching module adopts an in-process caching mechanism and implements data storage based on an ordered key-value pair structure; wherein, the interaction frequency is the number of times the client accesses the data per unit time.

[0102] The remote caching module is used to store data whose interaction frequency is less than the preset first threshold and greater than the preset second threshold, and the remote caching module adopts a distributed caching mechanism and uses Redis as the caching component; the preset first threshold is greater than the preset second threshold;

[0103] The database is used to store data that has missed the local cache module and the remote cache module;

[0104] The method includes:

[0105] Based on the data caching instructions from the client and the data storage conditions of the local caching module and the remote caching module respectively, a caching strategy is determined, and the data interaction between the local caching module, the remote caching module and the database is coordinated through the caching strategy to execute the data caching task indicated by the data caching instructions;

[0106] The data access priority of the local cache module is higher than that of the remote cache module.

[0107] In one possible implementation, determining a caching strategy based on data caching instructions from the client and the data storage conditions of the local caching module and the remote caching module, and coordinating data interactions between the local caching module, the remote caching module, and the database through the caching strategy to execute the data caching task indicated by the data caching instructions, includes:

[0108] Determine the data query identifier corresponding to the data caching instruction;

[0109] Based on the data query identifier, determine whether there is target data associated with the data query identifier in the local cache module;

[0110] If it is determined that the target data exists in the local cache module, the target data is fed back to the client through the local cache module;

[0111] If it is determined that the target data does not exist in the local cache module, the existence of the target data in the remote cache module is determined based on the data query identifier.

[0112] If the target data is stored in the remote cache module, the target data stored in the remote cache module is written into the local cache module, and the target data is fed back to the client through the local cache module.

[0113] The following will describe an electronic device and a computer storage medium provided in the embodiments of this application.

[0114] See Figure 3 The figure is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, including:

[0115] Memory 11 is used to store computer programs;

[0116] The processor 12 is configured to implement the steps of a data caching method as described in any of the above method embodiments when executing the computer program.

[0117] In this embodiment, the device can be an in-vehicle computer, a PC (Personal Computer), or a terminal device such as a smartphone, tablet computer, handheld computer, or portable computer.

[0118] The device may include a memory 11, a processor 12, and a bus 13.

[0119] The memory 11 includes at least one type of readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 may be an internal storage unit of the device, such as the hard disk of the device. In other embodiments, the memory 11 may be an external storage device of the device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory 11 may include both internal and external storage units of the device. The memory 11 can be used not only to store application software and various types of data installed on the device, such as program code executing fault scenario screening methods, but also to temporarily store data that has been output or will be output. In some embodiments, the processor 12 may be a central processing unit (CPU).

[0120] In some embodiments, processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip, used to run program code stored in memory 11 or process data, such as program code for executing data caching methods.

[0121] This bus 13 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0122] Furthermore, the device may also include a network interface 14, which may optionally include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), typically used to establish communication connections between the device and other electronic devices.

[0123] Optionally, the device may further include a user interface 15, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the device and to display a visual user interface.

[0124] Figure 3 Only devices with components 11-15 are shown; those skilled in the art will understand that... Figure 3 The structure shown does not constitute a limitation on the device and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0125] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a computer-readable storage medium storing computer instructions for causing the computer to execute the data caching method as described in any of the above embodiments.

[0126] The computer-readable media in this application embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0127] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the data caching method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0128] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the system, method, electronic device, and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system, method, electronic device, and medium embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0129] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data caching system, characterized in that, Applied to the server side, the system includes: a local cache module, a remote cache module, a cache management module, and a database; The local cache module is used to store data with an interaction frequency greater than a preset first threshold. The local cache module adopts an in-process caching mechanism and implements data storage based on an ordered key-value pair structure. The interaction frequency is the number of times the client accesses the data per unit time. The remote caching module is used to store data whose interaction frequency is less than the preset first threshold and greater than the preset second threshold, and the remote caching module adopts a distributed caching mechanism and uses Redis as the caching component; the preset first threshold is greater than the preset second threshold; The database is used to store data that has missed the local cache module and the remote cache module; The cache management module is used to determine a caching strategy based on the data caching instructions from the client and the data storage conditions of the local cache module and the remote cache module, and to coordinate the data interaction between the local cache module, the remote cache module and the database through the caching strategy in order to execute the data caching task indicated by the data caching instructions. The data access priority of the local cache module is higher than that of the remote cache module.

2. The system according to claim 1, characterized in that, The cache management module includes a data interaction unit, which is specifically used for: Determine the data query identifier corresponding to the data caching instruction; Based on the data query identifier, determine whether there is target data associated with the data query identifier in the local cache module; If it is determined that the target data exists in the local cache module, the target data is fed back to the client through the local cache module; If it is determined that the target data does not exist in the local cache module, the existence of the target data in the remote cache module is determined based on the data query identifier. If the target data is stored in the remote cache module, the target data stored in the remote cache module is written into the local cache module, and the target data is fed back to the client through the local cache module.

3. The system according to claim 2, characterized in that, The data interaction unit is also used for: If the target data does not exist in the remote cache module, the target data associated with the target data is obtained through the database, and the target data source is synchronized to the local cache module and the remote cache module. The target data source is fed back to the client through the local caching module.

4. The system according to claim 1, characterized in that, The system further includes a cache update module, which is specifically used for: In the Redis instance, key-value pairs and their expiration times are set to determine whether the key-value pairs can be successfully set in the Redis instance; the key-value pairs are distributed locks. If the key-value pair is successfully set in Redis, the data source is retrieved from the database, and the remote cache module is updated based on the data source. If the key-value pair fails to be set in Redis, the cache update process is aborted.

5. The system according to claim 1, characterized in that, The system also includes: a cache interface module and an abstract cache implementation module; The cache interface module inherits the Closeable interface and is used to release cache resources and define cache operation methods. The cache operation methods include: data acquisition, data storage, data deletion, and cache result encapsulation. The abstract cache implementation module is an abstract subclass of the cache interface module, used to provide caching logic for data, and the caching logic is implemented through a memory cache subclass and a remote cache subclass.

6. The system according to claim 2, characterized in that, The system further includes: a cache statistics module; the cache statistics module is specifically used for: The system records the cache hit count, cache miss count, and data access frequency for each of the local cache module and the remote module. The cache hit count is the number of times the target data associated with the data query identifier exists within the module. The cache miss count is the number of times the target data associated with the data query identifier does not exist within the module. The caching strategy is optimized based on the cache hit count, cache miss count, and data access frequency for the local caching module and the remote caching module, respectively.

7. A data caching method, characterized in that, The system is applied to the server side, which includes a local cache module, a remote cache module, and a database. The local cache module is used to store data with an interaction frequency greater than a preset first threshold, and the local cache module adopts an in-process caching mechanism and implements data storage based on an ordered key-value pair structure. The interaction frequency is the number of times the client accesses the data per unit time. The remote caching module is used to store data whose interaction frequency is less than the preset first threshold and greater than the preset second threshold, and the remote caching module adopts a distributed caching mechanism and uses Redis as the caching component; the preset first threshold is greater than the preset second threshold; The database is used to store data that has missed the local cache module and the remote cache module; The method includes: Based on the data caching instructions from the client and the data storage conditions of the local caching module and the remote caching module respectively, a caching strategy is determined, and the data interaction between the local caching module, the remote caching module and the database is coordinated through the caching strategy to execute the data caching task indicated by the data caching instructions; The data access priority of the local cache module is higher than that of the remote cache module.

8. The method according to claim 7, characterized in that, The step of determining a caching strategy based on data caching instructions from the client and the data storage conditions of the local caching module and the remote caching module, and coordinating data interactions between the local caching module, the remote caching module, and the database through the caching strategy to execute the data caching task indicated by the data caching instructions, includes: Determine the data query identifier corresponding to the data caching instruction; Based on the data query identifier, determine whether there is target data associated with the data query identifier in the local cache module; If it is determined that the target data exists in the local cache module, the target data is fed back to the client through the local cache module; If it is determined that the target data does not exist in the local cache module, the existence of the target data in the remote cache module is determined based on the data query identifier. If the target data is stored in the remote cache module, the target data stored in the remote cache module is written into the local cache module, and the target data is fed back to the client through the local cache module.

9. An electronic device, characterized in that, The device includes: a processor, a memory, and a system bus; The processor and the memory are connected via the system bus; The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform the data caching method of any one of claims 7-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the data caching method as described in any one of claims 7-8.

Images