I saw many people write “proficient in cache” on their resumes, but when I asked them “3 common read/write strategies for cache”, they were stunned.

The reason for this problem is that when we learn Redis, we may simply write some Demo, and do not pay attention to the cache read and write strategy, or do not know it.

However, understanding the three common cache read and write strategies can be very helpful both for using caching in the real world and when asked about caching in an interview!

I will briefly explain my understanding of these three cache read and write strategies.

In addition, each of the three cache read and write strategies has its own advantages and disadvantages, and there is no optimal one. Therefore, we need to choose a more suitable one based on specific business scenarios.

Personal ability is limited. If there is anything that needs to be added/improved/modified, please feel free to point it out in the comments section and make progress together! — Love your Guide brother

Cache Aside Pattern

Cache Aside Pattern is a Cache read/write Pattern that we usually use. It is suitable for scenarios with a lot of read requests.

In Cache Aside Pattern, the server needs to maintain both the DB and the Cache, and the result is based on the DB.

Let’s take a look at the cache read and write steps in this policy pattern.

Write:

  • To update the DB

  • Then delete the cache directly.

I’ve drawn a little diagram to help you understand what I’m doing.

​

Read:

  • Reads data from the cache and returns it

  • If the data cannot be read from cache, it is read from DB and returned

  • The data is then stored in the cache.

I drew a simple picture to help you understand the steps of reading.

​

It’s not enough for you to just know the above, we need to understand how it works.

For example, the interviewer may ask, “Can I delete the cache before updating the DB?”

Answer: That’s definitely not possible! Because this may cause database (DB) and Cache data inconsistency problem. Why is that? For example, if request 1 writes data A first and request 2 reads data A later, data inconsistency is likely to occur. The process can be simply described as:

Request 1: delete data from cache (A); request 2: update data from DB (A);

When you answer this question, the interviewer will probably follow up with the following question: “Is it ok to update the DATABASE and then delete the cache while writing data?”

Answer: It is theoretically possible to have data inconsistencies, but it is very unlikely because the cache writes much faster than the database!

For example, request 1 reads data A first, request 2 writes data A later, and data A is not in the cache may also cause data inconsistency problems. The process can be simply described as:

Request 1 reads data from DB (A) and writes data to database (B). Request 2 writes data to cache (A).

Now let’s analyze the defects of Cache Aside Pattern.

Defect 1: There must be no cache problem in the first data request

Solution: The hotspot data can be stored in the cache in advance.

Defect 2: Data in the cache is frequently deleted due to frequent write operations, which affects the cache hit ratio.

Solutions:

  • Strong consistency between database and cache data: The cache is also updated when the DATABASE is updated, but we need to add a lock/distributed lock to ensure that there is no thread safety problem when the cache is updated.

  • It is possible to temporarily allow inconsistencies between the database and the cache: updating the DB also updates the cache, but with a shorter expiration time for the cache, so that the impact of inconsistencies is minimized.

Read/Write Through Pattern

In Read/Write Through Pattern, the server reads and writes data from the cache as the primary data store. The cache service is responsible for reading and writing this data to the DB, relieving the application of its responsibility.

This cache read/write strategy is something that you may find very rare in development. Regardless of the performance impact, it is likely that Redis, the distributed cache we often use, does not provide cache writing to DB.

Write Through:

  • Check the cache. If the cache does not exist, update the DATABASE.

  • If the cache exists, the cache is updated first, and the cache service updates the DB (cache and DB) simultaneously.

I’ve drawn a little diagram to help you understand what I’m doing.

​

Read (Read) Through:

  • Reads data from the cache and returns it.

  • If the data cannot be read, it is loaded from DB and written to cache before returning a response.

I drew a simple picture to help you understand the steps of reading.

​

Read-Through Pattern actually encapsulates above cache-aside Pattern. In cache-aside Pattern, if there is no data in the Cache, the client writes the data to the Cache, while the Cache service writes the data to the Cache. This is transparent to the client.

Like Cache Aside Pattern, the Read-Through Pattern must not be in the Cache for the first time. For hot data, it can be placed in the Cache in advance.

Write Behind Pattern

Write Behind Pattern is similar to Read/Write Through Pattern. In both cases, the cache service is responsible for cache and DB reads and writes.

However, there is a big difference between the two. Read/Write Through updates the cache and DB synchronously, while Write Behind Caching updates only the cache and does not update the DB directly. Instead, it updates the DB asynchronously in batches.

Obviously, this approach presents a greater challenge to data consistency, as the cache service may fail before the database is asynchronously updated.

This strategy is also very rare in our normal development process, but it does not mean that it is rarely used in many scenarios, such as asynchronous writing messages to disk in the message queue and MySQL’s InnoDB Buffer Pool mechanism.

The Write performance of DB in Write Behind Pattern is very high, which is suitable for some scenarios where the data changes frequently and the data consistency is not so high, such as the number of views and likes.

The original address: mp.weixin.qq.com/s/bWofuM5eS…

Recommended reading:

Bytedance’s summary of design patterns in PDF is popular, and the full version is open for sharing

While swiping Github, I found a note of Ali’s algorithm! The star 70.5 K

If you can understand this, you can make $40K a month even for private work

Why alibaba’s programmer growth rate so fast, read their internal data I understand

The knowledge system required for a programmer to earn 50 million a year.

What you don’t know about violent recursive algorithms

Three things to watch ❤️

If you find this article helpful, I’d like to invite you to do three small favors for me:

Like, forward, have your “like and comment”, is the motivation of my creation.

Follow the public account “Java Doudi” to share original knowledge from time to time.

Also look forward to the follow-up article ing🚀