1, most primary cache inconsistencies as well as solutions to
the problem: to modify the database, and then delete the cache, if you delete the cache fails, the database will lead to new data, the cache is old data, data inconsistency.
Solution:
delete the cache, and then modify the database, if you delete the cache succeeded modify the database fails, then the database is old data, the cache is empty, then the data is not inconsistent, because when the cache is not read, then read database the old data, then update to the cache.
2, under the concurrent analysis of data cache inconsistency
problems:
the first request data is changed, first delete the cache, and then go to modify the database at this time have not had time to modify;
the second request came to read cache, the cache was found empty , and to query the database, found the old data before modification, into the buffer;
the third request to read data in the cache (in this case a request has completed a first modification of database operations).
Over, and cache data in the database is not the same. . . .
Analysis:
Only for concurrent read and write data in the same time, it may face this problem. In fact, if you say the words of concurrency is very low, especially in low concurrent read access per day to 10,000, then a few cases, the kind of inconsistency scene just described will appear; but if that day on million flow, tens of thousands of concurrent reads per second, per second as long as there is a request to update the data, it may be above + database cache inconsistencies.
Solutions
database cache update serializes read operations, a queue corresponding to a worker thread, each worker thread to get the corresponding serial operation, then a one is performed.
1. First, we maintain a set of items in the queue.
2. When updating data, based on the unique identification data jvm route the request to a queue, to update the database, then the end of the request.
3. The read data when the first check the cache, if the data is not found in the cache, then in accordance with the following unique identification routes and transmits the same jvm internal queue, re-read the database to update the cache, the final end of the request.
There is a need to optimize a point, such as a queue, there are a plurality of continuous update cache request is meaningless string together, so that duplicate query the database and to update the cache should be optimized operation: If it is found in the queue has a cache update request, then one would not recapture the update request into operation, a read request directly to the back of a blockage about 200ms (here is just an example, the actual value may be calculated based on the service response time and processing capability of the machine), then again query cache, the cache if there is no value to check the database without updating the cache get the result, returned directly to the page.