Redis data caching method and device, equipment and medium

By monitoring and analyzing the logs of Redis instances to identify hot keys and using the server event push interface to synchronize their information to the client, the resource consumption problem caused by hot keys in the Redis cluster is solved, achieving efficient data caching and improved stability.

CN121301416APending Publication Date: 2026-01-09YIQIQIFUNETWORK TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511626454.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-07
Publication Date
2026-01-09

AI Technical Summary

Technical Problem

In existing technologies, when a Redis client retrieves data, the resources of the node containing the hot key are consumed in large quantities, leading to a decrease in the performance and stability of the Redis cluster.

Method used

By periodically monitoring the command execution of the Redis instance, identifying hot keys using log analysis tools, and pushing hot key information to the client using the server event push interface, the client can determine whether the target data exists in the local cache space based on the hot key information. If it does not exist, it will retrieve it from the server and cache it locally.

Benefits of technology

It achieves automatic identification and near real-time synchronization of hot keys, reduces the access pressure on Redis nodes, avoids performance degradation and service unavailability caused by single-node overload, and improves cache hit rate and data consistency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121301416A_ABST
    Figure CN121301416A_ABST
Patent Text Reader

Abstract

The invention discloses a Redis data caching method, device and equipment and a medium, and relates to the technical field of data caching, and the method comprises the following steps: regularly monitoring a command execution condition of a local Redis instance to obtain a target monitoring log; analyzing the target monitoring log by using a log analysis tool to determine a hotspot key; and pushing current hotspot key information corresponding to the hotspot key to the Redis client by using a server event pushing interface, so that the Redis client judges whether target data exists in a local cache space based on the current hotspot key information, if not, the target data is acquired from the Redis server, and the target data is sent to the Redis server. And judging whether the target data is data corresponding to the hotspot key or not according to the current hotspot key information, and if so, caching the target data to the local. By caching the hotspot data, the problem of system crash caused by overload of a single node is avoided.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of data caching technology, and in particular to a Redis data caching method, apparatus, device, and medium. Background Technology

[0002] Redis is an open-source, high-performance key-value database that supports various data structures and functionalities. Redis is commonly used as a caching system to improve application responsiveness and scalability.

[0003] Currently, Redis clients typically retrieve the required data directly from the Redis server. This approach has the drawback of a large number of requests being concentrated on one or a few hot keys, which can lead to a significant consumption of resources such as CPU, memory, and network bandwidth on the Redis nodes containing these keys, thus affecting the overall performance and stability of the Redis cluster. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a Redis data caching method, apparatus, device, and medium that can avoid system crashes caused by single-node overload by caching hot data. The specific solution is as follows:

[0005] Firstly, this application provides a Redis data caching method applied to a Redis server, including:

[0006] Perform periodic monitoring of command execution on the local Redis instance to obtain the corresponding target monitoring logs;

[0007] The target monitoring logs are analyzed using a preset log analysis tool to identify hotspot keys whose access frequency exceeds a preset frequency threshold.

[0008] The current hot key information corresponding to the hot key is pushed to the Redis client using a preset server event push interface. The Redis client then determines whether the target data exists in its local target cache space based on the current hot key information. If the target data does not exist in the local target cache space, the target data is retrieved from the Redis server, and the client determines whether the target data is the data corresponding to the hot key based on the current hot key information. If the target data is the data corresponding to the hot key, the target data is cached in the local target cache space.

[0009] Optionally, the step of analyzing the target monitoring logs using a preset log analysis tool to determine hotspot keys with access frequencies exceeding a preset frequency threshold includes:

[0010] The preset log analysis tool is used to count the number of times each key appears in the target monitoring log. Based on the number of occurrences, the access frequency corresponding to each key is determined. Based on the access frequency, hot keys with access frequencies greater than the preset frequency threshold are selected from the keys.

[0011] Optionally, before pushing the current hot key information corresponding to the hot key to the Redis client using the preset server event push interface, the method further includes:

