Redis study notes --Redis Detailed data expiration policies

　This article expired simple mechanism to explain Redis
　　after the first throw before we explain a problem, we know that many times redis server is often used as a cache, there are a lot of data about the cache are temporary, may have used for a long time will no longer uses (such as staging session, or if the data is stored only day the stock market) then there will be a few questions about the

Redis will not clean up their own recovery data?
If so, how to configure it?
Intensive problem of storage space if not, how to prevent data accumulation?

　　Prior has been in contact with Redis is not very deep, recent projects which meet the needs of a scene, we need to clear some of the data stored in the Redis, mainly filtered through some time to delete those not satisfied with the data, but this kind of work need to be every day, that workload is relatively large, and it will need to manually clean up on time every day, this would also be impractical, later found Redis there is a set time expired function, namely the values stored in the database Redis can set an expiration time . As a cache database, which is very useful. This is what we want to address in this article Redis expires mechanism. In fact, this mechanism using a wide range of scenarios, such as our project in general or some token login information, especially SMS verification codes are time-bound, or limit the number of requests, according to the traditional database approach, usually own judgment expired, so no doubt will seriously affect project performance.

First, set the expiration time

　　Redis expiration process is actually stored values for the key (key) of the process value, i.e., the time setting is set to key valid time. Expires dictionary holds all the keys of the expiration time, it Expires also referred to expire field.

expire key time (in seconds) - This is the most common way
setex (String key, int seconds, String value) - string unique way

Note:
　　1, in addition to their own unique string set the expiration time of the method, the other methods rely expire way to set the time
　　2, if no time is that the cache never expires
　　3, if you set an expiration time, and later want the cache never expires, use persist key

1, the usual way

Generally includes four treatments expiration side, which are in seconds expire, pexpire are in milliseconds.

1 EXPIRE key seconds // set the key lifetime ttl seconds to 
2 PEXPIRE key milliseconds // The key generation time is set ttl ms 
3 EXPIREAT key timestamp // set the expiration time of the key number of seconds of the timestamp represents timestamp 
4 PEXPIREAT key milliseconds-timestamp // set the expiration time of the key to the number of milliseconds of the timestamp represents a time stamp

Note: timestamp is a timestamp unix (e.g.: timestamp = 1499788800 shows a expire in 2017.07.12)
2 is provided in two ways expiration of a period of time, we treated codes is the most commonly used strategy, setting three minutes or five minutes after the failure, the number of minutes into seconds or milliseconds converts stored in Redis.
3 and 4 are two ways to specify an expiration time, such as time expired coupons is a certain period of a day, but the unit is not the same.

Here we have an example of a simple explanation for the EXPIREAT next usage.

return value

An integer value of 1 or 0, as follows:

If you successfully set the timeout for that key, returns 1
If the key does not exist or can not set the timeout, returns 0

Syntax
The following is the basic syntax of EXPIREAT Redis commands.

1 redis 127.0.0.1:6379> Expireat KEY_NAME TIME_IN_UNIX_TIMESTAMP

Examples

First, create a key in the Redis: akeyand akeyset some values.

1 redis 127.0.0.1:6379> SET akey redis 
2 OK

Now, set the timeout to 60 seconds to create a set of keys.

 1 127.0.0.1:6379> SET akey redis
 2 OK
 3 127.0.0.1:6379> EXPIREAT akey 1393840000
 4 (integer) 1
 5 127.0.0.1:6379> EXISTS akey
 6 (integer) 0
 7 127.0.0.1:6379> SET akey redis
 8 OK
 9 127.0.0.1:6379> EXPIREAT akey 1493840000
10 (integer) 1
11 127.0.0.1:6379> EXISTS akey
12 (integer) 1

Three other similar uses, not one by one described here

2, a string unique way

The special manner SETEX command string, the command SETEX specified key value and set an expiration time. If the key already exists, SETEX command will replace the old value.

return value

When setting up a successful return OK.

grammar

Redis Setex basic command syntax is as follows:

redis 127.0.0.1:6379> SETEX KEY_NAME TIMEOUT VALUE

Examples

1 redis 127.0.0.1:6379> SETEX mykey 60 redis
2 OK
3 redis 127.0.0.1:6379> TTL mykey
4 60
5 redis 127.0.0.1:6379> GET mykey
6 "redis

Two, three kinds expiration policy

Regularly delete
- Meaning: set the expiration time of a key at the same time, create a timer for the key, so that the timer comes on the delete key in the key expiration time
- Pros: to ensure that memory is freed as soon as possible
- Disadvantages:
  - If a lot of expired key, delete the key will take up a lot of CPU time, CPU time in a stressful situation, can not put all the CPU time used to make critical thing, also need to take the time to remove these key
  - Create a time-consuming timer To create a timer to set the expiration time of each key (there will be plenty of timer generates), serious performance impact
  - No one with
