Master slave synchronous parsing of Redis

1. Master slave synchronization principle of Redis

1.1 master slave synchronization process of Redis

Once the master of the slave server connection is configured, slave establishes a connection to master and then sends the sync command. Whether the connection is made in the first synchronization or reconnected after the connection is broken, master starts a background process to save the database snapshot to a file, while the master main process begins to collect new write commands and cache them. When the background process is finished writing the file, master sends the snapshot file to slave, slave saves the file to disk, and then loads it into memory to restore the database snapshot to slave. Once slave has recovered the snapshot file, master forwards the cached commands to slave, which updates the in-memory database. Subsequent write commands received by master are sent to slave via the connection that was first established. Commands to synchronize data from master to slave use the same protocol format as commands to send from client to master. When the connection between master and slave is broken, slave can automatically re-establish the connection. If master receives synchronous connection commands from multiple slave at the same time, it will only use start 1 process to write the database image and send it to all slave.

1.2 master slave synchronization features of Redis

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

1) one master can have multiple slave, and one slave can have multiple slave;
2) slave can be connected not only to master, but also to other slave to form a tree-like structure;
3) master-slave synchronization will not block master, but it will block slave. That is, when one or more slave and master synchronize data for the first time, master can continue to process requests from client. On the contrary, slave will block the request of client when synchronizing data for the first time.
4) master-slave synchronization can be used to improve the scalability of the system. We can use multiple slave specially to handle the read requests of client, or we can use it to do simple data redundancy or persist only on slave, so as to improve the overall performance of the cluster.

1.3 Redis active synchronization setup method

There are two ways to synchronize Settings for master and slave Redis servers. Both need to be done on the slave server, specifying which Redis server slave needs to connect to (either master or slave).

1.3.1 set in the configuration file

In the configuration file (redis.conf) for the Redis server as slave.

Conf code

slaveof 10.1.1.102 6379 # The specified master the ip And port 

Obviously, this setup is very simple, but the configuration file needs to be modified, and the configuration file is loaded when the server starts. So the server can not be modified without starting, so the operation is not flexible.

This configuration is appropriate as an initial configuration for deployment.

1.3.2 setup in Redis client

Here, Jedis, which is officially recommended by Redis, is taken as an example. The test in the following paper is also based on Jedis. Here the jedis object instance belongs to slave, and the parameters are the address and port of the server.

Java code

slaveJdedis.slaveOf("10.1.1.102", 6379); # The specified master the ip And port  
slaveJdedis.slaveofNoOne(); # Cancel the specified master Become yourself 1 a master the 

The master-slave relationship of the master and slave servers can be easily modified by means specified by the client. So this is a great way to tweak the master and slave servers online as needed.

1.3.3 problems existing in the current master-slave synchronization

Since master and slave servers are not automatically elected by Redis, which requires human participation, master-slave switching cannot be done automatically. This raises the question of when and by whom to trigger the switch. I have checked that the client side does not have this ability. If you want it, you need to increase it by yourself.

At present, Jedis randomly selects which Redis server to read, so to realize automatic distributed reading, we need to encapsulate Jedis twice.

1) a mechanism should be developed to detect the working state of master and slave as soon as possible;
2) an automatic switching strategy of master and slave needs to be defined;
3) need to define a mechanism that can randomly read any 1 Redis server;

All of this can be done on the client side, but not very well. It would be perfect if the server itself could support it, but according to the introduction on the Redis website, it seems that no one has raised such a requirement or planned to do so.

2. Introduction to Redis mainstream client

On the official website of Redis, five Redis client software are listed. Jedis is the java client officially recommended by Redis, which is maintained and updated. At present, 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 Java client version officially recommended by Redis. The latest version is Jedis 2.1.0-5, which is fully compatible with Redis 2.0.0. This client 1 has been maintained and updated.

2.2 JRedis

JRedis has not been updated for a long time and is fully compatible with version 2.0.0 of Redis. It can be compatible with the latest Redis2.6.0 test version after being updated before may today.

2.3 JDBC-Redis

JDBC-Redis is the JDBC driver for the Redis NoSQL database. Only the version of jdbc-redis_0.1_beta released in March 2009 can be downloaded and is currently unmaintained.

2.4 RJC

RJC offers an Apache DBCP style connection pool. The update was stopped a year ago and is fully compatible with version 2.0.0 of Redis.

2.5 redis-protocol

This update is the fastest and most frequent, and is compatible with the latest version of Redis 2.6.0. However, it is positioned to fully support the Redis protocol, making it more efficient to interact with the Redis server. As a result, the redis server is not fully functional.

2.6 overall evaluation of each Java client

Overall, each client basically implements the basic functions defined by the Redis protocol. Redis-protocol updated most recent support for the Redis protocol; Jedis provides more configuration for Redis servers and is the easiest to use. Other clients are poorly maintained and function as 1.

If you want to extend the functionality of the client in a small amount, Jedis based development is the fastest.

If you want to maximize compatibility and extend client functionality, Redis-protocol is the best option.

3. Recommended use of Redis master slave synchronization

Redis master slave synchronization is poorly supported on all current Java clients. The main reason should be the limitation of the implementation mechanism of Redis server itself. It is possible to do this if you want to, but the effect may be compromised.

3.1 by encapsulating Jdedis

1) add a new management class, which is responsible for maintaining the server topological relationship of Redis server cluster;
2) a new monitoring class is added, which is responsible for monitoring and maintaining the running status of servers in the Redis server cluster;
3) add a new Master selection policy class, which is responsible for determining the switching time of master and slave, and selecting the most suitable Redis server as master.
4) add a new proxy class to take over the read and write operations of the current Jedis client to the Redis server. The application layer USES the Jedis client through proxy classes. The proxy class needs to ensure that the Redis server cluster is transparent to the application layer.

conclusion

That's all for the master-slave synchronous parsing of Redis. Interested friends can continue to see this site: Java programming redisson implementation of distributed lock code examples, redis transaction mechanism and optimistic lock implementation, if you have any questions can leave a message at any time, this site 1 will know without a word. Thank you for your support!