Redis official documentation (9) - Redis expiration time

Redis3 official documentation (9)
- Redis expiration time


    Keys with an expire
    Normally, a Redis key is created without a lifetime associated with it. Keys live forever unless explicitly deleted by the user, for example, using the DEL command.
    The EXPIRE command family can associate an expiration time with a specified key, at the cost of using additional memory for the key. When a key is set to expire, Redis will ensure that the key will be deleted when the specified time has elapsed.
    The key's time-to-live can be updated or removed entirely using the EXPIRE and PERSIST commands (or other more relevant commands).

    Expire accuracy
    In the Redis 2.4 version, the expiration time may not be very accurate, with an error of about 0 to 1 second.
    As of Redis 2.6, the expiration time error is 0 to 1 millisecond.

    Expires and persistence
    keys are stored as absolute Unix timestamps (in milliseconds for Redis 2.6 and above). This means that time is starting to pass even when the Redis instance is not activated.
    In order for the expiration time to roll well, the computer's time must be stable. If you move an RDB file between two computers with large clock delays, interesting things can happen (like all loaded keys are out of date by the time they are loaded).
    Even if the running instance keeps checking the computer's clock, for example, if you set a key's time-to-live to 1000 seconds, and then set your computer's time to 2000 seconds into the future, the key will expire immediately instead of persisting for 1000 seconds.

    How Redis expires keys
    Redis keys expire in two ways: passive and active.
    A key automatically expires when a client tries to access it and finds that it has timed out.
    Of course this is not enough, because there are some expired keys that may never be accessed. These keys are expired anyway, so Redis periodically tests some of the keys at random among the keys that are set to expire. All keys that have expired will be deleted from the keyspace.
    In particular, the following is an action that Redis performs 10 times per second:
  1. Test 20 random keys in the set of keys with associated expiration times.
  2. Delete all keys found to be out of date.
  3. If more than 25% of keys expire, start from step 1.

    This is a simple probabilistic algorithm, basically our assumption is that our sample is representative of the entire key space, and we keep expiring until the percentage of keys that are likely to expire is below 25%.
    This means that, at any given moment, the maximum number of keys that have expired will occupy memory equal to the maximum number of writes per second divided by 4.

    How expires are handled in the replication link and AOF file
    In order not to sacrifice consistency and get correct behavior, when a key expires, a DEL operation will be synced to the AOF file and all associations of the slave server. A master server instance in a processing set that expires in this way has no chance of a consistency error.
    However, while slaves connected to the master do not independently expire keys (but wait for a DEL operation from the master), they maintain a complete expiration state in the database, so when a slave is elected As a master, it can expire these keys independently, acting as a master entirely.
===================================================== ===============================
    Hello everyone, my name is Nguyen Wei. Huazhong University of Science and Technology, Master of Computer Software. After graduation, he joined Tencent and worked in Tencent's e-commerce department and wireless game product department successively, and now works in the basic product department of YY Times. IT man, so far. Welcome to my public account.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327072182&siteId=291194637