How to ensure the double write consistency between cache and database?

At present, most high concurrency systems use redis+mysql Database to ensure high performance , So how is the process of updating cache and database realized ？

Catalog

Category

analysis

summary

expand - Delay double delete

Category

There are roughly four categories to achieve double write consistency between cache and database , Namely ：

① Update cache first , Update the database

② Update the database first , Update the cache again

③ So let's delete the cache , Update the database

④ Update the database first , Delete the cache

analysis

Two questions need to be considered ：① Which is more appropriate to update cache or delete cache ？② Should I operate the database or cache first ？

• Which is more appropriate to update cache or delete cache ？

        Advantages of updating cache ： Every data change is updated to the cache , Therefore, the query hit rate is high .

        Disadvantages of updating cache ： The consumption of updating the cache is relatively large . Update cache frequently , It will affect the database performance , If you write frequent business scenarios , Then it may be that the cache is updated frequently but not read much , There is no practical point in updating the cache .

        Advantages of deleting cache ： It's easy to operate , Delete the cached data directly .

        The disadvantage of deleting cache ： Delete cache , The next query will miss , You need to read from the database to the cache .

        Sum up , Deleting the cache will be better .

• Should I operate the database or cache first ？

        First, compare deleting the cache first with deleting the database first Failure situation ：

       ① So let's delete the cache , Update the database

         

1. process A Delete cache   - success
2. process A Update the database - Failure
3. process B The query cache , Found no , To query the database
4. process B Query the database - success
5. process B Update cache - success

      It can be seen that , The final cache and database data is Agreement Of , But the data It's the original data , It's not new .

     ② Update the database first , Delete the cache

1. process A Update the database - success
2. process A Delete database - Failure
3. process B The query cache - success   Failed to delete cache , The data is Old data

      It can be seen that , The final database and cached data is inconsistent .

      Because there are problems when they fail , I don't know which one will be better , But when the second step fails , We'll all do Retry mechanism Solve the problem of operation failure . The retry mechanism usually adds the operation to the message queue , Then perform asynchronous update .

      After adopting retry mechanism , Then let's compare them There was no failure Next Possible problems ：

     ① So let's delete the cache , Update the database

1. process A Delete cache - success
2. process B The query cache , Found no , Go to the database to query
3. process B Query the database - success , obtain Old data
4. process B Update cache - success , take Old data Update to cache
5. process A Update the database - success , take The new data Update to the database  

      We found that , Because between the two processes Concurrent operations , process A Both steps of the operation were successful , Between these two steps , process B Accessed cache . The end result is , Old data is stored in the cache , And the database stores new data , The two data are inconsistent .

    ② Update the database first , Delete the cache

1. process A Update the database - success
2. process B The query cache - success , But what I read is old data
3. process A Delete cache - success

      so , The final cache is consistent with the data in the database , And they are the latest data . but process B In this process, I read the old data , There may be other processes like process B equally , Between these two steps, I read the old data in the cache , But because the execution speed of these two steps will be faster , So it's not a big impact . After these two steps , When other processes read cached data again , There will be no process like B The problem. .

summary

Update the database first 、 Deleting the cache again is a solution with less impact . If the second step fails , Then the retry mechanism can be used to solve the problem .

expand - Delay double delete

Because of the situation just mentioned , So let's delete the cache , When there is no error in updating the database , Data inconsistency may also occur , Adopt delay double deletion to solve ：

1. Delete cache
2. Update the database
3. sleep n millisecond
4. Delete cache

After blocking for some time , Delete cache again , You can delete the inconsistent data in the cache in this process . And the specific time , To evaluate the approximate time and specific setting of your business .

And for updating the database first , Then delete the cache without error , There is also a possibility ：

The probability of this happening is very low , First of all The cache just failed There is a reading request at the moment of , And this The time for the read request to write back to the cache is longer than the time for updating the database , Normally, writing back to the cache is faster than updating the database .

If this extreme situation occurs , It also needs to adopt the delayed double deletion strategy , After updating the database, the cache will be deleted , here Open a new thread and wait n Delete the cache again in milliseconds , or Put the deletion request into the message queue , Ensure that the cache is new data , Or use message queuing to schedule messages , Delay deletion .