Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

Redis interview question summary


May 16, 2021 Redis



Redis is a high-performance memory-based key-value database, and there is still a high demand for talent in the workplace. Today W3Cschool has compiled some classic interview questions about Redis, hoping to help children's shoes who are still on their way to a job search.


Related reading:

Reids tutorial

Redis develops a practical guide to operations and operations

Redis design and implementation


1. What is redis?

Redis is an open source (BSD licensed) data structure storage system that can be used as a database, cache, and message middleware.


2, Redis what characteristics

Redis is a Key-Value-type memory database, and a bit like memcached, the entire database is loaded in memory, regularly using asynchronous operations to save database data to the hard disk. R edis is the fastest Known Key-Value DB with a performance of more than 100,000 reads and writes per second.

In addition to performance, Redis also supports the preservation of a variety of data structures, in addition to the maximum limit of a single value is 1GB, much higher than memcached 1MB, so Redis can be used to achieve many useful functions, such as using his List to do FIFO bidirectional list, to achieve a lightweight high-performance message queue service, with his Set can do high-performance tag system and so on. I n addition, Redis can also set expire time for deposited Key-Value, so it can also be used as an enhanced version of memcached.

Of course, Redis also has a drawback that database capacity is limited by physical memory and cannot be used as high-performance read and write for large amounts of data, so Redis is better suited to high-performance operations and operations that are limited to small amounts of data.


3. What are the benefits of using redis?

(1) Fast because the data is in memory, similar to HashMap, the advantage of HashMap is that the time complexity of finding and operating is O(1)

(2) Support rich data types, support string, list, set, sorted set, hash

(3) Support transactions, operations are atomic, the so-called atomicity is the changes to the data are either all executed or not executed at all

(4) Rich features: Available for caching, messages, set expiration time by key, will be automatically deleted after expiration


4. What are the advantages of redis over memcached?

(1) All values of memcached are simple strings, with redis as its replacement for richer data types

(2) redis is much faster than memcached (3) redis can persist its data


5. What are the differences between Memcache and Redis?

1), the storage mode Memecache data all in memory, after the power will hang up, the data can not exceed the memory size. R edis has some of the hard drives, which ensures the durability of the data.

2), data support type Memcache support for data type is relatively simple. R edis has complex data types.

3), using the underlying model is different from the underlying implementation between them and the application protocol that communicates with the client. R edis builds the VM mechanism directly on its own, because the typical system calls system functions and wastes some time moving and requesting.


6.redis common performance issues and solutions:

1). M aster writes memory snapshots, save commands dispatch the rdbSave function, which blocks the work of the main thread, and when the snapshots are large, the performance impact is very large and the service is intermittently suspended, so it is best for Master not to write memory snapshots.

2). M aster AOF persistence, if you do not rewrite the AOF file, this persistence method has minimal impact on performance, but the AOF file will continue to grow, the AOF file over the general assembly will affect the master restart recovery speed. M aster is best not to do any persistence work, including memory snapshots and AOF log files, especially if memory snapshots are not enabled for persistence

if the data is critical, a Slave turns on AOF backup data, and the policy is to synchronize it every second.

3). M aster calls BGREWRITEAOF to rewrite the AOF file, which can take up a lot of CPU and memory resources when rewriting, resulting in a serviceload that is too high and a short service pause.

4). Redis Master-slave performance issues, slave and Master are best in the same LAN for master-slave speed and connection stability


7. MySQL has 2000w of data, only 20w of data is stored in redis, how to ensure that the data in redis are hot data

Related: When the size of the redis memory dataset rises to a certain size, a data phase-out strategy (recycling strategy) is implemented. R edis offers six data elimination strategies:

Volatile-lru: Pick the most recent least-used data obsolete from a dataset that has set an expiration time (server.db .i.expires).

Volatile-ttl: Pick the data that is about to expire from a dataset that has an expiration time set (server.db .expires).

Volatile-random: Any selection of data obsolete from a dataset that has an expiration time set (server.db .i.expires).

allkeys-lru: Pick the most recent least-used data obsolete from the data set (server.db .dict).

allkeys-random: Select any data .db data set (server) (i.dict).

No-enviction (expulsion): Expulsion data is prohibited


8. Please implement a malicious login protection code in Redis and any language, limiting Id to a maximum of 5 logins per user within 1 hour. S pecific login functions or functions with empty functions can be, do not need to write out in detail.

Implemented with list: Each element in the list represents the landing time and is prohibited as long as the last 5th landing time and the current time difference does not exceed 1 hour. T he code written with Python is as follows:

#!/usr/bin/env python3
import redis  
import sys  
import time  
 
r = redis.StrictRedis(host=’127.0.0.1′, port=6379, db=0)  
try:       
    id = sys.argv[1]