[0012] Run the Flask framework locally, create a target web service using the Flask framework, and configure a local Redis connection address in the target web service to build the preset server event push interface.

[0013] Optionally, the step of pushing the current hot key information corresponding to the hot key to the Redis client using a preset server event push interface includes:

[0014] The current hot key information is converted into a formatted target string, the target string is encapsulated into an event stream based on the server push event protocol, and the current hot key information is pushed to the Redis client in the form of an event stream using the preset server event push interface.

[0015] Secondly, this application provides a Redis data caching method applied to a Redis client, including:

[0016] The system determines whether target data exists in the local target cache space based on the current hot key information corresponding to the hot key. The hot key is data obtained by the Redis server using a preset target log analysis tool to analyze the target monitoring log. The hot key represents a key whose access frequency is greater than a preset frequency threshold. The target monitoring log is log obtained by the Redis server periodically monitoring the command execution status of the local Redis instance.

[0017] If the target data does not exist in the local target cache space, the target data is obtained from the Redis server, and it is determined whether the target data is the data corresponding to the hot key based on the current hot key information;

[0018] If the target data is the data corresponding to the hotspot key, then the target data is cached in the local target cache space.

[0019] Optionally, the Redis data caching method further includes:

[0020] If the target data exists in the local target cache space, then the target data is directly obtained from the local target cache space.

[0021] Optionally, the Redis data caching method further includes:

[0022] Clear the local current hotspot key information and receive new hotspot key information pushed by the preset server event push interface to update the local hotspot key information.

[0023] Thirdly, this application provides a Redis data caching device for use on a Redis server, comprising:

[0024] The monitoring log acquisition module is used to periodically monitor the command execution status of the local Redis instance in order to obtain the corresponding target monitoring logs;

[0025] The hotspot key determination module is used to analyze the target monitoring log using a preset log analysis tool to determine hotspot keys whose access frequency is greater than a preset frequency threshold.

[0026] The hotspot key information push module is used to push the current hotspot key information corresponding to the hotspot key to the Redis client using a preset server event push interface. This allows the Redis client to determine whether the target data exists in its local target cache space based on the current hotspot key information. If the target data does not exist in the local target cache space, the client retrieves the target data from the Redis server and determines whether the target data corresponds to the hotspot key based on the current hotspot key information. If the target data corresponds to the hotspot key, the client caches the target data in its local target cache space.

[0027] Fourthly, this application provides an electronic device, comprising:

[0028] Memory, used to store computer programs;

[0029] A processor for executing the computer program to implement the aforementioned Redis data caching method.

[0030] Fifthly, this application provides a computer-readable storage medium for storing a computer program that, when executed by a processor, implements the aforementioned Redis data caching method.

[0031] This application first performs periodic monitoring of command execution on the local Redis instance to obtain corresponding target monitoring logs. Then, it uses a preset log analysis tool to analyze the target monitoring logs to identify hot keys whose access frequency exceeds a preset frequency threshold. Finally, it uses a preset server event push interface to push the current hot key information corresponding to the hot key to the Redis client. This allows the Redis client to determine whether the target data exists in the local target cache space based on the current hot key information. If the target data does not exist in the local target cache space, the client retrieves the target data from the Redis server and determines whether the target data corresponds to the hot key based on the current hot key information. If the target data corresponds to the hot key, the client caches the target data in the local target cache space. Therefore, this application achieves automatic identification of frequently accessed hot keys by periodically monitoring the execution of Redis instance commands and analyzing logs; it also achieves near real-time synchronization of hot key information by actively pushing the identified hot key information to the client through the server event push interface; this allows the client to prioritize querying the local cache when accessing data based on the latest hot key information, and only requesting from the server if the data is not found locally, and automatically caching the data identified as a hot key locally. This transforms centralized hot access into distributed local cache access, effectively distributing the pressure on the Redis server and avoiding performance degradation and service unavailability caused by a single hot key exhausting resources. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0033] Figure 1 This application discloses a flowchart of a Redis data caching method applied to a Redis server.

