How to keep database and cache consistent

The server access speed is getting worse , How to solve

Add... To the server Redis, Let it be the cache of the database
This means that when the customer requests data , If you can hit data in the cache , Query cache , No need to check the database , So as to reduce the pressure of the database , Improve server performance

Update the database first or update the cache first

1. Update the database first , Update the cache again
   
2. Update cache first , Update the database
   

Because of concurrency , Both of these methods may cause inconsistency between database and cache data

Do not update cache , The strategy of deleting the cache

Cache Aside Strategy （ Bypass cache strategy ）： Do not update cache , Instead, delete the data in the cache , When reading data , If there is no data in the cache , Then read data from the database , Update to cache
Reading strategy ：
If the read data hits the cache , Then directly return the data
If the read data does not hit the cache , Read data from the database , Then write the data to the cache , And back to the user
Write strategy ：
Update the data in the database
Delete data in cache

The write strategy is to update the database first , Delete cache after , Delete the cache first , Update the database after

So let's delete the cache , Update the database after
A To update database values ,B To read this value
After deleting the cache on write , Cache misses when there are read requests , Will be updated to the old database value , Then the database is updated
When reading + When writing concurrent , The cache and database are inconsistent

Update the database first , Delete cache after
The value does not exist in the cache ,A To read this value , When the cache is not written ,B To update this value
Because cache writes tend to be faster than database writes , It is very difficult to appear in practice B The database has been updated and the cache deleted , request A Is updated to the cache
Data consistency can be guaranteed
To make sure that there is no risk , You can also add... To the cached data Expiration time , Ensure the final consistency of cached data

Update the database first , Delete cache after , This will affect the hit rate of the cache

If the business has high requirements for hit rate , May adopt Update the database + Update cache The plan , Because there will be no cache miss when updating the cache
But if two threads update them concurrently , The data will be inconsistent due to the different writing order
resolvent ：

1. Before cache update , First plus Distributed lock
   Ensure that only one request is run at the same time to update the cache , There will be no concurrency problems , But with the introduction of locks , Impact on write performance
   2. When the cache is updated , Add a shorter expiration time to the cache
   Even if cache data is inconsistent , Cached data will also expire very quickly , It's acceptable for business

Yes So let's delete the cache , Update the database after The solution to the concurrency problem —— Delay double delete

Delete cache
Update the database
sleep
Delete database

It is difficult to specify the specific sleep time , This method can only guarantee consistency as much as possible , It is recommended to update the database first , Then delete the cache scheme

Update the database first , Delete the cache , There may be a problem that deleting the cache failed

If delete cache fails , This will cause inconsistency between the database and the cache
Old database values , Cache save new value
If the cache has an expiration time , From the user's perspective , The data updated by the user is not changed immediately , It took a while for the changes to occur

Since deleting the cache may fail , How to ensure that both operations can be performed successfully

Adopt asynchronous operation cache

1. Retry mechanism
2. subscribe Mysql binlog, Reoperation cache

1. Retry mechanism

Message queues can be introduced , The second operation （ Delete cache ） The data to be manipulated is added to the message queue . Consumers manipulate data
Delete cache failed ：
Adopt retry mechanism , Reread data from the message queue , Then delete the cache again
If the number of retries exceeds a certain number of times , It is necessary to report errors to the business level
Delete cache succeeded ：
Remove data from the message queue , Avoid repetition

2. subscribe Mysql binlog, Reoperation cache

Update the database first , When the database is updated successfully , A change log will be generated , Recorded in the binlog in
We can subscribe binlog journal , Get the specific data to operate , Then perform cache deletion
Alibaba open source Canal Middleware is based on this implementation
Canal simulation MySQL Master slave replication interaction protocol , Disguise yourself as a MySQL The slave node , towards Mysql The master node sends dump request ,Mysql Upon receipt of the request , It's going to start pushing Binlog to Canal,Canal analysis Binlog After byte stream , Convert to easy to read structured data , For downstream application subscription