except:      
    print(‘input argument error’)    
    sys.exit(0)  
if r.llen(id) >= 5 and time.time() – float(r.lindex(id, 4)) <= 3600:      
    print(“you are forbidden logining”)
else:       
    print(‘you are allowed to login’)    
    r.lpush(id, time.time())    
    # login_func()

9. Why does redis need to put all the data in memory?

Redis reads data into memory for the fastest read and write speeds and writes it to disk asynchronously. S o redis has the characteristics of fast and data persistence. I f you do not put the data in memory, disk I/O speed is severely affecting the performance of redis. I n today's increasingly cheap memory, redis will become more and more popular.

If the maximum amount of memory is set, the number of records that have been recorded in the data reaches the memory limit and the new value cannot be inserted.


10. Redis is a single-process, single-threaded

Redis uses queue technology to turn conseconced access into serial access, eliminating the overhead of traditional database serial control


11. How can the problem of the same competition of redis be solved?

Redis is single-process single-threaded mode, which turns conscatenation access into serial access. R edis itself does not have the concept of locks, and Redis does not compete for multiple client connections, but problems such as connection timeouts, data conversion errors, blocking, and client-closed connections occur when Jedis clients access Redis in a synth

Due to client connection confusion. T here are two solutions to this:

1. Client angle, in order to ensure normal and orderly communication with Redis between each client, the connection is pooled, while the client read and write Redis operation using internal lock synchronized.

2. Server angle, the use of setnx to implement locks.

Note: For the first, you need the application to handle the synchronization of resources yourself, you can use a more popular method, you can use syncronized can also use lock;


12.Redis things to understand CAS (check-and-set operation achieves optimistic lock)?

Like many other databases, Redis provides a transactional mechanism as a NoSQL database. I n Redis, the four commands MULTI/EXEC/DISCARD/WATCH are the cornerstones of our implementation. I believe this concept is no stranger to developers with experience in database development, and even so, we'll list it briefly

In Redis

The implementation characteristics of the transaction:

1). All commands in the transaction will be executed in serial order, and during the execution of the transaction, Redis will no longer provide any services for requests from other clients, thus ensuring that all commands in the thing are executed by atoms.

2). In a Redis transaction, if a command fails to execute, the subsequent command will continue to execute compared to the transaction in the relationship database.

3) We can open a transaction with the MULTI command that can be understood as a "BEGIN TRANSACTION" statement by someone with experience in database development. C ommands executed after that statement are treated as actions within a transaction, and finally we can commit/roll back all operations within the transaction by executing the EXEC/DISCARD command. T hese two

Redis commands can be considered equivalent to COMMIT/ROLLBACK statements in a relationship database.

4). All statements to be executed will not be executed by the server until the transaction is turned on, if there is a communication failure between the client and the server that causes the network to disconnect. H owever, if the network outage event occurs after the client executes the EXEC command, all commands in the transaction are executed by the server.

5). When using TheEnd-Only mode, Redis writes all writes within the transaction to disk in this call by calling the system function write. H owever, if there is a system crash during the write process, such as an outage caused by a power failure, then perhaps only part of the data is written to disk and the other part is lost.

The Redis server performs a series of necessary consistency tests upon restart, exiting as soon as a similar problem is found and giving the appropriate error warning. A t this point, we'll take advantage of the redis-check-aof tool available in the Redis toolkit, which helps us locate errors in data inconseciency and write to the parts that have already been written

data is rolled back. A fter the fix, we can restart the Redis server again.


13.WATCH command and CAS-based optimistic lock:

In Redis' transactions, watch commands can be used to provide CAS (check-and-set) functionality. A ssuming that we monitor multiple Keys before the transaction executes through the WATCH command, if any Key values change after watch, the transaction executed by the EXEC command is discarded and a Null multi-bulk answer is returned to notify the caller transaction

The execution failed. F or example, let's assume again that the incr command is not provided in Redis to complete the atomic increment of key values, and if we want to do that, we'll have to write the appropriate code ourselves. The pseudocode is as follows:

  val = GET mykey
  val = val + 1
  SET mykey $val

The above code can only be guaranteed to execute correctly with a single connection, because if multiple clients execute the snippy code at the same time, an error scenario that often occurs in multithreaded programs, race contention, occurs. F or example, clients A and B both read mykey's original value at the same time, assuming a value of 10, and then both clients added the value back to the Redis server, resulting in mykey resulting in a result of 11 instead of what we thought was 12. To solve a similar problem, we need help with the WATCH command, see the following code:

  WATCH mykey
  val = GET mykey
  val = val + 1
  MULTI
  SET mykey $val
  EXEC

