A hotspot data caching processing method and device

Abstract

This application provides a method and apparatus for hot data caching, relating to the field of data processing technology. The method includes: determining whether the target data requested by a data retrieval request from a caller is already cached; if so, and the target data is not stored in the cache, then determining whether the target data is hot data based on the count values ​​of a pre-generated filter within each unit time period of the sliding time window; if so, updating the filter's count value in the current time period according to the filter's count value in each unit time period, setting the target data retrieved from the database into the cache, and returning it to the caller; if not, incrementing the filter's count value in the current time period by 1, and returning the target data retrieved from the database to the caller. This application determines whether the target data is hot data by the filter's count value in each unit time period, setting it into the cache only when the target data is hot data, thus avoiding writing a large amount of cold data into the cache.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for caching hot data. Background Technology

[0002] To enable fast access to certain data and reduce database access pressure, a common practice is to set a cache key for this data when it is first accessed, and then set an expiration time for that key to remove it from the cache. Normally, this data caching method supports services well and effectively reduces database access pressure. However, when a caller requests a large amount of data (such as hundreds of millions of full video data sets), a surge of cold data appears in the cache. The writing of new data and the failure to release memory space for expired cold data in a timely manner cause the cache to grow until it overflows, impacting business operations. Summary of the Invention

[0003] In view of this, this application provides a hot data caching processing method and apparatus to solve the problem of cold data occupying a large amount of cache in the prior art. The technical solution is as follows:

[0004] A method for caching hot data includes:

[0005] If the target data has been configured to be cached and the target data is not currently stored in the cache, the target data is determined as hot data based on the count value of the pre-generated filter in each unit time within the sliding time window. The sliding time window is determined according to the current time and the cache expiration time corresponding to the cache key of the target data. The count value of the filter in one unit time represents the number of database accesses of the target data by the caller in that unit time. The initial count value of the filter in one unit time is 0.

[0006] If the target data is hot data, then the filter count value in the current time is updated according to the filter count value in each unit time, the target data obtained from the database is set into the cache, and the obtained target data is returned to the caller.

[0007] If the target data is not hot data, the filter's count value for the current time is incremented by 1, and the target data obtained from the database is returned to the caller.

[0008] Optionally, determining whether the target data is hot data based on the count values ​​within each unit time period contained in the sliding time window using a pre-generated filter includes:

[0009] Determine whether hot data identification is needed for the target data;

[0010] If hot data identification is required for target data, it is determined whether the ID of the target data is less than the preset ID threshold. The larger the ID of a data, the later the data was generated.

[0011] If so, the target data is determined as hot data based on the count values ​​of the filter within each unit of time within the sliding time window.

[0012] Optional, also includes:

[0013] If hot data identification is not required for the target data, then the target data is identified as hot data.

[0014] Optionally, the filters include cuckoo filters generated for each unit of time within the sliding time window. The names of the cuckoo filters are based on the business keywords of the target data, the current time, and the cache expiration time.

[0015] Optionally, the first unit of time included in the sliding time window is the current time minus the cache expiration time, and the last unit of time is the current time;

[0016] Whether the target data is hot data is determined based on the count values ​​within each unit time period included in the sliding time window by the filter, including:

[0017] The count value of the cuckoo filter generated in the first unit time included in the sliding time window is taken as the first count value, the count value of the cuckoo filter generated in the last unit time included in the sliding time window is taken as the second count value, and the sum of the count values ​​of the cuckoo filters generated in all units time except the first unit time and the last unit time is calculated, and the sum is taken as the third count value.

[0018] If the second count value is greater than or equal to the preset count threshold, the target data is determined to be hot data;

[0019] If the second count value is less than the count threshold, calculate the sum of the first count value, the second count value and the third count value, and use the sum as the fourth count value;

[0020] If the fourth count value is greater than or equal to the count threshold, the target data is determined to be hot data; otherwise, the target data is determined not to be hot data.

[0021] Optionally, the filter's count value for the current time period is updated based on the filter's count value for each unit of time period, including:

[0022] Determine if the third count value is equal to 0;

[0023] If the third count value is equal to 0, then the second count value is reset to the count threshold;

[0024] If the third count value is not equal to 0, then increment the second count value by 1.

[0025] Optionally, the expiration time of the Cuckoo filter can be set to the cache expiration time plus 2.

[0026] Optionally, the relevant parameters and / or ID thresholds and / or business keywords and / or count thresholds of the Cuckoo filter during the generation phase can be configured online via Apollo.

[0027] Optionally, business keywords can be used as hashtags, and a Lua script can be used to determine whether the target data is hot data based on the count values ​​of the pre-generated filter within each unit time within the sliding time window. If the target data is hot data, the count value of the filter in the current time is updated according to the count value of the filter in each unit time. If the target data is not hot data, the count value of the filter in the current time is incremented by 1.

[0028] A hotspot data caching processing device, comprising:

[0029] The cache configuration judgment unit is used to receive data retrieval requests from the caller and determine whether the target data requested by the data retrieval request has been configured to be cached.

[0030] The hot data judgment unit is used to determine whether the target data is hot data based on the count value of the pre-generated filter in each unit time within the sliding time window when the target data has been configured to be cached and the target data is not currently stored in the cache. The sliding time window is determined according to the cache expiration time corresponding to the cache key of the target data at the current time. The count value of the filter in one unit time represents the number of database accesses of the target data by the caller in that unit time. The initial count value of the filter in one unit time is 0.

[0031] The hot data cache processing unit is used to update the filter's count value in the current time according to the filter's count value in each unit time if the target data is hot data, set the target data obtained from the database into the cache, and return the obtained target data to the caller.

[0032] The cold data processing unit is used to increment the filter's count value by 1 in the current time if the target data is not hot data, and then return the target data obtained from the database to the caller.

[0033] As can be seen from the above technical solution, the hot data caching method provided in this application receives a data retrieval request from the caller, determines whether the target data requested by the data retrieval request has been configured for caching, and if the target data has been configured for caching and is not currently stored in the cache, determines whether the target data is hot data based on the count value of a pre-generated filter within each unit time within the sliding time window. If the target data is hot data, the filter's count value in the current time is updated according to the filter's count value in each unit time, the target data retrieved from the database is set into the cache, and the retrieved target data is returned to the caller. If the target data is not hot data, the filter's count value in the current time is incremented by 1, and the target data retrieved from the database is returned to the caller. This application can determine whether the target data is hot data through the filter's count value in each unit time, and only sets the target data into the cache when the target data is hot data, avoiding a large amount of cold data being written to the cache, and indirectly solving the problem of expired cold data keys not being released from memory. Attached Figure Description

[0034] 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 embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0035] Figure 1 A flowchart illustrating a hotspot data caching method provided in an embodiment of this application;

[0036] Figure 2 This is a schematic diagram illustrating the process of determining whether target data is hot data based on count values;

[0037] Figure 3 A flowchart illustrating another hot data caching method provided in this application embodiment;

[0038] Figure 4 A schematic diagram of a hotspot data caching processing device provided in an embodiment of this application;

[0039] Figure 5 This is a hardware structure block diagram of a hotspot data caching processing device provided in an embodiment of this application. Detailed Implementation

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

[0041] To facilitate the explanation of the hot data caching method provided in this application, the relevant terms used in this application are explained below.

[0042] Distributed caching refers to a caching component or service that is separate from the application. It is an independent application in itself, isolated from the local application, and multiple applications can directly share the cache. In this invention, it specifically refers to Redis caching.

[0043] PUGC videos: User-uploaded videos, not copyrighted videos.

[0044] Hot and cold data: Based on the frequency of access, data can be categorized into hot data, warm data, and cold data. Cold data refers to data that is not frequently accessed, while hot data refers to data that is frequently accessed. In this invention, data accessed less than a threshold is considered cold data, and data accessed more than or equal to the threshold is considered hot data.

[0045] Bloom Filter: A Bloom filter, proposed by Howard Bloom in 1970, is a clever probabilistic data structure that tells you whether something definitely doesn't exist or might exist. When a Bloom filter says something exists, it might not exist; when a Bloom filter says something doesn't exist, it definitely doesn't exist. Bloom filters are highly efficient for insertion and querying, and consume very little memory.

[0046] Cuckoo Filter: To address the issue of Bloom filters' inability to delete elements, the authors of the paper "Cuckoo Filter: Better Than Bloom" proposed the Cuckoo Filter. Compared to Bloom filters, the Cuckoo Filter offers higher lookup performance, even when near full capacity (e.g., when space utilization reaches 95%). It also has lower space overhead than Bloom filters if a false positive rate of less than 3% is required. It supports dynamic addition and deletion of elements, and also supports counting.

[0047] Apollo: Apollo is a distributed configuration center developed by Ctrip's framework department. It can centrally manage the configuration of applications in different environments and clusters. After the configuration is modified, it can be pushed to the application in real time. It also has standardized permissions, process governance and other features, and is suitable for microservice configuration management scenarios.

[0048] Redis hashtag: Hashtags are used in Redis clusters and are implemented by adding curly braces {} to the key. The same hashtag is assigned to the same node and the same slot.

[0049] Redis Lua scripts: Redis scripts use a Lua interpreter to execute the scripts. In this invention, Lua scripts are used to ensure the atomicity of operations.

[0050] Lazy cleanup: When data expires, Redis does not rush to delete the data, but waits until the key is requested again before deleting it.

[0051] Periodic cleanup: At regular intervals, some keys are sampled and checked for expiration, and all expired keys are deleted. If the percentage of expired keys exceeds the acceptable percentage, the deletion process is repeated until the percentage of expired keys drops below the acceptable level.

[0052] As described in the background section, current solutions cannot distinguish between hot and cold data. All requested keys are cached, resulting in a large amount of cold data in the cache. For example, current solutions utilizing Redis's own data eviction policy limit the memory usage of Redis, allowing Redis to retain hot data in memory based on its eviction policy. Another example is a cache invalidation solution based on the Least Recently Used (LRU) principle. Each time the Redis cache is hit, a certain expiration time (TTL) is added to the hit cache key. After a period of time, the TTL of hot data becomes large, preventing automatic expiration, while cold data generally expires immediately after the set TTL.

[0053] Both of the above schemes result in a large amount of cold data in the cache. In addition, in the second scheme, hot data may never expire, thus forming dirty data. Furthermore, due to Redis's expired key deletion strategy, which combines lazy eviction and periodic eviction, even if cold data expires, memory will not be released immediately. Therefore, expired key memory will still be occupied. Moreover, as the amount of written data increases, Redis will run out of memory, thus triggering its own data eviction policy. Frequent triggering of its own data eviction policy is not CPU friendly and has a high cost.

[0054] To address the problems of existing technologies and reduce cache usage, the inventors of this case conducted research. In the initial stage, the inventors conceived of using a Redis incr counter in memory to count the accessed data when it is accessed in the database. Based on the count value, they could determine whether the accessed data was "hot" data; if so, it would be added to the cache; otherwise, if the accessed data was "cold" data, it would not be added to the cache. This data caching method can reduce cache usage to some extent.

[0055] However, after in-depth research on the Redis incr counter, the inventors of this case discovered that the Redis incr counter occupies a large amount of memory, while the amount of data that can be set to be cached is very large (usually hundreds of millions of data). Using the Redis incr counter to count each data would consume a large amount of memory.

