What are the Redis interview questions and answers?

Let’s talk about the basic data types of Redis

1. String: redis does not directly use the traditional string representation of C language, but implements its own called simple dynamic string SDS abstract type. The string in C language does not record its own length information, but SDS saves the length information, which reduces the time to obtain the string length from O(N) to O(1), while avoiding buffer overflow and reducing the need to modify characters. The number of memory reallocations required for the length of the string.

2. Linked list linkedlist: The redis linked list is a two-way acyclic linked list structure. Many publish and subscribe, slow query, and monitor functions are implemented using linked lists. Each linked list node consists of a Represented by the listNode structure, each node has a pointer to the previous node and the subsequent node, and at the same time, the previous and subsequent nodes of the header node point to NULL.

3. Dictionary hashtable: an abstract data structure used to save key-value pairs. Redis uses hash tables as the underlying implementation. Each dictionary has two hash tables for daily use and rehash. The hash table uses the chain address method to resolve key conflicts and is assigned to multiple key-value pairs at the same index position. A one-way linked list will be formed. When the hash table is expanded or reduced, for the sake of service availability, the rehash process is not completed at once, but gradually.

4. Skip list skiplist: Skip list is one of the underlying implementations of ordered sets. Skip tables are used in redis to implement ordered set keys and the internal structure of cluster nodes. The redis skip table consists of zskiplist and zskiplistNode. zskiplist is used to save skip table information (header, tail node, length, etc.). zskiplistNode is used to represent table skip nodes. The layer height of each skip table is random from 1 to 32. Number, in the same jump table, multiple nodes can contain the same score, but the member object of each node must be unique. The nodes are sorted according to the size of the score. If the scores are the same, they are sorted according to the size of the member object. .

5. Integer set intset: A collection abstract data structure used to save integer values. There will be no duplicate elements. The underlying implementation is an array.

6. Compressed list ziplist: Compressed list is a sequential data structure developed to save memory. It can contain multiple nodes, and each node can save a byte array or integer value.

Based on these basic data structures, redis encapsulates its own object system, including string object string, list object list, hash object hash, collection object set, and ordered collection object zset, each object uses at least one basic data structure.

redis sets the encoding form of the object through the encoding attribute to improve flexibility and efficiency. Redis will automatically make optimizations based on different scenarios. The encoding of different objects is as follows:

1. String object string: int integer, embstr encoded simple dynamic string, raw simple dynamic string

1. List object list: ziplist, linkedlist

1. Hash object hash: ziplist, hashtable

1. Set object set: intset, hashtable

1. Ordered collection object zset: ziplist, skiplist

Why is Redis fast?

redis is very fast. A single redis can support tens of thousands of concurrencies per second. Compared with mysql, the performance is dozens of times that of mysql. The main reasons for the fast speed are:

1. Completely based on memory operations

2. C language implementation, optimized data structure, based on several The basic data structure, redis has done a lot of optimization, and the performance is extremely high

3. Use single thread, no context switching cost

4. Based on non- Blocked IO multiplexing mechanism

So why did Redis switch to multi-threading after Redis6.0?

redis Using multi-threading is not Should we completely abandon single threading? Redis still uses a single-threaded model to process client requests. It only uses multi-threads to handle data reading and writing and protocol parsing. It still uses a single thread to execute commands.

The purpose of this is because the performance bottleneck of redis lies in network IO rather than CPU. Using multi-threading can improve the efficiency of IO reading and writing, thereby improving the overall performance of redis.

Do you know what a hot key is? How to solve the hot key problem?

The so-called hot key problem is that there are suddenly hundreds of thousands of requests to access a specific key on redis. This will cause the traffic to be too concentrated and reach the upper limit of the physical network card, thus causing the redis to of servers crashed causing an avalanche.

Solution for hot keys:

1. Spread the hot keys to different servers in advance to reduce the pressure

2. Add the second-level cache and load the hot key data into the memory in advance. If redis is down, use the memory query

What are cache breakdown, cache penetration, and cache avalanche?

Cache breakdown

The concept of cache breakdown is that the concurrent access of a single key is too high. When it expires, all requests will be sent directly to the db. This is similar to the problem of hot keys. , but the point is that expiration causes all requests to be hit to the DB.

Solution:

1. Lock and update, for example, request to query A and find that it is not in the cache. Lock the key A, and at the same time go to the database to query the data and write it. Cache, and then return it to the user, so that subsequent requests can get the data from the cache.

2. Write the expiration time combination in value, and continuously refresh the expiration time in an asynchronous manner to prevent this phenomenon.

Cache penetration

Cache penetration means querying data that does not exist in the cache. Each request will hit the DB, as if the cache does not exist.

To address this problem, add a layer of Bloom filter. The operation step of the Bloom filter is to map the data into K points in the bit array through a hash function, and set these points to 1 for storing the data.

