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

In this article, the editor introduces in detail "how to solve the double writing problem of Redis and MySQL". The content is detailed, the steps are clear, and the details are handled properly. I hope that this article "how to solve the double writing problem of Redis and MySQL" can help you solve your doubts.

Write at the front

Strictly speaking, any non-atomic operation can not guarantee consistency unless blocking read and write is used to achieve strong consistency, so the goal of cache architecture is the ultimate consistency.

Caching improves performance at the expense of strong consistency.

This is determined by CAP theory. The caching system is suitable for scenarios with non-strong consistency, which belongs to AP in CAP.

The following three cache read and write strategies have their own advantages and disadvantages, and there is no best.

Three read-write caching strategies Cache-Aside Pattern (bypass cache mode)

Cache-Aside Pattern, that is, bypass cache mode, is proposed to solve the data inconsistency between cache and database as much as possible.

Read: read data from the cache and read to return directly. If it cannot be read, it is loaded from the database, written to the cache, and the response is returned.

Write: when updating, update the database before deleting the cache.

Read-Through/Write-Through (read-write penetration)

In Read/Write Through Pattern, the server regards cache as the main data store, reading data from it and writing data into it. The cache service is responsible for reading and writing this data to DB, thus relieving the application of its responsibility.

Because the distributed cache Redis that we often use does not provide the ability for cache to write data to DB, it is not used much.

Write: first check that cache,cache does not exist, directly update DB. If it exists in the cache, the cache is updated first, and then the cache service itself updates the DB (synchronously updating cache and DB).

Read: read the data from cache, read it and return it directly. If it cannot be read, it is loaded from DB, written to cache, and then the response is returned.

Write Behind Pattern (asynchronous cache writes)

Write Behind Pattern is similar to Read/Write Through Pattern in that both cache services are responsible for reading and writing cache and DB.

However, the two are very different: Read/Write Through updates cache and DB synchronously, while Write Behind Caching only updates the cache, not DB directly, but updates DB in asynchronous batches instead.

Obviously, this approach poses a greater challenge to data consistency. For example, if the cache data may not be updated DB asynchronously, the cache service may be dead, which will lead to a greater disaster.

This strategy is also very rare in our usual development process, but it does not mean that it has few application scenarios, such as asynchronously writing messages to disk in message queues and MySQL's InnoDB Buffer Pool mechanism.

The write performance of DB under Write Behind Pattern is very high, which is very suitable for scenarios where data changes frequently and requires less data consistency, such as pageviews and likes.

Some questions about the parsing of Cache Aside Pattern by bypass cache mode

Bypass caching mode is the one we use most often. Based on the bypass caching mode described above, we can have the following questions.

Why the write operation is to delete the cache instead of updating it

Answer: thread A first initiates a write operation, and the first step is to update the database. Thread B initiates another write operation, and the second step updates the database. Due to network and other reasons, thread B updates the cache first, and thread A updates the cache.

At this time, the cache saves A's data (old data), the database saves B's data (new data), the data is inconsistent, dirty data appears. This dirty data problem does not occur if you delete the cache instead of updating the cache.

In fact, it is possible to update the cache when writing, but we need to add a lock / distributed lock to ensure that there are no thread safety issues when updating the cache.

In the process of writing data, why update the DB before deleting the cache

A: for example, request 1 is a write operation. If you delete cache A first, request 2 is a read operation, read cache A first, and find that the cache has been deleted (deleted by request 1), and then read the database. But before request 1 updates the data in time, request 2 reads the old data, and request 2 will also put the read old data in the cache, resulting in data inconsistency.

In fact, it is possible to delete the cache first, and then update the database, such as using delayed double deletion strategy.

Sleep for 1 second and eliminate the cache again. By doing so, the cache dirty data caused by 1 second can be deleted again. It doesn't have to be 1 second, depending on your business decision, but this practice is not recommended, because there are many factors that may happen in this 1 second, and it is too uncertain.

In the process of writing data, is it no problem to update DB first and then delete cache?

A: theoretically, there may still be data inconsistencies, but the probability is very small.

Suppose there are two requests, one for A to do the query operation and the other for B to do the update operation, then the following situations will occur

(1) the cache just expires

(2) request A to query the database to get an old value.

(3) request B to write the new value to the database

(4) request B to delete the cache

(5) request A to write the checked old value to the cache ok. If this happens, dirty data will indeed occur.

However, the probability of this happening is not high.

There is a congenital condition for the occurrence of the above situation, that is, the writing operation of step (3) takes less time than the read operation of step (2), which makes it possible for step (4) to precede step (5).

However, if you think about it, the speed of the read operation of the database is much faster than that of the write operation (otherwise, why else do read-write separation? the meaning of doing read-write separation is because read operations are faster and consume less resources), so step (3) takes less time than step (2). This situation is difficult to happen.

Are there any other causes of inconsistency?

A: if you fail to delete the cache, it will cause inconsistency.

How to solve?

Use Canal to subscribe to the binlog of the database to get the data you need to operate. Start another program, get the information from this subscriber, and delete the cache.

Defects of Cache Aside Pattern

Defect 1: the problem that the first request data must not be in cache

Solution: hot spot data can be put into cache in advance.

Defect 2: frequent write operations cause the data in the cache to be deleted frequently, which will affect the cache hit rate.

Strong consistency between database and cache data: update cache when updating DB, but we need to add a lock / distributed lock to ensure that there are no thread safety problems when updating cache. You can briefly allow scenarios where the database and cache data are inconsistent: update the cache when you update the DB, but add a relatively short expiration time to the cache to ensure that the impact is small even if the data is inconsistent.

After reading this, the article "how to solve the double-writing problem of Redis and MySQL" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, welcome to follow the industry information channel.

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.