[0056] To further reduce memory usage, the inventors conducted in-depth research and discovered that filters consume less memory than Redis incr counters. Therefore, filters can be used to replace the Redis incr counter, thus improving memory efficiency. Furthermore, considering that if a piece of data has a high access volume (i.e., a high overall count) but the access span is large, this data may not be hot data. Therefore, a sliding time window corresponding to the current time can be set, and the access volume within each unit of time included in the sliding time window can be studied to determine whether the data is hot data, resulting in a more accurate assessment. To this end, the inventors further improved the above preliminary research scheme and ultimately proposed a superior solution. The following embodiments will introduce the hot data caching method disclosed in this application.

[0057] Please see Figure 1 The diagram illustrates a flowchart of a hotspot data caching method provided in an embodiment of this application. This hotspot data caching method may include:

[0058] Step S101: Receive a data retrieval request from the caller and determine whether the target data requested by the data retrieval request has been cached.

[0059] Considering that different data characteristics result in varying probabilities of data becoming "hot data," for example, some products are affordable and cost-effective, making them more likely to become hot data, while other products are expensive and unlikely to become hot data. To avoid database overload caused by accessing hot data, configuration information is typically set for each piece of data written to the database, based on manual experience, to determine whether it can be cached. Specifically, caching is configured for data that is highly likely to become hot data, so that it is written to the cache space upon its first access.

[0060] In this step, when a data retrieval request is received from the caller, it can first be determined whether the target data requested by the data retrieval request has been cached. If no cache has been configured, the target data is directly retrieved from the database and returned to the caller. If a cache has been configured, the following steps are performed.

[0061] Optionally, the target data can be video data, such as PUGC video data. Of course, the target data can also be other types, and this application does not specifically limit it.

[0062] Step S102: If the target data has been configured to be cached and the target data is not currently stored in the cache, determine whether the target data is hot data based on the count value of each unit time within the sliding time window contained by the pre-generated filter.

[0063] Specifically, if the target data is already cached, this application will first determine whether the target data is already stored in the current cache. If the target data is already stored, it means that a caller has previously requested the target data, and the target data in the cache can be returned to the caller directly.

[0064] If the target data is not stored, this step is required to determine whether the target data is hot data (also known as hot spot data). Specifically, this application first determines the sliding time window corresponding to the current time, and then uses the count value of the filter generated within the sliding time window in each unit time period contained in the sliding time window to determine whether the target data is hot data.

[0065] It should be noted that the count value of the filter within a unit of time represents the number of database accesses to the target data by the caller within that unit of time, and the initial count value of the filter within a unit of time is 0. Here, database access refers to the number of times the target data is retrieved from the database.

[0066] The sliding time window is determined based on the current time and the cache expiration time corresponding to the cache key of the target data. For example, if the cache expiration time corresponding to the cache key of the target data is n hours and the current time is i, then the sliding time window is [in, i].

[0067] For example, if the cache expiration time corresponding to the cache key of the target data is 3 hours, the current time is 14:00, and the unit time is per hour, then the sliding time window is [11,14]. This application can use the filter to determine whether the target data is hot data based on a total of 4 count values ​​at 11:00, 12:00, 13:00 and 14:00 respectively.

[0068] It should be noted that this application counts the number of database accesses to the target data, rather than the actual number of accesses to the target data, in order to reduce the pressure on the filter. For example, if the actual number of accesses to the target data is statistically analyzed, the result is approximately 400,000 times per minute. However, according to the scheme of this application, the number of database accesses to the target data is approximately 80,000 times per minute, which is far lower than the actual number of accesses to the target data. This greatly reduces the pressure on the filter to identify hot data and the counting pressure.

[0069] Step S103a: If the target data is hot data, then update the filter's count value in the current time according to the filter's count value in each unit time, set the target data obtained from the database into the cache, and return the obtained target data to the caller.

[0070] Specifically, since the target data is not currently written to the cache, it is necessary to retrieve the target data from the database and return it to the caller.

[0071] Since the target data is hot data, in order to avoid a large number of data retrieval requests for the target data during the future cache expiration period, which would require retrieving the target data from the database and cause the database to be overwhelmed, this application can write the target data retrieved from the database into the current cache. In this way, the target data can be read from the cache instead of the database in the future.

[0072] Furthermore, in this embodiment of the application, if the target data is determined to be hot data, the filter's count value in the current time period needs to be updated based on the filter's count value in each unit time period. Optionally, the filter's count value in the current time period can be updated based on the filter's count value in other unit time periods included in the sliding time window, excluding the first and last unit time periods.

[0073] Step S103b: If the target data is not hot data, increment the filter's count value in the current time by 1, and return the target data obtained from the database to the caller.

[0074] If the target data is not hot data, i.e., it is cold data (in this application, data only has two forms: hot data and cold data), the target data can be retrieved from the database and returned to the caller, but the target data is not written to the current cache. This is because the database access volume of the target data itself is not large, and even if the target data is read from the database, it will not cause damage to the database.

[0075] Additionally, in this embodiment of the application, if the target data is determined to be cold data, the target data accessed from the database this time is added to the filter's count value in the current time, that is, the filter's count value in the current time is incremented by 1.

[0076] The hot data caching method provided in this application receives a data retrieval request from a caller, determines whether the target data requested in the data retrieval request is already cached, and if the target data is already cached and is not currently stored in the cache, determines whether the target data is hot data based on the count values ​​of a pre-generated filter within each unit time period of the sliding time window. If the target data is hot data, the filter's count value in the current time period is updated according to the filter's count value in each unit time period, the target data retrieved from the database is set into the cache, and the retrieved target data is returned to the caller. If the target data is not hot data, the filter's count value in the current time period is incremented by 1, and the target data retrieved from the database is returned to the caller. This application can determine whether the target data is hot data through the filter's count value in each unit time period, and only sets the target data into the cache when the target data is hot data, avoiding a large amount of cold data being written to the cache, and indirectly solving the problem of expired cold data keys not being released from memory.

[0077] In some embodiments of this application, the process of step S102, "determining whether the target data is hot data based on the count values ​​of each unit time within the sliding time window contained by the pre-generated filter", is described.

