The change of thinking of cache penetrating, cache concurrency and cache invalidation

When we use the cache, whether it is Redis or memcached, we basically encounter the following three issues: Cache-through-cache concurrency cache invalidation

First, the cache penetrates

Note:
What's wrong with the above three graphs?

Our use of caching in our projects is usually to check for the existence of the cache first, if there is a direct return to the cached content, and if it does not exist, query the database directly and then cache the query results back. This time if we query a certain data in the cache has not existed, it will cause each request to query the DB, so that the cache is meaningless, when the traffic is large, the db may be hung off.

So what's the best way to solve this problem?

If someone uses a nonexistent key to attack our application frequently, this is a loophole.
It is a clever practice to set a value in advance of this nonexistent key.
For example, "key", "&&".
When we return to this && value, our app can think of this as a nonexistent key, and our app can decide whether to continue to wait for access, or discard the operation. If you continue to wait for access, after a polling point, request this key again, if the value is no longer &&, then you can think that the key has a value, thus avoiding the upload to the database, so that a large number of similar requests in the cache.

Second, cache concurrency

Sometimes if the site concurrent access is high, if a cache fails, multiple processes may be querying the db at the same time, setting the cache situation, if the concurrency is really large, this can also cause the db too much pressure, there is frequent cache update problem.

My current idea is to lock the cache query, if the key does not exist, lock, then check the db into the cache, and then unlock, and other processes if the lock is found to wait, and then after the unlock to return data or into the DB query.

This situation is somewhat similar to the pre-set value problem just mentioned, except that the use of locks can cause some requests to wait.

Third, Cache invalidation

The main cause of this problem is high concurrency, usually when we set a cache expiration time, there may be some will be set to 1 minutes ah, 5 minutes of these, high concurrency may occur at a certain time at once generate a lot of cache, and the expiration time is the same, this time may be triggered when the expiration time, These caches fail at the same time, and all requests forwarded to the DB,DB may be overloaded.

So how to solve these problems?
One of the simple scenarios is that the cache expiration time is dispersed, for example, we can add a random value based on the original failure time, such as 1-5 minutes of random, so that each cache expiration time of the repetition rate will be reduced, it is difficult to trigger collective failure events.

The second issue we discussed when dealing with the same cache, the third issue is for many caches.

In summary:

1, Cache penetration: Query a certain non-existent data. For example, the article table, query a non-existent ID, each time access to the DB, if someone malicious damage, it is likely to directly affect the db.

2, Cache failure: If the cache is set to fail over time, the DB pressure is highlighted. There is no perfect solution, but you can analyze user behavior and try to make the failure time points evenly distributed.
When a large number of cache penetrations occur, such as large concurrent access to a failed cache, a cache avalanche is created.

Iv. Summary of all questions

1, question 1:
How to troubleshoot DB and cache consistency issues.
A: When the database has been modified, there is no timely modification of the cache. This kind of problem, has previously had the practice, modifies the database to succeed, but modifies the cache to fail the situation, most basically is the cache server hangs. And because the network problem caused by not updated in time, can be solved by the retry mechanism. When the cache server is hung up, the request is naturally unreachable, allowing direct access to the database. Then we cannot modify the cache after modifying the database, this time we can put this data into the database, and start an asynchronous task timed to detect whether the cache server is successful, once the connection is successful, the modified data is retrieved sequentially from the database, and then the updated values are cached.

2, Question 2:
Ask the cache to penetrate that block. For example, a user query article, through the ID query, as previously said, is to set the cached key preset a value, if through the ID plug in, found to be a predetermined value, such as "&&", then continue to wait for access to what is meant, When will this ID really be attached to the user's desired value?
A: I just said the main is we commonly used in the back of the configuration, the foreground to get the scene. The foreground cannot get the corresponding key, then wait, or discard. When the relevant key and value are configured on the background configuration interface, the previous key && will naturally be replaced. The kind of situation you're talking about, it's natural that there's a process that will set this ID in the cache at some point, and then get the latest ID and value when a new request arrives.

3, Question 3:
In fact, with Redis, see a good example of that day, double key, there is a then generated by a secondary key to identify the data modification due time, and then quickly to reload the data, if you think key can put the end time into the main key, secondary key to the function of the lock.
A: This scheme, we have practiced before. This scheme produces double data, and it needs to control the relationship between the attached key and key at the same time, which has a certain degree of complexity in operation.

4, Question 4:
What is the concept of multi-level caching?
A: Multi-level cache as I wrote before today, the article mentioned, will ehcache and Redis do level two cache, as I have written before the article http://www.jianshu.com/p/2cd6ad416a5a mentioned. But there will be consistency issues, if we need strong consistency, cache and database synchronization is a time lag, so we in the specific development process, must be based on the scene to specific analysis, two-level cache more solution is, cache penetration and the robustness of the program, when the central cache problems, Our app is able to continue running. Original: http://ifeve.com/concurrency-cache-cross/