Redis's caching policy and primary key invalidation mechanism

As the cache system periodically cleans up invalid data, a primary key invalidation and elimination policy is required.

In Redis, a lifetime key is called volatile. When creating a cache, to set the lifetime for a given key, it may be deleted when the key expires (with a lifetime of 0).

1, affecting the survival time of some operations

The time to live can be removed by using the DEL command to remove the entire key, or by overwriting the original data by the SET and Getset commands, i.e., modifying the value of the key and overwriting it with the same key and value, the current data has a different lifetime.

For example, executing a INCR command on a key, Lpush a command on a list, or executing a hset command on a hash table does not modify the lifetime of the key itself. On the other hand, if a key is renamed with rename, the name of the renamed key is the same as before the change of name.

Another possibility of the rename command is to attempt to rename a key with a time-to-live to another another_key with a time-to-live, when the old Another_key (and its lifetime) is deleted, and the old key is renamed to Another_key, so The new Another_key also has the same survival time as the original key. Using the Persist command, you can remove the key's lifetime without deleting the key, and let the key become a persistent key again.

2, how to update the survival time

You can execute the expire command on a key that already has a time-to-live, and the newly specified time-to-live replaces the old time-to-live. The accuracy of the expiration time has been controlled within 1ms, the time complexity of the primary key failure is O (1),
With the expire and TTL commands, the TTL can be used to see the current lifetime of the key. The setting returns 1 successfully, or 0 if key does not exist or the time to live is not set for key.

Maximum cache configuration

in Redis, allows the user to set the maximum memory size for use

Server.maxmemory

The default is 0, no maximum cache is specified, and if new data is added, exceeding the maximum memory will cause Redis to crash, so be sure to set it up. When the size of the Redis memory dataset rises to a certain size, a data-culling strategy is implemented.

Redis offers 6 kinds of data-culling strategies:

• VOLATILE-LRU: Pick the least recently used data from the set of data sets (Server.db[i].expires) that have expired time
• Volatile-ttl: Select the data that will expire from the set of expired data sets (Server.db[i].expires)
• Volatile-random: Choose data culling from any data set (Server.db[i].expires) that has an expiration time set
• ALLKEYS-LRU: Pick the least recently used data culling from the dataset (Server.db[i].dict)
• Allkeys-random: Choose data culling from data set (SERVER.DB[I].DICT)
• No-enviction (expulsion): Prohibition of eviction data

Note that the 6 mechanisms here, volatile and AllKeys, specify whether to retire data from the set expiration time or retire data from all datasets, and the LRU, TTL, and random are three different elimination strategies. Plus a strategy that no-enviction never recycles.

To use policy rules:

1, if the data display power law distribution, that is, part of the data access frequency, part of the data access frequency is low, then use ALLKEYS-LRU
2, if the data is distributed evenly, that is, all the data access frequency is the same, the use of allkeys-random

Three types of data-retirement strategies:

TTL and random are easier to understand and easier to implement. The most recent use of LRU is the most recently used elimination strategy, the design will be the key by the expiration time, and then take the first invalid key to eliminate

For the original text please see: Https://yq.aliyun.com/articles/38441?spm=5176.100239.blogrightarea.11.yP0aqU

Redis's caching policy and primary key invalidation mechanism