Different from the previous code, the new code monitors the key with the WATCH command before getting the value of mykey, and then surrounds the set command in a transaction, so that each connection can effectively guarantee that each connection will fail if the value of mykey obtained by the current connection is modified by the other connected client. T his allows the caller to know if the val was reset successfully after determining the return value.


14. Redis persistence in several ways

1, snapshot (snapshots)

By default, Redis stores a snapshot of the data in a binary file on disk named dump.rdb. Y ou can configure Redis' persistence policies, such as writing data to disk with more than M updates per N second in the data set, or you can manually call the command SAVE or BGSAVE.

How it works

. R edis forks.

. T he child process begins to write the data to the temporary RDB file.

. W hen the child process is done writing the RDB file, replace the old file with the new file.

. T his approach allows Redis to use copy-on-write technology.

2、AOF

Snapshot mode is not very robust, and when the system stops, or if Redis is accidentally dropped by kill, the data that is eventually written to Redis is lost. T his may not be a big problem for some applications, but for applications that require high reliability,

Redis is not an appropriate choice.

Append-only file mode is another option.

You can turn on AOF mode in the configuration file

3, virtual memory mode

It's better to use VM when your key is small and the value is big. B ecause the memory savings are relatively large.

When your key is not small, consider using some very methods to turn a big key into a big value, for example, you can consider combining key and value into a new value.

vm-max-threads this parameter, you can set the number of threads to access the swap file, set the best not to exceed the number of cores of the machine, if set to 0, then all operations on the swap file are serial. T his can cause long delays, but there is a good guarantee of data integrity.

When I tested myself, I found that virtual memory performance was also good. I f the amount of data is large, consider distributed or other databases


15.redis cache failure policy and primary key failure mechanism

As a caching system to clean up invalid data on a regular basis, you need a primary key failure and elimination strategy.

In Redis, the survival key is called volatile. W hen you create a cache, you set a lifetime for a given key, and when the key expires (the lifetime is 0), it may be deleted.

1, affecting the survival time of some operations

Lifetime can be removed by using the DEL command to remove the entire key, or by the SET and GETSET commands overwriting the original data, that is, modifying the key corresponding to the value and overwriting the current data after using the same key and value.

For example, executing an INCR command on a key, an LPUSH command on a list, or the HSET command on a hash table does not modify the time to live for the key itself. O n the other hand, if you use RERENAME to change the name of a key, the key after the name change has the same lifetime as before the name change.

Another possibility of the RENAME command is to try to rename a key with a lifetime to another another_key with a lifetime, when the old another_key (and its lifetime) is deleted and the old key is renamed another_key, so the new another_key has the same lifetime as the original key. U sing the PERSIST command, you can remove the key's lifetime without deleting the key, making the key a persistent key again.

2, how to update the survival time

ExPIRE commands can be executed on a key that already has a lifetime, and the newly specified lifetime replaces the old time to live. T he accuracy of the expiration time has been controlled within 1ms, and the time complexity of the primary key failure is O(1),

WITH EXPIRE and TTL commands, TTL can see key's current survival time. T he setting returns 1 successfully, and 0 when the key does not exist or cannot set a lifetime time for the key.

The maximum cache configuration

In redis, the user is allowed to set the maximum amount of memory used

server.maxmemory

The default is 0, no maximum cache is specified, and if new data is added beyond the maximum memory, it crashes, so be sure to set it. W hen the size of the redis memory dataset rises to a certain size, a data obsolete strategy is implemented.

Redis offers six data elimination strategies:

. V olatile-lru: Pick the most recent least-used data obsolete from a dataset that has set an expiration time (server.db .i.expires).

. V olatile-ttl: Pick the data that is about to expire from a dataset that has an expiration time set (server.db .expires).

. V olatile-random: Any selection of data obsolete from a dataset that has an expiration time set (server.db .i.expires).

. a llkeys-lru: Pick the most recent least-used data obsolete from the data set (server.db .dict).

. a llkeys-random: Select any data .db data set (server) (i.dict).

. N o-enviction (expulsion): Expulsion data is prohibited

Note that the six mechanisms here, volatile and allkeys, dictate whether to phase out data for data sets that have expired or from all datasets, followed by lru, ttl, and random as three different elimination strategies, plus a no-enviction never-recycling strategy.

Use policy rules:

1, if the data presents a power law distribution, that is, some of the data access frequency is high, part of the data access frequency is low, then use allkeys-lru

2, if the data is equally distributed, that is, all data access frequency is the same, then use allkeys-random

Three data phase-out strategies:

ttl and random are easier to understand, and the implementation is simpler. Mainly Lru has recently used the least phase-out strategy, which is designed to sort keys by failure time and then take the first failed keys for elimination.

The above is W3Cschool for you to bring the redis interview question summary, I hope to help you.