[0034] Figure 2 This application discloses a flowchart of a Redis data caching method applied to a Redis client;

[0035] Figure 3 This is a schematic diagram of the structure of a Redis data caching device disclosed in this application;

[0036] Figure 4 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] Currently, the methods used by Redis clients to retrieve required data can lead to significant resource consumption, such as CPU, memory, and network bandwidth, on the Redis nodes containing hot keys, impacting the overall performance and stability of the Redis cluster. To address this, this application provides a Redis data caching method that avoids system crashes caused by single-node overload by caching hot data.

[0039] See Figure 1 As shown, this embodiment of the invention discloses a Redis data caching method, applied to a Redis server, including:

[0040] Step S11: Periodically monitor the command execution status of the local Redis instance to obtain the corresponding target monitoring logs.

[0041] The purpose of this embodiment is to provide a Redis hot key solution based on SSE (Server-Sent Events, a data push technology) and JavaAgent (a Java Virtual Machine function), which can effectively identify and process hot keys in Redis, avoid affecting the performance and stability of the caching service, and improve cache hit rate and data consistency.

[0042] By running Flask on the Redis server and using the redis-cli monitor command and redis-faina tool to monitor and analyze the command execution of the Redis instance in real time, we can identify frequently accessed hot keys and push them to the client via the SSE interface.

[0043] By implementing a JavaAgent on the client side and using ByteBuddy technology to intercept Redis requests, access and updates to the local cache JetCache (i.e., the target cache space) are achieved. Simultaneously, an SSE interface is subscribed to obtain information on hot keys, and the set of hot keys is used to determine whether to retrieve or update data from the local cache.

[0044] By using the above methods, we can achieve dynamic identification and processing of Redis hot keys, reduce access pressure on Redis nodes, improve the utilization of local cache JetCache, and ensure data consistency.

[0045] The overall process of the data caching method in this embodiment is as follows:

[0046] 1. Run Flask on the Redis server and periodically use the monitor command from redis-cli to obtain real-time command execution status of the Redis instance.

[0047] 2. Then, analyze the log information output by the monitor (i.e., the target monitoring log) using redis-faina (the default log analysis tool) to find the keys with high access frequency.

[0048] 3. Start the HTTP service and provide an SSE interface for users to subscribe to.

[0049] 4. When a new hot key is generated, it is written to this SSE interface.

[0050] 5. On the Redis user side, implement a JavaAgent. This Agent is loaded when the program starts. This Agent will implement the following functionality in the premain method:

[0051] 6. Implement a hot key monitoring service and load it into the code. Monitor the Redis SSE interface; when new information is received, clear the HotKeySet and write the received information to the local variable HotKeySet.

[0052] 7. Redis requests are intercepted using JavaAgent and ByteBuddy bytecode technologies. If the key required by the request exists in the local JetCache, it is accessed directly. Otherwise, Redis is called to retrieve the result. After retrieving the result, the key is checked in HotKeySet. If it exists, the key and its corresponding value are written to JetCache.

[0053] Step S12: Analyze the target monitoring log using a preset log analysis tool to identify hotspot keys whose access frequency exceeds a preset frequency threshold.

[0054] In this embodiment, the Redis server needs to define a global variable to store a set of hot keys, initialized to an empty set; and define a function to execute the `redis-cli monitor` command and redirect the output to a file. The main steps of this function are as follows:

[0055] 1) Import the subprocess module to execute external commands.

[0056] 2) Open a file in write mode and name it monitor.log.

[0057] 3) Use the subprocess.run method to execute the redis-cli monitor command and redirect standard output to a file object.

[0058] 4) Close the file object.

[0059] In this embodiment, the process of analyzing the target monitoring log using a preset log analysis tool to determine hotspot keys with access frequencies greater than a preset frequency threshold can specifically include: using the preset log analysis tool to count the occurrence frequency of each key in the target monitoring log, determining the access frequency corresponding to each key based on the occurrence frequency, and filtering out hotspot keys with access frequencies greater than the preset frequency threshold from the keys based on the access frequencies. Specifically:

