Redis Why so fast ?

Redis It's a kind of key-value Memory database , In many business scenarios , Will use redis. One of the core reasons is redis Soon , Then why Redis So fast ?Redis What is the core of design ? Let's discuss it here .

1.Redis Data structure supported

string( character string )

byte array , The maximum limit is 1G byte

1. Binary sequence string . 2. Integer data . 3. Floating point data .

hash( Hash )

key-value Pair composition

list: Ordered string sequence

Maximum length is 2^32

set: aggregate

Duplicate elements are not allowed in a Set


Duplicate elements are not allowed in a Set

Added sorting function

2. Redis The reason is that the execution speed is very fast

Redis It's pure memory , Reading and writing speed is very fast

Avoid hard disk I/O Speed limit

Single threaded operation , Saves context switching thread time

Non blocking I/O Multiplexing mechanism

3. Redis Ten common interview questions

3.1 Redis And Memcached Differences between

redis Support richer data types ,Memcached Only support string type

Redis Support data persistence ,Memecache Store all data in memory

Memcached It's multithreading , Non blocking IO Reusable network model ;Redis Non blocking with single thread IO Multiplexing model

3.2 Redis support 5 Data types , Why is the speed so fast ?

Redis Full use hash structure , Fast reading speed , Data stored in memory , be similar to HashMap,HashMap The advantage of is that the time complexity of search and operation is O(1); Simple data operation , Different scenarios use different data types .

3.3 Redis Why is it single threaded ?

Redis Is a memory based operation ,CPU no Redis Bottleneck of ,Redis The most likely bottleneck is the size of machine memory or network bandwidth . Since single thread is easy to implement , and CPU Will not become a bottleneck , Then it is logical to adopt the single thread scheme .redis
Single thread refers to a thread used by the network request module , That is, one thread handles all network requests , Other modules still use multiple threads .

3.4 Redis Common usage scenarios

Application of time limited business ( Limited time offer information , Mobile phone verification code , Current limiting and other business scenarios )


Ranking List

Distributed lock

queue ( Second kill activity )

3.5 Redis in “ avalanche ” problem

A large number of Keys expire in the cache at the same time ( invalid ), Instant requests fall into the database instantly, resulting in connection exceptions .

Prevention strategy :

Mutex queue

All possible reasonable requests ( Request parameters ), Put on the white list , Illegal direct access ban

Multilevel cache , cache A,B, … The expiration time of the cache is different

Interface current limiting and fusing , Demotion

3.6 Data consistency between cache and database

Data inconsistency between cache and database often occurs when using cache : If the project is strong consistency , Caching is not recommended ; Use caching for frequent access , Infrequently changed data . Issues to consider : Refresh cache , Cache expiration time , Cache fetch failed , Multilevel cache, etc .

3.7 Redis Data elimination algorithm

Redis All data is stored in memory , But memory is a limited resource , So to prevent Redis Unlimited use of memory , At startup Redis You can use the configuration item maxmemory To specify the maximum amount of memory it can use .

volatile-lru: Least recently used algorithm , Select the key value pair with the longest idle time from the keys with the expiration time set, and clear it

volatile-lfu: Algorithms are least frequently used recently , Select the key value pair with the lowest frequency in a certain period of time from the keys with the expiration time set, and clear it

volatile-ttl: Select the key value pair with the earliest expiration time from the keys with the expiration time set to clear

volatile-random: From the key with the expiration time set , Random selection key to clear

allkeys-lru: Least recently used algorithm , Select the key value pair with the longest idle time from all keys to clear

allkeys-lfu: Algorithms are least frequently used recently , Select the key value pair with the least frequent use in a certain period of time from all keys to clear

allkeys-random: In all keys , Random selection key for deletion

noeviction: Do not do any cleaning work , stay redis After the memory exceeds the limit , All write operations return errors ; But the read operation can proceed normally

3.8 Redis Second kill problem

Simple thought :

Implement three queues , Commodity queue , User successfully purchased queue , User waiting queue

Put a specified number of products into the product queue

Asynchronous order processing , Fail to add inventory ;

3.9 Redis Master slave synchronization problem

stay Redis in , Users can execute SLAVEOF Command or setting slaveof option , Let a server copy (replicate) Another server , We call the replicated server the primary server (master), The server that replicates the master server is called the slave server (slave)

The synchronization operation from the slave server to the master server needs to be sent to the master server SYNC Command to complete , Here is SYNC Execution steps of the command :

Send from server to master server SYNC command ;

received SYNC Master server execution of command BGSAVE command , Generate a in the background RDB file , And use a buffer to record all write commands executed from now on ;

When the primary server BGSAVE When the command is completed , The master server will BGSAVE Command generated RDB Send file to slave server , Receive and load this from the server RDB file , Update your database status to the master server for execution BGSAVE Database state at command time .

The master server sends all write commands recorded in the buffer to the slave server , Execute these write commands from the server , Update your database status to the current status of the primary server database .

3.10 Redis Publish and subscribe

Redis It provides publish and subscribe functions , It can be used for message transmission ,Redis The publish subscribe mechanism includes three parts , Publisher , Subscribers and Channel.
Both publishers and subscribers are Redis client ,Channel Then Redis Server side , The publisher sends a message to a channel , Subscribers who subscribe to this channel can receive this message .Redis This publish subscribe mechanism is similar to topic based publish subscribe ,Channel Equivalent to theme .

4. conclusion

The above is Redis All knowledge points included , No matter in the actual project development , Or do you have to master these in the interview .



Post Views: