Whether the first to write MySQL database, and then delete Redis cache; or delete the cache, write libraries have data inconsistencies may occur. As an example:
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.
Delay time expired double deletion +
During the operation of the library before and after the write cache operations are carried deleted
1) to delete the cache: In order to read the data not read other threads, to take the database
2) write database
3) Sleep n milliseconds: For the second time after the thread to prevent deletion, while another thread is reading the contents of the database before writing data in the thread, resulting in data cache is write from the other thread came in, so it has been a dirty the data.
4) delete the cache again
How to determine the number of milliseconds to sleep
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.
Of course, this strategy should also be considered time-consuming and redis database master-slave synchronization. The final write data of the sleep time: the time-consuming foundation in reading data on the business logic, we can add a few hundred ms. For example: Sleep one second.
Malpractice
Such worst-case scenario is that there is inconsistency (unavoidable), but also added a time-consuming written requests (delay caused dormancy and can be opened by the second thread delete data within the timeout period, so the current request does not there are additional delay).
Asynchronous update the cache
1. Technical whole idea:
MySQL binlog incremental subscription message queue consumption + + incremental data updates to redis
1) Read Redis: thermal data substantially in Redis
2) write MySQL: MySQL CRUD operations are
3) Update Redis data: MySQ data manipulation binlog, to update the Redis
2.Redis update
1) the operation data is divided into two blocks:
- It is a total amount (all data to the write-once Redis)
- One is the incremental (live update)
Here that is incremental, referring to the mysql the update, insert, delate change data.
2) After reading binlog analysis, using message queues, push updates cache data of each redis station.
Once such a MySQL generated new write, update, or delete operation, it can be pushed to the associated message binlog Redis, Redis binlog then the recording of Redis update.
In fact, this mechanism is very similar to the master-slave MySQL backup mechanism, because the MySQL data consistency standby is achieved by binlog.
Here can combine canal (Ali, an open source framework), you can subscribe to the MySQL binlog through the frame, while the canal is the imitation of a backup request slave mysql database, so the data update Redis reached the same effect.
Of course, here the message push tool you can use other third party: kafka, rabbitMQ push updates, etc. to achieve Redis.