Two years later, restart this blog. Familiar and a little unfamiliar, two years my technical direction has changed dramatically, but has been known to use notes, therefore these changes do not put on this blog now. The reason to restart the blog, mainly because the blog is an open thing, can bring some exchanges, but notes it is a personal thing, thinking the lack of collision. Gossip less Syria, which beginning.
Problem: how to maintain consistency with the cache database?
To answer this question, we first look at several cases inconsistent. I will not be consistent divided into three cases:
1. Database data, no data cache;
2. The database has data, the buffer has data, are not equal;
3. The database has no data, cache data.
Before discussing these three cases, I first explain the use of caching strategy, strategy is that most people use, called Cache Aside Pattern. Cool shell of cache update routine article, well worth reading, my strategy is also learned from him.
In short,
1. First, try to read from the cache, the data is read directly back; if not read, attend the database, and the data is written to the cache, and returns.
2. When the data needs to be updated, to update the database, then the corresponding cache data failed out (deleted).
Read logic we are very easy to understand, talk about the update. If you do not take this update method I mentioned, what else can you update method would have thought it? Probably it would be: to delete the cache, and then update the database. Problems caused by doing that, if A, B two threads at the same time to update the data, and A, B have already done this step to delete the cache, then, A to update the database, C thread reads the data, because the cache is not , then check the database and the updated data a, the write cache, B last database update. Then the value of the cache and the database will not match up.
In addition Some people may ask, if the method you mentioned, why the last is to delete the cached data, rather than the updated data is written to the cache. Doing so caused the problem is, if A, B two threads doing simultaneous data update, A to update the database, update the database after B, at this time the database is stored data B. And update the cache when it is B to update the cache, the cache is updated after A, the data A cache is. Such data cache and the database is also inconsistent.
According to this update the cache strategy I mentioned, there are also theoretically inconsistent risks, cool shell of the article mentioned, but the probability is very small, we can not consider being behind we have other means to remedy.
After discussing the use of caching strategies, we look at these three inconsistent.
1. For the first, when reading data, the data is automatically written to the database cache, and therefore automatically eliminate inconsistencies
2. For the second, final data becomes unequal, but at a certain time before they point the way must be equal (or whatever you use lazy loading preloaded, at that moment the cache load, and it certainly database consistent). This inconsistency, because you must update the data caused. Earlier we talked about strategy update data, to update the database, and then delete the cache. Therefore, the reasons for the discrepancy, the database must be updated, but delete the cache failed.
3. For the third, and a second similar case, you put the data in the database is deleted, but deleted when the cache failed.
Therefore, the final conclusion is inconsistent need to address the causes of success is to update the database, but the deleted cache miss.
I came up with solutions about the following:
The higher the consistency requirements 1. Delete Cache retry data, the more I retry quickly.
2. Regularly update the full amount, simply, that I regularly cleared away all the cache, then the full amount is loaded.
3. Give all of a cache expiration date.
The third option can be a big kill, any inconsistencies can be resolved by the expiration date, the shorter the expiration date, the higher the data consistency. But the shorter the expiration date, check the database will be more frequent. Therefore expiration date should be set according to the service.
Reprinted from: https://www.cnblogs.com/johnsblog/p/6426287.html