Inert delete
- Meaning: key does not remove the expired time, every acquisition key from the database to check whether the time has expired, if expired, deleted, returns null.
- Advantages: deletion occurred only in the key removed from the database occurs when, and only delete the current key, so the occupation of the CPU time is relatively small, and at this time do not delete that reached a point where (if at this time do not delete it, we will get to the key has expired)
- Cons: If a large number of key after a timeout beyond, within a long period of time, have not been acquired, the memory leak may occur (unwanted junk take up a lot of memory)
Periodically delete
- Meaning: from time to time perform a deletion (hz set in redis.conf profile, 1s refresh frequency) expired key operation
- advantage:
  - By limiting the duration of the delete operation frequency and to reduce the occupation of the CPU deletes Time - process "Timing deleted" disadvantage
  - Shortcoming regularly delete expired key-- handle "inert deleted"
- Shortcoming
  - In friendliness memory, as "regular Delete"
  - In terms of CPU time and friendly, not as good as "inert Delete"
- difficulty
  - Long (each deletion execution how long) and the execution frequency (how often do delete) (this should be determined according to the operation of the server) when deleting a reasonable set of operations performed

The following conclusions can be drawn after reading the above three strategies:
regular and periodic delete delete is automatically deleted: Redis regularly take the initiative to eliminate a number of elapsed key

Delete to delete the inert passive: when used only to test key is not expired, delete expired

Inert delete built-in policy for the redis server

Deleted regularly by:

First, the configuration redis.conf hz options, default is 10 (i.e., 1 second performed 10 times, once 100ms, the faster the greater the value of the refresh rate, the greater the loss in performance most Redis)
Second, maxmemory maximum configuration redis.conf when the used memory more than maxmemory limit, it will trigger unsolicited clean-up

note:

The upper side of said memory database refers to the database, each redis default server database 16 (disposed on the database to see the code below), using the default database 0, all operations are on a database 0 operations on the database storage structure redis, check out Chapter 8 Redis database structure and principles of reading and writing

# Set the number of databases. The default is 16 banks, default DB 0, you can use the "select 1" to select One database 
# Note: Due to the default database using the numbers 0, then all we do is cache operations exist on the database numbers 0, 
# when you look up in the database No. 1 when it is set before finding a nice cache 
# If you want to move the cache on the No. 0 to No. 1 database database, you can use "the move Key 1" 
databases 16

memcached but with the inert deleted and Redis uses both inert and regularly delete delete, which is a difference between the two (redis can be seen as a little better than the memcached)
For inert deleted, the acquisition is not the only key to check whether the key time will expire on some of the key setting method also checks (eg.setnx key2 value2: add memcached method of the method is similar to, if set key2 already exists, the method returns false, do nothing; if key2 set does not exist, then the method cache key2-value2 assumptions set when calling this method and found redis key2 already exists, but this has been key2. expired, if not a delete operation at this time, then, will direct setnx method returns false, that is to say at this time is not reset key2-value2 success, which is why we must perform before setnx of key2 be expired inspection)

Three, Redis adopted expiration policy

Remove + periodically delete inactive

Inert removal process
- During operations such as get or setnx, first check whether the key expired,
- If expired, delete key, and then perform the appropriate action;
- If not expired, directly perform the appropriate action
Regular removal process (In simple terms, each library specified number of libraries of random delete the specified number of months or less expired key)
- Through each database (that is, the number of "database" redis.conf configured, the default is 16)
  - Check the current predetermined number of banks in the key (default library checker 20 for each key, note that the loop is executed is equivalent to 20 times, when the loop described below)
    - If the current library is not a key set an expiration time, directly executed next traversal library
    - Gets a random set of key expiration time, check that the key has expired, if expired, delete key
    - Periodically determine whether the deletion specified length of time has been reached, have already been reached, exit regularly removed.

Four, RDB's handling of expired key

Expired key has no effect on the RDB

Persistent data from memory to the database RDB file
- Before persistence key, checks for expired expired key file does not enter the RDB
RDB to recover data from a database file into memory
- Before the data loaded into the database, the first key will be expired inspection, expired if not into the database (main library case)

Five, AOF of the handling of expired key

Expired key has no effect on the AOF

Persistent data from memory to the database AOF file:
- When the key expires, has not yet been deleted at this time to perform persistence operations (the key is not entered aof file, modify the command did not happen because)
- When the key expires, when the deletion occurs, the program will append a del command to the aof file (which expired keys will be deleted when restoring data files to aof the future)
AOF rewrite
- When overridden, it will first determine whether the key expired, expired key file will not be rewritten to aof

PS: If you have questions, please leave a message, without permission shall not be reproduced without permission, please indicate the source: http://www.cnblogs.com/xuliangxing/p/7151812.html