Shulou(Shulou.com)05/31 Report--

How to achieve backup and disaster recovery in Redis, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

1. Session caching (Session Cache)

Redis caching session has a very good advantage, because Redis provides persistence, provides good long session support in application scenarios that require long-term session persistence, such as shopping cart scenarios, and provides users with a good shopping experience.

two。 Full page cache

In WordPress, Pantheon provides a good plug-in, wp-redis, which can load pages you have visited as quickly as possible.

3. Queue

Reids provides list and set operations, which makes Redis a good message queuing platform to use.

We often make purchase restrictions through the queuing function of Reids. For example, during the holiday or promotion period, carry out some activities to restrict the purchase behavior of users, and limit the purchase of goods only a few times today or only once in a period of time. It is also more suitable for application.

4. Ranking

Redis performs very well in incrementing or decrementing numbers in memory. So we will use Redis in many ranking scenes, such as the novel website to rank the novel, according to the ranking, recommend the top novel to the user.

5. Publish / subscribe

Redis provides publish and subscribe functions, and there are many scenarios of publishing and subscribing. For example, we can use the publish and subscribe functions of Redis to build a chat system based on publish and subscribe script triggers.

There are a lot of other scenarios, and Redis is doing well.

Second, the single point of failure in the use of Redis

It is precisely because Redis has a variety of excellent and special features, and the application scenarios are so rich that Redis has its presence in various companies. Then the problems and risks that follow will come. Although Redis is rich in application scenarios, some companies still use single-node deployment relatively conservatively when implementing Redis applications, which brings security risks to future maintenance.

In 2015, it dealt with a business interruption caused by a single point of failure. At that time, Redis did not adopt distributed deployment, adopted single instance deployment, and did not consider the problem of disaster recovery.

At that time, we used the Redis server to control the behavior of users to buy discounted goods, but later, due to unknown reasons, the server of the Redis node went down, resulting in the inability to control the purchasing behavior of users, resulting in the behavior that users can buy discounted goods many times in a period of time.

It can be said that this kind of downtime has caused irreparable losses to the company, and the security risk problem is very serious. As the operation and maintenance system at that time, it is necessary for me to repair this problem and improve the structure. So I began to study how to solve the single point of failure of Redis in non-distributed applications.

Third, backup and disaster recovery of Redis applications in non-distributed scenarios

Redis master-slave replication should be very common now. The common master-slave replication architecture has the following two architectural schemes.

Common Redis master-slave replication

Option one

This is the most common architecture, one Master node and two Slave nodes. When the client writes data, it writes the Master node, and when it reads, it reads two Slave, thus realizing the read expansion and reducing the read load of the Master node.

Option 2

This architecture is also one Master and two Slave. The difference is that Master and Slave1 use keepalived for VIP transfer. When Client connects to Master, it connects through VIP. The change of IP in scenario 1 is avoided.

Advantages and disadvantages of Redis master-slave replication

Advantages

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The backup of master data is realized. Once the master fails, the slave node can be upgraded to the new master and continue to provide services in place of the old master.

Implement read extension. The use of master-slave replication architecture is generally for read extension. Master mainly implements the writing function, while Slave implements the reading function.

Deficiency

Architectural solution one

When the Master fails, the Client is disconnected from the Master and cannot write, and the Slave cannot copy from the Master.

At this point, you need to do the following (if you upgrade Slave1 to Master):

1) execute the slaveof no one command on Slave1 to promote Slave1 to the new Master node.

2) configure writable on Slave1 because slave is configured read-only in most cases.

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

4) configure Slave2 to replicate data from the new Master.

Architecture option 2

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

After that, you need to do the following:

1) execute the slaveof no one command on Slave1 to upgrade Slave1 to a new Master node

2) configure writable on Slave1, because in most cases, Slave is configured read-only

3) configure Slave2 to replicate data from the new Master

It can be found that no matter which architectural scenario it is, human intervention is required for failover. The need for human intervention not only increases the workload of operation and maintenance, but also has a great impact on the business. At this point, you can use Redis's highly available solution-Sentinel.

Fourth, Redis Sentinel introduction

Redis Sentinel provides a highly available solution for Redis. In practice, using Redis Sentinel can create a Redis environment that prevents certain failures without human intervention.

Redis Sentinel is designed as a distributed architecture that runs multiple Sentinel processes to work together. Running multiple Sentinel processes cooperates, and when multiple Sentinel can no longer provide services with a given master, fault detection is performed, which reduces the possibility of false positives.

Fifth, Redis Sentinel function

The main functions of Redis Sentinel in Redis high availability scenarios are as follows:

Monitor and control

Sentinel will constantly check whether master and slave are working as expected.

Notice

Through API,Sentinel, the system administrator can be notified and the Redis instance monitored by the program has failed.

Automatic failover

If master does not work as expected, Sentinel can start the failover process, one of the slave will be master, the other slave will be reconfigured to use the new master, and applications that use Redis services will be notified to use the new address when connecting.

Configuration provider

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

Sixth, Redis Sentinel architecture

Seventh, the realization principle of Redis Sentinel

The Sentinel cluster monitors itself and Redis master-slave replication. When a failure of the Master node is found, the following steps are taken:

1) there is an election between Sentinel, and a leader is elected, and the elected leader is used for failover

2) Sentinel leader selects a slave in the slave node as the new Master node. For the slave election, you need to elect the slave as follows:

A) disconnect time from master

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

B) slave priority

Each slave has a priority and is saved in the redis.conf configuration file. If the priority is the same, proceed.

C) copy offset location

The replication offset records where the data copied from the master is copied to. The greater the replication offset, the more data is received from the master. If the replication offset is the same, the election continues.

D) Run ID

Select Slave with the smallest Run ID as the new Master

The flow chart is as follows:

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

4) Sentinel leader sends commands to other slave to make the remaining slave become the slave of the new master node

5) Sentinel leader will downgrade the original master to slave. When it returns to normal operation, Sentinel leader will send a command to copy from the new master.

After reading the above, have you mastered how to achieve backup and disaster recovery in Redis? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.