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

Redis in how to achieve master-slave replication, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

An introduction to Redis replication

Database replication refers to the behavior of one-way information dissemination between different database instances, which is usually composed of the replicated party and the replicated party, and a network connection is established between the replicated party and the replicated party. Usually, the replicated party takes the initiative to send the data to the replicator, and the replicator receives the data stored in the current instance. The ultimate goal is to ensure that the data of both parties are consistent and synchronized.

Copy the schematic diagram

Redis replication mode

There are two ways to copy Redis, one is master-slave mode, the other is slave-slave mode, so the replication topology diagram of Redis will be richer, either like star topology or directed acyclic:

Redis cluster replication structure diagram

Multiple Redis instances are configured to run independently and replicate directionally to form a Redis cluster. Master is responsible for writing and slave is responsible for reading.

Advantages of replication

By configuring multiple Redis instances, the data is backed up on different instances. The master database focuses on the write request, and the slave database is responsible for the read request. This benefit is mainly reflected in the following aspects:

1. High availability

In a Redis cluster, if master goes down, slave can step in and replace master, so it is not impossible to provide services for the entire Redis service, which makes the entire Redis service secure enough.

2. High performance

In a Redis cluster, master is responsible for writing requests and slave for reading requests, which on the one hand greatly reduces the pressure on master servers by spreading read requests to other machines, and on the other hand slave focuses on providing read services to improve response and read speed.

3. Horizontal scalability

By adding slave machines, you can horizontally (horizontally) extend the entire query service capabilities of Redis services.

Copy shortcoming

Replication provides a high availability solution, but at the same time introduces the complexity of distributed computing and believes that there are two core issues:

Data consistency problem, how to ensure that the data written by the master server can be synchronized to the slave machine in time.

Programming is complex, how to provide the implementation scheme of read-write separation on the client side, and route the read-write requests to the master and slave instances respectively through the client implementation.

The above two issues, especially the first one, is one that Redis service implementations have been evolving to address.

Contradiction between real-time replication and data consistency

Redis provides solutions to improve data consistency, which will be described later in this article, although the increase in consistency enables me to trust data more, but better consistency solutions are usually accompanied by performance loss, thus reducing throughput and service capacity. However, if we want the system to achieve the best performance, we must sacrifice the degree of consistency, so there is a contradiction between real-time replication and data consistency of Redis.

Principles and characteristics of Redis replication slave points to master

For example, we have four redis instances, M1 is R1, R2, R3, where M1 is master,R1, R2, R3 are three slave redis instances. Start at M1 as follows:

. / redis-server.. / redis8000.conf-- port 8000

The following are the startup commands for R1, R2, and R3, respectively:

. / redis-server.. / redis8001.conf-- port 8001-- slaveof 127.0.0.1 8000. / redis-server.. / redis8002.conf-- port 8002-- slaveof 127.0.0.1 8000. / redis-server.. / redis8003.conf-- port 8003-- slaveof 127.0.0.1 8000

In this way, we have successfully started four Redis instances. The service ports of master instances are 8000, and the service ports of R1, R2 and R3 are 8001, 8002 and 8003, respectively. The cluster diagram is as follows:

Redis cluster replication topology

The above command specifies the master machine when slave starts, and we can also use the slaveof command to specify the master machine when slave is running.

Replication process

Redis replication is mainly implemented by the SYNC command, and the replication process is shown below:

Redis replication process

The figure above shows the working process of Redis replication:

Slave sends a sync command to master.

Master starts the child process to write dataset to the rdb file and caches the write commands received before the child process completes.

When the child process is finished, the parent process learns that it begins to send the RDB file to slave.

After master sends the RDB file, it also sends the cached command to slave.

Master incrementally sends write commands to slave.

It is worth noting that when slave is disconnected from master, slave can automatically reconnect to master. Prior to the redis2.8 version, every time the slave process hung up and reconnected to master, a new round of full replication was started. If master receives synchronization requests from multiple slave at the same time, master only needs to back up the RDB file once.

Incremental replication

At the end of the above replication process, it is mentioned that slave and master are disconnected, and full replication is required when slave and master are reconnected. This strategy is very unfriendly. Starting with Redis2.8, Redis provides a mechanism for incremental replication:

Incremental replication mechanism

In addition to backing up RDB files, master maintains a ring queue, as well as the write index of the ring queue and the global offset synchronized with slave. The ring queue is used to store the latest operation data. When slave and maste are disconnected and reconnected, the offset maintained by slave, that is, the value of where the synchronization was last synchronized, will be told to master. At the same time, it will tell master that the runid of the last master connected to the current slave meets the following two conditions, and Redis will not replicate in full:

The run id passed by slave is the same as the run id of master.

Master can find the value of offset on the ring queue.

If the above two conditions are met, Redis will not be copied in full, which has the advantage of greatly improving performance and not doing invalid work.

Incremental replication is implemented by the psync command, and slave can use the psync command to allow Redis to do incremental replication. Of course, whether the incremental replication can be done ultimately depends on the size of the ring queue, the length of disconnection of the slave and whether the reconnected master is the previous master.

Ring queue size configuration parameters:

Repl-backlog-size 1mb

Redis also provides how long it takes to release a ring queue when there is no slave to synchronize:

Repl-backlog-ttl 3600 No persistent replication

The hands-free persistence mechanism is officially called Diskless Replication. As can be seen in the previous way of writing RDB files to disk, Redis must write RDB files to disk before network transfer, so why can't RDB files be transferred to slave directly through the network? This is what persistence-free replication does, and it is supported in the Redis2.8.18 version, although it is still an experimental phase.

It is worth noting that once the Diskless Replication-based replication transfer begins, new slave requests need to wait for the transfer to complete before they can be served.

The switch on whether to enable Diskless Replication is configured as follows:

Repo-diskless-sync no

In order to enable subsequent slave to catch up with this replication as much as possible, Redis provides a parameter configuration to specify the time delay for the start of replication:

Repl-diskless-sync-delay 5slave read-only mode

Since the Redis2.6 version, the read-only configuration of slave is supported, and the default configuration of slave is read-only. Slave in read-only mode will reject write requests from the client, thus avoiding data inconsistencies caused by writes from slave.

Semi-synchronous replication

Similar to the MySQL replication strategy, Redis replication itself is asynchronous, but it also provides a semi-synchronous replication strategy, which has the following semantics in Redis replication:

Allow the user to give such a configuration: when the maste accepts write operations, only if there are at least N slave online within a certain time interval, otherwise the write is invalid.

The implementation of the above functions is based on the following features of Redis:

Redis slaves ping master every second, telling master where the current slave has been copied.

Redis master remembers where each slave is copied.

We can specify the interval and the value of N through the following configuration:

Min-slaves-to-write min-slaves-max-lag

When the above two parameters are configured, once the above two conditions are not met for a write operation, master will report an error and treat the write operation as invalid. This is a bit like the "C" in CAP theory, that is, consistency implementation. although the semi-synchronous strategy can not fully guarantee the data consistency of master and slave, it relatively reduces the window period of inconsistency.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.