How to ensure the consistency between Redis cache and database

This article brings you relevant knowledge about Redis, which mainly introduces how to ensure the consistency of the redis cache and the database, including updating the cache and updating the database, etc. I hope everyone has to help.

Recommended learning: Redis learning tutorial

1. Four synchronization strategies:

Want to ensure caching Consistent with the double writing of the database, there are 4 ways, that is, 4 synchronization strategies:

1. Update the cache first, then update the database;
2. Update the database first, then update the cache;
3. Delete the cache first, then update the database;
4. Update the database first, then delete the cache.

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

Which method is more appropriate to update the cache or delete the cache? Should the database be operated first or the cache first?

2. Update the cache or delete the cache

Next, let’s analyze whether we should update the cache or delete the cache.

2.1 Update cache

Advantages:The cache is updated in time every time the data changes, so misses are less likely to occur during queries.

Disadvantages:Updating the cache consumes a lot of money. If the data needs to undergo complex calculations before being written to the cache, frequent updates to the cache will affect the performance of the server. If it is a business scenario where data is written frequently, there may be no business reading the data when the cache is frequently updated.

2.2 Delete cache

Advantages:The operation is simple. No matter whether the update operation is complicated or not, the data in the cache will be deleted directly.

Disadvantages:After deleting the cache, the next query cache will miss, and the database needs to be read again. From the above comparison, in general, deleting the cache is a better solution.

3. Operate the database or the cache first

Next, let’s analyze whether the database or the cache should be operated first.
First, we will delete the cache first and update the database first, and make a comparison when failure occurs:

3.1 Delete the cache first and then update the database

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

• Thread A deletes the cache successfully, but thread A fails to update the database;
• Thread B reads 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. Then the data is updated to the cache.
• In the end, the data in the cache and the database are consistent, but it is still the old data

##3.2 Update the database first and then delete the cache

As shown above, the database is updated first and then the cache is deleted. Problems that may occur when
fails:

Thread A updates the database successfully, thread A The cache deletion failed;
• Thread B read the cache successfully. Since the cache deletion failed, thread B read the old data in the cache.
• Finally, thread A deletes the cache successfully, and other threads access the same data in the cache, which is the same as the data in the database.
• Eventually, the cache and database data are consistent, but some threads will read the old data.

After the above comparison, we found that when

failure occurs, it is impossible to clearly distinguish which method is better: deleting the cache first or updating the database first, thinking that they are both better. There is a problem. We will further compare these two methods later, but here we first discuss how to solve the problems that arise in the above scenarios?

In fact, no matter which method we use above to synchronize the cache and the database, when the second step fails, it is recommended to

use a retry mechanism to solve the problem, in the above two pictures Already painted.

---

---

---

Next we will delete the cache first and update the database first, and compare

when there is no failure:
As shown above, the cache is deleted first and then the database is updated. When does not fail,
possible problems: <ul> <li>Thread A successfully deleted the cache; </li> <li>Thread B failed to read the cache;</li> <li>Thread B successfully read the database and obtained the old data;</li> <li>Thread B successfully updated the old data to the cache; </li> <li> Thread A successfully updated the new data to the database. </li> </ul> <p>It can be seen that the two steps of process A were successful, but due to concurrency, process B accessed the cache between the two steps. <strong>The end result is that the old data is stored in the cache, and the new data is stored in the database, and the two data are inconsistent. </strong></p> <hr> <hr> <p><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/067/e73f1a06231a665bb67debaa27b6baf0-3.png?x-oss-process=image/resize,p_40" class="lazy" alt="How to ensure the consistency between Redis cache and database"><br> As shown above, the database is updated first and then the cache is deleted. When <code> does not fail, possible problems:

• Thread A updates the database successfully;
• Thread B reads the cache successfully;
• Thread A deletes the cache successfully.

It can be seen that the final cache is consistent with the data in the database, and both are the latest data. But thread B read the old data during this process. There may be other threads like thread B that read the old data in the cache between these two steps, but because the execution speed of these two steps will be faster, So the impact is not big. After these two steps, when other processes read cached data, problems similar to process B will not occur.

Final conclusion:

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

4. Delayed double deletion

We mentioned above that if the cache is deleted first and then the database is updated, it may cause a problem when there is no failure. Data inconsistency. If in actual applications, we need to choose this method due to certain considerations, is there a way to solve this problem? The answer is yes, that is to adopt the strategy of delayed double deletion. The basic idea of ​​delayed double deletion is as follows:

1. Delete the cache;
2. Update the database ;
3. sleep N milliseconds;
4. Delete 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 to delete the inconsistent data in the cache. As for the specific time, you need to evaluate the approximate time of your business and set it according to this time.

4.1 What should we do if we adopt a read-write separation architecture?

If the database adopts a read-write separation architecture, then new problems will arise, as shown below:

At this time, two requests came, requesting A (update operation ) and request B (query operation)

1. Request A update operation, delete Redis;
2. Request the main library to perform an update operation, and the main library and the slave library to synchronize data ;
3. Please ask B for query operation and find that there is no data in Redis;
4. Go and get the data from the database;
5. At this time, the data synchronization has not been completed, and the data obtained It is old data;

The solution at this time is that if Redis is used to query the database for filling data, then it must be forced to point to the main database for query.

What should I do if the deletion fails?

If the deletion still fails, you can increase the number of retries, but this number must be limited. When it exceeds a certain number, measures such as reporting errors, recording logs, and sending email reminders must be taken.

5. Use message queue to compensate for deletion

Update the database first, then delete the cacheThis situation will also cause problems. For example, the database is updated successfully, but If an error occurs during the cache deletion stage and the deletion is not successful, then when reading the cache again at this time, the data will be wrong every time.

The solution at this time is to use the message queue to compensate for deletion. The specific business logic is described in the following language:

1. Request thread A to update the database first;
2. An error was reported when deleting Redis, and the deletion failed;
3. At this time, the Redis key is sent to the message queue as the message body;
4. The system deletes Redis again after receiving the message sent by the message queue;

But this solution will have a disadvantage, which is that it will cause a lot of intrusion into the business code and be deeply coupled together, so there will be an optimization method at this time. We know that the Mysql database is updated in the binlog after the operation. We can all find the corresponding operations, then we can subscribe to the binlog log of the Mysql database to operate the cache.

Recommended learning: Redis tutorial

The above is the detailed content of How to ensure the consistency between Redis cache and database. For more information, please follow other related articles on the PHP Chinese website!