Double write consistency of MySQL and redis

What is the double write consistency problem ？

Look at us first redis Read process ：

（1） First reading cache, If the data hits, it returns
（2） If the data misses, read db
（3） take db The data read out in the cache

Strategy 1: Update cache first , Update the database
If the update cache succeeds, the database update fails , Then it will cause cache dirty data

Strategy 2: Update the database first , Update the cache again
This happens in high concurrency ：

Threads A New database , Because of the Internet or something , At this time, there is no time to update the cache , The thread updates the database , And updated the cache , however A New cache . Cause our thread B New lost

Strategy 3: So let's delete the cache , Update the database

Delete the cache first and then update the database , This is the mitigation strategy 2 Cache update loss of , But it may still be inconsistent

A To delete the cache ,B Read operation , Discover again redis No hits in , therefore B The thread is going to read from the database , And write this data to redis in , Then the thread A Finish updating the database , Database and redis Cache inconsistency

How to solve ：
Just in the thread A After updating the database , And then delete One cache , This is called delayed double deletion , The delay time here must be greater than the reading time of our business

Strategy 4: Update the database first , Delete the cache

When we A Query data , Preparing to write to the cache , Threads B Updated database , Then the cache is deleted , then A Before writing the previous old value to redis. The probability of occurrence is very low , Because the write operation time is more likely than the read operation time

resolvent ：
Delay double delete , But what if the deletion fails ？
Then it will be deleted repeatedly , We can delete key Put in queue , Then repeat the attempt to delete , Until success