In this way, when the user queries A again, and the Bloom filter value of A is 0, it will be returned directly, and no breakdown request will be generated and hit the DB.

Obviously, there will be a problem after using the Bloom filter, which is misjudgment. Because it is an array itself, there may be multiple values ​​falling into the same position. In theory, as long as the length of our array If it is long enough, the probability of misjudgment will be lower. This kind of problem should be dealt with based on the actual situation.

Cache Avalanche

When a large-scale cache failure occurs at a certain moment, for example, your cache service is down, a large number of requests will come in and hit the DB directly, which may Leading to the collapse of the entire system is called an avalanche. Unlike the breakdown and hot key problems, the avalanche problem refers to the simultaneous expiration of large-scale caches.

Several solutions for avalanche:

1. Set different expiration times for different keys to avoid simultaneous expiration

2. Stream, if redis is down, you can limit the stream to avoid crashing the DB with a large number of requests at the same time

3. Second level cache, same hot key solution.

#What are the expiration strategies of Redis?

redis mainly has 2 expired deletion strategies

Lazy deletion

Lazy deletion means to detect the key only when it is queried, and if it has expired, then delete. If these expired keys have not been accessed, an obvious disadvantage is that they will always occupy memory and cannot be deleted.

Periodic deletion

In Redis, periodic deletion is to check the key-value pairs in the database when specified and delete the expired key-value pairs. Redis cannot perform polling for all keys when deleting operations, so some keys are randomly selected for checking and deletion.

What should I do if the expired keys are not deleted regularly and lazily?

Assuming that redis does not delete the key every time it randomly queries the key regularly, and these keys are not queried, it will cause these keys to be stored in redis and cannot be deleted, and then it will go away To the memory elimination mechanism of redis.

1. volatile-lru: From the keys with set expiration time, remove the least recently used key for elimination

2. volatile-ttl: From Among the keys with an expiration time set, remove the keys that are about to expire

3. volatile-random: Randomly select keys from the keys with an expiration time set for elimination

4. allkeys-lru: Select the least recently used key from the key for elimination

5. allkeys-random: Randomly select the key from the key for elimination

6. noeviction: When the memory reaches the threshold, an error is reported for the new write operation

What are the persistence methods? What's the difference?

Redis persistence solutions are divided into two types: RDB and AOF.

RDB

RDB persistence can be executed manually or periodically according to the configuration. Its function is to save the database status at a certain point in time to an RDB file. The RDB file is a compressed A binary file through which the state of the database at a certain moment can be restored. Since the RDB file is saved on the hard disk, even if redis crashes or exits, as long as the RDB file exists, it can be used to restore the state of the database.

RDB files can be generated through SAVE or BGSAVE.

The SAVE command will block the redis process until the RDB file is generated. During the process blocking period, redis cannot process any command requests, which is obviously inappropriate.

BGSAVE will fork out a child process, and then the child process will be responsible for generating the RDB file. The parent process can continue to process command requests without blocking the process.

AOF

AOF is different from RDB. AOF records the database status by saving the write commands executed by the redis server.

AOF implements the persistence mechanism through three steps: append, write, and synchronize.

1. When AOF persistence is activated, after the server executes the write command, the write command will be appended to the end of the aof_buf buffer

2. Before each event loop ends in the server, the flushAppendOnlyFile function will be called to determine whether to save the contents of aof_buf to the AOF file. This can be determined by configuring appendfsync.

always ##aof_buf内容写入并同步到AOF文件
everysec ##将aof_buf中内容写入到AOF文件，如果上次同步AOF文件时间距离现在超过1秒，则再次对AOF文件进行同步
no ##将aof_buf内容写入AOF文件，但是并不对AOF文件进行同步，同步时间由操作系统决定

If not set, the default option will be everysec, because although always is the safest (only one event loop write command will be lost), the performance is poor, and everysec The mode may only lose 1 second of data, while the efficiency of the no mode is similar to everysec, but all write command data after the last synchronization of the AOF file will be lost.

How to achieve high availability of Redis?

To achieve high availability, one machine is definitely not enough. To ensure high availability for redis, there are two options.

Master-slave architecture

The master-slave mode is the simplest solution to achieve high availability, and the core is master-slave synchronization. The principle of master-slave synchronization is as follows:

1. slave sends the sync command to the master

2. After the master receives the sync, it executes bgsave and generates the full RDB file.

3. The master records the slave's write command into the cache

4. After bgsave is executed, it sends the RDB file to the slave, and the slave executes it

5. The master sends the write command in the cache to the slave, and the slave executes it

The command I wrote here is sync, but it has been used after redis2.8 version psync has been used to replace sync. The reason is that the sync command consumes system resources, and psync is more efficient.

Sentinel

