In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/01 Report--
This article mainly explains "what are the interview questions and answers for Redis". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what are the interview questions and answers for Redis.
Tell me about the basic data types of Redis.
String: instead of directly using the traditional string representation of the C language, redis implements its own abstract type called simple dynamic string SDS. The string in C language does not record its own length information, while SDS saves the length information, which reduces the time to obtain string length from O (N) to O (1), avoids buffer overflow and reduces the number of memory redistributions needed to modify string length.
Linked list linkedlist:redis linked list is a two-way acyclic linked list structure, many functions of publish and subscribe, slow query and monitor are realized by linked list. The node of each linked list is represented by a listNode structure, and each node has pointers to the front node and the post node. At the same time, the front and back nodes of the header node point to NULL.
Dictionary hashtable: an abstract data structure used to hold key-value pairs. Redis uses hash table as the underlying implementation, and each dictionary has two hash tables for normal use and rehash. Hash table uses chain address method to resolve key conflicts. Multiple key-value pairs assigned to the same index location will form an one-way linked list. When expanding or reducing the capacity of hash table, the rehash process is not completed at once, but gradually.
Jump table skiplist: jump table is one of the underlying implementations of ordered sets, which is used in redis in the implementation of ordered set keys and the internal structure of cluster nodes. The redis jump table consists of zskiplist and zskiplistNode. Zskiplist is used to save the jump table information (header, footer node, length, etc.). ZskiplistNode is used to represent the table jump node. The layer height of each jump table is a random number from 1 to 32. In the same jump table, multiple nodes can contain the same score, but the member objects of each node must be unique, and the nodes are sorted by score size, if the score is the same. Is sorted by the size of the member object.
Collection of integers intset: a collection of abstract data structures used to hold integer values, with no duplicate elements, and the underlying implementation is an array.
Compressed list ziplist: a compressed list is a sequential data structure developed to save memory. It can contain multiple nodes, each of which can hold 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, ordered collection object zset, each of which uses at least one basic data structure.
Redis uses the encoding attribute to set the encoding form of the object to improve flexibility and efficiency, and redis will automatically make optimizations based on different scenarios. The codes for different objects are as follows:
String object string:int integer, embstr encoded simple dynamic string, raw simple dynamic string
List objects list:ziplist, linkedlist
Hash objects hash:ziplist, hashtable
Collection objects set:intset, hashtable
Ordered collection objects zset:ziplist, skiplist
Why is Redis fast?
The speed of redis is very fast, stand-alone redis can support more than 100,000 concurrency per second, compared to mysql, the performance is dozens of times that of mysql. The main reasons for the speed are as follows:
Based entirely on memory operations
C language implementation, optimized data structure, based on several basic data structures, redis has done a lot of optimization, extremely high performance
Single-threaded, context-free switching cost
IO Multiplexing Mechanism based on non-blocking
So why did you switch to multithreading after Redis6.0?
Redis uses multithreading not to completely abandon single threading, redis still uses single threading model to handle client requests, only uses multithreading to handle data reading and writing and protocol parsing, and executes commands using single threading.
The purpose of this is because the performance bottleneck of redis lies in the network IO rather than CPU, and the use of multithreading can improve the efficiency of IO reading and writing, thus improving the performance of redis as a whole.
Do you know what hot key is? How to solve the hot key problem?
The so-called hot key problem is that suddenly hundreds of thousands of requests to access a particular key on the redis will cause traffic to be too concentrated and reach the upper limit of the physical network card, resulting in an avalanche when the redis server goes down.
Solutions for hot key:
Break up the hot key to different servers in advance to reduce the pressure
Add second-level cache to load hot key data into memory in advance. If redis is down, query in memory.
What is cache breakdown, cache penetration, cache avalanche? Cache breakdown
The concept of cache breakdown is that the concurrent access of a single key is too high, and when it expires, all requests are called directly to the db. This is similar to the problem of hot key, except that the expiration causes all requests to be called to the DB.
Solution:
Lock update, for example, request query A, find that it is not in the cache, lock the key A, query the data in the database, write it to the cache, and return it to the user, so that the later requests can get the data from the cache.
Write the expiration time combination in value, and constantly refresh the expiration time asynchronously to prevent this kind of phenomenon.
Cache penetration
Cache traversal means that the data in the cache does not exist in the query, and each request will hit DB, just as if the cache does not exist.
To solve this problem, add a layer of Bloom filter. The principle of the Bloom filter is that when you save data, you map it to K points in a bit array through a hash function, and set them to 1.
In this way, when the user queries An again, and A has a value of 0 in the Bloom filter and returns directly, there will be no breakdown request to hit the DB.
Obviously, a problem after using Bloom filter is misjudgment, because it is an array, and multiple values may fall into the same position, so theoretically, as long as our array is long enough, the probability of misjudgment will be lower. This kind of problem should be based on the actual situation.
Cache avalanche
When a large-scale cache invalidation occurs at some point, such as when your cache service goes down, a large number of requests will come in and call DB directly, which may lead to the collapse of the whole system, which is called avalanche. The problem with avalanches is not quite the same as the problem with breakdown and hot key, which means that large-scale caches are expired.
Several solutions for avalanches:
Set different expiration times for different key to avoid simultaneous expiration
Current limit. If redis is down, it can be limited to avoid the collapse of DB by a large number of requests at the same time.
Second-level cache, the same as the hot key scheme.
What are the expiration policies of Redis?
There are two main expired deletion policies in redis.
Lazy deletion
Lazy deletion means that the key is only detected when we query the key, and delete if the expiration time has been reached. Obviously, one of his drawbacks is that if these expired key are not accessed, then he cannot be deleted and takes up memory all the time.
Delete periodically
Regular deletion means that redis checks the database at regular intervals to delete the expired key. Since it is impossible to poll all key to delete, redis will randomly take some key at a time to check and delete.
What if regular + laziness doesn't delete expired key?
Assuming that redis does not delete the key every time it queries randomly, and the key does not query, it will cause these key to be stored in redis and cannot be deleted. At this time, it will go to the memory elimination mechanism of redis.
Volatile-lru: from the key with the expiration time set, remove the least recently used key for elimination
Volatile-ttl: remove the key that is about to expire from the key with the expiration time set
Volatile-random: randomly select key elimination from key with expiration time set
Allkeys-lru: select the least recently used one from key to be eliminated
Allkeys-random: randomly select key from key to be eliminated
Noeviction: when memory reaches the threshold, the new write operation reports an error
What are the persistence methods? What's the difference?
There are two kinds of redis persistence schemes: RDB and AOF.
RDB
RDB persistence can be performed manually or periodically according to configuration. Its function is to save the database state at a certain point in time to a RDB file. RDB file is a compressed binary file, through which you can restore the state of the database at a certain time. Because the RDB file is saved on the hard disk, even if the redis crashes or exits, you can use it to restore the state of the restored database as long as the RDB file exists.
You can generate RDB files through SAVE or BGSAVE.
The SAVE command blocks the redis process until the RDB file is generated, and redis cannot process any command requests during the process blocking, which is obviously inappropriate.
BGSAVE will fork a child process, and then the child process will be responsible for generating the RDB file, and the parent process can continue to process command requests without blocking the process.
AOF
Unlike RDB, AOF records the state of the database by saving write commands executed by the redis server.
AOF implements the persistence mechanism through three steps: append, write and synchronization.
When AOF persistence is active and the server finishes executing the write command, the write command will be appended to the end of the aof_buf buffer by append
Before the server ends each event loop, the flushAppendOnlyFile function is called to decide whether to save the contents of the aof_buf to the AOF file, which can be determined by configuring appendfsync.
Always # # aof_buf content is written and synchronized to the AOF file everysec # # writes the contents of the aof_buf to the AOF file. If the time of the last synchronization of the AOF file is now more than 1 second, the AOF file is synchronized again. No # # writes the aof_buf content to the AOF file, but the AOF file is not synchronized. The synchronization time is determined by the operating system.
If not set, the default option will be everysec, because although always is the safest (write commands for only one event loop will be lost), the performance is poor, while everysec mode may only lose 1 second of data, while no mode is as efficient as everysec, but will lose all write command data since the last time the AOF file was synchronized.
How to achieve high availability of Redis?
To achieve high availability, one machine is certainly not enough, while redis has two options to ensure high availability.
Master-slave architecture
Master-slave mode is the simplest way to achieve high availability, and the core is master-slave synchronization. The principle of master-slave synchronization is as follows:
Slave sends sync commands to master
After receiving the sync, master executes bgsave to generate the full RDB file.
Master records slave write commands to the cache
After the bgsave execution is finished, send the RDB file to slave,slave for execution
Master sends write commands in the cache to slave,slave for execution.
The command I wrote here is sync, but psync has been used instead of sync since the redis2.8 version, because the sync command consumes system resources and psync is more efficient.
Sentinel
Based on the shortcomings of the master-slave solution is still obvious, assuming that the master down, then can not write data, then slave will not be useful, the entire architecture will not be available, unless you switch manually, the main reason is that there is no automatic failure mechanism. The function of sentinel is much more comprehensive than the simple master-slave architecture, it has automatic failover, cluster monitoring, message notification and other functions.
The Sentinel can monitor multiple master and slave servers at the same time, and automatically promote a slave to master when the monitored master is offline, and then the new master continues to receive commands. The whole process is as follows:
Initialize sentinel and replace ordinary redis code with sentinel-specific code
Initialize the masters dictionary and server information, which mainly stores ip:port and records the address and ID of the instance
Create two connections to master, command connection and subscription connection, and subscribe to sentinel:hello channel
Send an info command to master every 10 seconds to get current information about master and all the slave below it
When a new slave is found in master, sentinel and the new slave also establish two connections and send an info command every 10 seconds to update the master information
Sentinel sends ping commands to all servers every 1 second. If a server continuously returns invalid responses within the configured response time, it will be marked as offline.
To elect the lead sentinel, the lead sentinel needs the consent of more than half of the sentinel.
The leader sentinel selects one of all the slave of the offline master and converts it to master
Change all slave to copy data from the new master
When the original master is set 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 sends ping commands to all instances (including master and slave servers and other sentinel) every second, and determines whether it has been offline based on the reply, which is called subjective offline. When it is judged to be subjectively offline, it will ask other monitored sentinel. If more than half of the votes think it is offline, it will be marked as objective offline and a failover will be triggered.
Can you tell me the principle of redis cluster?
If you can rely on sentinels to achieve high availability of redis, if you still want to support high concurrency while accommodating large amounts of data, you need a redis cluster. Redis cluster is a distributed data storage scheme provided by redis. Cluster shares data through data slicing sharding and provides replication and failover functions.
Node
A redis cluster consists of multiple node node, and multiple node are connected by the cluster meet command. The handshake process of the node:
Node A receives a cluster meet command from the client
A sends a meet message to B based on the IP address and port number received
Node B receives the meet message and returns pong.
A knows that B has received a meet message and returns a ping message. The handshake is successful.
Finally, node A will propagate 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 slot
Redis stores data in the form of cluster fragmentation. The entire cluster database is divided into 16384 slot. Each node in the cluster can handle 0-16384 slot. When there are 16384 slot nodes in the database, the cluster is online. On the contrary, as long as one slot is not processed, the offline state will be processed. The slot can be assigned to the corresponding node for processing through the cluster addslots command.
Slot is an array of bits. The length of the array is 16384. 8. 2048, and each bit of the array is processed by the node by 1. 0 means not processed. As shown in the figure, node A processes the slot of 0-7.
When the client sends a command to the node, if it happens to find that slot belongs to the current node, then the node executes the command, otherwise, it will return a MOVED command to the client to direct the client to the correct node. (the MOVED process is automatic)
If you add or remove nodes, it is also very convenient for the reallocation of slot. Redis provides tools to help migrate slot. The whole process is completely online and there is no need to stop the service.
Fail-over
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 suspected pfail offline and send B's status to other nodes in the form of a message. If more than half of the nodes are marked as pfail, B will be marked as fail offline, and a failover will occur. Priority is given to selecting a slave node from a slave node with more replicated data as the master node and taking over the slot of the offline node. The whole process is very similar to the Sentinel, which makes the election based on the Raft protocol.
Do you know 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 sequentially at one time, and during the execution, the transaction will not be interrupted and other requests from the client will not be executed until all the commands have been executed. The execution process of the transaction is as follows:
The server receives the client request, and the transaction starts with MULTI
If the client is in a transactional state, the transaction will be queued and returned to the client QUEUED, otherwise the command will be executed directly
When the client EXEC command is received, the WATCH command monitors whether the key in the entire transaction has been modified. If so, a null reply to the client indicates failure, otherwise the redis will traverse the entire transaction queue, execute all commands saved in the queue, and finally return the result to the client.
The WATCH mechanism itself is a CAS mechanism, and the monitored key will be saved to a linked list. If a key is modified, the REDIS_DIRTY_CAS flag will be opened, and the server will refuse to execute the transaction.
Thank you for your reading, the above is the content of "what are the interview questions and answers of Redis". After the study of this article, I believe you have a deeper understanding of the interview questions and answers of Redis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.