What are the techniques used by Redis and local cache


This article mainly introduces the skills used by Redis and local cache. In daily operations, I believe many people have doubts about the skills used by Redis and local cache. The editor consulted various materials and sorted them out. Here is a simple and easy-to-use operation method, and I hope it will be helpful for you to answer your doubts about the skills used by Redis and local cache! Next, please follow the editor to learn together!

Three kinds of cache usage scenarios

This part will introduce the usage scenarios and limitations of redis, such as Guava's LoadingCache and Kuaishou open source ReloadableCache. What kind of cache should be used in what business scenario, and why.

Usage scenarios and limitations of Redis

If you broadly say when redis is used, then it is naturally used in places with too many user visits, thereby speeding up access and alleviating database pressure . If subdivided, it is also divided into single-node problems and non-single-node problems.

If a page has a relatively high number of user visits, but the access is not the same resource. For example, the user details page has a relatively high number of visits, but the data of each user is different. In this case, it is obvious that only distributed caching can be used. If redis is used, the key is the unique key of the user, and the value is the user information.

Cache breakdown caused by redis.

But you need to pay attention to one thing, you must set the expiration time, and it cannot be set to expire at the same time. For example, if the user has an event page, the event page can see the user's award-winning data during the event. Careless people may set the expiration time of the user data to the end of the event, which will

Single (hot) point problem

The single node problem refers to the concurrency problem of a single node of redis, because the same key will fall on the same node of the redis cluster, then if the If the access volume of this key is too high, then there is a hidden danger of concurrency in this redis node, and this key is called a hot key.

If all users access the same resource, for example, the homepage of the Xiaoai classmate app shows the same content to all users (initial stage), and the server returns the same big json to h6, obviously Use the cache. First of all, let's consider whether it is feasible to use redis. Since redis has a single point problem, if the traffic is too large, then all user requests will reach the same node of redis. It is necessary to evaluate whether the node can withstand such a large traffic. Our rule is that if the qps of a single node reaches the thousand level, we must solve the single point problem (even if redis claims to be able to withstand the qps of the 100,000 level), the most common way is to use the local cachelive. Obviously, the traffic on the homepage of the Xiaoai app is only a hundred, so it is no problem to use redis.

Usage scenarios and limitations of LoadingCache

For the hot key problem mentioned above, our most direct approach is to use local cache, such as the LoadingCache of guava that you are most familiar with, but The use of local cache requires the acceptance of certain dirty data, because if you update the homepage, the local cache will not be updated, it will only reload the cache according to a certain expiration policy, but in our scenario it is completely fine, Because once the home page is pushed in the background, it will not be changed again. Even if it is changed, there is no problem. You can set the write expiration to half an hour, and reload the cache after half an hour. We can accept dirty data in such a short period of time.

Cache breakdown caused by LoadingCache

Although the local cache is strongly related to the machine, although the code level is written to expire in half an hour, due to The startup time of each machine is different, resulting in different cache loading time and expiration time, so requests on all machines will not request the database after the cache expires at the same time. But for a single machine, it will also cause cache penetration. If there are 10 machines, each with 1000 qps, as long as one cache expires, these 1000 requests may hit the database at the same time. This kind of problem is actually easier to solve, but it is easy to be ignored, that is, when setting LoadingCache, use LoadingCache's load-miss method instead of directly judging cache.getIfPresent() == null and then requesting db; the former will add a virtual machine Level locks ensure that only one request hits the database, thus perfectly solving this problem.

However, if the real-time requirements are high, such as frequent activities for a period of time, I need to ensure that the activity page can be updated in near real time, that is, after the operation has configured the activity information in the background, It is necessary to display the activity information of this configuration on the C side in near real time. At this time, using LoadingCache is definitely not enough.

Usage scenarios and limitations of ReloadableCache

For real-time problems that cannot be solved by LoadingCache mentioned above, you can consider using ReloadableCache, which is a local cache framework open sourced by Kuaishou. The biggest feature It supports multiple machines to update the cache at the same time. Suppose we modify the home page information, and then the request hits machine A. At this time, reload the ReloadableCache, and then it will send a notification, and other machines listening to the same zk node will re-update after receiving the notification cache. The general requirement for using this cache is to load the full amount of data locallyCache, so if the amount of data is too large, it will definitely put pressure on the gc, and this situation cannot be used. Since Xiao Ai's homepage is stateful, there are generally only two in the online state, so ReloadableCache can be used to load only the homepage in the online state.


The three types of caches are basically introduced here, so make a summary:

  • For non-hot data access, such as For data in the user dimension, you can directly use redis;

  • For access to hot data, if the traffic is not very high, you can use redis without thinking;

  • For hot data, if you allow dirty data within a certain period of time, you can use LoadingCache;

  • For hot data, if the consistency requirements are high , and if the amount of data is not large, you can use ReloadableCache;


No matter what kind of local cache, although it has a virtual machine level Locking to solve the problem of breakdown, but accidents may always happen in unexpected ways. To be on the safe side, you can use two-level caching, that is, local caching + redis + db.

Copyright Description:No reproduction without permission。

Knowledge sharing community for developers。

Let more developers benefit from it。

Help developers share knowledge through the Internet。

Follow us

Recommended reading

high perspicacity