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

This article mainly shows you "how to ensure the consistency of Redis cache and database". The content is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to ensure the consistency of Redis cache and database".

1. Four synchronization strategies:

There are four ways to ensure that the cache is consistent with the double writes of the database, that is, there are four synchronization strategies:

Update the cache before updating the database

Update the database before updating the cache

Delete the cache before updating the database

Update the database before deleting the cache.

From these four synchronization strategies, what we need to compare is:

Which way is more appropriate to update the cache or delete the cache? Should you manipulate the database or the cache first?

2. Update cache or delete cache

Next, let's analyze whether the cache should be updated or deleted.

2.1 update cache

Advantages: update the cache every time the data changes, so it is not easy to miss when querying.

Disadvantages: the cost of updating the cache is high. If the data needs to be written to the cache after complex calculations, then frequently updating the cache will affect the performance of the server. If it is a business scenario where data is written frequently, it is possible that when the cache is updated frequently, no business reads the data.

2.2 Delete cache

Advantages: the operation is simple, regardless of whether the update operation is complex or not, the data in the cache is deleted directly.

Cons: after deleting the cache, the next query cache will miss, and you need to re-read the database. From the above comparison, in general, deleting the cache is the better solution.

3. Operate the database or cache first

Next, let's analyze whether we should manipulate the database or the cache first.

First, we will delete the cache first and update the database first to make a comparison in the event of a failure:

3.1 Delete the cache before updating the database

As shown in the figure above, the cache is deleted and then the database is updated. Problems that may occur in the event of failure:

Thread A successfully deleted the cache, and thread A failed to update the database

Thread B reads the data from the cache; because the cache is deleted, process B cannot get the data from the cache and then reads the data from the database; at this time, the data update in the database fails, and thread B successfully obtains the old data from the database, and then updates the data to the cache.

In the end, the data in the cache and the database are consistent, but they are still old data.

3.2 update the database before deleting the cache

As shown in the figure above, the database is updated first and then the cache is deleted. Problems that may occur in the event of failure:

Thread A updates the database successfully, and thread A fails to delete the cache

Thread B read the cache successfully, because the cache deletion failed, so thread B read the old data in the cache.

Finally, thread A deletes the cache successfully, and other threads access the same data as the data in the database.

In the end, the cache and database data are consistent, but some threads will read the old data.

After the above comparison, we find that when there is a failure, it is impossible to clearly distinguish which way is better to delete the cache first and update the database first, thinking that they are both problematic. Later, we will make a further comparison between the two methods, but let's first discuss how to solve the problems in the above scenarios.

In fact, no matter which method we use to synchronize the cache and the database above, it is recommended to use the retry mechanism when the second step fails, as already shown in the above two pictures.

Let's compare deleting the cache first with updating the database first when there is no failure:

As shown in the figure above, the cache is deleted and then the database is updated. Problems that may occur when there is no failure:

Thread A deleted cache successfully

Thread B failed to read cache

Thread B successfully reads the database and gets the old data

Thread B successfully updates the old data to the cache

Thread A successfully updates the new data to the database.

It can be seen that both steps of process An are successful, but because of concurrency, process B accesses the cache between these two steps. The end result is that old data is stored in the cache, while new data is stored in the database, and the two data are inconsistent.

As shown in the figure above, the database is updated first and then the cache is deleted. Problems that may occur when there is no failure:

Thread A updated the database successfully

Thread B read cache successfully

Thread A successfully deleted the cache.

It can be seen that the final cache is consistent with the database data, and are all up-to-date data. However, thread B reads the old data in this process, and there may be other threads that, like thread B, read the old data in the cache between these two steps, but because the execution speed of these two steps is faster, it does not have much impact. After these two steps, when other processes read the cached data, there will be no problems similar to process B.

Final conclusion:

After comparison, you will find that updating the database first and then deleting the cache is a less influential solution. If the second step fails, you can use the retry mechanism to solve the problem.

4. Delay double deletion

As mentioned above, if you delete the cache first, and then update the database, it may lead to data inconsistency when there is no failure. If in practical application, we need to choose this way for some reasons, is there a way to solve this problem? The answer is yes, that is, the strategy of delayed double deletion is adopted. The basic ideas of delayed double deletion are as follows:

Delete cach

Update the database

Sleep N millisecond

Delete the cache again.

Public void write (String key, Object data) {Redis.delKey (key); db.updateData (data); Thread.sleep (1000); Redis.delKey (key);}

After blocking for a period of time, delete the cache again, and you can delete the inconsistent data in the cache in the process. For the specific time, to evaluate the approximate time of your business, you can set it according to this time.

4.1 what should I do if I adopt a read-write separation architecture?

If the database uses a read-write separation architecture, new problems will arise, as shown in the following figure:

There are two requests, request A (update operation) and request B (query operation)

Request A update operation, deleted Redis

Request the master database to enter the update operation, and the master database synchronizes the data with the slave database.

Let B query operation and find no data in Redis

To get the data from the library.

At this time, the synchronization data has not yet been completed, and the data obtained is old data.

The solution at this point is to force the Redis to point to the main database query if it is to populate the database with data.

What if the deletion fails?

If the deletion still fails, you can increase the number of retries, but the number of retries should be limited. When the number of times is exceeded, measures such as error reporting, logging, and email reminders should be taken.

5. Compensation for deletion using message queue

There will also be problems in the case of updating the database first and then deleting the cache. For example, if the database is updated successfully, but the deletion is not successful at the stage of deleting the cache, then every time you read the cache, it will be the wrong data.

At this point, the solution is to make use of message queuing for deletion compensation. The specific business logic is described as follows:

Request thread A updates the database first.

An error was found when deleting the Redis, and the deletion failed.

At this point, the key of Redis is sent to the message queue as the message body.

The system deletes the Redis again after receiving the message sent by the message queue.

However, the drawback of this solution is that it will cause a large number of intrusions into the business code, which is deeply coupled, so there will be an optimization method at this time. We know that we can find the corresponding operation in the binlog log after the update operation of the Mysql database, so we can subscribe to the binlog log of the Mysql database to operate on the cache.

The above is all the contents of the article "how to ensure the consistency of Redis cache and database". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, 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.