[0060] Define a function to analyze the monitor.log file, identify frequently accessed keys, and update the hot key set. The main steps of this function are as follows:

[0061] 1) Import the re module for regular expression matching.

[0062] 2) Import the collections module to create a counter object.

[0063] 3) Open the monitor.log file in read mode and read all lines into a list.

[0064] 4) Define a regular expression to match the key, i.e. the string within the double quotes.

[0065] 5) Create a counter object to count the number of times the key appears.

[0066] 6) Iterate through each log line, use regular expressions to search for the key, and update the counter object.

[0067] 7) Define a threshold to determine whether a key is a hot key. This threshold can be adjusted according to the actual situation.

[0068] 8) Clear the hot key set.

[0069] 9) Iterate through the counter object, find the keys that exceed the threshold (i.e., the preset frequency threshold), and add them to the hot key set.

[0070] By identifying hot keys in the system, it is easier to cache these hot keys on the client side. This allows the client to retrieve hot keys directly from the local cache, reducing direct access to Redis nodes and thus avoiding the problem of single-node overload.

[0071] Step S13: Push the current hot key information corresponding to the hot key to the Redis client using the preset server event push interface, so that the Redis client can determine whether the target data exists in the local target cache space based on the current hot key information. If the target data does not exist in the local target cache space, the target data is obtained from the Redis server, and the client determines whether the target data is the data corresponding to the hot key based on the current hot key information. If the target data is the data corresponding to the hot key, the target data is cached in the local target cache space.

[0072] In this embodiment, before pushing the current hot key information corresponding to the hot key to the Redis client using the preset server event push interface, the method further includes: running the Flask framework locally, creating a target web service using the Flask framework, and configuring the local Redis connection address in the target web service to construct the preset server event push interface.

[0073] The process described above involves: running the Flask framework on the Redis server; creating a web application (the target web service) to provide an SSE (Server-Sent Events) interface (a pre-defined server event push interface) for Redis users to subscribe to information about hot keys; configuring the Redis connection address within the web application and registering an SSE blueprint to implement the SSE interface functionality; defining a function to start the web application and provide an SSE interface for Redis users to subscribe to; and finally, calling the Flask framework's `run` method to start the web application.

[0074] In addition, in this embodiment, the process of pushing the current hot key information corresponding to the hot key to the Redis client using the preset server event push interface may specifically include: converting the current hot key information into a formatted target string, encapsulating the target string into an event stream based on the server push event protocol, and pushing the current hot key information to the Redis client in the form of an event stream using the preset server event push interface.

[0075] Specifically, this embodiment defines a route to return information about hot keys to the Redis user. The main steps of this route are as follows:

[0076] 1) Convert the hot key set to a string and separate it with commas.

[0077] 2) Return an SSE response and set the event type to hotkeys and the relevant response header information.

[0078] In addition, this embodiment also defines a scheduled task that executes the monitor_redis and analyze_log functions at regular intervals. The main steps of this scheduled task are as follows:

[0079] 1) Import the schedule and time modules to implement the timer function.

[0080] 2) Use the schedule.every method to set the monitor_redis and analyze_log functions to be executed every 10 seconds. This can be adjusted according to the actual situation.

[0081] 3) Run scheduled tasks in a loop, use the schedule.run_pending method to execute tasks that have expired, and use the time.sleep method to pause for one second.

[0082] The `start_server` function is run in another thread. The main steps of this thread are as follows:

[0083] 1) Import the threading module, which is used to create thread objects.

[0084] 2) Create a thread object and pass the start_server function as the target function.

[0085] 3) Start the thread object.

[0086] In other words, this embodiment updates hot data regularly to ensure the timeliness of the data.

