Shulou(Shulou.com)06/01 Report--

This article focuses on "how to solve the Redis cache avalanche", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to solve the Redis cache avalanche.

Cache avalanche

The cache layer carries a large number of requests, which effectively protects the storage layer. However, if a large number of requests arrive at the storage layer due to a large number of cache failures or the overall failure of the cache to provide services, the load of the storage layer will increase, which is the scenario of cache avalanche.

Resolve cache avalanche

1. Maintain high availability of the cache layer

Using Redis Sentinel mode or Redis cluster deployment mode, even if individual Redis nodes go offline, the entire cache layer can still be used. In addition, Redis can be deployed in multiple computer rooms, so that even if the computer room crashes, the high availability of the cache layer can still be achieved.

two。 Current limiting and degraded assembly

Both the cache layer and the storage layer have the probability of error and can be thought of as resources. As a distributed system with large concurrency, if a resource is not available, it may cause all threads to get the resource exception and make the whole system unavailable. Downgrading is very normal in high concurrency systems, such as recommendation services, if personalized recommendation services are not available, you can downgrade to supplement hot data, so as not to cause the entire recommendation service to be unavailable. Common current limiting and degraded components such as Hystrix, Sentinel and so on.

3. Cache does not expire

The key saved in Redis never expires, so there is no problem of a large number of caches being invalidated at the same time, but with it, Redis needs more storage space.

4. Optimize cache expiration time

When designing the cache, select the appropriate expiration time for each key to avoid a large number of key invalidation at the same time, resulting in cache avalanches.

5. Rebuild the cache using mutexes

In high concurrency scenarios, in order to avoid a large number of requests reaching the storage layer to query data and rebuild the cache at the same time, mutex control can be used, such as querying the data in the cache layer according to key, locking the key when the cache layer is hit, and then querying the data from the storage layer, writing the data to the cache layer, and finally releasing the lock. If another thread finds that it failed to acquire the lock, let the thread sleep for a period of time and try again. For lock types, Lock under Java concurrent package can be used in a stand-alone environment, and distributed locks (SETNX method in Redis) can be used in a distributed environment.

Using Redis distributed lock to realize cache reconstruction in distributed environment, the advantage is that the design idea is simple, and the data consistency is guaranteed; the disadvantage is that the code complexity increases, which may cause users to wait. Suppose that under high concurrency, the key is locked during cache reconstruction. if 1000 requests are currently concurrent, 999 of them are blocking, which will cause 999 user requests to block and wait.

6. Rebuild cache asynchronously

Under this scheme, the asynchronous strategy is adopted to build the cache, which will obtain threads from the thread pool to build the cache asynchronously, so that all requests will not reach the storage layer directly. In this scheme, each Redis key maintains a logical timeout. When the logical timeout is less than the current time, the current cache has expired and the cache should be updated. Otherwise, the current cache is not invalidated and the value value in the cache is returned directly. For example, set the expiration time of key to 60 min in Redis and set the logical expiration time to 30 min in the corresponding value. In this way, when the key reaches the logical expiration time of 30 min, the cache of the key can be updated asynchronously, but the old cache is still available during the time the cache is updated. This way of rebuilding cache asynchronously can effectively avoid a large number of key invalidation at the same time.

At this point, I believe you have a deeper understanding of "how to solve the Redis cache avalanche". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.