Headache delayed double deletion

I often see a problem redis and mysql There are several ways of data synchronization , Which is more applicable , Although personal feeling is not difficult , But sometimes I can't understand , So I made a summary , And the way of using diagrams is easy to understand .

redis and mysql There are five cases of data synchronization ：

1. Update the database , Update cache

2. Update cache , Update the database

3. Delete cache , Update the database

4. Update the database , Delete cache

5. Delete cache , Update the database , Delay deleting cache

1. Update the database , Update cache

The scene in the picture is a mysql and redis The initial values of the database are 10, user 1( Users above ) At this time, the update operation is performed , hold num Change to 9, here mysql The database is updated to 9, But before updating the cache, the user 2( The following users ) Query operation , At this time, the reading is redis The old value of is 10,mysql and redis Data inconsistency . In conclusion, it is step 2 And steps 3 Insert a thread access , In this way, we can better understand .

 2. Update cache , Update the database

This situation is similar to the first principle .

3. Delete cache , Update the database

First picture user 1 To update the data num=9, Perform step at this time 1 Delete cache ,redis Medium 10 Be deleted , But at this time, the user 2 Execute the query operation because redis It was deleted before, so I will query mysql, At this time mysql Because it hasn't been updated yet, the user 2 Got The value is still 10, And cache to redis in , Finally, perform the database update operation ,mysql The data becomes 9.mysql and redis Data inconsistency .

4. Update the database , Delete cache

Similar to the above , user 1 Request update operation num=9, Perform step at this time 1, Update the database ,mysql The value of the into 9, 

But at this time, the user 2 Query operation , Find out redis It's worth returning 10, Although at this time mysql and redis The data are inconsistent , But the last step 4, After deleting the cache, the data accessed by other threads is consistent , That is to say, this process is the final consistency , In the middle, only part of the data is out of sync , Is there a solution ？ Delayed double deletion can solve ！

 5. Delete cache , Update the database , Delay deleting cache

 

  Finally, it's time to delay double deletion ！ user 1 Update data num=9, Then follow the steps 2 Delete cache , At this time, the user 2 To query data , because redis The cache was deleted in the previous step , So search mysql Database access num=10, And cache to redis in , Then follow the steps 4 Update the database mysql obtain num=9, At this time, delay for a period of time before deleting the cache , The next time other users visit mysql The data in is synchronized to redis Achieve data synchronization ！ But due to the delay , Resulting in poor performance , Throughput is not high , Not suitable for high concurrency scenarios .

Why delay ？

Compare with the second picture , here redis No value , user 2 Go to query mysql database , Then return the value and build the cache , If you delete the cache directly instead of delaying it , Then it is possible that the return value construction cache has not been completed , In this case, delete the cache directly , And will turn from mysql Return value ( The old value ) Build cache , It is equivalent to having no effect . To put it bluntly , The purpose of delay is to let users 2 There is time to mysql The queried value is built to redis in , Only after it is built can it be deleted Ensure final redis No cache in .​​​​​​​

additional ：

MQ Retry mechanism  

Use canal

summary ： commonly redis and mysql Update the database before using data synchronization , Delete the cache again , Reach final consistency , Although delayed double deletion can ensure data consistency, it is not suitable for high concurrency scenarios due to the need for delay , In high concurrency scenarios, you can use MQ Retry mechanism , If deleting the cache fails, try again consistently , But high coupling . The low coupling solution is to use canal.canal Disguised as a mysql Slave of , Monitor host mysql Binary file , Send to... When data changes MQ.