Home  >  Article  >  Backend Development  >  Detailed explanation of Redis master-slave synchronization

Detailed explanation of Redis master-slave synchronization

小云云
小云云Original
2017-12-14 14:38:562418browse

The literal meaning of master-slave synchronization is who is the master and who is the slave, and they are carried out simultaneously to form a synchronization effect. So how much do you know about the master-slave synchronization of Redis? This article mainly introduces the master-slave synchronization analysis of Redis. It is for reference only. I hope it can help everyone.

1. Principle of Redis master-slave synchronization

1.1 Redis master-slave synchronization process

After configuring the master connected to the slave server, the slave will be established Connect to the master and then send the sync command. Whether it is the connection established for the first time by synchronization or the reconnection after the connection is disconnected, the master will start a background process to save the database snapshot to a file. At the same time, the master main process will start to collect new write commands and cache them. When the background process completes writing the file, the master sends the snapshot file to the slave. The slave saves the file to disk and then loads it into memory to restore the database snapshot to the slave. After the slave completes the recovery of the snapshot file, the master will forward all the cached commands to the slave, and the slave will update the memory database. Subsequent write commands received by the master will be sent to the slave through the connection initially established. The commands to synchronize data from master to slave and the commands sent from client to master use the same protocol format. When the connection between master and slave is disconnected, slave can automatically re-establish the connection. If the master receives synchronous connection commands from multiple slaves at the same time, it will only start a process to write the database mirror, and then send it to all slaves.

1.2 Characteristics of Redis master-slave synchronization

Master-slave synchronization has obvious distributed cache characteristics, mainly including the following aspects:

1) A master can have multiple slaves, and a slave can also have multiple slaves;
2) A slave can not only connect to the master, but a slave can also connect to other slaves to form a tree structure;
3) Master-slave synchronization It will not block the master, but it will block the slave. That is to say, when one or more slaves synchronize data with the master for the first time, the master can continue to process requests from the client. On the contrary, when the slave synchronizes data for the first time, it will block and cannot handle the client's request;
4) Master-slave synchronization can be used to improve the scalability of the system. We can use multiple slaves to specifically handle the client's read request, or we can use To do simple data redundancy or only persist on the slave to improve the overall performance of the cluster.

1.3 Redis active synchronization setting method

There are two ways to complete the synchronization setting of the master-slave Redis server. All need to be done on the slave server, specifying the Redis server that the slave needs to connect to (it may be the master or the slave).

1.3.1 Set in the configuration file

Set in the configuration file (redis.conf) of the Redis server as the slave.

Conf code

slaveof 10.1.1.102 6379 #指定master的ip和端口

Obviously, this setting method is very simple, but it requires modifying the configuration file, and the configuration file is started when the server loaded at the time. Therefore, the server cannot be modified without starting, and the operation is inflexible.

This configuration method is suitable as the initial configuration during deployment.

1.3.2 Setting up in the Redis client

Here we take the Jedis officially recommended by Redis as an example. The tests in the following article are also based on Jedis. The jedis object instance here belongs to the slave, and the parameters are the address and port of the server.

Java code

slaveJdedis.slaveOf("10.1.1.102", 6379); #指定master的ip和端口 
slaveJdedis.slaveofNoOne(); #取消指定master,自己成为一个master了

The master-slave relationship between the master and slave servers can be easily modified through the method specified by the client. So this method is very suitable for adjusting the master and slave servers online as needed.

1.3.3 Problems with current master-slave synchronization

Since the master and slave servers are not automatically elected by Redis and require manual participation, the master-slave switching cannot be automatic. Finish. This raises the question of when and who should trigger the switching. I checked that the client does not have this capability. If necessary, you need to add it yourself.

Jedis currently randomly selects which Redis server to read from, so to implement automatic distributed reading we need to re-encapsulate Jedis.

1) A mechanism needs to be developed to detect the working status of master and slave as soon as possible;
2) An automatic switching strategy for master and slave needs to be defined;
3) Required Define a mechanism that can randomly read any Redis server;

These functions can be implemented on the client, but the effect will not be very good. It would be perfect if the server itself could support it. However, judging from the introduction on the Redis official website, it seems that no one has made such a demand yet, and there is no such plan.

2. Introduction to Redis mainstream clients

On the official website of Redis, 5 Redis java client software are listed. Among them, Jedis is the java client officially recommended by Redis, which has been maintained and updated. Currently, the latest stable version of the server is Redis2.4.17, and the latest test version is Redis 2.6.0 RC7.

2.1 Jedis

Jedis is the officially recommended Java client version of Redis. The latest version is currently Jedis 2.1.0-5, which is fully compatible with Redis version 2.0.0. This client is always maintained and updated.

2.2 JRedis

JRedis has not been updated for a long time and is fully compatible with Redis 2.0.0 version. After being updated before May today, it can be compatible with the latest Redis2.6.0 test version.

2.3 JDBC-Redis

JDBC-Redis is the JDBC driver for the NoSQL database Redis. You can only download the jdbc-redis_0.1_beta version released in March 2009, which is currently no longer maintained.

2.4 RJC

RJC provides Apache DBCP style connection pooling. Updates were stopped 1 year ago and are fully compatible with Redis 2.0.0 version.

2.5 redis-protocol

This update is the fastest and most frequent and is compatible with the latest Redis 2.6.0 version. However, it is positioned to fully support the Redis protocol and interact with the Redis server more efficiently. Therefore, the functions of the redis server are not fully utilized.

2.6 Overall evaluation of each Java client

Overall, each client basically implements the basic functions defined by the Redis protocol. The recent Redis-protocol update has the most complete support for the Redis protocol; Jedis provides more configuration operations for the Redis server and is the most convenient to use. Other clients are rarely maintained and their functions are average.

If you want to expand the functionality of the client a little, developing based on Jedis is the fastest way.

If you want to maximize compatibility and expand client functions, Redis-protocol is the best choice.

3. Suggestions for using Redis master-slave synchronization

Redis master-slave synchronization is not well supported by all current Java clients. The main reason should be caused by the limitations of the implementation mechanism of the Redis server itself. It is possible if you must do it, but the effect may be compromised.

3.1 Implemented by encapsulating Jdedis

1) Add a management class, responsible for maintaining the server topology relationship of the Redis server cluster;
2) Add a new The monitoring class is responsible for monitoring and maintaining the running status of the servers in the Redis server cluster;
3) Add a new Master selection strategy class, which is responsible for determining the switching timing between master and slave, and selecting the most appropriate Redis server to act as the master.
4) Add a proxy class to take over the current Jedis client's read and write operations on the Redis server. The application layer uses the Jedis client through the proxy class. The proxy class needs to ensure that the Redis server cluster is transparent to the application layer.

Related recommendations:

Detailed explanation of Mysql master-slave synchronization configuration sample code

Detailed introduction to the implementation of Mysql master-slave synchronization principle (picture and text )

MySQL master-slave synchronization monitoring shell script under Linux

The above is the detailed content of Detailed explanation of Redis master-slave synchronization. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn