Shulou(Shulou.com)06/01 Report--

Directory Preface Update database first, then update cache first, then update database first, then delete cache first, then update database first, then delete cache Delete cache failure, resulting in inconsistency Read and write separation, resulting in inconsistency Preface

Cache is often used in projects. In order to reduce interaction with the database, the ideas of using cache by small partners are as follows:

Cache Design Ideas

Our friends have not considered the cache update problem, the friends will definitely say that it has been used ah, when there is data update, the cache will be cleared ah, the next time the service will set the new value to the cache. Isn't that enough? Yes, in general projects, this kind of use is enough. Old Gu then led everyone to see what problems would occur in high-concurrency scenarios.

For example, let's take the inventory of goods as a cache. Now we need to update the inventory value in the cache. How to do this, let's look at the following scenarios:

Update database first, then cache

Problem scenarios exist: Request A update value 99, Request B update value 98

The above flow chart:

Request A is initiated first, updating the database to 99, but not yet updating the cache. Request B is initiated, updating the database to 98, and updating the cache value to 98. Request A then updates the cache value to 99.

Thus, the database value is 98, but the cached value is 99, and the values are inconsistent. (Not recommended)

Update cache first, then database

This process is very similar to the above, and the problems that arise are very similar.

Request A updates the cache to 99, but before it can update the database Request B updates the cache to 98, and updates the database to 98 Request A updates the database to 99

This results in a cached value of 98 and a database value of 99 resulting in inconsistency. (Not recommended)

Delete cache before updating database

Problem scenarios exist: Request A updates the value to 99, request B obtains the value

The request flow in the above figure:

Request A to update the value, first delete the value in the cache, but before updating the database, request B to query the value, find that the cache does not exist, query the database, request B to obtain the value in the database, and set the value to the cache. Request A updates the database to 99.

This leads to inconsistency between the cache and the database, where the cache always has old data. (Not recommended)

Update database before deleting cache

This scheme is also a strategy for updating cache in the "Cache-Outside pattern" proposed by foreigners. This strategy first ensures that the data at the source must be correct. Is this strategy foolproof? There's a very specific scenario.

Flow chart above: The cache suddenly fails during establishment.

Request A initiates a query request and directly queries the database to 100, but before it has time to set the update value of cache request B, update the database first, and then set the cache to 100 when cache request A is deleted.

This inconsistency occurs because the cache is suddenly invalidated. And make sure that the update operation of request B is faster than the query operation of request A; this will lead to inconsistency. The probability of this happening is very small. This approach is recommended for projects that are generally not demanding.

Cache deletion failed, resulting in inconsistency

In this strategy of updating the database first and then deleting the cache, because the cache is to be deleted, but if the cache deletion fails, it will cause the database to be inconsistent with the cache. What about this problem? What we normally think of is to use our MQ middleware to implement.

In the process shown in the figure above, if the cache deletion fails, the message is sent to the messaging middleware and enters the message queue. Perhaps a small partner will ask, what if the message delivery fails? We can take advantage of the mechanisms on the messaging middleware side that guarantee 100% message delivery (more on that later). This ensures that we try again even if deleting the message fails.

However, there is a problem with this solution, which is that it is more coupled with the business code of our application service. Code business is unclear.

So do we have any other plans that don't intrude on the business?

In the above figure, the underlying mechanism of mysql is actually utilized. Binlog logs delete cache, so that it does not need to be associated with business. Delete cache service is independent. We can use Ali open source canal to operate.

Read and write separation, leading to inconsistency

Is there no problem with updating the database first and then deleting the cache? Let's look at another scenario, one where the database reads and writes separately. Generally, large and medium-sized projects will use the separation of database reads and writes. Write requests are in one repository and read requests are in another. The problem with read/write separation is that there is data latency between libraries because there is data synchronization.

If we look at the scenario flow above, there is a problem, because request B updates data on one repository and request A reads data on another repository.

Request B update value 99, delete cache Request A query value 100 (read database data has not been synchronized), update to cache (value 100)

This leads to inconsistency, which is a frequent occurrence, not a small probability event. So how do we handle this? Old Gu would introduce him next time.

Summary: The reason for the inconsistency is that the order of execution of each request in high concurrency cases cannot be determined, and it is not known which request is executed first and which is executed later.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.