Redis caching is a great way to speed up an application’s read and write speeds. In terms of DB, Redis is amazing, but memcached, not to mention the likes of MemCacheDB and Tokyo Cabinet, seems to be only as fast as it can be. Today I’ll focus on a few common problems with Redis. Cache avalanche, cache breakdown, cache penetration, cache warm-up, cache update, cache degradation.

V Cache avalanche

Cache avalanche is when a cache set expires during a certain period of time. All the requests that should have access to the cache are queried by the database, which causes great pressure on the database CPU and memory, and even leads to database downtime. It creates a chain reaction that causes the whole system to collapse.

Cache avalanche schematic:

What are the options for dealing with the Redis cache avalanche, when the avalanche effect of cache failures can be fatal to the underlying system?

1.1 Locking or queuing

You can consider locking or queuing to prevent a large number of threads from reading and writing the database at one time to avoid the huge impact of cache failure on the database.

The above effect can also be considered access to Redis lock implementation, specific can refer to the “SpringBoot advanced tutorial (27) integration Redis distributed lock” lock or queue is a very shallow way. Although it can relieve the database pressure to a certain extent, it also greatly reduces the throughput of the system.

1.2 Coordinate Redis expiration time

Analyze user behavior, try to make cache failure time evenly distributed, at least random distribution, especially some access to large interfaces

