What are the properties of cache system design?

This article mainly explains "what are the properties of cache system design". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought. Let's study and learn what are the properties of cache system design.

Previously

There are many problems and knowledge points involved in the cache system. I will mainly discuss it with you in the following aspects:

Stability.

Correctness

Observability

Standardize landing and tool construction

Cache correctness

Common practices for data updating

First of all, we talk about the premise of data consistency is that our DB update and cache deletion will not be treated as an atomic operation, because in a high concurrency scenario, it is impossible to introduce a distributed lock to bind the two into an atomic operation, if bound, it will greatly affect concurrency performance and increase system complexity, so we will only pursue the ultimate consistency of data. And this paper only aims at the high concurrency scenarios that do not pursue strong consistency requirements, financial payment and other students make their own judgment.

There are two common ways to update data, and the rest are basically variants of these two categories:

Delete the cache before updating the database

In this way, when we encounter a data update, we first delete the cache and then update the DB, as shown in the figure on the left. Let's take a look at the whole process of operation:

A request needs to update the data. Delete the corresponding cache first, and the DB has not been updated.

B request to read the data

B request to read the DB and write the old data to the cache (dirty data) if it is not in the cache

A request to update DB

You can see that the B request writes dirty data to the cache. If this is a data with more reads and less writes, the dirty data may exist for a long time (either there are subsequent updates or waiting for the cache to expire), which is not acceptable in business.

Update the database before deleting the cache

In the right part of the figure above, you can see that request B reads the old data between A updating DB and deleting cache, because the An operation has not yet been completed, and the time to read the old data is very short, which can meet the final data consistency requirements.

As you can see in the image above, we use to delete the cache instead of updating it, as shown in the following figure:

In the above picture, I use actions instead of deletions or updates. When we do delete operations, it doesn't matter whether A deletes first or B deletes first, because subsequent read requests will load the latest data from DB. However, when we update the cache, we will be sensitive to whether A updates the cache first or B updates the cache first. If An is updated later, there will be dirty data in the cache again, so go-zero only deletes the cache.

Let's take a look at the complete request processing process:

Note: different colors represent different requests.

Request 1 to update DB

Request 2 queries the same data and returns the old data. It is acceptable to return the old data within a short period of time, which satisfies the final consistency.

Request 1 to delete the cache

If request 3 is not in the cache when the request is made again, the database will be queried and the result will be returned after writing back to the cache.

Subsequent requests will read the cache directly.

Leave another question you can think about, for the following picture of the scene, how should we deal with it?

Thank you for your reading. The above is the content of "what is the nature of cache system design". After the study of this article, I believe you have a deeper understanding of the nature of cache system design. Specific use also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!