Example analysis of Redis backup, disaster recovery and high availability practice

1. A brief introduction to Redis

Redis is a high-performance key-value non-relational database. Due to its high-performance characteristics, it supports high availability, persistence, and multiple A variety of data structures, clusters, etc. make it stand out and become a commonly used non-relational database.

In addition, Redis has many usage scenarios.

Session Cache

Redis cache session has a very good advantage, because Redis provides persistence, in application scenarios that need to maintain sessions for a long time, such as shopping cart scenarios. The scene can provide good long session support and provide users with a good shopping experience.

Full page caching

In WordPress, Pantheon provides a good plug-in wp-redis, which can load the pages you have browsed at the fastest speed.

Queue

Redis supports list and set operations, so it is very suitable for use as a message queue platform. We often use Reids’ queue function to limit purchases. For example, during holidays or promotion periods, some activities may be carried out to restrict users' purchasing behavior, limiting them to only a few purchases today or only once within a period of time. It is also more suitable for application.

Ranking

Redis implements the operation of incrementing or decrementing numbers in memory very well. Therefore, we use Redis in many ranking scenarios. For example, novel websites rank novels and recommend top-ranked novels to users based on the ranking.

Publish/Subscribe

Redis provides publish and subscribe functions. There are many scenarios for publish and subscribe. For example, we can use the publish and subscribe functions of Redis to create a script based on publish and subscribe script triggers. Up chat system.

In addition, there are many other scenarios in which Redis performs well.

2. Single point of failure problem in the use of Redis

Redis is used in various companies. Its multiple excellent features and rich application scenarios are the reason for its existence. . Then the problems and risks will come. Although Redis has rich application scenarios, some companies still use single-node deployment relatively conservatively when practicing Redis applications, which brings security risks to future maintenance.

I once dealt with a business interruption problem caused by a single point of failure in 2015. When Redis was first deployed, it used a single-node deployment rather than a distributed deployment, and did not consider disaster recovery issues.

At that time, we used the Redis server to control the user's purchase of discounted goods. However, due to unknown reasons, the server of the Redis node went down, resulting in us being unable to control the user's purchase behavior, resulting in the user being able to The behavior of purchasing discounted products multiple times within a period.

This kind of downtime accident can be said to have caused irreparable losses to the company. The security risk problem is very serious. As the person who operated and maintained the system at the time, it was necessary for me to repair this problem and improve the architecture. improvements on. Therefore, I started researching and learning about ways to solve Redis single point of failure in non-distributed applications.

3. Backup and disaster recovery of Redis applications in non-distributed scenarios

Redis master-slave replication should be very common now. Commonly used master-slave replication architectures include the following two architecture solutions.

Commonly used Redis master-slave replication

Option 1

Under normal circumstances, This structure is the most common, with one master node and two slave nodes. When the client writes data, it writes to the Master node, and when reading, it reads from two Slaves. This achieves read expansion and reduces the read load on the Master node.

Option 2

This architecture also has one Master and two Slaves. Master and Slave1 use keepalived to implement VIP migration in different ways. When the Client connects to the Master, it connects through VIP. This avoids the situation of IP change in Solution 1.

Advantages and disadvantages of Redis master-slave replication

Advantages

It realizes the backup of master data, once the master fails , the slave node can be promoted to the new master and continue to provide services in place of the old master

to achieve read expansion. The master-slave replication architecture is generally used to achieve read expansion. Master mainly implements the writing function, and Slave implements the reading function

Insufficiency

Architecture Solution 1

When the Master fails , the Client is disconnected from the Master and cannot implement the write function. At the same time, the Slave cannot copy from the Master.

At this time, you need to go through the following operations (assuming that Slave1 is promoted to Master):

1. Execute the slaveof no one command on Slave1 to upgrade Slave1 is the new Master node.

2. Configure Slave1 to be writable. This is because in most cases, slave is configured as read-only.

3. Tell the client (that is, the program that connects to Redis) the connection address of the new Master node.

4. Configure Slave2 to copy data from the new Master.

Architecture Plan 2

When the master fails, the Client can connect to Slave1 for data operations, but Slave1 becomes a single point, there is a single point of failure (single point of failure) that often needs to be avoided.

After that, you need to go through the following operations:

1. Execute the slaveof no one command on Slave1 to promote Slave1 as the new Master node

2. Configure Slave1 to be writable. This is because in most cases, the Slave configuration is read-only.

3. Configure Slave2 from the new Master. Data replication

It should be noted that all architectural solutions require manual intervention for failover. The need for manual intervention increases the workload of operation and maintenance, and also has a huge impact on the business. At this time, you can use Redis's high-availability solution - Sentinel

IV. Introduction to Redis Sentinel

Redis Sentinel provides a high-availability solution for Redis. From a practical perspective, using Redis Sentinel can create a Redis environment that prevents certain failures without human intervention.

Redis Sentinel adopts a distributed architecture and runs multiple processes for collaborative cooperation. Run multiple Sentinel processes to cooperate. When multiple Sentinels can no longer provide services to a given master, fault detection will be performed, which will reduce the possibility of false positives.

5. Redis Sentinel functions

The main functions of Redis Sentinel in the Redis high availability solution include the following functions:

Monitoring

Sentinel will constantly check whether the master and slave are running normally as expected

Notification

Through API, Sentinel can notify system administrators and programs The monitored Redis instance fails

Automatic failover

If the master does not run as expected, Sentinel can start the failover process, and one of the slaves will If it becomes the master, other slaves will be reconfigured to use the new master. Applications using the Redis service will also be notified to use the new address when connecting.

Configuration provider

Sentinel can be used as the authentication source for client service discovery: the client connects to Sentinel to obtain the Redis master address currently responsible for a given service. If a failover occurs, Sentinel will report the new address.

6. Redis Sentinel Architecture

##7. Redis Sentinel Implementation Principle

The Sentinel cluster monitors itself and Redis master-slave replication. When it is discovered that the Master node fails, the following steps will be followed:

• 1) An election is held between Sentinels to elect a leader, and the elected leader will perform failover

• The Sentinel leader selects one from the Slave nodes as the new master node. Here is a rewrite of that sentence: To implement slave election, the following election methods need to be performed: a) The time to disconnect from the master

If the time to disconnect from the master exceeds down-after-milliseconds (sentinel configuration ) * 10 seconds plus the time from when sentinel determines that the master is unavailable to when sentinel starts to perform failover, it is considered that the slave is not suitable for promotion to master.

b) Slave priority

Each slave has a priority, which is stored in the redis.conf configuration file. If the priorities are the same, proceed.

c) Copy offset position

The copy offset records where the data is copied from the master. The larger the copy offset, the more data is received from the master. If the copy offset is Likewise, continue with the election

d) Run ID

Elect the Slave with the smallest Run ID as the new Master

The flow chart is as follows:

• 3) Sentinel leader will perform slaveof no one operation on the new master elected in the previous step and promote it to the master node

• 4) The Sentinel leader sends commands to other slaves to make the remaining slaves the slaves of the new master node

• 5) The Sentinel leader will let the original The master is downgraded to slave. When normal operation resumes, the Sentinel leader will send a command to replicate from the new master.

The above failover operations are all completed by Sentinel itself without any manual intervention.

The above is the detailed content of Example analysis of Redis backup, disaster recovery and high availability practice. For more information, please follow other related articles on the PHP Chinese website!