@Override public UserDetails getUserInfoById(Integer uid){ String key = String.format("user_info_id:%d",uid); UserDetails userDetails = (UserDetails)templateRedis.opsForValue().get(key); if(userDetails ! = null){ return userDetails; }else{ userDetails = userDetailsMapper.getUserDetailsByUid(uid); Random random = new Random(); int time = 600; // type: 1: big V user 2: net red 3: common user if(userDetails! = null){ if(userDetails.getType() == 1){ time = 3600 + random.nextInt(3600); Else if(userdetails.getType () == 2){time = 1200 + random.nextint (1200); / / if there are other logic} else {} / / if there are other logic redisTemplate. OpsForValue (). The set (key, populated userDetails, time, TimeUnit. SECONDS); } } return userDetails; }Copy the code

Here is mainly based on business scenarios to evenly distribute the cache expiration time. For example, in the above code, big V users and Internet celebrities generally have millions of fans, so it is possible to cache a longer time.

1.3 Level 2 Cache

Level 2 cache. A1 is the original cache and A2 is the copy cache. When A1 fails, access A2.

1.4 Ensure high availability of cache layer services

Ensure high availability of cache layer services. If the cache layer is designed to be highly available, services can be provided even if individual nodes, individual machines, or even machine rooms go down.

For more information on this topic, see “SpringBoot Advanced Tutorial (30) integrating Redis Sentinel mode” and “Detailed Explanation of Redis Cluster”.

1.5 Dependency Isolation components limit and degrade back-end traffic.

Important resources (such as Redis, MySQL, external interfaces) need to be isolated so that each resource runs separately in its own thread pool. Even if problems occur with individual resources, there is no impact on other services. However, thread pool management, such as how to turn off the resource pool, enable the resource pool, resource pool threshold management, is quite complex to do.

V Cache penetration

Cache penetration is querying for data that must not exist. Because of cache mismatches and fault tolerance, if the data is not retrieved from the database, it is not written to the cache. This will result in the non-existent data being queried in the database every time, losing the significance of the cache.

Schematic of cache penetration:

How to resolve cache penetration? Corresponding several reference schemes:

2.1 BloomFilter

A Bloom filter is used to hash all possible data into a large enough bitmap. A non-existent data will be intercepted by the bitmap, thus avoiding the query pressure on the underlying storage system. Since the requested parameters are not valid (each time a non-existent parameter is requested), we can use a BloomFilter or a compressed filter to intercept the request in advance and prevent the request from going to the database layer if it is not valid.

BloomFilter is similar to a hash set used to quickly determine whether an element exists in a set. Its typical application scenario is to quickly determine whether a key exists in a container and return if it does not. The key to bloom filters is the hash algorithm and the container size,

2.2 Record empty objects in the cache.

If the database returns null, the empty object can also be set to the cache. The next time a request is made, the empty object can be fetched from the cache and set to a short expiration time. See the code example in 1.1.

V Cache breakdown

Cache breakdown refers to the failure of the hot key at a particular time in a particular scenario, when a large number of concurrent requests come, causing DB pressure.

Cache breakdowns are conceptually similar to cache avalanches, except that cache breakdowns are hot keys, and avalanches are large scale keys.

How to solve the cache breakdown, the corresponding several reference schemes:

3.1 Similar to 1.1, prevent a large number of requests from passing through Redis to DB by locking or queuing.

3.2 For some hot keys, the expiration time can be extended indefinitely

You can adjust the expiration time of hotspot keys indefinitely. Then, you can use the Job service to manage the expiration of hotspot keys, ensuring the stability of hotspot keys (especially hotspot keys that require a lot of calculation, such as rankings and popularity on the home page). Note that the job service itself may be unstable, for example, the service where the job is deployed is suspended. Check out a previous post here. Detailed Supervisor Process Monitoring

V Cache degradation

Cache degradation refers to the need to ensure that the service is still available, even if it damages the service, when there is a surge in traffic, a problem with the service (such as slow or unresponsive response times), or a non-core service affects the performance of the core process. The system can automatically degrade according to some key data, or manually degrade by configuring switches.

The ultimate goal of a downgrade is to ensure that the core service is available, even if it is lossy. And some services can’t be downgraded (add to cart, checkout).

Those who participated in tmall Double 11 in the past year should be very clear about the downgrade. At that time, the most serious downgrade was to add to the shopping cart and not be able to change the delivery address when settling accounts. You can only use the default shipping address. That’s a lot of ex-boyfriends, ex-girlfriends.

The system should be combed before demoting to see if the system can lose the pawn to protect the boss; To sort out what must be fiercely protected and what can be downgraded; For example, you can refer to log level Settings:

General: For example, if some services time out due to network jitter or online services, they can be automatically degraded.

Warning: If the success rate of some services fluctuates within a period of time (for example, between 95 and 100%), the service can be automatically degraded or manually degraded, and an alarm is sent.

Error: for example, the availability rate is less than 90%, or the database connection pool is hit, or the number of visits suddenly jumped to the system can bear the maximum threshold, at this time can be automatically degraded or manually degraded according to the situation;

Critical error: For example, the data is wrong due to special reasons, and an emergency manual downgrade is required.

Ps: stronger than “Horse father”, in double 11 in the face of massive concurrency, but also downgraded, there is no blame. But when you’re downgrading, you have to think about trade-offs. This, on the contrary, is the most difficult downgrade.

V Cache preheating

When you do your first chemistry experiment in junior high school, you know that test tubes need to be preheated before being heated. Cache preheating is also a common concept. Cache preheating means that relevant cache data is directly loaded into the cache system after the system goes online. This avoids the problem of querying the database and then caching the data when the user requests it. Users directly query cached data that has been preheated.

Cache preheating

Write a cache refresh page directly, manual operation when on-line;

The amount of data is not large and can be loaded automatically when the project is started.

Periodically refresh the cache;

For some very computation-intensive interfaces, cache preheating is definitely necessary.

V Cache update

In addition to the cache invalidation policies provided by the cache server (Redis has 6 policies to choose from by default), we can also customize the cache invalidation policies based on specific business requirements. There are two common policies:

Timed tasks to clear expired caches;

Provides an interface to manually clear the cache.

When there is a user request, and then determine whether the cache used for this request expires, expired to the underlying system to get new data and update the cache.

Each of the above schemes has its own advantages and disadvantages. The disadvantage of the first one is that maintaining a large number of cached keys is more troublesome. The second kind of labor costs too much; The disadvantage of the third method is that each time the user requests to determine the cache is invalid, the logic is relatively complex. Specific application scenarios must be treated according to the business.

V Blog Summary

Redis has taken a lot of the stress out of SQL, and leveraging the various mechanisms of Redis has become an essential skill.

V Source code address

Github.com/toutouge/ja…

About the author: Focus on basic platform project development. If you have any questions or suggestions, please feel free to comment! Copyright notice: The copyright of this article belongs to the author and the blog garden, welcome to reprint, but without the consent of the author must retain this statement, and give the original text link in a prominent place on the page of the article. For the record: all comments and messages will be answered as soon as possible. You are welcome to correct your mistakes and make progress together. Or direct private message I support the blogger: if you think the article is helpful to you, you can click on the lower right corner of the article [recommendation]. Your encouragement is the author to adhere to the original and continuous writing of the biggest power! \