On the best moves of cache penetration, cache concurrency, hotspot caching

First, preface

In the past, a cache penetration, cache concurrency, cache failure of the idea of change in the article introduced some common ideas about cache penetration, concurrency, but the personal feeling of the article does not have a clear idea of the use of the scene, this article will continue to deepen the discussion with you, but also very grateful for this period of time to my valuable suggestions of friends.

Description: The cache mentioned in this article can be understood as redis. second, cache penetration and concurrency scenarios

I believe many of my friends have read a lot of similar articles before, but in the final analysis, there are two questions: how to solve the concurrency

When the concurrency is high, in fact, I do not recommend the use of cache expiration policy, I would like to cache always exist, through the background system to update the data in the cache system to achieve consistency of data, some friends may be questioned if the cache system hangs, so that the database updated but the cache is not updated, The state of consistency is not reached.

the problem-solving approach is :
If the cache is because the network problem does not update the success of the data, it is recommended to retry several times, if the update is still not successful, the cache system error is not available, the client will be the data key into the message system, the message system can filter the same key, just to ensure that the message system does not exist the same key, When the cache system is available for recovery, remove the key value from MQ and then read the latest data update cache from the database.
Note : There is still old data in the cache before the cache is updated, so it does not cause the cache to penetrate.

The following diagram shows the whole idea of the process:

After reading the above plan, there will be many friends to ask questions, if I am the first time to use the cache or cache in the absence of the data I need, then how to deal with it.

problem-Solving ideas :
In this scenario, the client reads the data from the cache according to the key, and if the data is read the process ends, if the data is not read (there may be more than one concurrency to read the data), then the Setnx method in the cache system is used to set a value (this method is similar to a lock) Failed to set a successful request then sleep for a period of time, set a successful request to read the database to get the value, if the fetch to update the cache, the process is over, before the sleep request to wake up directly from the cache to read the data, the process is over.

After reading this process, I think there will be a loophole, if the database does not have the data we need to deal with, if not processing the request will cause a dead loop, constantly in the cache and database query, That's when we're going to follow my previous article. If you do not read the data, insert a NULL string into the cache so that other requests can be processed directly on a "null" basis until the backend system synchronously updates clean NULL data and updates the cache after the database has successfully inserted the data.

The flowchart is as follows:

Summary:
In practice, we tend to combine the above two scenarios to achieve the best results, although the second scenario will also cause request blocking, but only when the first use or cache temporarily no data to be generated, in production is tested in the TPS is not tens of thousands of cases will not cause problems. third, hotspot cache solution 1. Cache Usage Background:

Let's take a case from the user Center to illustrate:
Each user will first get their own user information, and then do other related actions, there may be some scenarios such as: There will be a large number of the same user repeatedly access the project. The same user will have frequent access to the same module. 2. Analysis of Ideas

Because the user itself is not fixed and the number of users also have millions of especially tens of millions, we can not all the user information cached, through the first scenario to see a number of rules, that is, there are a large number of the same user repeated access, but exactly which users are repeated access we do not know.

If there is a user frequently refresh read items, then the database itself will be a great pressure, of course, we will have the relevant protection mechanism to do malicious attacks, can be controlled from the front, or can be blacklisted and other mechanisms, here is not to repeat. If we use the cache, how can we control the same user's heavy read user information?

Take a look at the following picture:

We will make a sort queue through the cache system, such as 1000 users, the system will update the user's information according to the user's access time, the more recently visited the ranking of the users, the system will periodically filter out the last 200 users, and then randomly removed from the database 200 users to join the queue, Each time the request arrives, the user information is fetched from the queue, and if the hit is based on the UserID, the user information is read from another cached data structure, which indicates that the user request is not high if there is no hit.

the Java pseudo-code looks like this:

       for (int i = 0; I < times; i++) {user = new Externaluser ();
            User.setid (i+ "");
            User.setupdatetime (New Date (System.currenttimemillis ()));
            Cacheutil.zadd (SortKey, User.getupdatetime (). GetTime (), User.getid ());
        Cacheutil.putandthrowerror (Userkey+user.getid (), json.tojsonstring (user));
        } set<string> Userset = Cacheutil.zrange (SortKey, 0,-1);
        System.out.println ("[SortedSet]-" + json.tojsonstring (userset));

        if (Userset = = NULL | | userset.size () = = 0) return;
        set<tuple> usersets = cacheutil.zrangewithscores (SortKey, 0,-1);
        StringBuffer sb = new StringBuffer (); for (Tuple t:usersets) {sb.append ("{member:"). Append (T.getelement ()). Append (", Score:"). Append (T.getscore ()).
        Append ("},");

        } System.out.println ("[Sortedcollect]-" + sb.tostring (). substring (0, Sb.length ()-2)); Set<string> Members = new Hashset<string> ();
            for (string uid:userset) {string key = UserKey + uid;
            Members.add (UID);
            Externaluser user2 = Cacheutil.getobject (key, Externaluser.class);
        System.out.println ("[User]-" + json.tojsonstring (user2));

        } System.out.println ("[User]-" + system.currenttimemillis ());
        String[] keys = new string[members.size ()];

        Members.toarray (keys);
        Long rem = Cacheutil.zrem (SortKey, keys);
        System.out.println ("[REM]-" + REM);
        Userset = Cacheutil.zrange (SortKey, 0,-1); System.out.println ("[Remove-sortedset]-" + json.tojsonstring (userset));