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

This article will explain in detail the example analysis of Redis backup, disaster recovery and high availability combat. The content of the article is of high quality, so Xiaobian shares it with you for reference. I hope you have a certain understanding of relevant knowledge after reading this article.

A brief introduction to Redis

Redis is a high-performance key-value non-relational database. Because of its high-performance characteristics, it supports high availability, persistence, multiple data structures, clustering, etc., which makes it stand out and become a commonly used non-relational database.

In addition, the use of Redis scenarios are also relatively large.

Session Cache

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

full page cache

In WordPress, Pantheon provides a nice plugin wp-redis, which loads the fastest pages you've ever browsed.

queue

Reids provides list and set operations, which makes Redis a good message queuing platform to use. We often restrict purchases through Reids queue feature. For example, during holidays or promotion periods, some activities are carried out to restrict users 'purchase behavior, limiting the purchase of goods only a few times today or only once in a period of time. It is also more suitable for application.

ranking

Redis does an excellent job of incrementing or decrementing numbers in memory. Therefore, we will apply Redis in many ranked scenarios, such as novel websites ranking novels and recommending the top novels to users according to the rankings.

publish/subscribe

Redis provides publish and subscribe functions. There are many scenarios for publish and subscribe. For example, we can implement a chat system established with Redis publish and subscribe functions based on script triggers for publish and subscribe.

There are many other scenes, and Redis is doing well.

Second, Redis uses a single point fault problem

It is precisely because Redis has a variety of excellent and innovative, and the application scenarios are very rich, so that Redis has its presence in various companies. Then there are the problems and risks that come with it. Although Redis has rich application scenarios, some companies still use single-node deployment relatively conservatively when practicing Redis applications, which brings security risks for future maintenance.

In 2015, I handled a business interruption due to a single point of failure. At that time, Redis did not adopt distributed deployment, but adopted single instance deployment, and did not consider disaster recovery issues.

At that time, we controlled the behavior of users to purchase preferential goods through Redis server, but later due to unknown reasons, the server of Redis node went down, which caused us to be unable to control users 'purchase behavior, resulting in users being able to purchase preferential goods many times within a period of time.

This kind of downtime accident can be said to have caused irreparable losses to the company, and the security risk problem is very serious. As the operator of this system at that time, it is necessary for me to repair this problem and improve the architecture. So I started to study how to solve Redis single point failures in non-distributed applications.

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

Redis master-slave replication should be common by now. There are two common master-slave replication architectures:

Common Redis master-slave copy

scheme I

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

scheme II

This architecture is also one Master and two slaves. The difference is that Master and Slave1 use keepalived for VIP transfers. Client connects to Master via VIP. The IP change of Scheme I is avoided.

Advantages and disadvantages of Redis master-slave replication

advantages

The backup of master data is implemented. Once master fails, slave node can be promoted to new master and replace old master to continue providing services.

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

insufficient

Framework Option 1

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

The following operations are required (assuming Slave1 is promoted to Master):

On Slave1, execute the slave of no one command to promote Slave1 to the new Master node.

Configured to be writable on Slave1, because in most cases slave will be configured read-only.

Tells the client (i.e., the program that connects to Redis) the connection address of the new Master node.

Configure Slave2 to copy data from the new Master.

Framework Option II

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

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

Execute the slave of no one command on Slave1 to promote Slave1 to the new Master node

Configure writeable on Slave1 because Slave is configured read-only in most cases

Configure Slave2 to replicate data from the new Master

It can be seen that no matter which architectural scheme, manual intervention is required for failover. The need for manual intervention increases the O & M workload and 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. In practical terms, using Redis Sentinel creates a Redis environment that prevents certain failures without human intervention.

Redis Sentinel is designed as a distributed architecture, running multiple Sentinel processes to work together. Running multiple Sentinel processes collaborates to perform fault detection when multiple Sentinels with a given master can no longer provide service, which reduces the likelihood of false positives.

5. Redis Sentinel function

Redis Sentinel has the following functions in Redis High Availability Solution:

monitoring

Sentinel constantly checks whether master and slave are working as expected

notice

Through the API, Sentinel is able to notify system administrators that instances of Redis monitored by the program have failed

automatic failover

If the master doesn't work as expected, Sentinel can initiate a failover process in which one of the slaves becomes the master, the other slaves are reconfigured to use the new master, and applications using Redis services are notified to use the new address when they connect.

Configuration Provider

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

VI. Redis Sentinel Architecture

VII. Redis Sentinel Implementation Principle

The Sentinel cluster monitors itself and Redis master-slave replication. When a fault is found in the Master node, the following steps will be followed:

1)Sentinel election, election of a leader, by the election of the leader to fail

2)Sentinel leader selects one of the slave nodes as the new Master node. The method for electing slaves is as follows: a) Disconnect time from master

If the time disconnected from master exceeds down-after-milliseconds(sentinel configuration) * 10 seconds plus the time between when sentinel determines master is unavailable and when sentinel begins performing failover, the slave is considered unsuitable for promotion to master.

b) Slave priority

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

c) Copy offset position

Copy offset records where data copied from master is copied, larger copy offset indicates more data received from master, and if copy offset is the same, proceed to election

d) Run ID

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

The flow chart is as follows:

3)The Sentinel leader performs a slaveof no one operation on the new master elected in the previous step, promoting it to the master node

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

5)The Sentinel leader demotes the master to slave, and when it returns to normal operation, the Sentinel leader sends a command to copy from the new master.

All the above failovers are completed by sentinel itself, completely without manual intervention.

The sample analysis of Redis backup, disaster recovery and high availability combat is shared here. I hope the above content can be of some help to everyone and learn more knowledge. If you think the article is good, you can share it so that more people can see it.

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.