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

Today, the editor shares with you an introduction to the Redis cache failure mechanism, which many people don't know much about. Today, in order to let you know more about the Redis cache failure mechanism, the editor summarizes the following contents. Let's move on. I'm sure you'll get something.

The story of Redis cache invalidation starts with the command EXPIRE. EXPIRE allows users to specify a timeout period for a key, after which the corresponding value of key will be cleared. This article mainly considers the issues related to Redis cache failure from the point of view of Redis designers based on the analysis of Redis source code.

Redis cache invalidation mechanism

Redis cache invalidation mechanism is designed to deal with a common scenario of cache applications. Let's talk about a scenario:

In order to reduce the pressure on the back-end database, we are happy to use the Redis service to put the data that does not change very frequently from the DB load to the cache, so we can get the data directly from the cache for a period of time, but we hope that after a period of time, we can re-put the current data from the DB load into the cache.

If the problem is raised, how can it be solved? Well, we are familiar with the language tools at hand, and we firmly believe that we can quickly write such a logic: we record the time of the last data from db load, and then every time we respond to the service, we determine whether the time has expired and whether we want to re-load from db. Of course, this method is also possible, but when we look up Redis command document, we find that we have done something we don't need to do. Redis itself provides this mechanism, and we can easily do it with the help of the EXPIRE command:

EXPIRE key 30

The above command sets the expiration time of 30 seconds for key. After this time, we should not be able to access this value. So far, we probably understand what the cache invalidation mechanism is and some application scenarios of the cache invalidation mechanism. Next, let's explore this question in depth. How is the Redis cache invalidation mechanism implemented?

Delayed failure mechanism

Delay failure mechanism means that when the client requests to operate a certain key, the Redis will check the validity of the key of the client request operation, and deal with it accordingly if the key expires. The delay failure mechanism is also called negative failure mechanism. Let's take a look at the server-side execution stack for get request processing under the t_string component:

GetCommand-> getGenericCommand-> lookupKeyReadOrReply-> lookupKeyRead-> expireIfNeeded

The key point is that the get operation of expireIfNeed,Redis to key will determine whether the value associated with key is invalid. Let's insert a short episode here to see what the actual value stored in Redis looks like:

Typedef struct redisDb {dict * dict; / * The keyspace for this DB * / dict * expires; / * Timeout of keys with a timeout set * / dict * blocking_keys; / * Keys with clients waiting for data (BLPOP) * / dict * ready_keys; / * Blocked keys that received a PUSH * / dict * watched_keys; / * WATCHED keys for MULTI/EXEC CAS * / int id Long long avg_ttl; / * Average TTL, just for stats * /} redisDb

The above is a structure defined in Redis. Dict is a dictionary implemented by Redis, that is, each DB will include the above five fields. We only care about two dictionaries here, one is dict and the other is expires:

Dict is used to store normal data, for example, we execute set key "", and this data is stored in dict.

Expires is used to store the key associated with the expiration time, for example, if we have executed expire key 1 on the above basis, a record will be added to the expires at this time.

Looking back at the process of expireIfNeeded, it is roughly as follows:

Find the expiration time of the key from the expires. If it does not exist, it means that the corresponding key has not set the expiration time, return it directly.

If it is a slave machine, it will be returned directly, because in order to ensure data consistency and simple implementation, Redis gives the initiative of cache invalidation to the Master machine, and the slave machine does not have the permission to invalidate the key.

If you are currently on a Master machine and the key expires, master does two important things: 1) write the delete command to the AOF file. 2) notify Slave that the current key is invalid and can be deleted.

Master removes the value of key from the local dictionary.

Active failure mechanism

The active failure mechanism is also called the active failure mechanism, that is, the server checks the cache of the failure at a fixed time, and carries out the corresponding operation if it fails.

We all know that Redis is single-threaded and event-driven, and there is an EventLoop,EventLoop in Redis that handles two types of events:

One is the IO event, which is separated from the underlying multiplexer.

One is the timing event, which is mainly used to event the scheduled execution of a task.

It seems that Redis's EventLoop and Netty and JavaScript's EventLoop function are designed to be similar. On the one hand, they can handle network Imax O events, on the other hand, they can also do some small tasks.

Why do we talk about the single-threaded model of Redis? because the active failure mechanism logic of Redis is executed by the main thread as a scheduled task, the related code is as follows:

If (aeCreateTimeEvent (server.el, 1, serverCron, NULL, NULL) = = AE_ERR) {redisPanic ("Can't create the serverCron time event."); exit (1);}

ServerCron is the function pointer to this scheduled task. AdCreateTimeEvent registers the serverCron task with EventLoop and sets the initial execution time to 1 millisecond later. Next, everything we want to know is in serverCron. ServerCron does a lot of things. We only care about the parts related to this article, that is, how cache invalidation is implemented. I think the call stack is more intuitive depending on what the code does:

AeProcessEvents-> processTimeEvents-> serverCron-> databasesCron-> activeExpireCycle-> activeExpireCycleTryExpire

EventLoop triggers the execution of serverCron logic through the processing of scheduled tasks, and finally executes the logic of key expiration processing. It is worth mentioning that activeExpireCycle logic can only be done by master.

For more information about redis, please follow the introduction to redis tutorial.

The above is a brief introduction to the Redis cache failure mechanism, of course, the detailed use of the above differences still need to be used before you understand. If you want to know more, welcome to follow the industry information channel!

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.