[0087] Therefore, this application achieves automatic identification of frequently accessed hot keys by periodically monitoring the execution of Redis instance commands and analyzing logs; it also achieves near real-time synchronization of hot key information by actively pushing the identified hot key information to the client through the server event push interface; this allows the client to prioritize querying the local cache when accessing data based on the latest hot key information, and only requesting from the server if the data is not found locally, and automatically caching the data identified as a hot key locally. This transforms centralized hot access into distributed local cache access, effectively distributing the pressure on the Redis server and avoiding performance degradation and service unavailability caused by a single hot key exhausting resources.

[0088] As can be seen from the foregoing embodiments, this application has described in detail the Redis client operations during the data caching process. To make the technical solution in this application more complete, the Redis client operations will be described in detail below. See also Figure 2 As shown in the figure, this invention discloses a Redis data caching method, applied to a Redis client, including:

[0089] Step S21: Determine whether target data exists in the local target cache space based on the current hot key information corresponding to the hot key; wherein, the hot key is data obtained by the Redis server using a preset target log analysis tool to analyze the target monitoring log, the hot key represents a key whose access frequency is greater than a preset frequency threshold, and the target monitoring log is log obtained by the Redis server periodically monitoring the command execution status of the local Redis instance.

[0090] In this embodiment, the Redis client is:

[0091] 1. Implement a JavaAgent class that loads at program startup, passing an Instrumentation object as a parameter. The main steps of this class are as follows:

[0092] Define a static variable to store an instance of the local cache JetCache, and initialize it to null.

[0093] Define a static variable to store a collection of hot keys, and initialize it to empty.

[0094] Define a `premain` method, which is loaded when the program starts, and passes an `Instrumentation` object as a parameter. The main steps of this method are as follows:

[0095] The init method is called to initialize the local cache JetCache and the hot key collection, and the SSE interface is subscribed to obtain hot key information.

[0096] Use ByteBuddy technology to create an AgentBuilder object to intercept Redis requests. The main steps of this object are as follows:

[0097] The class name to be intercepted is specified as org.springframework.data.redis.core.RedisTemplate, which can be modified according to the actual situation.

[0098] Specify the method to be intercepted as opsForValue, which can be modified according to the actual situation.

[0099] Use the Advice technique to insert custom logic before and after method execution, and specify the RedisAdvice class as the notification class.

[0100] Install the AgentBuilder object into the Instrumentation object.

[0101] 2. In the `init` method, subscribe to the SSE interface to obtain hot key information. The main steps of this method are as follows:

[0102] Create an instance of the hot key collection, using a thread-safe ConcurrentHashMap as the underlying data structure.

[0103] Create an instance of RestTemplate to send HTTP requests.

[0104] Send an HTTP request and retrieve an SSE response. An SSE response is a regular HTTP response, but it has specific headers and data formatting. Assume the SSE interface address is http: / / localhost:5000 / stream / hotkeys; this can be modified according to your specific needs.

[0105] Use a loop to continuously read the data portion of the SSE response until completion. Read one line of data at a time, representing one event. Each event is a string containing the event type, data, and other information.

[0106] Within the loop, the event's data portion, specifically the hotspot key information, is parsed. This data portion is a string containing multiple hotspot keys, separated by commas.

[0107] Convert the data portion into a string array, that is, treat each hot key as an element.

[0108] Clear the hot key set, which means removing all elements.

[0109] Iterate through the string array and add each element to the hot key set. This completes the update of the hot key set.

[0110] 3. Implement a RedisAdvice class to insert custom logic before and after method execution. The main steps of this class are as follows:

[0111] Define a static method that intercepts the Redis request before the method execution, checks if the key exists in the local cache JetCache, and if so, returns the result directly and skips the Redis request. The main steps of this method are as follows:

[0112] Use the Advice.Argument annotation to get the first parameter as the key.

[0113] Use the jetCache.containsKey method to determine if the key is in the local cache JetCache.

[0114] If the value exists, retrieve it from the local JetCache cache using the `jetCache.get` method and return the result. Simultaneously, use the `Advice.OnNonDefaultValue` annotation to indicate that the Redis request should be skipped.

[0115] If it does not exist, return null and continue executing the Redis request.

