Go zero micro Service Practice Series (VI. cache consistency assurance)

As long as we use caching , You will inevitably face the consistency problem between the cache and the database . If the data in the cache is inconsistent with the data in the database , Then the data read from the cache by the business application is not the latest data , The impact on the business can be imagined . For example, we store the inventory data of commodities in the cache , If the inventory data in the cache is incorrect , It may affect the order placing operation , This is difficult to accept in business . In this article, let's talk about cache consistency .

How to solve cache inconsistency

Delete the cache before updating the database

Assuming that thread A After deleting the cache , I haven't had time to update the database yet , At this point, the thread B Start reading data , Threads B If you find that the cache is missing, you can only read the database , Wait until the thread B After reading the data from the database back to the cache , Threads A Just started updating the database , here , The data in the cache is old , And the database is the latest value , The two have been inconsistent .

The solution to this scenario is in the thread A After updating the database values , You can make it sleep For a short time , Do another cache delete operation , Why add sleep For a while , Just to make the thread B It can read and fetch data from the database first, and then cache it miss Data back into the cache , Then the thread A Then delete . So threads A Of sleep The time needs to be greater than the thread B The time to read data and then write it to the cache . How much time is it ？ We need to add management monitoring to the business to make statistics , Estimate the time based on this statistic . thus , When other threads read data , You will find that the cache is missing , Will read the latest value from the database . We call this model " Delay double delete ".

First update the database and then delete the cache

If the thread A Updated the value in the database , But I haven't had time to delete the value in the cache , Threads B At this time, the data is read , here , Threads B When querying the cache , Hit cache , The values in the cache will be used directly , The value is old . But in this scenario , If the number of concurrent requests is not high , In fact, almost no thread will read the old value , And threads A After updating the database , Deleting the cache is a very fast operation , therefore , The overall impact on the business is small . Generally in the production environment , This mode is also recommended .

Retry mechanism

You can put the cache value to be deleted or the database value to be updated into the message queue , When the application fails to successfully delete the cache or update the database value , These values can be consumed from the message queue , The service that consumes the message queue here is called job, Then delete or update again , Play a role of bottom compensation , So as to ensure the final consistency .

If you can successfully delete or update , You need to remove these values from the message queue , So as not to repeat the operation , here , We can also ensure the consistency between the database and the cached data , Otherwise , We need to try again , If the retry exceeds a certain number of times, it still fails , At this time, it is generally necessary to record the error log or send an alarm notification .

Concurrent reading and writing

The first step is to thread A Read cache , At this time, the cache misses , Because of the use of cache aside This model , So the next step is to thread A I can read the database , At this point the thread B Update the database , After updating the database, you can use set cache Updated cache , Finally, step 5: thread A Read the value from the database through set cache Also updated the cache , But this time the thread A The data in is already dirty , Since the fourth and fifth steps are to set the cache , Causes written values to overwrite each other , And the sequence of operations is uncertain , This leads to cache inconsistencies .

How to solve this problem ？ It's actually very simple , We just need to take step five set cache Replace the operation with add cache that will do ,add cache namely setnx operation , Only when the cache does not exist will it be successfully written , It is equivalent to adding priority , That is, the update cache priority after updating the database is higher , However, the priority of the rollback cache after reading the database is lower , This ensures that the latest data of the write operation will not be overwritten by the data of the read operation .

Conclusion

This article explains one of the most common problems encountered when using caching , That is, the cache is inconsistent with the database , To solve this problem, we listed some scenarios that may lead to inconsistencies and solutions for corresponding scenarios , Specially , about job For the asynchronous compensation scenario, we can use set Operation to forcibly overwrite the cache , Ensure that the cache is updated to the latest data , For the operation of reading the database back plug cache, we generally use add To update the cache .

I hope this article can help you , thank you .

Every Monday 、 Thursday update

Code warehouse : github.com/zhoushuguan…