Students who work on the backend all know about caching, and the greater the number of visits to the backend service, the more important the role of caching. I recently read some explanations by some big guys and thought they were very good. I will record my understanding here and summarize some knowledge points about back-end caching. As the name suggests, how does caching appear? The literal meaning is to save the data of this request in the memory. When the next access request comes, the cached data will be returned directly without having to access the DB (database) data. The advantage of this is that the access request can be responded to quickly, and it can also greatly reduce the pressure on database access; but to fully realize this, it actually requires a lot of work. If your business volume does not have concurrent access, then This cache is unnecessary and can be removed directly.
Next, let’s list some common problems we will encounter when doing caching.
1. Frequently Asked Questions about System Cache
Here are just a few very common problems that need to be taken into special consideration when designing system framework caches: cache penetration, cache breakdown, cache avalanche, data consistency and cache monitoring.
2. Cache penetration
What is cache penetration? It means that the access request does not hit the cache, but goes directly to the back-end DB for a request. Such a request is cache penetration. Generally, such a request is nothing, because it does not exist and reaches directly. Without the back-end DB database, if it is a hacker, it may be used to carry out malicious attacks and penetrate continuously, causing huge access pressure on the back-end DB until the database crashes, causing other normal requests to be unable to access normally. How to solve this situation? The method given by the boss is relatively simple:
- cache placeholder
- Cache for a short period of time, such as one minute
The above method means that when you design the cache, if there is no required data when penetrating to the DB, record a placeholder in the cache and set the effective time to one minute, which can completely prevent criminals. Use cache penetration to maliciously attack database access requests.
3. Cache breakdown
Although the boss classifies it into a separate category, in fact, the literal meaning is similar to penetration, but it is actually different. The breakdown is because the cached data time has expired and there are a large number of concurrent requests. If the cache is processed at this time, a large number of the same access requests will penetrate the cache and reach the database for access. At this time, the database It can't stand such a large amount of access, and the database can easily be brought down directly. The solution to this situation is:
- Unique DB request, shared request result
The solution means that if for the same request, when the cached data expires, a unique request ID needs to be generated when an access request comes, and then if there are a large number of requests, just wait for the result, no need to continue Go to the database to request, which can reduce the pressure on the database and ensure the normal operation of the system. When the new cache returns, the same previous request can directly return with this minimum result.
4. Cache avalanche
What does cache avalanche mean? That is, a large number of caches (such as tens of thousands of caches) reach their expiration time at the same time. At this time, a large number of requests will fall on the back-end database at the same time, which will also cause huge pressure on the back-end database. The solution to this situation is this:
- Add a random time offset of a period of time (such as half an hour) to the cache expiration time
The above solution means to add a random time deviation when setting the cache time validity period to avoid a large amount of cached data from expiring at the same time, resulting in a large number of access requests falling to the back-end data at the same time.
5. Cache and database consistency
Data consistency is to ensure the consistency of data in multiple places. The cache has a copy of the data, and the database also has a copy of the data. It is necessary to maintain the consistency of the data in the two places. So under what circumstances is it guaranteed? In fact, it is when the cached data expires and the data needs to be pulled again. At this time, some previous request may have modified the cache, and then it needs to be updated into the database. At this time, there are two methods:
- Delete cache first, then update to database
- Update the database first, then delete the cache
So which one should we choose? If we choose the first one and delete the cache first, then there will be a situation where you delete the cache, but you have not finished updating the database, and there is another request at this time, then he will Go to the database to pull data and update the cache, but the data in the database has not been updated at this time, so there will be incorrect data in the cache, which is dirty data, so this method will not work.
If you choose the second method, update the database first, then this situation will not exist, so we choose the second method: update the database first, and then delete the cache .
6. Cache monitoring
Cache monitoring is to check whether our cache design is effective. We need to monitor and record the hit rate of the cache. If the hit rate is too low, it can be said that our cache is not working and has failed. For example, there are 1,000 pieces of data in our cache. If statistics show that there are only 10 pieces of hotspot data, then the cache needs to be optimized because the hit rate is too low. Monitoring also needs to check whether the expiration time setting is reasonable for further optimization. Therefore, the cache design is a process of continuous optimization based on testing or business development. After reading this, you probably understand why caching is so troublesome.