The shortcomings of the master-slave scheme are still obvious. If the master goes down, data cannot be written, then the slave will lose its function, and the entire architecture will become unavailable. , unless you switch manually, the main reason is because there is no automatic failover mechanism. The function of sentinel is much more comprehensive than that of a simple master-slave architecture. It has functions such as automatic failover, cluster monitoring, and message notification.

Sentry can monitor multiple master-slave servers at the same time, and when the monitored master goes offline, it will automatically promote a slave to master, and then the new master will continue to receive commands. The whole process is as follows:

1. Initialize sentinel, replace ordinary redis code with sentinel-specific code

2. Initialize masters dictionary and server information, server information Mainly save ip:port, and record the address and ID of the instance

3. Create two connections with the master, the command connection and the subscription connection, and subscribe to the sentinel:hello channel

4. Send the info command to the master every 10 seconds to obtain the current information of the master and all slaves under it

5. When it is discovered that the master has a new slave, sentinel and The new slave also establishes two connections, and sends the info command every 10 seconds to update the master information

6. sentinel sends a ping command to all servers every 1 second. If a server is Continuously returning invalid replies within the configured response time will be marked as offline

7. Elect the leading sentinel, which requires the consent of more than half of the sentinels

8. The leading sentinel selects one of the slaves of the offline master and converts it to the master

9. Let all slaves copy data from the new master

10. Set the original master as the slave server of the new master. When the original master resumes the connection, it becomes the slave server of the new master

Sentinel will send a ping command to all instances (including master-slave servers and other sentinels) every 1 second, and determine whether it is offline based on the reply. This method is called subjective offline. When it is judged to be subjectively offline, other monitoring sentinels will be asked. If more than half of the votes believe that it is offline, it will be marked as objectively offline and a failover will be triggered.

Can you talk about the principle of redis cluster?

If you can rely on sentinels to achieve high availability of redis, and if you want to support high concurrency while accommodating massive amounts of data, you need a redis cluster. Redis cluster is a distributed data storage solution provided by redis. The cluster shares data through data sharding and provides replication and failover functions.

Node

A redis cluster consists of multiple nodes, and multiple nodes are connected through the cluster meet command. The handshake process of the nodes:

1. Node A receives the cluster meet command from the client

2. A sends a meet message to B based on the received IP address and port number

3. Node B receives the meet message and returns pong

4. A knows that B has received the meet message, returns a ping message, and the handshake is successful

5. Finally, node A will spread the information of node B to other nodes in the cluster through the gossip protocol, and other nodes will also shake hands with B

slot

redis saves data in the form of cluster sharding. The entire cluster database is divided into 16384 slots. Each node in the cluster can handle 0-16384 slots. When all 16384 slots in the database are processed by nodes, the cluster is in Online status, otherwise as long as one slot is not processed, the offline status will be processed. Use the cluster addslots command to assign slots to corresponding nodes for processing.

slot is a bit array, the length of the array is 16384/8=2048, and each bit of the array is represented by 1 to be processed by the node, and 0 represents not processed. As shown in the figure, it means that node A processes 0-7 slot.

When the client sends a command to the node, if it happens to find that the slot belongs to the current node, the node will execute the command. Otherwise, a MOVED command will be returned to the client to guide the client to the correct node. (The MOVED process is automatic)

If you add or remove nodes, it is also very convenient to reallocate slots. Redis provides tools to help realize slot migration. The entire process is completely online and does not need to stop the service. .

Failover

If node A sends a ping message to node B, and node B does not respond to pong within the specified time, then node A will mark node B as pfail suspected offline state, and at the same time Send the status of B to other nodes in the form of messages. If more than half of the nodes mark B as pfail status, B will be marked as fail offline. At this time, failover will occur, and priority will be given to replicating data from Multiple slave nodes choose one to become the master node and take over the slot of the offline node. The whole process is very similar to that of the sentinel, both of which are based on the Raft protocol for election.

Do you understand the Redis transaction mechanism?

redis implements the transaction mechanism through MULTI, EXEC, WATCH and other commands. The transaction execution process executes a series of multiple commands in sequence at one time, and during the execution, the transaction will not be interrupted, nor will the transaction be interrupted. Other requests from the client will not be executed until all commands are executed. The execution process of the transaction is as follows:

1. The server receives the client request, and the transaction starts with MULTI

2. If the client is in the transaction state, then The transaction will be put into the queue and returned to the client QUEUED. Otherwise, this command will be executed directly.

3. When receiving the client EXEC command, the WATCH command monitors whether the key in the entire transaction exists. is modified, if so, an empty reply will be returned to the client to indicate failure, otherwise redis will traverse the entire transaction queue, execute all commands saved in the queue, and finally return the result to the client

WATCH The mechanism itself is a CAS mechanism. The monitored key will be saved in a linked list. If a key is modified, the REDIS_DIRTY_CAS flag will be turned on, and the server will refuse to execute the transaction.

The above is the detailed content of What are the Redis interview questions and answers?. For more information, please follow other related articles on the PHP Chinese website!