Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to understand the double write consistency between database and cache". In the daily operation, I believe that many people have doubts about how to understand the double write consistency between database and cache. I have consulted all kinds of materials and sorted out a simple and useful operation method. I hope it will be helpful to answer the doubt of "how to understand the double write consistency between database and cache". Next, please follow the editor to study!

1 about consistency

Caching mechanisms, such as Redis, are generally introduced to speed up system performance. In this case, when users read the data, they generally follow the following process:

Reading process

There is no objection to the reading process, but for the update of the data, how to operate is reasonable?

Update the database before updating the cache.

Delete the cache before updating the database.

Update the database before deleting the cache.

2 consistency solution 2.1 caching TTL

Simple, direct and violent method. If some data is not important, we can set a TTL after reading the data to the cache. After waiting for the timeout, the cache automatically reads the data from the database.

2.2 update the database before updating the cache

If we have two requests An and B, A request will age = 14 and B request will age = 12. Let's take a look at normal and abnormal execution:

Cache old data

It can be found that if there is a network shock, the cached data will be old data. Therefore, this method is not desirable. And it is not appropriate for the following scenarios:

For the business requirements with more write scenarios and fewer read scenarios, the cache is not read frequently, but is updated frequently.

If the cached data is written after a variety of complex calculations, then each write cache has to be calculated once, which is not desirable.

2.3 delete the cache before updating the database

If A requests to change the data first, B requests to read the data. If the following occurs because of the network, it will also cause dirty data to be cached. If the cache does not set TTL at this time, it will always be dirty data.

Cache dirty data

How to solve the above situation? Generally speaking, the delayed double deletion strategy can be used. Its core execution process is as follows: public void write (String key,Object value) {

Redis.delKey (key)

Db.updateValue (value)

Thread.sleep (1000); / / Delete again

Redis.delKey (key)

}

The idea is implemented on the flowchart as follows:

Delayed double deletion strategy

The time of sleep depends on the time consumed by the business data logic. Anyway, the purpose is to ensure that the read request ends, and the write request can delete the cache dirty data caused by the read request.

Of course, if the master-slave write-read architecture is used, the processing idea is similar to the above, except for the dormancy time plus the master-slave synchronization time.

Secondary deletion of master-slave mode

But in fact, there is still something wrong with the second deletion:

The second deletion involves hibernation, which may degrade the performance of the system. You can delete it asynchronously by setting up another thread.

If the second deletion fails, it will still lead to the existence of cache dirty data.

2.4 update the database before deleting the cache

In order to solve the problem of cache update, foreigners have proposed a cache update routine called "Cache-Aside pattern". This strategy is also widely used in Facebook, which points out:

Invalidation: the application first caches the data, and if it does not get it, it fetches the data from the database and, after success, puts it in the cache.

Hit: the application fetches the data from the cache, fetches it and returns.

Update: save the data in the database first, and then invalidate the cache after success.

If two threads An and B request at the same time, normally, whether you are reading and writing separate or stand-alone version, reading is generally faster than writing. Then deleting the cache is generally effective.

Update the database before deleting the cache

But there may be other reasons why reading is slower than writing, causing us to delete a loneliness, although this rarely happens.

When reading is slower than writing

This scheme is safer than deleting the cache and then updating the database, but it is not foolproof. Whether it is to delete the cache and then update the database or update the database and then delete the cache, if you fail to delete the cache, it will cause the cache to be inconsistent with the data! 2.5 message queuing ensures message deletion

Delete the cache through the confirmation consumption mechanism of the message queue.

Message queuing mechanism ensures deletion

The disadvantages are also obvious:

Cause a lot of intrusions into the business line code, and introduce middleware.

Delayed deletion of messages can also cause temporary inconsistencies.

2.6 specialized programs + message queuing to ensure message deletion

This scheme starts a subscriber to subscribe to the binlog of the database to get the data that needs to be operated. In the application, start another program, get the information from this subscriber, and delete the cache.

Specialized programs delete cache

The subscription binlog program has a ready-made middleware called canal in mysql, which can complete the function of subscribing to binlog logs. At this point, the study on "how to understand the double write consistency between database and cache" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.