Hello, I’m Redis, a man named Antirez brought me into this world.
Speaking of my birth, with the relational database MySQL is quite a source.
Before I came to this world, MySQL had a hard time. As the Internet developed faster and faster, it contained more and more data, and user requests skyrocketed. Every user request turned into one read and write operation after another. Especially to “Double 11”, “618” such days of nationwide shopping spree, are the days of MySQL suffering.
I was later told by MySQL that more than half of all user requests are read operations, and that they often query the same thing repeatedly, wasting a lot of time on disk I/O.
Later, someone wondered if they could learn from the CPU and add a cache to the database. And so I was born!
I’ve been good friends with MySQL since I was born, and we often work hand in hand on back-end servers.
Applications can register the data they query from MySQL with me. When they need it later, they can ask me first. I don’t ask MySQL for it.
For ease of use, I support storage of several data structures:
- String
- Hash
- List
- Set
- SortedSet
- Bitmap
- · · · · · ·
Because I keep all the registered data in memory and don’t have to do the snail’s pace I/O, it takes less time to find me than to find MySQL.
Don’t underestimate this simple change, I can take a lot of load off MySQL! As the program ran, I cached more and more data, and I blocked user requests for most of the time. Now it’s sitting pretty!
With me on board, the performance of web services improved a lot, thanks to the number of shots I took for the database.
Cache expiration && cache obsolescence
But soon I found that things are not good, MY cache of data are in memory, but even in the server, memory space resources are still very limited, can not be uncontrolled so save, I have to think of a way, or eat jujube pills.
After a while, I came up with an idea: set a timeout period for cached content, and leave it up to the apps to set the timeout period. All I had to do was delete expired content from my cache and make room in time.
When should I do the cleaning?
The easiest thing to do is to delete it regularly. I decided to do it every 100ms, 10 times a second!
When I clean up, I can’t delete all the expired ones at one go. I have stored a large amount of data in it. I don’t know how long it will take to sweep it comprehensively, which will seriously affect my reception of new customer requests!
Time is tight and the task is heavy, SO I have to randomly select a part to clean, can relieve the memory pressure on the line.
After a while, I found that some of the key values were lucky enough to not be selected by my random algorithm every time, which was not good, because these long-expired data were occupying a lot of memory space! Cold gas shake!
I can’t rub sand in my eyes! So on the basis of the original regular deletion, and added a move:
The key values that had escaped my random selection algorithm were immediately deleted as soon as I found that they had expired in a query request.
This way because it is passive trigger, no query will not happen, so also called lazy delete!
However, there are still some key values, both escaped my random selection algorithm, and have not been queried, so they remain unpunished! At the same time, there is less and less memory available.
And even if, to say the least, I could delete all the data that was out of date, I’d have to figure out a way to do that if the expiration time was set so long that I couldn’t even clean it up and the memory was full.
I thought hard for a long time, finally hold back a big idea: memory elimination strategy, this time I want to solve the problem completely!
I have provided eight policy provisioning application options for how I should decide when I run out of memory:
- Noeviction: Returns errors without removing any key values
- Allkeys-lru: Removes the least recently used key value using the LRU algorithm
- Volatile – lRU: Use the LRU algorithm to remove the least recently used key from the set of keys with expiration time
- Allkeys-random: deletes allkeys randomly
- Volatile -random: Randomly removed from the set of keys with expiration time
- Volatile – TTL: Deletes the key with the shortest remaining time from the key whose expiration time is set
- Volatile – lFU: Removes the least frequently used key from the key whose expiration time is configured
- Allkeys-lfu: removes the least frequently used key from allkeys
With the combination of the above, I no longer have to worry about expired data to fill up the space
The cache penetrates the bloom filter
My life is quite comfortable, but MySQL brother is not so comfortable, sometimes encounter some annoying requests, query data does not exist, MySQL will be wasted work! Not only that, but I can’t cache it because it doesn’t exist, so I’m going to get the same request every time and I’m going to make MySQL work for nothing. My value as a cache has not been demonstrated! This is often referred to as cache penetration.
MySQL: “Hey, brother, can you help me find a way to block those query requests that I know will not have results?”
Then I thought of another good friend of mine: bloom filters
There have skill, my friend, he is good at from a very large datasets quickly tell you find data does not exist (quietly tell you, my friend is a bit wonky, it tells you is not all that actually there is no such thing as possible, but it if he told you don’t exist, then don’t exist).
I introduced this friend to the application, so I didn’t have to bother MySQL with non-existent data, which easily helped solve the cache penetration problem.
Cache breakdown && cache avalanche
After that there was a period of peace until the day
One time, the MySQL guy was taking his time when he was caught off guard by a flood of requests.
After a while of busy work, MySQL angrily found me, “brother, how come ah, how suddenly come so fierce.”
I checked the log and quickly explained, “Brother, I’m really sorry. Just now, there was a hot data expired and I deleted it. Unfortunately, a large number of query requests for this data came later.
“You this stem of call what matter, next time pay attention to point”, MySQL eldest brother a face not happy of left.
I did not think much of this incident, and then forgot about it, but did not think that a few days later I had caused a bigger mess.
That day, there were a large number of network requests sent to MySQL, much larger than the previous one, MySQL brother in a short time to dry out several times!
It took a long time for this wave of traffic to pass and MySQL to recover.
“What’s the reason this time, brother?” MySQL big brother tired out of energy.
“This is even worse than the last time, because this time it was a whole bunch of data that expired almost at the same time, and then there were a lot of requests for that data, so it was much bigger than the last time.”
MySQL brother listened to a frown, “then you would like to think of a way ah, every two days to torture me, this who can withstand ah?”
“In fact, I have no choice. This time is not set by me. How about I talk to the application and ask it to set the cache expiration time evenly? At the very least, don’t let large amounts of data collectively fail.”
“Let’s go. Let’s go together.”
Later, we went to the application to discuss, not only randomize the expiration time of the key value, but also set the hot data never expire, which alleviated the problem a lot. By the way, we also gave these two problems names: cache breakdown and cache avalanche.
We are finally living a comfortable life again
eggs
I was trying to work that day when I made a mistake and the whole process crashed. When I start up again, all the cached data is gone, and the storm of requests is once again directed at MySQL. Oh, if only I could remember the contents of the cache before the crash… how to predict the future, please pay attention to the following highlights…
Author: xuan yuan wind link: www.cnblogs.com/xuanyuan/p/… Source: Blogland