Redis set valid time

1. Effective time setting:

The expiration processing of the stored value by redis is actually processed for the key of the value, that is, the setting of time is also the effective time of setting the key. The Expires dictionary stores the expiration time of all keys. Expires is also called the expiration field. 
Four treatment strategies

  1. EXPIRE sets the survival time of the key to ttl seconds
  2. PEXPIRE sets the key generation time to ttl milliseconds
  3. EXPIREAT sets the expiration time of the key to the timestamp of the number of seconds represented by timestamp
  4. PEXPIREAT sets the expiration time of the key to the timestamp in milliseconds represented by timestamp

In fact, the above several processing methods are implemented based on PEXPIREAT. When setting the survival time, redis internally calculates the time and processes it in the memory. The final processing will turn to PEXPIREAT. 
The first and second methods are to set an expiration time period, which is the most commonly used strategy for processing verification codes. Set it to expire after three or five minutes, and convert the minutes into seconds or milliseconds and store them in redis. 
The two methods 3 and 4 are to specify an expiration time. For example, the expiration time of the coupon is a certain day, a certain month, and a year, but the unit is different.

 

2. Overdue processing

 

The processing of the expired key is to delete the expired key, and the operation here is mainly for the processing of the expired field. 
There are three processing strategies in Redis: scheduled deletion, lazy deletion and periodic deletion.

  1. Timed deletion: Create a timer when setting the expiration time of the key, and execute the delete operation immediately when the expiration time is up. However, this processing method is instant, no matter how many expired keys within this time, no matter the current running status of the server, it will be executed immediately, so it is not very CPU friendly.
  2. Lazy deletion: The lazy deletion strategy will not delete the key immediately when it expires, but will actively delete it when the key is acquired by an external command. The processing process is: receiving get execution, judging whether it is expired (here judged by expiration), executing the delete operation, and returning nil (empty).
  3. Periodic deletion: Periodic deletion is to set a time interval, each time period will detect whether there is an expired key, if there is a delete operation. This concept should be easy to understand.

After reading the above three strategies, the following conclusions can be drawn: 
4. 1 and 3 are active deletion, and 2 is passive deletion. 
5.1 is executed in real time and is not very CPU-friendly, but this releases the memory to the greatest extent, so this method is considered a memory-first optimization strategy. 
6. 2 and 3 are passive deletion, so the expired key should exist for a certain period of time, so that the expired key will not be deleted immediately and still occupy memory. However, the lazy deletion is generally a single deletion, which is relatively CPU-friendly. 
7. The delete strategy of regular keys is a painful strategy. It has the possibility of avoiding the disadvantages of the 1 and 2 strategies, as well as the possibility of the 1 and 2 strategies at the same time. If the regular deletion is executed too frequently, it may become a regular deletion. If the execution is too few, it may cause too many expired keys to be deleted and take up too much memory. If the time setting is not too good, it may take up too much The memory also has a bad effect on the CPU. and so. When using regular deletion, be sure to grasp the time point of this deletion.

 

Three, the master-slave server deletes expired key processing

 

There are three types: RDB persistence, AOF persistence and replication functions.

RDB: 
1. When the main server mode is running when loading an RDB file, the program will check the keys in the file. Only the unexpired keys will be loaded, and the expired keys will be ignored. Therefore, the expired keys in RDB mode will not affect the main server. 
2. When running from the server to load the RDB file, all keys will be loaded, including expired and unexpired. When the master server performs data synchronization, the data of the slave server will be emptied, so the expired key of the RDB file generally will not affect the slave server.

AOF: 
AOF files will not be affected by expired keys. If any expired keys have not been deleted, the following actions will be performed: 
When requested by the client (expired keys):

  1. Recharge and delete the expired keys that are accessed from the database;
  2. Append a DEL command to the AOF file;
  3. Reply nil (empty) to the client executing the request.

copy:

  1. After the master server deletes the expired key, it sends a DEL instruction to the slave server to tell it to delete the expired key.
  2. When the get command is received from the server, the expired key will not be processed, and will only be returned as an unexpired key. (In order to maintain the consistency of the master and slave server data)
  3. The slave server will delete the expired key only after receiving the DEL instruction sent by the master server. 

Guess you like

Origin blog.csdn.net/weixin_43452467/article/details/113860008