Redis cache data consistency and problems

How to ensure the consistency of cache and database data

Cache data insertion timing ：
For the server ： Query data steps ：
1、 First, go to the cache to query the data , If the data exists, get the data directly and return
2、 If the cache does not exist , Need to query database , Get data from the database and insert it into the cache , Return the data to
3、 When the second query , Subsequent query operations can query cached data

When updating data ：
1、 First delete the cache and update the database
When updating database data , So let's delete the cache , Then update the database , When subsequent requests read data again , The data will be read from the database and updated to the cache
Existing problems ： After deleting the cache , Before updating the database , If there is a new request during this time period , The old data will be read from the database and written to the cache , Again, the data is inconsistent , And subsequent read operations are old data

2、 First update the database and delete the cache
Update operation , Update the database first , After success , Deleting cache , Subsequent requests write new data back to the cache
Existing problems ： to update MySQL And delete the cache , The requested read is still old data in the cache , But when the database update is complete , It's going to come back together

3、 Update cache asynchronously
After the database update operation is completed, the cache will not be operated directly , Encapsulate the operation command into a message and put it in the message queue , Then from Redis Update the data yourself , Message queuing ensures the consistency of data operation data , Ensure that the cached data is normal

The cache problem

Cache penetration - We can't find it

Concept ：
Cache penetration means that a user wants to query a data , Find out Redis There is no , That is, cache miss , It's like a persistent database initiating a query , It is found that the database does not have this data , So the query failed , When users request a lot , Cache miss , There's no data in the database , It will put a lot of pressure on the database , This is cache penetration

Solution ：
The first solution ： Using the bloon filter

After using the bloom filter , Put the stored data into the bloom filter , Each data query first queries the bloom filter , When the existence is judged in the filter, the query is cached in the database , If you do not enter the data query , If the filter does not exist , Then it directly returns to tell the user that the data cannot be found , This can greatly reduce the pressure of database query

Second option ： Caching empty objects
When the database data does not exist , Empty objects returned in time are also cached , Also set an expiration time , After that, the access data will be obtained from the cache , Protect the database
Existing problems ：
1、 Set expiration time for null values , There will be a period of time from updating the database data to invalidating the cached data , There is a problem with cached data , It will have an impact on the business that needs to ensure data consistency
2、 You will need more space to store more null values , A key that causes a large number of null values in memory

Cache breakdown - Too much , Cache expiration

Buffer breakdown refers to a key It's a hot spot key, Carrying a lot of concurrent , When key At the moment of failure , Continuous large concurrency will break through the cache , Request directly to the database . Cause instantaneous excessive pressure on the database

Solution ：
First option ： Hot data never expires
From a caching perspective , Expiration time is not set , There will be no problems after the cache expires

Second option ： Add mutex lock
Time use distributed lock , Guaranteed for every key Only one thread can query back-end services at the same time , Other threads that do not have access to the lock can wait

Cache avalanche

A cache avalanche is a time period , The cache set expires or Redis Downtime
For databases , All request pressures will reach the database , This leads to a surge in database calls , It may also cause database downtime

Solution ：
First option ：Redis High availability
The idea of this scheme is that the data is in Redis Is stored on the server , A server hangs up in time , Other servers can continue to work

Second option ： Current limiting the drop
This idea is after the cache expires , The number of threads reading the database is controlled by locking or queuing, and the threads are queued in the queue , Control the overall request rate

The third option ： Data preheating
Data preheating is timely before the deployment of services , First access the data , Most of the data can be loaded into the cache , Before the big concurrency happens, different key, Set different expiration times , Make cache invalidation time more uniform