Shulou(Shulou.com)06/02 Report--

What is the Redis infrastructure and caching strategy and what are the common caching problems? for this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

What are the common caching strategies

Because the data access modes of different systems are different, it is difficult for the same cache strategy to achieve satisfactory performance cache policy classification under different data access modes.

1) FIFO based on the principle of fairness (first-in, first-out queue)

2), LRU based on access time (least recent use of linked lists)

3), based on access frequency such as LFU (least frequently used recently), LRU2, 2Q, LIRS

4) give consideration to both access time and frequency: by taking into account both access time and frequency. So that the caching strategy still has a good performance when the data schema changes. Such as FBR, LRUF, ALRFU. Most of these algorithms have an adjustable or adaptive parameter, which makes the cache policy achieve a balance based on access time and frequency.

5) based on access mode: some applications have clear characteristics of data access, and then produce corresponding caching strategies. For example, the SARC cache strategy designed by the dedicated VoD system adapts to random and sequential access modes at the same time.

II. Redis cache elimination strategy

Recycling strategy

The behavior that Redis will use when the maxmemory limit is reached is configured by the maxmemory-policy configuration instruction of Redis.

The following policies are available:

Noeviction: returns an error when the memory limit is reached and the client tries to execute a command to allocate more memory (most write instructions, with DEL and a few exceptions)

Allkeys-lru: try to recycle the least used key (LRU) so that the newly added data has room to store.

Volatile-lru: try to recycle the least used keys (LRU), but only those keys in expired collections, so that newly added data has room to store.

Allkeys-random: reclaim random keys to make room for newly added data.

Volatile-random: reclaiming random keys gives room for newly added data, but only for keys in expired collections.

Volatile-ttl: reclaim keys in expired collections, and give priority to keys with a short time to live (TTL) so that newly added data can be stored.

If there are no keys to meet the prerequisites for recycling, the strategies volatile-lru, volatile-random, and volatile-ttl are almost the same as noeviction.

It is important to choose the right recycling strategy, depending on the access mode of your application, but you can make relevant policy adjustments at run time, and monitor cache hit rates and miss times, output through the RedisINFO command for tuning.

General rules of thumb:

Use allkeys-lru strategy: when you want your request to follow a power law distribution, that is, you want some subset elements to be accessed more than other elements. If you're not sure what to choose, it's a good choice. .

Use allkeys-random: if you are iterating, all keys are scanned continuously, or you want the request distribution to be normal (all elements have the same probability of being accessed).

Use volatile-ttl: if you want to determine which objects should be expired by setting the TTL value when creating cached objects.

Allkeys-lru and volatile-random strategies are useful when you want a single instance to implement caching and persist some keys. However, running two instances is generally a better way to solve this problem.

Setting expiration times for keys also consumes memory, so using allkeys-lru is more efficient because there is no need to set expiration times for keys when memory is under pressure.

Third, how to achieve cache data consistency

The causes of data inconsistency

[1] before deleting the cache first, and then writing to the database successfully, if a read request occurs, it may cause the old data to be cached and lead to data inconsistency. If you do not set the expiration policy for the cache, the data will always be dirty.

[solution]:

1) double delete cache strategy before and after update can be adopted.

2) it can be solved by "serialization" to ensure that the reading and writing of the same data fall on the same back-end service.

[2] first operate the database, and then clear the cache. If the deletion cache fails, there will be data inconsistencies.

[solution]:

1). Store the key value that failed to delete in the queue and delete it repeatedly.

2), option 2: obtain the key value data that needs to be deleted by subscribing to binlog. In the application, start another program, get the message from this subscriber, and delete the cache.

Fourth, prevent cache penetration, breakdown, avalanche and refresh

[1], cache penetration: cache penetration means that a request is received, but the request does not exist in the cache. You can only query it in the database and put it in the cache. However, when there are many requests accessing the same data at the same time, the business system sends all these requests to the database, or maliciously constructs a data that logically does not exist, and then sends the request in large quantities, so that it will be sent to the database every time, always causing the database to hang up. The solution: for malicious access, one idea is to verify the malicious data directly and not to send it to the database layer; the second idea is to cache the empty results, that is, the data that does not exist in the query is also recorded in the cache. this can effectively reduce the number of queries to the database. Non-malicious access, combined with cache breakdown instructions.

[2], cache breakdown: one of the data mentioned above does not exist, and then many requests query the database, which can be classified as cache breakdown: for hot data, when the cache fails, all requests are delegated to the database to request a solution to update the cache: one way to prevent such problems is to add a global lock, that is, all requests to access a certain data share a lock The one who gets the lock is eligible to access the database, and other threads must wait. Another idea is to actively refresh the data that is about to expire, such as setting up a new thread to poll the data, or dividing all the data into different cache intervals and refreshing the data periodically. The second idea has something to do with cache avalanches.

[3], cache avalanche: cache avalanche means that when we set the same expiration time for all caches, at some point, all the cached data expires, and then all requests are thrown to the database, and the database collapses. Solution: the solution is either divide and conquer, divide into smaller cache intervals and expire according to the interval, or add a random value to the expiration time of each key to avoid expiration at the same time and achieve the purpose of refreshing the cache with off-peak.

[4]. Cache refresh: once the cache is cleared, it is generally necessary to refresh the cache after insert, update and delete operations. If not, dirty data will appear. However, when the system of the cache request pops up, the value returned to the cache is null.

5. The difference between redis and memcached

[1], working principle:

Redis is a single-process operation command, and memcached is multi-process.

[2], efficiency difference:

Redis for small data (

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.