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

This article "Redis expiration strategy and memory elimination strategy how to use" most people do not understand, so the editor summarizes the following content, detailed, clear steps, with a certain reference value, I hope you can get something after reading this article, let's take a look at this "Redis expiration strategy and memory elimination strategy how to use" article.

1 set the time complexity of keyexpire key seconds with expiration time: O (1)

Sets the expiration time of the key. After the timeout, the key will be deleted automatically. In Redis terminology, the associated timeout of a key is volatile.

After the timeout, it is cleared only when DEL, SET, and GETSET are executed on key. This means that conceptually all operations that change the key without having to replace the new value will remain timeout. For example, using INCR to increment the value of key, performing LPUSH to push the new value into list, or changing the field of hash with HSET all keep the timeout unchanged.

Use the PERSIST command to clear the timeout and make it a permanent key

If the key is modified by the RENAME command, the associated timeout will be transferred to the new key

If the key is modified by the RENAME command, such as Key_A already exists, and then the RENAME Key_B Key_A command is called, no matter whether the original Key_A is permanent or timed out, it will be overwritten by the validity status of the Key_B.

Note that calling EXPIRE/PEXPIRE with a non-positive timeout or EXPIREAT/PEXPIREAT with a past time will cause the key to be deleted rather than expired (therefore, the key event emitted will be del, not expired).

1.1 Refresh expiration time

EXPIRE a key that already has an expiration time, and its expiration time will be updated. There are many applications that have this kind of business scenario, such as session that records sessions.

1.2 differences of 2.1.3 before Redis

In version 2.1.3 prior to Redis, changing a key with an expired set using the command to change its value had the effect of completely deleting key. This semantics is required because there are limitations in the replication layer that is now being repaired.

EXPIRE returns 0 and does not change the timeout of keys with timeout sets.

1.3 return value

1 if the expiration time is set successfully.

0 if key does not exist or the expiration time cannot be set.

1.4 exampl

Suppose there is a Web service that is interested in the most recent N pages visited by the user, so that each adjacent page view is no more than 60 seconds after the previous page. Conceptually, this set of page views can be thought of as a user's navigation session, which may contain interesting information about the product ta is currently looking for so that you can recommend it.

You can easily model this pattern in Redis using the following strategy: each time a user executes a page view, you invoke the following command:

MULTIRPUSH pagewviews.user: http://.....EXPIRE pagewviews.user: 60EXEC

If the user is idle for more than 60 seconds, the key is deleted and only subsequent page views with differences of less than 60 seconds are recorded. This mode is easy to modify, using INCR instead of RPUSH's list.

1.5 key with expiration

Typically, there is no associated time to live when the Redis key is created. The key will persist unless the user explicitly deletes it, such as the DEL command. The command of the EXPIRE family can associate an expired item with a given key, but at the cost of the extra memory used by the key. When a key has an expired set, Redis ensures that the key is deleted when the specified time has elapsed. You can use the EXPIRE and PERSIST commands (or other strict commands) to update or completely delete critical times for survival.

1.6 expiration accuracy

In Redis 2.4, expiration may be inaccurate and may be between 0 and 1 second. Due to Redis 2.6, the expiration error ranges from 0 to 1 millisecond.

1.7 expiration and persistence

Keys for expired information are stored as absolute Unix timestamps (milliseconds for Redis version 2.6 or later). This means that time is flowing even if the Redis instance is not active. For overdue work to work well, computer time must be stabilized. If you move a RDB file from two computers with a large desync in its clock, interesting things can happen (such as loading into all expired key at load time). Even the running instance always checks the computer clock, for example, if you set a key to 1000 seconds, and then set the computer time to 2000 seconds in the future, the key will expire immediately instead of lasting 1000 seconds.

2 how does Redis expire key

There are two ways for keys to expire: passive-lazy deletion and active-periodic deletion.

2.1 lazy deletion

When the client tries to access the key, the key expires passively, that is, the Redis checks whether the key has an expiration time, deletes it if it expires, and returns nothing. Note that key is not automatically deleted when it expires, but when querying the key, Redis lazily checks to see if it is deleted. This is similar to the delayed initialization of spring.