[0078] In an optional embodiment, considering that when the relevant code deployment end of step S102 is abnormal, the process of determining whether the target data is hot data in step S102 may be abnormally time-consuming, and the caller may not receive a response for a long time, resulting in a poor service experience.

[0079] In order to quickly provide feedback on the request results to the caller in the event of an anomaly in the aforementioned code deployment, this embodiment can first determine whether it is necessary to identify hot data for the target data. If so, it can determine whether the target data is hot data based on the count value of the filter in each unit time within the sliding time window.

[0080] For example, if an anomaly occurs on the deployment end of the aforementioned code, it is determined that hot data identification of the target data is not required; if no anomaly occurs on the deployment end of the aforementioned code, it is determined that hot data identification of the target data is required.

[0081] Optionally, this application can perform some pre-configuration, such as setting a hot data identification switch. When an anomaly is detected at the deployment end of the aforementioned related code, the hot data identification switch is turned off, and no hot data identification is performed on the target data thereafter. When no anomaly is detected at the deployment end of the aforementioned related code, the hot data identification switch is turned on. Then, the target data is determined as hot data based on the count value of the filter in each unit time within the sliding time window.

[0082] In a preferred scenario, considering the massive amount of data on the internet today—taking PUGC video data as an example—a PUGC video service system stores hundreds of millions of video records. If these video records are accessed, filters are generated, and counting and hot data identification are performed using these filters, the computational load and memory consumption are enormous. However, some older data, once requested, may become hot data due to certain events. Therefore, hot data identification can be specifically performed on this older data. When older data is identified as cold data, it is not written to the cache, thus reducing computational load and memory consumption.

[0083] Therefore, optionally, the process of "determining whether the target data is hot data based on the count values ​​of the pre-generated filter within each unit time period contained in the sliding time window" may include:

[0084] Step S11: Determine whether it is necessary to perform hot data identification on the target data.

[0085] Step S12: If hot data identification is required for the target data, determine whether the ID of the target data is less than the preset ID threshold. The larger the ID of a data, the later the data was generated.

[0086] Specifically, the identity document (ID) of the data requested by the caller typically increases gradually with the generation of new data; that is, the later the data was generated, the larger its ID. Based on this, this embodiment can determine whether the target data is old data by its ID. If the ID of the target data is less than a preset ID threshold maxid, the target data is determined to be old data; conversely, if the ID of the target data is greater than or equal to maxid, the target data is determined to be recently generated data.

[0087] Step S13a: If yes, then determine whether the target data is hot data based on the count value of the filter in each unit time within the sliding time window.

[0088] Specifically, if the ID of the target data is less than maxid, it is possible to determine whether the target data is hot data based on the count value of the filter within each unit time within the sliding time window.

[0089] Optionally, embodiments of this application may further include the following step S13b.

[0090] Step S13b: If not, then the target data is determined as hot data.

[0091] Specifically, if the ID of the target data is greater than or equal to maxid, this embodiment can determine the target data as hot data to ensure compatibility with existing technologies.

[0092] In other words, this embodiment identifies hot data by using the count value of the filter for old data; for new data, it follows the existing technology, that is, if the cache is configured and the target data is not stored in the current cache, it will be written into the current cache space as soon as the target data is accessed.

[0093] In some other embodiments of this application, the process of the aforementioned step S13a, "determining whether the target data is hot data based on the count value of the filter in each unit time within the sliding time window", is described.

[0094] Optionally, this application dynamically generates a cuckoo filter for counting database accesses to the target data at each unit of time (e.g., per hour). In this application, to better accommodate hot data, the count values ​​of the cuckoo filters generated at each unit of time within the sliding time window are used to determine whether the target data is hot data. That is, the filter mentioned in step S102 above can include the cuckoo filters generated at each unit of time within the sliding time window.

[0095] Here, the names of the cuckoo filters generated for each unit of time within the sliding time window are set based on the target data's business keyword, the current time, and the cache expiration time. For example, assuming the current time is i, the cache expiration time corresponding to the target data's cache key is n hours, and the target data's business keyword is hashtag, then there are n+1 cuckoo filters, and the names of these n+1 cuckoo filters are: {hashtag}_i, {hashtag}_i-1, ..., {hashtag}_i-n.

[0096] For example, taking video data as the target data, the keyword of the target data as com.sohu.spaces.videos.model.VideoInfo, the cache expiration time as 3 hours, and the current time as 2 PM, this application will generate a cuckoo filter between 11 AM and 2 PM. The cuckoo filter generated at 11 AM will be named {com.sohu.spaces.videos.model.VideoInfo}_11, the cuckoo filter generated at 12 PM will be named {com.sohu.spaces.videos.model.VideoInfo}_12, the cuckoo filter generated at 1 PM will be named {com.sohu.spaces.videos.model.VideoInfo}_13, and the cuckoo filter generated at 2 PM will be named {com.sohu.spaces.videos.model.VideoInfo}_14.

[0097] Taking the first unit time contained in the sliding time window as the current time minus the cache expiration time, and the last unit time as the current time (i.e., the sliding time window is [in, i], where i is the current time and n is the cache expiration time) as an example, the process of step S13a "determining whether the target data is hot data based on the count value of the filter in each unit time contained in the sliding time window" can include:

[0098] Step S21: Take the count value of the cuckoo filter generated in the first unit time included in the sliding time window as the first count value, take the count value of the cuckoo filter generated in the last unit time included in the sliding time window as the second count value, and calculate the sum of the count values ​​of all cuckoo filters generated in all unit times except the first unit time and the last unit time, and take the sum as the third count value.

[0099] For example, taking a sliding time window of [11,14] as an example, the first count value refers to the count value of the cuckoo filter generated at 11 o'clock, the second count value refers to the count value of the cuckoo filter generated at 14 o'clock, and the third count value refers to the sum of the count values ​​of the cuckoo filters generated at 12 o'clock and 13 o'clock.

