Redis is a non-relational database containing multiple data structures, memory-based, optional persistent key-value storage system, and APIs in multiple languages.
Application scenario
- Hotspot data caching
- Distributed session
- Counter and mark related issues
- Leaderboard related issues
- Distributed lock
- Other business data that are immutable or have little chance of change
type of data
- String
- Hash
- List
- Set
- Zset/Sorted set: ordered set
- High-level: HyperLogLog, Geo, Pub/Sub, BloomFilter, RedisSearch, Redis-ML, etc.
Principle analysis
- When the redis server starts, it will register AE_READABLE with eventLoop (IO multiplexing).
- The client requests to establish a connection with the server, and the server generates the Scoke (s1) channel and binds the AE_READABLE event.
- The client (s1) requests to execute set key value (write command), s1 triggers AE_READABLE. The command requester
reads the key and value into the memory and modifies the data - After setting the value, associate s1 with the AE_WRITABLE event to trigger the write operation. After success, the command replyer will output the result "OK"
- The returned result unbinds the AE_WRITABLE event of s1 from the command reply processor.
IO multiplexing
IO multiplexing: I/O refers to network I/O, multiplexing refers to multiple TCP connections (ie socket or channel), multiplexing refers to multiplexing one or several threads. This means that one or a group of threads handle multiple TCP connections. The biggest advantage is to reduce the system overhead, do not have to create too many processes/threads, and do not need to maintain these processes/threads.
Main mechanism: select, poll, epoll
select mechanism:
basic principle:
These three file descriptors (fd for short) are generated when the client operates the server: writefds (write), readfds (read), and exceptfds (exception). select will block the monitoring of 3 types of file descriptors, and will return when there is data, readable, writable, abnormal or timeout; after returning, find the ready descriptor fd by traversing the entire array of fdset, and then perform the corresponding IO operating.
advantage:
- It is supported on almost all platforms, with good cross-platform support.
Disadvantages:
-
Since the polling method is used for full scan, the performance will decrease as the number of file descriptors FD increases.
-
Every time you call select(), you need to copy the fd set from user mode to kernel mode and traverse (message transmission is from kernel to user space)
-
The default limit of FD opened by a single process is 1024, and the macro definition can be modified, but the efficiency is still slow.
Poll mechanism:
basic principle: the
basic principle is the same as that of select, which is also polling + traversal; the only difference is that poll does not have a maximum file descriptor limit (using a linked list to store fd).
epoll mechanism:
basic principle:
there is no limit on the number of fd, the user mode is copied to the kernel mode only once, and the time notification mechanism is used to trigger. Register fd through epoll_ctl, once fd is ready, it will activate the corresponding fd through the callback mechanism to perform related io operations.
The high performance of epoll is due to its three functions:
- When the epoll_create() system starts, apply for a B+ tree structure file system in the Linux kernel, and return the epoll object, which is also an fd
- epoll_ctl() Every time a new connection is created, the epoll object is manipulated through this function, the corresponding link fd is modified, added and deleted in this object, and a callback function is bound
- epoll_wait() Rotates all callback sets and completes the corresponding IO operation
Advantages:
1. There is no fd limit, the upper limit of the supported FD is the maximum number of file handles of the operating system, and 1G memory supports approximately 100,000 handles
. 2. Improved efficiency , Using callback notification instead of polling, will not decrease efficiency as the number of FDs increases
. 3. The kernel and user space mmap are implemented in the same memory (mmap is a method of memory mapping files, that is, a file or other object mapping To the address space of the process).
Example:
1 million connections, of which 10,000 connections are active, we can compare the performance of select, poll, and epoll
select: the macro definition is not modified, the default is 1024, l requires 100w/1024 =977 processes can support 1 million connections, which will make the CPU performance particularly poor.
Poll: There is no limit on the maximum file descriptor, 100w fd is required for 1 million links, and the traversal cannot respond, and the copy of space consumes a lot of resources.
epoll: When the request comes in, create fd and bind a callback, the main need to traverse 1w active connection callbacks, that is efficient without memory copy
Persistence
Persistence is to write memory data to disk to prevent memory data loss when the service is down.
Redis provides two persistence methods: RDB (default) and AOF
RDB:
RDB persistence refers to writing a snapshot of a data set in memory to disk within a specified time interval. The actual operation process is to fork a child process. The data set is written into a temporary file. After the writing is successful, the previous file is replaced and stored with binary compression.
Default configuration:
save 900 1 #After 900 seconds (15 minutes), if at least one key changes, dump the memory snapshot.
save 300 10 #After 300 seconds (5 minutes), if at least 10 keys have changed, dump the memory snapshot.
save 60 10000 #After 60 seconds (1 minute), if at least 10,000 keys have changed, dump the memory snapshot.
Advantage:
- RDB files are compact, full backups, very suitable for backup (cold standby) and disaster recovery.
- Maximize performance. For the Redis service process, when it starts to persist, the only thing it needs to do is to fork the child process, and then the child process will complete the persistence work, which can greatly avoid the service process from performing IO operations.
- RDB is faster in restoring large data sets than AOF.
AOF:
Full backup is always time-consuming. Sometimes we provide a more efficient way of AOF. The working mechanism is very simple. Redis will append every write command received to the file through the write function. The popular understanding is logging.
Default configuration:
appendfsync always #AOF file will be written every time there is data modification.
appendfsync everysec #Sync once every second, this strategy is the default strategy of AOF.
appendfsync no #Never synchronize. Efficient but the data will not be persisted.
Advantage:
- AOF can better protect data from loss. Generally, AOF will perform an fsync operation through a background thread every 1 second, and lose up to 1 second of data.
- The AOF log file does not have any disk addressing overhead, the writing performance is very high, and the file is not easily damaged.
- Even if the AOF log file is too large, the background rewrite operation will not affect the client's reading and writing.
- The commands of the AOF log file are recorded in a very readable way. This feature is very suitable for emergency recovery of catastrophic accidental deletion. For example, if someone accidentally emptied all data with the fluxhall command, as long as the background rewrite has not occurred at this time, then you can copy the AOF file immediately, delete the last fluxhall command, and then put the AOF file back.
How to choose RDB and AOF to automatically restore all data through the recovery mechanism
The editor recommends my own C/C++Linux server development technology exchange group: [960994558] I have compiled some learning books and video materials that I think are better for sharing (including C/C++, Linux, Nginx, ZeroMQ, MySQL, Redis, fastdfs, MongoDB, ZK, streaming media, CDN, P2P, K8S, Docker, TCP/IP, coroutine, DPDK, etc.), you can add it yourself if you need it! ~
Cluster mode
Redis provides a total of three cluster modes:
master-slave replication/synchronization, sentinel mode, and Cluster cluster
Master-slave replication/synchronization
In order to avoid a single point of failure, the usual practice is to replicate multiple copies of the database to deploy on different servers, so that even if one server fails, other servers can continue to provide services. To this end, Redis provides a replication function, which can automatically synchronize the updated data to other databases when the data in one database is updated.
In the concept of replication, databases are divided into two categories, one is the master database (master), and the other is the slave database (slave). The master database can perform read and write operations, and when the write operation causes data changes, it will automatically synchronize the data to the slave database. The slave database is generally read-only and accepts data synchronized from the master database. A master database can have multiple slave databases, and a slave database can only have one master database.
principle
- Connect to the main database from the database and send the SYNC command;
- After the main database receives the SYNC command, it starts to execute the BGSAVE command to generate the RDB file and uses the buffer to record all write commands executed thereafter;
- After the master database BGSAVE is executed, it sends a snapshot file to all slave databases, and continues to record the executed write commands during the sending;
- After receiving the snapshot file from the database, discard all old data and load the received snapshot;
- After the master database snapshot is sent, it starts to send the write command in the buffer to the slave database;
- Complete the loading of the snapshot from the database, start to receive command requests, and execute write commands from the main database buffer; (completed from database initialization)
- Each time the master database executes a write command, it will send the same write command to the slave database, receive and execute the received write command from the database (operation after the initialization of the slave database is completed)
- After disconnection and reconnection, the version after 2.8 will transmit the commands during the disconnection period to the re-database for incremental replication.
- When the master and slave are just connected, perform full synchronization; after the full synchronization ends, perform incremental synchronization. Of course, if necessary, the slave can initiate full synchronization at any time. Redis's strategy is, in any case, it will first try to perform incremental synchronization, if it is unsuccessful, request the slave to perform full synchronization.
Advantages:
1. Supports master-slave replication, the master will automatically synchronize data to the slave, which can separate read and write;
2. In order to offload the read operation pressure of the Master, the Slave server can provide read-only operation services for the client;
3 .Slave can also accept connection and synchronization requests from other Slaves, which can effectively offload the synchronization pressure of the Master;
4. The Master Server provides services to Slaves in a non-blocking manner. Therefore, during Master-Slave synchronization, the client can still submit query or modification requests;
5. Slave Server also completes data synchronization in a non-blocking manner. During synchronization, if a client submits a query request, Redis will return the data before the synchronization;
Disadvantages:
1. Redis does not have automatic fault tolerance and recovery functions. The downtime of the host and slave will cause the front-end read and write requests to fail, requiring waiting Restart the machine or manually switch the front-end IP;
2. The host is down, and some data cannot be synchronized to the slave in time before the downtime. After the IP is switched, data inconsistency will be introduced, which reduces the availability of the system;
3. If multiple slaves are disconnected and need to be restarted, try not to restart at the same time. Because as long as the slave is started, it will send a sync request and the host will be fully synchronized. When multiple slaves are restarted, it may cause the Master IO to increase sharply and cause downtime.
4. Redis is difficult to support online expansion, and online expansion will become very complicated when the cluster capacity reaches the upper limit;
5. Because all slave servers have a full data backup of the master server, the total amount of data supported is limited.
Sentinel mode
In the master-slave synchronization/replication mode, when the master server goes down, a slave server needs to be manually switched to the master server, which requires manual intervention, laborious, and unavailable services for a period of time. This is not a recommended way. More often, we give priority to sentinel mode.
The sentinel mode is a special mode. First of all, Redis provides the sentinel command. The sentinel is an independent process. As a process, it will run independently. The principle is that the sentinel can monitor multiple Redis instances running by sending commands and waiting for the response from the Redis server.
effect:
- Send commands to let the Redis server return to monitor its running status, including the master server and the slave server;
- When the sentinel detects that the master is down, it will automatically switch the slave to the
master, and then notify other slave servers through the publish and subscribe mode, modify the configuration file, and let them switch the master;
principle:
- Each Sentinel
process sends a PING command to the master server, slave server and other Sentinel processes in the entire cluster at a frequency of once per second . - If a master master server is marked as subjectively offline (SDOWN), all
Sentinel processes that are monitoring the master master server must confirm that the master master server has indeed entered a subjective offline state at a frequency of once per second - When a sufficient number of Sentinel processes (greater than or equal to the value specified in the configuration file) confirm that the Master
master server has entered the subjective offline state (SDOWN) within the specified time range , the Master master server will be marked as objectively offline (ODOWN) - In general, each Sentinel process will
send an INFO command to all the Master and Slave servers in the cluster at a frequency of once every 10 seconds . - When the Master master server is marked as ODOWN by the Sentinel process, the Sentinel process goes offline to all the
master master servers
The frequency of Slave sending INFO commands from the server will be changed from once every 10 seconds to once every second.
6. If there are not enough Sentinel processes to agree to the offline master server, the objective offline status of the master master server will be removed. If the Master master server sends a PING command to the Sentinel process to return a valid reply, the subjective offline status of the Master master server will be removed.
Advantages:
- The sentinel mode is based on the master-slave mode, all the advantages of the master-slave, the sentry mode has.
- The master and slave can switch automatically, the system is more robust and the usability is higher.
Cluster
Redis's sentinel mode can basically achieve high availability, read-write separation, but in this mode, each Redis server stores the same data, which is a waste of memory, so the Cluster cluster mode is added to redis3.0 to realize Redis Distributed storage means that different content is stored on each Redis node.
principle:
- On each node of Redis, there are two things, one is a slot, and its value range is 0--16383. Another is cluster, which can be understood as a cluster management plug-in. When our access key arrives, Redis will get a result according to the algorithm of crc16, and then calculate the remainder of the result to 16384, so that each key will correspond to a hash slot numbered between 0--16383, and pass This value is used to find the node corresponding to the corresponding slot, and then automatically route to the corresponding node for access operations.
- In order to ensure high availability, the redis-cluster
cluster introduces a master-slave mode. A master node corresponds to one or more slave nodes. When the master node goes down, the slave nodes are enabled. When other master nodes ping a master node A
, if more than half of the master nodes communicate with A overtime, then the master node A is considered down. If the master node A and its slave node A1
are down, the cluster can no longer provide services.
advantage:
- The cluster is completely decentralized, using multiple masters and multiple slaves; all redis nodes are interconnected with each other (PING-PONG mechanism), and a binary protocol is used internally to optimize transmission speed and bandwidth.
- The client is directly connected to the Redis node and does not require an intermediate proxy layer. The client does not need to connect to all nodes in the cluster, just connect to any available node in the cluster.
- Each partition is composed of a Redis master and multiple slaves, and shards and shards are parallel to each other.
Cache avalanche, breakdown, penetration
Cache avalanche
Cache avalanche refers to the restart of the cache server or the failure of a large number of caches at a certain point in time, which causes a large number of requests to reach the database, which leads to the unavailability of the database
solution:
- When storing cached data in batches, add a random value to the cache invalidation time
- Hot data will never expire, update the cache when there is an update operation (note that the double write is consistent) just fine
Cache breakdown
Cache breakdown is similar to avalanche, it refers to a key (very hot key) failure at a certain point in time, which causes all requests to hit the database.
Solution:
- Using mutex locks, only one request is allowed to reload the latest data of the database into redis at the moment of key failure, and the rest of the threads still get it from redis
- You can also set the hot data to never expire, and update the cache when there is an update operation (note that the double write is consistent).
Cache penetration
Cache penetration refers to data that is not in the cache or the database, and users continue to request the general cache system. Some malicious requests will deliberately query non-existent keys. The request volume is large, which will cause a lot to the back-end system. pressure.
solution:
- Add parameter verification at the interface level to filter illegal requests
- Store the data that cannot be retrieved in the cache and the data that is not retrieved in the database also in redis and set the expiration time
- Using bloom filter, you can see the analysis of bloom filter, judge whether the data exists through bloom filter, and return if it does not exist.
The above shortcomings are welcome to point out the discussion