Of course, this is not enough, because there is an expired key that will never be visited again. In any case, these key should be out of date, so periodically Redis tests several key randomly between key with expired sets. All expired key will be removed from the key space.

2.2 periodically delete

Specifically, the following Redis is done 10 times per second:

Test 20 random keys with expiration

Delete all expired key found

If more than 25% of the key is out of date, restart from step 1

This is a trivial probability algorithm, basically assuming that our sample represents the entire key space and continues to expire until the percentage of key that may expire is less than 25%. This means that at any given time, the maximum number of expired keys using memory is equal to the maximum number of write operations per second divided by 4.

2.3 how to handle expiration in replication links and AOF files

In order to get the correct behavior without sacrificing consistency, when the key expires, the DEL operation synthesizes and fetches all additional slave nodes in the AOF file at the same time. In this way, the expired process is concentrated in the primary node, and there is no possibility of consistency errors.

However, although the slave nodes connected to the master node will not independently expire the key (but will wait for the DEL from the master), they will still use the full state of the existing expiration in the dataset, so when selecting slave as the master, it will be able to independently expire the key and act as the master completely.

However, a lot of expired key, you did not check in time, regular deletion also missed, a large number of expired key accumulated memory, Redis memory almost exhausted!

Therefore, there needs to be a memory elimination mechanism!

3 memory phase-out 3.1 memory phase-out strategy

Noeviction (Redis default policy)

The write request will not be served (the DEL request can continue to serve) and the read request can continue. This ensures that data will not be lost, but it will make online business unsustainable.

Config.c

CreateEnumConfig ("maxmemory-policy", NULL, MODIFIABLE_CONFIG, maxmemory_policy_enum, server.maxmemory_policy, MAXMEMORY_NO_EVICTION, NULL, NULL), allkeys-random

When there is not enough memory to hold newly written data, a key is randomly removed from the key space. Why should it be random? at least delete the least used key recently.

Allkeys-lru (Least Recently Used)

When there is not enough memory to hold the newly written data, the least recently used key is removed from the key space, and the key with no expiration time is eliminated.

Allkeys-lfu (Least Frequently Used)

The key to LRU is to see how long the page was last used until scheduling occurred, while the key to LFU is to see how often the page is used in a certain period of time.

Volatile-lru

Try to phase out the key with the expiration time set, and the least used key will be eliminated first. Key that does not set an expiration time will not be eliminated, which ensures that data that needs to be persisted will not be suddenly lost. Unlike allkey-lru, this strategy eliminates only expired key collections.

Volatile-lfuvolatile-random

The obsolete key is a random key in the expired key collection.

Volatile-ttl

The elimination strategy is not LRU, but the value of ttl of the remaining life of key. The smaller the ttl is, the more priority it is to be eliminated.

The volatile-xxx policy will only phase out the key with expiration time, and the allkeys-xxx policy will phase out all key.

If you just use Redis for caching, you should use allkeys-xxx. Clients don't have to carry expiration time when writing to the cache.

If you also want to use Redis's persistence feature at the same time, then use the volatile-xxx policy, so that you can retain the key that does not set the expiration time, they are permanent key and will not be eliminated by the LRU algorithm.

3.2 handwritten LRU

It is true that they sometimes ask this, because if some candidates do go through the five hurdles and answer all the previous questions very well, then actually ask him to write the LRU algorithm and examine the coding skills.

You can handwrite the most primitive LRU algorithm on the spot, which is too large to be realistic.

Public class LRUCache extends LinkedHashMap {private final int CACHE_SIZE; / / here is the maximum amount of data that can be passed in public LRUCache (int cacheSize) {/ / true means that linkedhashmap sorts elements in access order super ((int) Math.ceil (cacheSize / 0.75) + 1,0.75f, true); CACHE_SIZE = cacheSize } @ Override protected boolean removeEldestEntry (Map.Entry eldest) {/ / when the amount of KV data is greater than the specified number of caches, the oldest data return size () > CACHE_SIZE is automatically deleted }} the above is the content of this article on "how to use the expiration strategy and memory elimination strategy of Redis". I believe everyone has a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

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.