I talked about the previous article redis And two special data structures , This article mainly analyzes redis Memory obsolescence mechanism and cache expiration policy based on .
Caching is to directly put the retrieved data into memory after the first request to the database , And then it fetches data from memory every time , So it speeds up the pace , Directly improve the performance of the program . Then there is a problem , As more and more data, the memory consumption will increase , Because memory is limited , If you do not agree on some memory obsolescence mechanism and expiration policy , Memory will soon burst .
<> Memory recycling mechanism
because C Language does not have the function of automatic memory recycling , therefore redis In our own object system, we build a memory recycling mechanism based on reference counting technology , Through this mechanism , The program can trace the reference count information of an object , Automatically release objects and reclaim memory when appropriate
typedef struct redisObject { // Reference count int refcount; } robj;
The reference count information of an object changes with the state of use of the object ：
* When creating an object , The value of the reference count is initialized to 1
* When an object is used by a new program , Its reference count value will be +1
* When an object is no longer used by a program , Its reference count value will be -1
* When the reference count value of the object changes to 0 Time , The memory occupied by the object is freed
<> Memory elimination mechanism
Redis A threshold is reached when memory is used （ adopt maxmemory to configure ) When , The memory elimination mechanism will be triggered , Select some key To delete . There are many strategies for memory obsolescence , Here are some different strategies .
# maxmemory <bytes> Configure memory threshold # maxmemory-policy noeviction
* noeviction： When there is not enough memory to hold newly written data , An error is reported for a new write operation . Default policy
* allkeys-lru： When there is not enough memory to hold newly written data , In key space , Remove least recently used key.
* allkeys-random： When there is not enough memory to hold newly written data , In key space , Remove a random key.
* volatile-lru： When there is not enough memory to hold newly written data , In the key space where the expiration time is set , Remove least recently used key.
* volatile-random： When there is not enough memory to hold newly written data , In the key space where the expiration time is set , Remove a random key.
* volatile-ttl： When there is not enough memory to hold newly written data , In the key space where the expiration time is set , There is an earlier expiration date key Priority removal .
It is recommended in business development allkeys-lru and volatile-lru Two expiration policies .
LRU yes Least Recently
Used Abbreviation for , That is, the least used recently .LRU A page replacement algorithm based on operating system , Select the most recently unused page to eliminate . stay Redis in , Is to choose the most recently unused key Delete .
<> Expiration Policies
Used redis We all know , set up key Can be set when key Expiration time of , that key Will it lapse at the appointed expiration time ? answer ： no, it isn't .
Redis Is the use of periodic deletion + Lazy delete the expiration policy of both .
* Delete periodically
The so-called periodic deletion ,redis It's done like this . every other 100ms They will be randomly selected
Scan for the key, Judge these key Is it overdue , Delete if expired . So why not just delete all expired ones key What about ? because key Full scan when the volume is large key It's very performance intensive , Therefore, it is necessary to cooperate with inert deletion .
* Lazy deletion
The so-called lazy deletion is no longer active deletion . That is, the client requests a key When ,redis Will judge key Is it invalid , If it fails, delete it , Return to the client without invalidation . Therefore, lazy deletion can solve some overdue problems , But they have not been deleted regularly key. But some are overdue key It was not randomly selected , It is not accessed by the client , It will remain in the database all the time , Occupied memory , In the long run, memory may run out . So you can use the one mentioned above
Memory elimination mechanism .
<> On persistence key Treatment of
* RDB
In persistence key It will be checked before key Is it overdue , If key Expired , It's not going to last RDB in . In the same way , from RDB It is also checked when recovering data key Is it overdue , If expired, it will not be restored to the database .
* AOF
In persistence key before ,key Invalid but not executed del command , It doesn't persist to AOF in （ Because it wasn't there AOF In addition del command ）. When key It's invalid del When you order , Will be in AOF An additional item was added del command （ In the future aof The expired key will be deleted when the file recovers data ）. When rewriting , Will judge first key Is it overdue , Expired key Will not be rewritten to aof file .
Technology
Daily Recommendation