Setting expiration Time

Redis provides four commands to add an expiration time to a key:

  • EXPIRE

    < TTL > : Sets the lifetime of the key to TTL seconds.
  • PEXPIRE

    < TTL > : sets the lifetime of the key to TTL milliseconds.
  • EXPIREAT


    : Sets the expiration time of key to the timestamp specified in seconds.

  • EXPIREAT


    : Sets the expiration time of key to the millisecond timestamp specified by timestamp.

These four commands can be distinguished by TTL/expiration time and SEC/ms.

In fact, EXPIRE, PEXPIRE, and EXPIREAT are all implemented by converting parameters to an expiration time in milliseconds and then calling PEXPIREAT.

Redis records the expiration date of each key in a special little book (a dictionary called Expires). Each time the above command is invoked, expiration information is logged into the dictionary.

Run the following command to delete the expiration time: PERSIST <key> Query the remaining time: TTL <key>; PTTL <key>

Deletion policy

Redis provides three deletion strategies, each with advantages and disadvantages in terms of CPU and memory.

Time to delete

When the key is set to expire, a timer is created that triggers the deletion logic when the expiration time is reached. This policy ensures that the key is deleted immediately after the expiration time is reached. A scheduled deletion policy is memory-friendly: A timer can be used to delete expired keys as soon as possible and release the memory occupied by expired keys. However, this policy is cpu-unfriendly: Deletion operations may consume considerable CPU time when there are a large number of delete keys, and service response time and throughput may be affected when CPU time is very tight.

Lazy to delete

This policy does not actively trigger the delete logic after the expiration time is reached, but determines whether the key has expired before reading its value. If the key is expired, delete it; otherwise, normal procedure is performed. This makes the policy very CPU-friendly, and there is no rush to delete keys even if a large number of keys expire at the same time. Correspondingly, this policy is less memory friendly because expired keys are not deleted immediately, resulting in a large number of expired keys in memory. Some cases can even cause “memory leaks”. For example, some keys may be date-dependent and will not be accessed after a point in time, so they will never be deleted.

Periodically delete

The periodic deletion policy makes a trade-off between CPU and memory. The periodic deletion policy performs the deletion operation at intervals and limits the time and frequency of the deletion operation to reduce the impact on the CPU time. Although the policy does not delete expired keys immediately, it can guarantee that expired keys will be deleted within a certain period of time, which also reduces the burden of memory to some extent.

conclusion

In practice, inertia and periodicity are generally adopted. By using these two strategies together, the server can achieve a good balance between CPU and memory.