A consistency problem
In a highly concurrent business scenarios, concurrent database users access most cases the weakest link. So, do you need to use a buffer redis operation, so the first request access to redis, rather than direct access to MySQL and other databases.
Read caching step is generally no problem, but when it comes to data update: update the database and cache, it is easy to data consistency between the cache (Redis) and database (MySQL) appears.
Whether the first to write MySQL database, and then delete Redis cache; or delete the cache, write libraries have data inconsistencies may occur. for instance:
1. If you delete the cache Redis, has not had time to write database MySQL, another thread to read, find the cache is empty, then go to the database to read data written to the cache, then the cache is dirty.
2. If the first to write a library before deleting cache, write down the thread library, not deleted the cache, data inconsistencies can also occur.
Because writing and reading are concurrent, can not guarantee the sequence, there will be inconsistencies in the data cache and database problems. Tathagata solve? Here are two solutions, the easier issues first, combining business and technology costs choose to use
Second, the cache and database consistency Solutions
2.1 Option One: using delay tactics double deletion
Before and after the write libraries were redis.del (key) operation, and set a reasonable time-out. Pseudo code
public void write( String key, Object data )
{
redis.delKey( key );
db.updateData( data );
Thread.sleep( 500 );
redis.delKey( key );
}
Concrete step is:
- Delete cache
- Write database
- Sleep 500 ms
- Delete the cache again
then, this 500 milliseconds how determined the specific sleep how long? Read data time-consuming need to assess the business logic of their own projects. The purpose of doing so is to ensure that the end of the read requests, write requests can delete cached read requests caused by dirty data.
Set the cache expiration time
, in theory, to set the cache expiration time, it is to ensure the consistency of the final solution. All writes to the database prevail, as long as the cache expiration time is reached, the read request back naturally read the new values from the database and then backfill the cache.
2.2 Option Two: asynchronous update cache (subscription-based binlog synchronization mechanisms)
An open source framework canal Ali Baba, provides a synchronization mechanism publish / subscribe model, we can use this framework for MySQL binlog subscription, so once in MySQL creates a new write, update, delete, etc., it can be pushed to the associated message binlog Redis, Redis binlog then the recording of Redis update. It is noteworthy that, binlog need to manually open and will not be recorded on the MySQL command and query operations.
In fact, this mechanism is very similar to the master-slave MySQL backup mechanism, because the MySQL data consistency standby is achieved by binlog. It mimics the canal slave database backup request, such that data update Redis reached the same effect.
