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

This article introduces the relevant knowledge of "how to understand the elimination mechanism of Redis cache, cache avalanche and data inconsistency". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

In actual work projects, caching becomes a key component of a high-concurrency, high-performance architecture, so why can Redis be used as a cache? First, there are two main characteristics that can be used as caches:

Memory/CPU access performance is good in hierarchical systems

Cache data saturation, good data elimination mechanism

Because Redis naturally has these two characteristics, Redis is based on memory operations, and it has a perfect data elimination mechanism, which is very suitable as a cache component.

Among them, based on memory operation, the capacity can be 32-96GB, and the average operation time is 100ns, and the operation efficiency is high. And there are many data elimination mechanisms, and after Redis 4.0, there are 8 kinds that make Redis as a cache can be applied to many scenarios.

So why does Redis cache need a data culling mechanism? What are the 8 data elimination mechanisms?

Data elimination mechanism

Redis cache is based on memory implementation, then its cache capacity is limited, when the cache is full, then how should Redis handle it?

Redis For the case where the cache is full, Redis needs a cache data elimination mechanism to select and delete some data through certain elimination rules, so that the cache service can be reused. So what elimination strategies does Redis use to brush and delete data?

After Redis 4.0, there are 6+2 Redis cache retirement policies, including three categories:

No elimination of data

noeviction, no data elimination, when the cache is full, Redis does not provide service and returns an error directly.

In the key-value pair that sets the expiration time,

volatile-random, randomly deleted from key-value pairs that set expiration times

volatile-ttl, key pairs that set expiration time are deleted based on the order of expiration time. The earlier the expiration time, the earlier the deletion.

volatile-lru, based on LRU(Least Recently Used) algorithm to filter key pairs with expiration time set, the least recently used principle to filter data

Volatile-lfu, which uses LFU( Least Frequently Used ) algorithm to select the key-value pair with expiration time set, and uses the key-value pair with least frequency to filter the data.

Among all key pairs,

allkeys-random, randomly selects and deletes data from all key pairs

allkeys-lru, filtering through all data using LRU algorithm

allkeys-lfu, filtering through all data using the LFU algorithm

Note: LRU(Least Recently Used) algorithm, LRU maintains a bidirectional linked list, the head and tail of the linked list represent the MRU end and LRU end respectively, representing the most recently used data and the least Recently used data respectively.

LRU algorithm in practice, the need to use linked list management of all cache data, which will bring additional space overhead. Moreover, when data is accessed, the data needs to be moved to the MRU end on the linked list. If a large amount of data is accessed, it will bring a lot of linked list movement operations, which will be very time-consuming and will reduce Redis cache performance.

Among them, LRU and LFU are based on the object structure of Redis. The lru and refcount attributes of redisObject realize:

typedef struct redisObject { unsigned type:4; unsigned encoding:4; //last time the object was accessed unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or * LFU data (least significant 8 bits frequency //reference count * and most significant 16 bits access time). */ int refcount; void *ptr; } robj;

The LRU of Redis will use the lru of redisObject to record the last time it was accessed, randomly select the number of parameters configured by maxmemory-samples as the candidate set, and select the data with the smallest lru attribute value to be eliminated.

In a real project, how do you choose a data culling mechanism?

The allkeys-lru algorithm is preferred to keep the most recently accessed data in the cache and improve the access performance of the application.

Some overhead data use volatile-lru algorithm, overhead data does not set cache expiration time, other data set expiration time, based on LRU rules for filtering.

After understanding the Redis cache elimination mechanism, let's see how many modes Redis has as a cache?

Redis cache mode

Redis cache mode can be divided into read-only cache and read-write cache based on whether write requests are received:

Read-only cache: only reads are processed, all updates are in the database, so there is no risk of data loss.

Cache Outside Mode

Read and write cache, read and write operations are performed in the cache, downtime failure, will lead to data loss. Cache writes back data to the database in two ways: synchronous and asynchronous:

Synchronization: Low access performance, more focused on ensuring data reliability

Read-Throug mode

Write-Through mode

Asynchronous: Risk of data loss, which focuses on providing low-latency access

Write-Behind mode

Cache Outside Mode

Query data reads data from cache first. If it does not exist in cache, read data from database. After obtaining data, update it into cache. However, update data operation will update data of database first, and then invalidate data of cache.

Moreover, there is a concurrent risk in Cache Outside mode: performing a read operation misses the cache, then querying the database to fetch data, the data has been queried and has not been put into the cache, and at the same time an update write operation causes the cache to be invalidated, and then the read operation loads the query data into the cache, resulting in dirty data cached.

Read/Write-Throug mode

Both query data and update data access the cache service directly, and the cache service updates the data to the database synchronously. The probability of dirty data is low, but it is strongly dependent on cache, which requires greater stability of cache service, but synchronous update will lead to poor performance.

Write Behind mode

Query data and update data directly access cache service, but cache service updates data to database asynchronously (through asynchronous task), which is fast and efficient, but data consistency is poor, data loss may occur, and implementation logic is complex.

In actual project development, the cache mode is selected according to the actual business scenario requirements. After understanding the above, why do we need to use redis cache in our application?

Using Redis cache in applications can improve system performance and concurrency, mainly reflected in

High performance: memory-based query, KV structure, simple logic operation

High concurrency: Mysql can only support about 2000 requests per second, Redis easily more than 1W per second. Let more than 80% of queries go through cache, and less than 20% of queries go through database, which can greatly improve system throughput.

Although the use of Redis cache can greatly improve the performance of the system, but the use of cache, there will be some problems, such as cache and database bi-directional inconsistency, cache avalanche, etc., how to solve these problems?

Common problems with cache

Using cache, there will be some problems, mainly reflected in:

Cache and database double-write inconsistency

Cache avalanche: Redis cache cannot handle a large number of application requests, moving to the database layer causes pressure on the database layer to surge;

Cache penetration: Access data does not exist in the Redis cache and database, resulting in a large number of accesses penetrating the cache directly to the database resulting in a pressure surge at the database layer;

Cache breakdown: cache can not handle high-frequency hot data, resulting in direct high-frequency access to the database resulting in a surge in pressure on the database layer;

Cache inconsistent with database data

Read-only cache ( Cache Outside mode)

For a read-only cache ( Cache Outside mode), read operations occur in the cache, data inconsistencies occur only on delete operations (new operations do not, because new operations are only processed in the database), and when delete operations occur, the cache marks the data as invalid and updates the database. Therefore, in the process of updating the database and deleting the cache value, no matter which of these two operations is executed first, as long as one operation fails, there will be data inconsistency.

To sum up, when there is no concurrency, use the retry mechanism (message queue use), when there is high concurrency, use delayed double deletion (after the first deletion, sleep for a certain time, and then delete), as follows:

operation sequence is high concurrency potential problem phenomenon solution delete cache first, then update database no cache delete success, database update failure read old value of database retry mechanism (database update) update database first, then delete cache no database update success, cache delete failure read old value of cache retry mechanism (cache delete) delete cache first, then update database yes cache delete, database has not been updated, There are concurrent read requests. Concurrent read requests read old values in the database and update them to the cache, resulting in a delay in reading old values in subsequent read requests. Double deletion () Update the database first, then delete the cache. Database update is successful, but the cache has not been deleted. The inconsistent old values read in the cache exist temporarily, which has little impact on the business.

NOTE:

Delayed double erasure pseudocode:

redis.delKey(X) db.update(X) Thread.sleep(N) redis.delKey(X)

Read/Write cache (Read/Write-Throug, Write Behind)

For read and write caches, write operations occur in the cache, and then update the database. As long as one operation fails, there will be data inconsistency.

In summary, retry is used when there is no concurrency (message queue usage) and distributed locking is used when there is high concurrency. The details are as follows:

Operation sequence is high Concurrency potential problem phenomenon Solution Update cache first, then update database No cache update success, database update failure will read the latest value from cache, short term impact is not significant Retry mechanism (database update) Update database first, then update cache No database update success, cache update failure will read old value from cache Retry mechanism (cache deletion) Update database first, then update cache Write + Read concurrent thread A updates database first, Thread B then reads the data, thread A updates cache B will hit the cache, read the old value A before updating the cache, there is a temporary impact on the business First update the cache, then update the database Write + read concurrent thread A first update the cache successfully, then thread B reads the data, at this time thread B hits the cache, read the latest value and return, then thread A updates the database successfully B will hit the cache, read the latest value Business does not affect the first update database, Update cache write + write concurrent thread A and thread B update the same piece of data at the same time. The order of updating the database is A first and then B, but the order of updating the cache is B first and then A. This will lead to inconsistent write operations of database and cache plus distributed locks. Update cache first and then update database write + write concurrent thread A and thread B update the same piece of data at the same time. The order of updating the cache is A first and then B, but the order of updating the database is B first and then A. This can also lead to inconsistent database and cache writes plus distributed lock cache avalanches

Cache avalanche, because a large number of data in the cache expires at the same time or the cache is down, a large number of application requests cannot be processed in the Redis cache, and then sent to the database layer, resulting in a surge in pressure on the database layer.

A large number of requests cannot be processed due to a large amount of data expired at the same time in the cache. Solution:

Data preheating, manually triggering the loading of cache different keys before large concurrent access, can avoid querying the database first when the user requests

Set different expiration times to make the cache invalidation time points as uniform as possible

Two-tier cache policy, adding copy cache on top of original cache, accessing copy cache when original cache fails, and setting original cache failure time to short and copy cache to long

Service degradation. When cache avalanche occurs, different degradation schemes are adopted for different data. For example, non-core data directly returns predefined information, null value or error information.

For cache downtime, workaround:

Implement service fuse or request current limiting mechanism in business system to prevent database downtime caused by large number of accesses

cache penetration

Cache penetration, the data does not exist in the database and cache, which leads to querying the data. If the corresponding key value is not found in the cache, you have to query the database again, and then return null (equivalent to two useless queries).

When there are a large number of access requests, and they bypass the cache to directly check the database, resulting in a surge in pressure on the database layer, which can cause serious database downtime.

For cache penetration, workaround:

Cache null value or default value. When the data returned by a query is null, the null result will also be cached, and its expiration time will be set to be relatively short. The value will be directly taken from the cache for the next access, avoiding sending a large number of requests to the database for processing, causing database problems.

Bloom Filter hashes all possible query data keys into a bitmap of sufficient size. When querying, first go to Bloom Filter to query whether the key exists. If it does not exist, return directly. If it exists, then go to query cache. There is no query database in cache, thus avoiding downtime due to pressure surge at database layer.

buffer breakdown

Cache breakdown, for a very frequent access to hot data expiration failure, resulting in access can not be processed in the cache, which will lead to a large number of direct requests to the database, resulting in a surge in pressure on the database layer, serious database downtime.

For cache breakdown, workaround:

Do not set expiration time, especially for hot spot data that is accessed frequently.

summary

In most business scenarios, Redis cache is used as a read-only cache. For read-only caches, the preference is to update the database before deleting the cache to ensure data consistency.

Among them, cache avalanche, cache penetration, cache breakdown three major problems of the causes and solutions

Problem Cause Solution Cache avalanche

A large amount of data is lost at the same time

Effective cache downtime

data preheating

Set different expiration times

Two-tier caching strategy

service degradation

service fuse

current-limiting mechanism

Cache penetration data does not exist in the database or cache

Cache null or default

Value Bloom Filter

Cache breakdown access very frequent hot data expiration failure For particularly frequent access to hot data, do not set the expiration time "How to understand the elimination mechanism of Redis cache, cache avalanche, data inconsistency" content is introduced here, thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

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.