[0116] Define a static method that intercepts Redis requests after the method execution, checks if the key is in the hot key set, and if so, writes the key and its corresponding value to the local cache JetCache. The main steps of this method are as follows:

[0117] Use the Advice.Argument annotation to get the first parameter as the key.

[0118] Use the Advice.Return annotation to retrieve the return value as the value.

[0119] Use the hotKeySet.contains method to determine if a key is in the hotkey set.

[0120] If it exists, use the jetCache.put method to write the key and the corresponding value into the local cache JetCache.

[0121] Step S22: If the target data does not exist in the local target cache space, the target data is obtained from the Redis server, and the target data is determined to be the data corresponding to the hot key based on the current hot key information.

[0122] The data caching method in this embodiment further includes: if target data exists in the local target cache space, then the target data is directly obtained from the local target cache space.

[0123] It is understandable that the local target cache space stores the data corresponding to the hot keys that the client previously obtained from the server. A certain key may have been cached locally by the client in the previous round of judgment because it is a hot key, so this time the value corresponding to the hot key can be directly obtained from the local cache.

[0124] By retrieving data from the local cache space, the problem of excessive load on hot nodes due to direct access to Redis nodes is avoided.

[0125] Step S23: If the target data is the data corresponding to the hotspot key, then cache the target data in the local target cache space.

[0126] The data caching method in this embodiment further includes: clearing the current hotspot key information locally, and receiving new hotspot key information pushed by a preset server event push interface to update the local hotspot key information.

[0127] It is understandable that in this embodiment, the server can periodically monitor the command execution status of the Redis instance and update the monitoring log accordingly. Therefore, the hot keys may be different at different times. By updating the local hot key information, the timeliness of the data is ensured.

[0128] Therefore, this application achieves automatic identification of frequently accessed hot keys by periodically monitoring the execution of Redis instance commands and analyzing logs; it also achieves near real-time synchronization of hot key information by actively pushing the identified hot key information to the client through the server event push interface; this allows the client to prioritize querying the local cache when accessing data based on the latest hot key information, and only requesting from the server if the data is not found locally, and automatically caching the data identified as a hot key locally. This transforms centralized hot access into distributed local cache access, effectively distributing the pressure on the Redis server and avoiding performance degradation and service unavailability caused by a single hot key exhausting resources.

[0129] See Figure 3 As shown in the figure, an embodiment of the present invention discloses a Redis data caching device, applied to a Redis server, comprising:

[0130] The monitoring log acquisition module 11 is used to periodically monitor the command execution status of the local Redis instance in order to obtain the corresponding target monitoring logs;

[0131] Hotspot key determination module 12 is used to analyze the target monitoring log using a preset log analysis tool to determine hotspot keys whose access frequency is greater than a preset frequency threshold.

[0132] The hotspot key information push module 13 is used to push the current hotspot key information corresponding to the hotspot key to the Redis client using a preset server event push interface. This allows the Redis client to determine whether the target data exists in its local target cache space based on the current hotspot key information. If the target data does not exist in the local target cache space, the client retrieves the target data from the Redis server and determines whether the target data is the data corresponding to the hotspot key based on the current hotspot key information. If the target data is the data corresponding to the hotspot key, the client caches the target data in its local target cache space.

[0133] In some specific embodiments, the hotspot key determination module 12 may specifically include:

[0134] The hotspot key determination unit is used to use the preset log analysis tool to count the number of times each key appears in the target monitoring log, determine the access frequency corresponding to each key based on the number of occurrences, and filter out hotspot keys whose access frequency is greater than the preset frequency threshold from the keys according to the access frequency.

[0135] In some specific embodiments, the hotspot key information push module 13 further includes:

[0136] The interface construction unit is used to run the Flask framework locally, create a target web service using the Flask framework, and configure a local Redis connection address in the target web service to build the preset server event push interface.

[0137] In some specific embodiments, the hotspot key information push module 13 may specifically include:

[0138] The hotspot key information push unit is used to convert the current hotspot key information into a formatted target string, encapsulate the target string into an event stream based on the server push event protocol, and push the current hotspot key information to the Redis client in the form of an event stream using the preset server event push interface.

