Redis expiration time and cache

1. Set the expiration time

 

EXPIRE key seconds The seconds parameter identifies the expiration time of the key, in seconds. A return of 1 indicates that the setting is successful, and a return of 0 indicates that the key does not exist or the setting fails.

 

TTL key to see how long a key will be deleted. The return value is the remaining time in seconds. The command returns -2 when the key does not exist.

 

 PEXPIRE key seconds The seconds parameter identifies the expiration time of the key in milliseconds. A return of 1 indicates that the setting is successful, and a return of 0 indicates that the key does not exist or the setting fails.

 

PTTL key Check how long a key will be deleted. The return value is the remaining time in milliseconds. The command returns -2 when the key does not exist.

 

PERSIST key Cancel the expiration time of the key, that is, restore the key to be permanent. Returns 1 if the expiration time is successfully cleared, otherwise returns 0 (the key does not exist or the key is inherently permanent)

 

127.0.0.1:6379> set session:101 uid1314

 

OK

 

127.0.0.1:6379> expire session:101 120

 

(integer) 1

 

 127.0.0.1:6379> ttl session:101

 

(integer) 106

 

127.0.0.1:6379> ttl session:101

 

(integer) 93

 

127.0.0.1:6379> ttl session:101

 

(integer) -2

 

There is no expiration time set for the key, it is permanent, which is the default after a key is established. The TTL command returns -1.

 

In version 2.6, whether the key does not exist or the key has no expiration time, it will return -1. After knowing the 2.8 version, the two cases will return -2 and -1 respectively.

 

2. Implement caching

 

When the server memory is limited, if a large number of cache keys are used and the expiration time is set too long, Redis will fill up the memory; if the expiration time of the cache key is set too short, the cache hit rate may be too low and a large amount of memory may be caused. Idle in vain.

 

It is difficult to set a reasonable expiration time for cache keys. For this reason, you can limit the maximum memory that Redis can use, and let Redis eliminate unnecessary cache keys according to certain rules.

 

Setting method: Modify the maxmemory parameter of the configuration file to limit the maximum available memory size of Redis (in bytes). When this limit is exceeded, Redis will delete unnecessary keys according to the policy specified by the maxmemory-policy parameter until the memory occupied by Redis is less than specified memory.

 

volatile-lru uses the LRU algorithm to delete a key (the key for which the detachment has set an expiration time)

 

allkeys-lru delete a key using the LRU algorithm

 

volatile-random deletes a key at random (the key with the expiration time set by the detachment)

 

allkeys-random removes a key immediately

 

volatile-ttl delete the key with the most recent expiration time

 

noeviction does not delete the key, just returns an error

 

The LRU (Least Recently Used) algorithm is "least recently used", which considers that the least recently used keys will not be used for a period of time in the future, that is, when space is needed, it is considered that these keys can be deleted.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326174940&siteId=291194637