What to do if redis cache breakdown occurs

Distributed caching is a technology often used on website servers. In business scenarios where there are many reads and few writes, the use of cache can effectively support high concurrent visits. Data sources such as back-end databases are well protected. There are many distributed caches on the market now, such as Redis, Memcached and Alibaba's Tair. No matter which cache product we use, we will basically encounter cache breakdown, cache invalidation and hot key problems. How to effectively prevent these problems is also a difficult problem that we must solve while enjoying the dividends brought by caching.

Usually when we use the cache, we first check whether it exists in the cache. If it exists, we will directly return the cache content. If it does not exist, we will directly query the database and then cache the query results and return them. For example, as shown in the figure below,

Cache breakdown:

Description

Query data that does not exist in a database, such as product details, query a data that does not exist ID will access the DB every time. If someone maliciously destroys it, it is likely to directly cause excessive pressure on the DB.

Solution:

When querying data through a certain key, if the corresponding data in the database does not exist, we set the value corresponding to this key to a default value , such as "NULL", and set a cache expiration time. At this time, all accesses through this key will be blocked by the cache before the cache expires. If the data corresponding to this key exists in the DB later, after the cache is invalidated, you can get the new value by accessing the data again through this key.

Cache invalidation:

Description

In a high-concurrency environment, if the cache corresponding to the key fails at this time, multiple processes will query it at the same time. DB, and then set up the cache at the same time. At this time, if the key is a hotspot key in the system or a large number of them fail at the same time, the DB access volume will increase instantly, causing excessive pressure.

Solution:

Stagger the cache expiration times of keys in the system evenly to prevent cache failures corresponding to a large number of keys at the same time point;
Redesign the way the cache is used, when we pass When the key is used to query data, the cache is first queried. If the cache cannot be queried at this time, the lock is locked through the distributed lock. The process that obtains the lock checks the DB and sets the cache, and then unlocks it; if other processes find that there is a lock, they wait. Then wait for the unlock to return the cached data or query the DB again.

Hotspot key:

Description

The value corresponding to certain Keys in the cache (perhaps for the application and a certain promotional product) is stored on a machine in the cluster, so that All traffic flows to the same machine, becoming the bottleneck of the system. The challenge with this problem is that it cannot be solved by increasing the machine capacity.

Solution:

Client hotspot key cache: cache the hotspot key corresponding to the value locally on the client, and set an expiration time. For each read request, it will first check whether the key exists in the local cache. If it exists, it will be returned directly. If it does not exist, it will then access the distributed cache machine.
Disperse the hotspot key into multiple subkeys, and then store them on different machines in the cache cluster. The values ​​corresponding to these subkeys are the same as the hotspot key. When querying data through hotspot keys, a subkey is randomly selected through some hash algorithm, and then the cache machine is accessed to distribute the hotspots to multiple subkeys.

For more Redis related technical articles, please visit Redis Tutorial column to study!

The above is the detailed content of What to do if redis cache breakdown occurs. For more information, please follow other related articles on the PHP Chinese website!