当前位置:网站首页>Redis cache obsolescence strategy
Redis cache obsolescence strategy
2022-07-06 13:23:00 【North of Xincheng】
「 This is my participation 2022 For the first time, the third challenge is 27 God , Check out the activity details :2022 For the first time, it's a challenge 」.
This article mainly explains redis Cache expiration elimination policy , And our combination LeetCode Of LRU Algorithm title , Do it yourself LRU Algorithm case of .
Common questions
1、 Produce your redis How much memory is set ?
2、 If configured 、 modify redis Memory size ?
3、 What do you do if the memory is full ?
4、redis How to clean up memory ? Regular deletion and lazy deletion. Have you seen ?
5、redis Cache retirement strategy
6、redis Of lru Do you know ? Can you write a lru Algorithm ?
redis What to do when the memory is full ?
redis How much is the default memory ? Where to check ? How to set and modify ?
1、 see redis Maximum memory consumption ?
2、redis How much of the default memory can be used ?
If you do not set the maximum memory size or set the matching memory size 0 , stay 64 Unlimited memory size under bit operating system , stay 32 Bit operating system is the most commonly used 3G Memory
3、 How do you configure in general production ?
General recommendation reids Set the memory to... Of the maximum physical memory 3/4
4、 How to modify redis Memory settings ?
By modifying the file configuration
Modify... By command
5、 What command to view redis Memory usage ?
info memory
If redis What happens when your memory is full ? If redis What happens if the memory usage exceeds the maximum setting ?
1、 If redis What happens when your memory is full ? If redis What happens if the memory usage exceeds the maximum setting ?
If redis The memory is full , Will prompt “(error) OOM command not allowed when used memory > 'maxmemory'.”
Conclusion
- Set up maxmemory The option to , Join in redis Memory usage has reached the maximum
- Without the expiration time, the data will be full maxmemory To avoid this problem , Next, we will elaborate on the memory obsolescence strategy
redis Cache retirement strategy ?
1、 Go to redis The data is written in it, but why is it gone ?
redis Delete strategy of expired key
- If a key is expired , Is it deleted from the memory immediately after the expiration time ?
- Definitely not
- If not , When will it be deleted after expiration ?? What operation is it
Three different deletion strategies
1、 Delete regularly
Redis It's impossible to traverse all the time with the lifetime set key, To check whether the data has reached the expiration time , Then delete him .
Immediate deletion can maximize the freshness of the data in the whole memory , Because it guarantees that the expired key value will be deleted immediately after expiration , The memory occupied by it will also be released , But delete right now CPU Is the most unfriendly . Because deletion will occupy CPU Time for , If you happen to meet CPU When you're busy , For example, when doing intersection or sorting calculations , This time will give CPU Cause additional stress , Give Way CPU Heart tired , Sometimes you need to delete . Busy to die ....
At this time, there will be a lot of performance consumption , At the same time, it will also affect the data reading operation .
summary : Yes CPU unfriendly , Use the processor to absorb energy for storage space ( Time for space ).
2、 Lazy deletion
Data arrival expiration time , Don't deal with it , The next time you access the data ,
If not expired , Return the data :
Found expired , Delete , Return does not exist
The disadvantage of lazy deletion strategy is , It is the least memory friendly .
If a key has expired , And this key remains in the database , So as long as the expiration key is not deleted , The memory it occupies will not be released .
When using the lazy deletion policy , If the database has many expiration keys , And these expiration keys happen ️ If not visited , Then they may never be deleted ( Unless the user manually performs flushdb), We can even think of this as a memory leak - Useless garbage takes up a lot of memory , The server will not release them by itself , This is very memory dependent for the running state Redis For the server , It's definitely not good news .
summary : Yes memory unfriendly , Swap storage space for processor performance ( Change space for time )
3、 Both of the above schemes go to extremes
Delete periodically
The periodic deletion strategy is the choice of the first two strategies
Periodically delete the policy. Delete the expired key every interval , And by limiting the execution time and frequency of the deletion operation, we can reduce the impact of the deletion operation on CPU The effect of time .
Periodic polling redis Timeliness data in the Library , Adopt the strategy of random sobbing , Use the proportion of expired data to control the frequency of deletion
characteristic 1:CPU Performance occupancy settings have peaks , The detection frequency can be customized .
characteristic 2: Memory pressure is not great , Cold data that has occupied memory for a long time will be continuously cleaned up
summary : Periodically spot check storage space ( Random sampling , Focus on spot check )
for instance :
redis The default for each 100ms Check , Is there any expired key, If there is key Delete . Be careful : redis Not intervals 100ms Will all key Check once, but randomly ( If every interval 100ms , All key Inspection ,redis Go straight into icu ). If only periodic deletion strategy is used , It will lead to a lot of key The time has not been deleted .
The difficulty of periodic deletion strategy is to determine the duration and frequency of deletion operation . If the delete operation is performed too frequently , Or the operation takes too long , A periodic deletion policy degenerates into a scheduled deletion policy , So much so that CPU Too much time is spent on deleting expired keys , If the delete operation is performed too little , Or cherish i The time given to you is too short , The periodic deletion policy will be the same as the inert deletion policy , There's a waste of memory . because , If the periodic deletion strategy is adopted , The server must be based on the situation , Reasonable deletion operation execution time and frequency .
summary : Regular sampling key , Judge whether it is overdue
There are still fish in the net
The above steps have been passed , Are there any loopholes ?
1、 Delete periodically , Never been spot checked
2、 Lazy deletion , I've never been hit
Above 2 step ==> A lot of overdue key Accumulated in memory , Lead to redis Memory space is tight or runs out quickly .
There must be a better plan .....
Memory retirement strategy
redis.conf
redis Of 8 Kind of elimination strategy
The original text in the official configuration file :
volatile-lru -> Evict using approximated LRU among the keys with an expire set.
allkeys-lru -> Evict any key using approximated LRU.
volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
allkeys-lfu -> Evict any key using approximated LFU.
volatile-random -> Remove a random key among the ones with an expire set.
allkeys-random -> Remove a random key, any key.
volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
noeviction -> Don't evict anything, just return an error on write operations.
Copy code
The default configuration : noeviction
Chinese summary
1、noevication : No one will be expelled key ( Default )
2、allkeys-lru: For all the key Use lru Algorithm to delete
3、volatile-lru: Set the expiration time for all key Conduct lru Algorithm to delete
4、allkeys-random: For all key Random delete
5、volatile-random: For all of the key Random delete
6、volatile-ttl : Delete those that are about to expire now key
7、allkeys-lfu: For all key Conduct lfu Algorithm to delete
8、volatile-lfu: For all of the key Use lfu Algorithm to delete
summary :
- 2 * 4 = 8
- Two dimensions : Filter through expired keys ; Filter all keys
- 4 In terms of : LRU ,LFU , random , ttl
- 8 An option
You usually use that ?
Usually used : allkeys-lru
How to modify
1、 Command mode
2、 The configuration file
边栏推荐
- Tyut outline of 2022 database examination of Taiyuan University of Technology
- MPLS experiment
- Record: the solution of MySQL denial of access when CMD starts for the first time
- MySQL 三万字精华总结 + 面试100 问,吊打面试官绰绰有余(收藏系列
- 分支语句和循环语句
- Rich Shenzhen people and renting Shenzhen people
- 十分鐘徹底掌握緩存擊穿、緩存穿透、緩存雪崩
- Record: newinstance() obsolete replacement method
- TYUT太原理工大学2022数据库大题之E-R图转关系模式
- 167. Sum of two numbers II - input ordered array - Double pointers
猜你喜欢
One article to get UDP and TCP high-frequency interview questions!
学编程的八大电脑操作,总有一款你不会
阿里云微服务(四) Service Mesh综述以及实例Istio
Inheritance and polymorphism (I)
一文搞定 UDP 和 TCP 高频面试题!
面渣逆袭:Redis连环五十二问,三万字+八十图详解。
Conceptual model design of the 2022 database of tyut Taiyuan University of Technology
TYUT太原理工大学2022软工导论大题汇总
Questions and answers of "Fundamentals of RF circuits" in the first semester of the 22nd academic year of Xi'an University of Electronic Science and technology
Application architecture of large live broadcast platform
随机推荐
Fairygui bar subfamily (scroll bar, slider, progress bar)
There is always one of the eight computer operations that you can't learn programming
Arduino+ds18b20 temperature sensor (buzzer alarm) +lcd1602 display (IIC drive)
凡人修仙学指针-1
(超详细onenet TCP协议接入)arduino+esp8266-01s接入物联网平台,上传实时采集数据/TCP透传(以及lua脚本如何获取和编写)
Tyut outline of 2022 database examination of Taiyuan University of Technology
13 power map
Exception: ioexception:stream closed
6.函数的递归
View UI Plus 發布 1.3.1 版本,增强 TypeScript 使用體驗
4.30动态内存分配笔记
一文搞定 UDP 和 TCP 高频面试题!
View UI plus released version 1.3.1 to enhance the experience of typescript
View UI Plus 发布 1.2.0 版本,新增 Image、Skeleton、Typography组件
Inheritance and polymorphism (Part 2)
Application architecture of large live broadcast platform
阿里云微服务(三)Sentinel开源流控熔断降级组件
Edit distance (multi-source BFS)
Database operation of tyut Taiyuan University of technology 2022 database
十分钟彻底掌握缓存击穿、缓存穿透、缓存雪崩