Some thoughts on Cache Breakdown

Preface

Caching (memory or Memcached or Redis.) is widely used in Internet projects. This blog will discuss the topic of cache breakdown, covering the phenomenon of cache breakdown, ideas to solve, and dealing with cache breakdown through code abstraction.

What is cache breakdown?

The above code is typically written: when querying, take it from the Redis cluster first, and if not, query it from DB and set it to the Redis cluster.

Note that in actual development, we are usually in the cache and the data structure stored is JSON. (the serialization method provided by JDK is slightly less efficient than JSON serialization; and JDK serialization is very strict, so the increase or decrease of fields is likely to cause reverse sequence failure, while JSON is more compatible in this respect.)

Assuming that it takes 2S to query from DB, it is obvious that all requests over this period of time will go through DB queries under the above code, which is equivalent to cache penetration directly. This phenomenon is called "cache breakdown"!

Analysis of ideas to avoid cache breakdown

Add synchronized?

If synchronized is added to the method so that query requests have to be queued, our original intention is to let concurrent queries go out of cache. That is, the granularity of synchronized is too large now.

Reduce the granularity of synchronized?

The above code, when caching data, so that the query cache requests do not have to queue, reducing the granularity of synchronization. However, the problem of cache breakdown is still not solved.

Although multiple requests for querying DB are queued, even if one DB query request is completed and set to cache, other requests for querying DB will continue to query DB!

Synchronized+ double check mechanism

Through the double check mechanism of synchronized+:

In the synchronization block, continue to judge and check to ensure that it does not exist before checking the DB.

Code abstraction

Found no, in fact, we deal with the cached code, except for the specific query DB logic, the other is templated. Next, let's abstract!

An API for querying DB:

Since querying a specific DB is determined by the business, exposing this interface allows the business to implement it.

A template:

Doesn't Spring have a lot of Template classes? We can also use this idea to abstract the code, let the outside world decide the specific business implementation, and write the template steps. (somewhat similar to the concept of AOP)

The improved code:

From this, we can see that we don't care where the cached data is loaded, but give it to the specific user, and the user no longer has to pay attention to the cache breakdown when using it, because we are all abstracted.