Concern public number: XY’s technical circle
Redis is very versatile. As a high-performance in-memory database, it is often used in caching business scenarios.
The so-called cache is that when data is first retrieved, it is temporarily stored in memory. The next time the data is needed, it can be fetched directly from memory without having to query the database or call a remote interface, which can greatly improve the performance of your application.
If the data in the cache is permanent, the memory footprint becomes larger and larger. Memory is limited, so the cache system needs to delete some unnecessary cache data when needed to save memory space.
Redis provides two mechanisms that work together to achieve this goal: an expiration policy and a memory flushing mechanism.
Expiry policies
For those of you who have used Redis, once you set up a key, you can specify an expiration date for that key. Will the key be deleted as soon as it expires? How does Redis remove expired keys?
Conclusion: Redis is an expiration policy that uses a combination of periodic deletion and lazy deletion.
Periodically delete
Periodic deletion means that Redis randomly selects some keys with expiration time every 100ms by default, checks whether these keys are expired, and deletes them if they are expired.
Because there are too many keys, scanning all keys will consume very much performance, so some keys are randomly selected to delete. So it is possible to delete not over, need inert delete cooperate.
Lazy to delete
Lazy deletion is no longer an active deletion by Redis. Instead, when a client wants to obtain a key, Redis checks whether the key has expired and returns it to the client. If it has expired, Redis deletes the key and does not return it to the client.
So lazy delete can solve some expired, but not regularly deleted randomly selected keys. However, some expired keys are neither randomly selected nor accessed by clients, so they remain in the database and occupy memory, which may cause memory exhaustion in the long run. So Redis provides a memory flushing mechanism to solve this problem.
Why not use timed deletion? Scheduled deletion means that a timer is used to monitor the key and automatically delete the key when it expires. Although the memory is released in time, CPU resources are consumed. Therefore, this policy is not recommended.
Memory flushing mechanism
When Redis memory usage reaches a certain threshold (via maxMemory configuration), it triggers a memory flushing mechanism and selects some keys to delete. There are many strategies for memory flushing, and here are some of the different strategies.
# maxmemory
Configure the memory threshold
# maxmemory-policy noeviction
Copy the code
- Noeviction: New write operations will bug when memory is insufficient to accommodate new write data. The default policy
- Allkeys-lru: Removes the least recently used key from the key space when memory is insufficient to accommodate new writes.
- Allkeys-random: Randomly removes a key from the key space when memory is insufficient to accommodate new writes.
- Volatile – lRU: Removes the least recently used key from the expired key space when memory is insufficient to accommodate new writes.
- Volatile -random: Randomly removes a key from the expired key space when memory is insufficient to accommodate new writes.
- Volatile – TTL: When the memory is insufficient to accommodate new data, the key whose expiration time is earlier is removed from the key space.
How to choose the right strategy? Two LRU strategies are recommended. According to their own business needs. Allkeys-lru is recommended if you use Redis only for caching and not for DB persistence; If you use Redis for both caching and data persistence, volatile- LRU is recommended.
LRU is an abbreviation for Least Recently Used. LRU is a page replacement algorithm derived from the operating system, which selects the most recent unused pages to be eliminated. In Redis, select the most recent unused key and delete it.
How does persistence handle expiration?
The previous article introduced Redis’ two persistence strategies: RDB and AOF. There are also special treatments for expired keys during the persistence and data recovery phases.
RDB
Persisting data from the in-memory database to the RDB file: Before persisting a key, the system checks whether it has expired. The expired key is not stored in the RDB file. Recovering data from the RDB file to the in-memory database: Before loading data into the database, the system checks whether the key has expired.
AOF
Persist data from an in-memory database to an AOF file: When the key expires and has not been deleted, persistent operations are performed (the key will not enter the AOF file, because there is no modification command). When the deletion operation occurs after the key expires, The program will append a del command to the aOF file (the expired key will be deleted when the data is recovered from the AOF file in the future). Aof overwrite: When overwriting, the program will check whether the expired key is expired. The expired key will not be overwritten to the AOF file
Write articles carefully and share with your heart.
Personal website: Yasinshaw.com
Public number: XY’s technical circle