Cache penetration, cache concurrency, cache failure

Http://zeroq.me/p/279

 

 

I. cache penetration

When cache is used in projects, the app first checks whether the cache exists. If cache content exists, the app directly queries the database and then caches the query result and returns it. At this time, if a piece of data we query does not exist in the cache, it will cause every request to query the database. In this way, the cache will lose its meaning. When traffic is high, the database may be suspended.

This problem is often encountered, but does not attract enough attention. In my opinion, if such a problem occurs, I can add a step in the encapsulated cache set and get, if a key does not exist in the query, an ID key is already set as the prefix. If a key does not exist, an ID key is first queried, return a non-falsh or null value of the Protocol, and then the app performs corresponding processing, so that the cache layer will not be penetrated. Of course, the validity period of the verification key cannot be too long.

 

Ii. cache concurrency

Sometimes, if the website has high concurrent access and a cache becomes invalid, multiple processes may query the database at the same time and set the cache. If the concurrency is large, this may also cause high dB pressure and frequent cache updates.

My current idea is to lock the cache query in the app again. If the key does not exist, lock it, check the database into the cache, and unlock it. If other processes find a lock, they will wait, after unlocking, the system returns data or queries the database.

 

Iii. cache failure

The main cause of this problem is high concurrency. When we set a cache expiration time, some may be set to 5 minutes or 10 minutes; when concurrency is very high, many caches may be generated at a certain time, and the expiration time is the same. In this case, the cache may become invalid when the expiration time is reached, if all requests are forwarded to the dB, the DB may be under heavy pressure.

Some time ago, I just saw related articles on the Internet. When I reference a simple solution, I will talk about the scattered cache expiration time, for example, we can add a random value based on the original expiration time, such as 1-5 minutes random, so that the repetition rate of each cache expiration time will be reduced, it is difficult to trigger a collective failure event.

 

The second and third problems are actually similar, mainly when the second problem is about the same cache, and the third problem is about many caches.