1. How to ensure high availability and concurrency of Redis?

Redis master-slave architecture, with one master and many slaves, can meet high availability and high concurrency. When the instance is down, the system automatically performs an active/standby switchover. Configure read/write separation to relieve the Master read/write pressure.

2. How to implement the Redis high availability scheme?

This can be achieved by using the officially recommended Sentinel mechanism. When the primary node fails, Sentinel automatically completes the fault detection and transfer, and notifying the application party, thus achieving high availability.

It has four main functions:

  • Cluster monitoring: Monitors whether the Redis master and Slave processes are working properly.
  • Message notification. If a Redis instance fails, the sentry is responsible for sending a message as an alarm notification to the administrator.
  • Failover. If the master node fails, it is automatically transferred to the slave node.
  • Configure the center to notify the client client of the new master address if failover occurs.

3. Can you talk about how Redis sentry works?

After starting Redis in Sentinel mode, it automatically monitors the running status of master/slave. The basic principle is as follows: heartbeat mechanism + voting decision.

Each sentinel periodically sends messages to other Sentinal, master, and slave servers to check whether the sentinel is alive or not. If the sentinel fails to respond within the specified time, the sentinel is temporarily considered to be down.

If most sentinels in the sentinel cluster report that a master is not responding, the system considers the master to be down. Through Raft voting algorithm, one of the remaining slave nodes is selected to be promoted as master, and then the relevant configuration is automatically modified.

4. What should be paid attention to when deploying Redis sentry?

Sentinels need at least three instances to be robust. Sentinel tutorial and how to integrate with Spring Boot.

5. Will Redis master/slave architecture data be lost? Why?

There are two types of data loss:

1) Data loss caused by asynchronous replication: The master -> slave replication is asynchronous, so some data may break down before being replicated to the slave, and some data may be lost.

2) Data loss caused by split brain: a master’s machine suddenly disconnects from the normal network and cannot be connected to other slave machines, but the master is still running. In this case, the sentry may think that the master is down, and then open elections to switch other slaves to master. At this point, there will be two masters in the cluster, which is called split brain. At this time, a slave is switched to the master, but data written to the old master may be lost before the slave is switched to the new master. Therefore, when the old master is recovered, it is attached to the new master as a slave, and its own data is cleared and data is copied from the new master.

6. How does Redis master slave replication work?

1) A Slave instance issues SYNC whenever it is first connected or reconnected to the Master;

2) when the Master receives SYNC, it does two things :(a) the Master BGSAVE, which is to save data to disk in the background (RDB snapshot file); (b) The Master simultaneously buffers newly received commands to write and modify data sets (non-query classes);

3) After the Master saves data to a snapshot file in the background, the Master sends the snapshot file to the Slave. The Slave clears the memory and loads the snapshot file into the memory.

4) The Master forwards the commands collected in the buffer to the Slave through the Reids command protocol, and the Slave executes these commands to synchronize with the Master.

5) The Master/Slave will continue to synchronize commands asynchronously to achieve the consistency of the final data synchronization;

7. How to deal with expired data read due to master-slave delay?

1) Scan libraries by using the scan command: When a key in Redis is scanned, it is equivalent to accessing the key, and expiration detection is also performed, giving full play to the Redis lazy deletion policy. This method greatly reduces the probability of reading dirty data. However, its disadvantages are obvious. It may cause some database pressure, otherwise, the efficiency of online services will be affected.

2) Redis has added a new feature to solve the problem of reading expired data due to inconsistency between master and slave. It has added whether the key is expired and whether the master or slave library is expired. If the key is expired, the currently accessed master will return NULL. Null is also returned when the current access is from a slave library and a read-only command is executed.

8. What are the expiration strategies of Redis Key?

1) Lazy delete: When an expired key is read/written, the lazy delete policy is triggered and the expired key is deleted directly, which is obviously passive.

2) Regular deletion: Because the lazy deletion strategy cannot ensure that cold data can be deleted in time, Redis will regularly take the initiative to eliminate a batch of expired keys.

3) Active deletion: When the current used memory exceeds the maxMemory limit, the active deletion policy is triggered. Active setting is preceded by setting the value of maxMemory.

The last

Thank you for reading the last, if the article is not enough, welcome to support in the comment section, give your opinion. If you find my article helpful, give me a thumbs up.