[0100] For ease of description below, the first count value will be denoted by CFf, the second count value by CFi, and the third count value by CFm.

[0101] Step S22: Determine whether the second count value is greater than or equal to the preset count threshold.

[0102] See Figure 2 The diagram shows the process of determining whether target data is hot data based on the count value, where T represents the preset count threshold.

[0103] This step determines whether CFi is greater than or equal to T.

[0104] Step S23: If the second count value is greater than or equal to the counting threshold, the target data is determined to be hot data. If the second count value is less than the counting threshold, the sum of the first count value, the second count value, and the third count value is calculated, and the sum is used as the fourth count value. It is then determined whether the fourth count value is greater than or equal to the counting threshold.

[0105] Specifically, if CFi is greater than or equal to T, then true is returned, indicating that the target data is hot data; if CFi is less than T, then further judgment is made based on the count values ​​of all cuckoo filters within the sliding time window, that is, whether the sum of CFf, CFi and CFm (i.e. the fourth count value) is greater than or equal to T.

[0106] Step S24: If the fourth count value is greater than or equal to the count threshold, the target data is determined to be hot data; otherwise, the target data is determined not to be hot data.

[0107] Specifically, if CFf+CFi+CFm≥T, then return true, indicating that the target data is hot data; if CFf+CFi+CFm<T, then return false, indicating that the target data is cold data.

[0108] The above steps can be used to determine whether the target data is hot data.

[0109] It is worth noting that this embodiment determines whether the target data is hot data based on the database access volume within the sliding time window corresponding to the current time. As time goes by, the target data may no longer be hot data, or it may still be hot data. The specific determination needs to be made by the database access volume within the sliding time window after the time has passed.

[0110] Since this application determines the target data as hot data within the current sliding time window, it sets the hot data in the cache. Subsequent data retrieval requests for the target data within the cache expiration period will directly read the target data from the cache. Because the target data is not read from the database, the Cuckoo filter does not count the accesses in the cache until the target data expires in the cache. Only then will the newly generated Cuckoo filter start counting when the target data is read from the database again.

[0111] For example, if the target data is determined to be hot data at 2 PM, this application sets the target data in the cache. Assuming the cache key for the target data has a cache expiration time of 3 hours, when a data retrieval request for the target data is received between 3 PM and 4 PM, the target data will be read from the cache. Therefore, the count values ​​of the two cuckoo filters generated between 3 PM and 4 PM will both be 0. When the target data expires in the cache at 5 PM, when a data retrieval request for the target data is received, the target data will be read from the database. At this point, the cuckoo filter generated at 5 PM will start counting.

[0112] In one possible scenario, when the cache access volume of the target data is large between 3 PM and 4 PM, i.e. the target data is still hot data, the count value within the sliding time window corresponding to 5 PM is used to determine whether the target data is hot data. The result may be that the target data is not hot data. For example, if the count value of the cuckoo filter generated at 5 PM is less than the count threshold T, the result may be that the target data is not hot data, and the judgment result is incorrect.

[0113] To avoid errors in judgment, this application also provides an optimization measure. See [link to relevant documentation]. Figure 2 As shown, optionally, if the fourth count value is greater than or equal to the count threshold, this application can further determine whether the third count value CFm is equal to 0. If so, it means that the target data has been identified as hot data, but the target data may have just expired in the cache. At this time, the second count value CFi is reset to the count threshold T.

[0114] Of course, if the third count value CFm is not equal to 0, then this visit needs to be counted in the second count value CFi, that is, the second count value CFi is incremented by 1.

[0115] That is, the aforementioned step S103a, "updating the filter's count value in the current time based on the filter's count value in each unit time period", includes: determining whether the third count value is equal to 0; if the third count value is equal to 0, then resetting the second count value to the count threshold; if the third count value is not equal to 0, then incrementing the second count value by 1.

[0116] As described in the foregoing embodiments, this application dynamically generates a cuckoo filter for counting the number of database accesses to the target data at each unit of time. However, the count value used to determine whether the target data is hot data is only the count value of the cuckoo filter generated within the sliding time window corresponding to the current time. Therefore, the count values ​​of the cuckoo filters generated before the sliding time window are no longer needed. To avoid these cuckoo filters occupying memory, optionally, this application embodiment can set an expiration time for the cuckoo filters.

[0117] Optionally, the expiration time of the Cuckoo filter can be set to the cache expiration time plus 2.

[0118] It should be noted that the filter provided in the aforementioned embodiments of this application is a cuckoo filter, which is merely an example and is not intended to limit this application.

[0119] For example, optionally, if the aforementioned counting threshold is 1 or 2, step S102 can also use a Bloom filter instead of a cuckoo filter for counting. The differences are as follows:

[0120] First, as the threshold T increases, the computational cost and time consumption of the Bloom filter increase significantly. Assuming the threshold is T and the cache expiration time is n, creating T Bloom filters for each hourly window to count results in a total of T*(n+1) Bloom filters needed within that time window. Under the same threshold, only n+1 Cuckoo filters are needed; therefore, the computational cost and time consumption of the Cuckoo counter do not increase significantly with the increase of the threshold.

[0121] Secondly, the advantages of Bloom filter counting are low error rate (below 1%) and high fill rate (100%). When counting large amounts of data, you can directly create a Bloom filter with the corresponding number of elements. In contrast, the error rate of the Cuckoo counter is relatively higher (below 3%) and the fill rate is lower than that of the Bloom filter. The parameters for creating the Cuckoo filter need to be estimated based on experience.

[0122] In some other embodiments of this application, the aforementioned steps S102 "determine whether the target data is hot data based on the count values ​​of the pre-generated filter in each unit time within the sliding time window", S103a "if the target data is hot data, update the count value of the filter in the current time according to the count value of the filter in each unit time", and S103b "if the target data is not hot data, increment the count value of the filter in the current time by 1" can be implemented by the hot and cold data identification device pre-set in this application.

[0123] Taking the cuckoo filter as an example, the hot and cold data recognition device may optionally include a pre-judgment module, a hot and cold data recognition module for the cuckoo filter based on a sliding time window (hereinafter referred to as the hot and cold data recognition module), and a cuckoo filter generation module.

[0124] The pre-judgment module is used to determine whether to use the hot and cold data identification module (i.e., whether to perform hot data identification on the target data), and if hot data identification on the target data is required, to determine whether the ID of the target data is less than the ID threshold.

[0125] The Cuckoo Filter Generation Module is used to dynamically generate a Cuckoo Filter at each unit of time to count the number of database accesses to the target data.

[0126] The hot and cold data identification module is used to determine whether the target data is hot data based on the count value of the pre-generated filter in each unit time within the sliding time window. If the target data is determined to be hot data, the filter count value in the current time is updated according to the count value of the filter in each unit time. If the target data is determined not to be hot data, the filter count value in the current time is incremented by 1.

[0127] See Figure 3 This is a flowchart illustrating another hot data caching method provided in this application embodiment, which specifically includes the following steps:

[0128] Step S300: Receive a data retrieval request from the caller, and determine whether the target data requested by the data retrieval request has been cached. If not, proceed to step S301; if yes, proceed to step S302.

[0129] Step S301: Determine whether the target data exists in the database. If it does, retrieve the target data from the database and return it to the caller. If not, return an empty object to the caller.

[0130] Step S302: Determine whether the target data is already stored in the current cache. If yes, retrieve the target data from the current cache and return it to the caller. If no, proceed to step S303.

[0131] Specifically, if the target data is not stored in the current cache, the hot and cold data identification device is executed, which includes the pre-judgment module, the hot and cold data identification module, and the cuckoo filter generation module.

[0132] Step S303: Determine whether the hot / cold data identification module is used. If not, proceed to step S306. If yes, proceed to step S304.

[0133] Specifically, this step is implemented through a pre-judgment module.

[0134] This step determines whether to use the hot / cold data identification module. If yes, it determines that hot data identification is required for the target data; otherwise, it determines that hot data identification is not required for the target data, and the target data is considered to be hot data.

[0135] Step S304: Determine whether the ID of the target data is less than the preset ID threshold. If not, proceed to step S306; if yes, proceed to step S305.

[0136] Step S305: Execute the hot and cold data identification module to identify whether the target data is hot data. If not, execute step S301; if yes, execute step S306.

[0137] Specifically, this step generates a timed task through the cuckoo filter generation module, generates a cuckoo filter, and determines whether the target data is hot data based on the count value of the cuckoo filter in each unit time within the sliding time window. If it is, the count value of the filter in the current time is updated according to the count value of the filter in each unit time, and step S306 is executed. If not, the count value of the filter in the current time is incremented by 1, and step S301 is executed.

[0138] Step S306: Determine whether the target data exists in the database. If yes, retrieve the target data from the database, store the retrieved target data in the current cache, and return the retrieved target data to the caller. If no, return an empty object to the caller.

[0139] This application embodiment uses a hot and cold data identification device based on a sliding time window cuckoo filter to identify hot and cold data. Only hot data is set in the cache, while cold data is not. This avoids writing a large amount of cold data to the cache and indirectly solves the problem of expired cold data keys not being released from memory. This allows the cache to better support the service and enables the service to provide services more smoothly. In addition, using a cuckoo filter to count hundreds of millions of data points greatly saves memory.

[0140] The foregoing embodiments involve various types of parameters, such as key parameters for creating filters (e.g., cuckoo filters), including initial capacity, bucket size, ID threshold, count threshold, and business keywords. These parameters need to be pre-configured so that only hot data is written to the cache according to the foregoing steps.

[0141] To avoid the need to redeploy the service after parameter configuration, the above parameters can optionally be configured online via Apollo. For example, the relevant parameters of the Cuckoo filter during the generation phase and / or ID threshold and / or business keyword and / or count threshold can be configured online via Apollo.

[0142] This application utilizes Apollo's online configuration method to achieve dynamic and smooth parameter adjustments without the need to redeploy the service, thus increasing flexibility.

[0143] In some other embodiments of this application, in order to ensure atomicity, this embodiment can use business keywords as hashtags and execute the aforementioned steps S102 "determine whether the target data is hot data based on the count values ​​of the pre-generated filter in each unit time within the sliding time window", S103a "if the target data is hot data, update the count value of the filter in the current time according to the count value of the filter in each unit time", and S103b "if the target data is not hot data, increment the count value of the filter in the current time by 1".

[0144] In this embodiment, the process of using the Cuckoo Filter to identify hot and cold data requires the use of Lua scripts to ensure atomicity. Using Lua scripts requires ensuring that the key in the packaging command is on the same instance. Therefore, using business keywords as hashtags can ensure that all Cuckoo Filters are scattered on the same Redis instance.

[0145] This application also provides a hot data caching processing device. The hot data caching processing device provided in this application is described below. The hot data caching processing device described below can be referred to in correspondence with the hot data caching processing method described above.

[0146] Please see Figure 4 The diagram shows a schematic representation of the hotspot data caching processing device provided in an embodiment of this application. Figure 4 As shown, the hot data caching processing device may include: a cache configuration judgment unit 401, a hot data judgment unit 402, a hot data caching processing unit 403, and a cold data processing unit 404.

[0147] The cache configuration judgment unit 401 is used to receive a data retrieval request from the caller and determine whether the target data requested by the data retrieval request has been configured for caching.