[0139] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0140] Figure 4This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the Redis data caching method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0141] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0142] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0143] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the Redis data caching method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0144] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed Redis data caching method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0145] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0146] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0148] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0149] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A Redis data caching method, characterized in that, Applied to Redis server, including: Perform periodic monitoring of command execution on the local Redis instance to obtain the corresponding target monitoring logs; The target monitoring logs are analyzed using a preset log analysis tool to identify hotspot keys whose access frequency exceeds a preset frequency threshold. The current hot key information corresponding to the hot key is pushed to the Redis client using a preset server event push interface. The Redis client then determines whether the target data exists in its local target cache space based on the current hot key information. If the target data does not exist in the local target cache space, the target data is retrieved from the Redis server, and the client determines whether the target data is the data corresponding to the hot key based on the current hot key information. If the target data is the data corresponding to the hot key, the target data is cached in the local target cache space.

2. The Redis data caching method according to claim 1, characterized in that, The step of analyzing the target monitoring logs using a preset log analysis tool to identify hotspot keys with access frequencies exceeding a preset frequency threshold includes: The preset log analysis tool is used to count the number of times each key appears in the target monitoring log. Based on the number of occurrences, the access frequency corresponding to each key is determined. Based on the access frequency, hot keys with access frequencies greater than the preset frequency threshold are selected from the keys.

3. The Redis data caching method according to claim 1, characterized in that, Before pushing the current hot key information corresponding to the hot key to the Redis client using the preset server event push interface, the method further includes: Run the Flask framework locally, create a target web service using the Flask framework, and configure a local Redis connection address in the target web service to build the preset server event push interface.

4. The Redis data caching method according to claim 1, characterized in that, The step of pushing the current hot key information corresponding to the hot key to the Redis client using a preset server event push interface includes: The current hot key information is converted into a formatted target string, the target string is encapsulated into an event stream based on the server push event protocol, and the current hot key information is pushed to the Redis client in the form of an event stream using the preset server event push interface.

5. A Redis data caching method, characterized in that, Applied to Redis clients, including: The system determines whether target data exists in the local target cache space based on the current hot key information corresponding to the hot key. The hot key is data obtained by the Redis server using a preset target log analysis tool to analyze the target monitoring log. The hot key represents a key whose access frequency is greater than a preset frequency threshold. The target monitoring log is log obtained by the Redis server periodically monitoring the command execution status of the local Redis instance. If the target data does not exist in the local target cache space, the target data is obtained from the Redis server, and it is determined whether the target data is the data corresponding to the hot key based on the current hot key information; If the target data is the data corresponding to the hotspot key, then the target data is cached in the local target cache space.

6. The Redis data caching method according to claim 5, characterized in that, Also includes: If the target data exists in the local target cache space, then the target data is directly obtained from the local target cache space.

7. The Redis data caching method according to claim 5, characterized in that, Also includes: Clear the local current hotspot key information and receive new hotspot key information pushed by the preset server event push interface to update the local hotspot key information.

8. A Redis data caching device, characterized in that, Applied to Redis server, including: The monitoring log acquisition module is used to periodically monitor the command execution status of the local Redis instance in order to obtain the corresponding target monitoring logs; The hotspot key determination module is used to analyze the target monitoring log using a preset log analysis tool to determine hotspot keys whose access frequency is greater than a preset frequency threshold. The hotspot key information push module is used to push the current hotspot key information corresponding to the hotspot key to the Redis client using a preset server event push interface. This allows the Redis client to determine whether the target data exists in its local target cache space based on the current hotspot key information. If the target data does not exist in the local target cache space, the client retrieves the target data from the Redis server and determines whether the target data corresponds to the hotspot key based on the current hotspot key information. If the target data corresponds to the hotspot key, the client caches the target data in its local target cache space.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the Redis data caching method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program, which, when executed by a processor, implements the Redis data caching method as described in any one of claims 1 to 7.