Cause of demand
In high-concurrency business scenarios, the database is in most cases the weakest link for concurrent user access. Therefore, you need to use redis to perform a buffering operation so that the request can access redis first instead of directly accessing databases such as MySQL.
This business scenario mainly solves the problem of reading data from Redis cache. Business operations are generally carried out according to the process in the figure below.
There is generally no problem in reading the cache step, but once data updates are involved: database and cache updates, data consistency issues between the cache (Redis) and the database (MySQL) are prone to occur.
Whether you write the MySQL database first and then delete the Redis cache; or delete the cache first and then write to the database, data inconsistency may occur. As an example:
1. If the Redis cache is deleted and another thread comes to read before it has time to write to the database MySQL, and finds that the cache is empty, it reads the data from the database and writes it to the cache. At this time, the cache contains dirty data.
2. If the library is written first, and the thread writing the library crashes before the cache is deleted, and the cache is not deleted, data inconsistency will also occur.
Because writing and reading are concurrent and the order cannot be guaranteed, there will be data inconsistency between the cache and the database.
Tathagata solves it? Here are two solutions, easy first and then difficult, chosen based on business and technical costs.
Cache and database consistency solution
1. The first option: adopt delayed double deletion strategy
Perform the redis.del (key) operation before and after writing the library, and set a reasonable timeout.
The pseudo code is as follows
public void write（String key,Object data）{
redis.delKey(key);
db.updateData(data);
Thread.sleep(500);
redis.delKey(key);
}
2. The specific steps are:
1) Delete the cache first
2) Write the database again
3) Sleep for 500 milliseconds
4) Delete cache again
So, how is this 500 milliseconds determined, and how long should it sleep for?
You need to evaluate the time-consuming data reading business logic of your project. The purpose of this is to ensure that the read request ends, and the write request can delete the cached dirty data caused by the read request.
Of course, this strategy also needs to consider the time-consuming synchronization between redis and database master-slave. The final sleep time for writing data: Add a few hundred milliseconds to the time it takes to read data business logic. For example: sleep for 1 second.
3. Set cache expiration time
Theoretically, setting an expiration time for the cache is a solution to ensure eventual consistency. All write operations are subject to the database. As long as the cache expiration time is reached, subsequent read requests will naturally read new values from the database and backfill the cache.
4. Disadvantages of this plan
Combined with the double delete strategy and the cache timeout setting, the worst case scenario is that the data is inconsistent within the timeout period, and it also increases the time it takes to write the request.
2. The second solution: asynchronous update cache (synchronization mechanism based on subscribing to binlog)
1. Overall technical idea:
MySQL binlog incremental subscription consumption message queue incremental data update to redis
1) Read Redis: Hot data is basically in Redis
2) Writing MySQL: Addition, deletion and modification are all operations on MySQL
3) Update Redis data: MySQ data operation binlog to update to Redis
2.Redis update
1) Data operations are mainly divided into two blocks:
One is full (write all data to redis at once)
One is incremental (real-time update)
What we are talking about here is increment, which refers to the update, insert and delete change data of mysql.
2) After reading the binlog, analyze it, and use the message queue to push and update the redis cache data of each station.
In this way, once new write, update, delete and other operations occur in MySQL, binlog-related messages can be pushed to Redis, and Redis will update Redis based on the records in the binlog.
In fact, this mechanism is very similar to MySQL's master-slave backup mechanism, because MySQL's master-slave backup also achieves data consistency through binlog.
Here you can use canal (an open source framework of Alibaba) in combination, through which you can subscribe to MySQL's binlog. Canal imitates the backup request of mysql's slave database, so that Redis's data update achieves the same effect.
Of course, for the message push tool here, you can also use other third parties: kafka, rabbitMQ, etc. to implement push updates to Redis.
The above is the detailed content of Redis cache and MySQL data consistency methods. For more information, please follow other related articles on the PHP Chinese website!