[0148] The hot data determination unit 402 is used to determine whether the target data is hot data based on the count value of a pre-generated filter within each unit time within a sliding time window when the target data has been configured to be cached and the target data is not currently stored in the cache. The sliding time window is determined according to the cache expiration time corresponding to the cache key of the target data at the current time. The count value of the filter within one unit time represents the number of database accesses of the target data by the caller within that unit time. The initial count value of the filter within one unit time is 0.

[0149] The hot data cache processing unit 403 is used to update the filter's count value in the current time according to the filter's count value in each unit time if the target data is hot data, set the target data obtained from the database into the cache, and return the obtained target data to the caller.

[0150] The cold data processing unit 404 is used to increment the filter's count value by 1 in the current time if the target data is not hot data, and return the target data obtained from the database to the caller.

[0151] In one possible implementation, the aforementioned thermal data judgment unit may include: a thermal identification execution judgment subunit, an ID comparison subunit, and a first thermal data identification subunit.

[0152] The thermal identification execution judgment subunit is used to determine whether thermal data identification is required for the target data.

[0153] The ID comparison subunit is used to determine whether the identity number ID of the target data is less than a preset ID threshold if the hot data recognition execution judgment unit determines that hot data recognition of the target data is required. The larger the ID of a data, the later the data was generated.

[0154] The first hot data identification subunit is used to determine whether the target data is hot data based on the count value of the filter in each unit time within the sliding time window if the ID comparison unit determines that the ID of the target data is less than the ID threshold.

[0155] In one possible implementation, the above-mentioned thermal data judgment unit may further include: a second thermal data identification subunit.

[0156] The second thermal data identification subunit is used to identify the target data as thermal data if the thermal identification execution judgment unit determines that thermal data identification is not required.

[0157] In one possible implementation, the above filters include cuckoo filters generated at each unit of time within the sliding time window, with the names of the cuckoo filters based on the business keywords of the target data, the current time, and the cache expiration time.

[0158] In one possible implementation, the first unit of time in the sliding time window is the current time minus the cache expiration time, and the last unit of time is the current time.

[0159] Based on this, the first thermal data identification subunit mentioned above can be used to determine whether the target data is thermal data based on the count values ​​of the filter within each unit time period included in the sliding time window, specifically for:

[0160] The count value of the cuckoo filter generated in the first unit time included in the sliding time window is taken as the first count value, the count value of the cuckoo filter generated in the last unit time included in the sliding time window is taken as the second count value, and the sum of the count values ​​of the cuckoo filters generated in all units time except the first unit time and the last unit time is calculated, and the sum is taken as the third count value.

[0161] If the second count value is greater than or equal to the preset count threshold, the target data is determined to be hot data;

[0162] If the second count value is less than the count threshold, calculate the sum of the first count value, the second count value and the third count value, and use the sum as the fourth count value;

[0163] If the fourth count value is greater than or equal to the count threshold, the target data is determined to be hot data; otherwise, the target data is determined not to be hot data.

[0164] In one possible implementation, when the hot data caching processing unit updates the filter's count value in the current time based on the filter's count value in each unit of time, it can specifically be used to: determine whether the third count value is equal to 0; if the third count value is equal to 0, then reset the second count value to the count threshold; if the third count value is not equal to 0, then increment the second count value by 1.

[0165] In one possible implementation, the expiration time of the above cuckoo filter is set to the cache expiration time plus 2.

[0166] In one possible implementation, the relevant parameters and / or ID thresholds and / or business keywords and / or count thresholds of the above-mentioned cuckoo filter during the generation phase are configured online via Apollo.

[0167] In one possible implementation, the hot data caching processing device provided in this application embodiment can use business keywords as hashtags and execute the process by the hot data judgment unit to determine whether the target data is hot data based on the count value of the pre-generated filter in each unit time within the sliding time window through Lua script; and the process by the hot data caching processing unit to update the count value of the filter in the current time according to the count value of the filter in each unit time if the target data is hot data; and the process by the cold data processing unit to increment the count value of the filter in the current time by 1 if the target data is not hot data.

[0168] This application also provides a hotspot data caching processing device. Optionally, Figure 5 The hardware structure block diagram of the hot data caching processing device is shown below. Figure 5The hardware structure of the hotspot data caching processing device may include: at least one processor 501, at least one communication interface 502, at least one memory 503 and at least one communication bus 504.

[0169] In this embodiment of the application, the number of processor 501, communication interface 502, memory 503 and communication bus 504 is at least one, and processor 501, communication interface 502 and memory 503 communicate with each other through communication bus 504.

[0170] The processor 501 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0171] The memory 503 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0172] The memory 503 stores a program, and the processor 501 can call the program stored in the memory 503. The program is used for:

[0173] Receive a data retrieval request from the caller and determine whether the target data requested by the data retrieval request has been cached.

[0174] If the target data has been configured to be cached and the target data is not currently stored in the cache, the target data is determined as hot data based on the count value of the pre-generated filter in each unit time within the sliding time window. The sliding time window is determined according to the current time and the cache expiration time corresponding to the cache key of the target data. The count value of the filter in one unit time represents the number of database accesses of the target data by the caller in that unit time. The initial count value of the filter in one unit time is 0.

[0175] If the target data is hot data, then the filter count value in the current time is updated according to the filter count value in each unit time, the target data obtained from the database is set into the cache, and the obtained target data is returned to the caller.

[0176] If the target data is not hot data, the filter's count value for the current time is incremented by 1, and the target data obtained from the database is returned to the caller.

[0177] Optionally, the refined and extended functions of the program can be found in the description above.

[0178] This application also provides a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the hot data caching processing method described above.

[0179] Optionally, the refined and extended functions of the program can be found in the description above.

[0180] Finally, it should be noted that in this document, relational terms such as "second" and "etc." are used merely 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.

[0181] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0182] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for handling hotspot data caching, the method comprising: The method comprises the following steps: receiving a data acquisition request from a calling party, and determining whether a cache has been configured for target data requested by the data acquisition request; in a case where the cache has been configured for the target data and the target data is not stored in the current cache, determining whether the target data is hot data based on count values of a pre-generated filter in each unit time included in a sliding time window, wherein the filter comprises pigeonhole filters respectively generated in each unit time included in the sliding time window, a name of the pigeonhole filter is set based on a business keyword of the target data, a current time and a cache expiration time corresponding to a cache key of the target data, a first unit time included in the sliding time window is the current time minus the cache expiration time, a last unit time included in the sliding time window is the current time, the count value of the filter in a unit time represents a database access amount of the target data by the calling party in the unit time, and an initial count value of the filter in a unit time is 0; if the target data is hot data, updating the count value of the filter in the current time according to the count values of the filter in the unit times, setting the target data obtained from a database into the cache, and returning the target data to the calling party; if the target data is not hot data, adding 1 to the count value of the filter in the current time, and returning the target data obtained from the database to the calling party; wherein the determination of whether the target data is hot data based on the count values of the filter in each unit time included in the sliding time window comprises: taking the count value of the pigeonhole filter generated in the first unit time included in the sliding time window as a first count value, taking the count value of the pigeonhole filter generated in the last unit time included in the sliding time window as a second count value, calculating a sum of count values of the pigeonhole filters generated in all unit times except the first unit time and the last unit time, and taking the sum as a third count value; in a case where the second count value is greater than or equal to a preset count threshold, determining that the target data is hot data; in a case where the second count value is less than the count threshold, calculating a sum of the first count value, the second count value and the third count value, and taking the sum as a fourth count value; if the fourth count value is greater than or equal to the count threshold, determining that the target data is hot data, otherwise, determining that the target data is not hot data.

2. The hotspot data caching processing method of claim 1, wherein, the determination of whether the target data is hot data based on the count values of the filter in each unit time included in the sliding time window comprises: If no exception occurs in the relevant code deployment end, it is determined that hot data identification is needed for the target data, and the relevant code deployment end is the relevant code deployment end in a case where a cache has been configured for the target data and the target data is not stored in the current cache, and whether the target data is hot data is determined based on the count value of each unit time included in a sliding time window according to a pre-generated filter; If hot data identification is needed for the target data, it is determined whether the identity identification number (ID) of the target data is less than a preset ID threshold, wherein the larger the ID of a data, the later the generation time of the data; If yes, whether the target data is hot data is determined based on the count value of each unit time included in a sliding time window according to the filter.

3. The hotspot data caching processing method of claim 2, wherein, Further comprising: If hot data identification is not needed for the target data, the target data is determined to be hot data.

4. The hotspot data cache processing method of claim 2, wherein, The updating of the count value of the filter in the current time according to the count value of each unit time of the filter includes: It is determined whether the third count value is equal to 0; If the third count value is equal to 0, the second count value is reset to the count threshold; If the third count value is not equal to 0, the second count value is increased by 1.

5. The hotspot data cache processing method of claim 2, wherein, The expiration time of the cuckoo filter is set to the cache expiration time plus 2.

6. The hotspot data cache processing method of claim 5, wherein, The relevant parameters of the cuckoo filter in the generation stage and / or the ID threshold and / or the business keyword and / or the count threshold are configured online through apollo.

7. The hotspot data cache processing method of claim 1, wherein, The business keyword is used as a hashtag, and the determination of whether the target data is hot data based on the count value of each unit time included in a sliding time window according to a pre-generated filter is performed through a lua script, if the target data is hot data, the count value of the filter in the current time is updated according to the count value of each unit time of the filter, and if the target data is not hot data, the count value of the filter in the current time is increased by 1.

8. A hotspot data caching processing apparatus, characterized by comprising: Comprising: A cache configuration determination unit configured to receive a data acquisition request from a calling party and determine whether a cache has been configured for target data requested by the data acquisition request; The hot data judgment unit is configured to, in a case where the target data has been configured with a cache and the target data is not stored in the current cache, judge whether the target data is hot data based on a count value of a filter generated in advance in each unit time included in a sliding time window, wherein the filter comprises a plurality of cuckoo filters respectively generated in each unit time included in the sliding time window, a name of the cuckoo filter is set based on a business keyword of the target data, a current time, and a cache expiration time corresponding to a cache key of the target data, a first unit time included in the sliding time window is the current time minus the cache expiration time, a last unit time included in the sliding time window is the current time, the count value of the filter in a unit time represents a database access amount of the target data by the caller in the unit time, and an initial count value of the filter in a unit time is 0; The hot data cache processing unit is configured to, in a case where the target data is hot data, update a count value of the filter in the current time according to the count value of the filter in each unit time, set the target data obtained from a database to the cache, and return the obtained target data to the caller. The cold data processing unit is configured to, in a case where the target data is not hot data, add 1 to the count value of the filter in the current time, and return the target data obtained from the database to the caller. The hot data judgment unit is configured to, in a case where the target data is hot data, update a count value of the filter in the current time according to the count value of the filter in each unit time, set the target data obtained from a database to the cache, and return the obtained target data to the caller. The hot data judgment unit is configured to, in a case where the target data is hot data, update a count value of the filter in the current time according to the count value of the filter in each unit time, set the target data obtained from a database to the cache, and return the obtained target data to the caller. The hot data judgment unit is configured to, in a case where the target data is hot data, update a count value of the filter in the current time according to the count value of the filter in each unit time, set the target data obtained from a database to the cache, and return the obtained target data to the caller. The hot data judgment unit is configured to, in a case where the target data is hot data, update a count value of the filter in the current time according to the count value of the filter in each unit time, set the target data obtained from a database to the cache, and return the obtained target data to the caller. The hot data judgment unit is configured to, in a case where the target data is hot data, update a count value of the filter in the current time according to the count value of the filter in each unit time, set the target data obtained from a database to the cache, and return the obtained target data to the caller.

Images