Three modes Redis ==> cluster

A master-slave synchronization / replication

　　By persistence function, Redis to ensure that even in the case of a server restart is not lost (or a small loss) data as persistent memory will save data to the hard disk, restart loads the data from the hard disk. However, because the data is stored on a server, if that server hard drive failure and other problems, can lead to data loss.

　　In order to avoid a single point of failure, the usual practice is to copy the database to be deployed in multiple copies on different servers, so that even if a server fails, other servers can still continue to provide services. For this purpose, the Redis provided a copy (Replication) function can be achieved when the data of a database is updated, the updated data is automatically synchronized to other databases .

　　In the concept of replication, the database is divided into two categories, one is a master database (Master), the other is from the database (slave). Primary database can read and write, when the write operation causes data changes will automatically synchronize to the data from the database. And from the general database is read-only and receive data over the primary database synchronization . A master database from a database can have multiple, but can only have a master database from a database.

Master-slave configuration database:

　　Without primary database configuration information may be loaded from the master database profile database (redis.conf), the boot may be used redis-server --port 6380 --slaveof 127.0.0.1 6379 command specified in the primary database IP and ports. From the general database is read-only, it can instead write, but writing data can easily be synchronized no master, so you can still read-only. You can also use slaveof ip port command is running, stop the original primary, switched to the main slaveof no one would just set themselves into the main.

Copy the master-slave principle:

Connecting the main database from the database, transmitting SYNC command;
After receipt of the SYNC command master database, RDB command to generate begin BGSAVE file and records all write command buffer execution thereafter;
After the implementation of the master database BGSAVE, all sent from the database snapshot files, and continue to record write command is executed during transmission;
After receiving the snapshot files from the database to discard all the old data, after loading snapshot received;
He began to write commands sent from the database buffer after the master database snapshot has been sent;
Completion of loading from the database snapshot command to start receiving the request, and executes the write command from the master database buffer; ( done from database initialization )
Each primary database will execute a write command in the same write command transmitted from the database, to receive and execute the write command received (from database operation after completion of the database initialization )
After disconnecting reconnection occurs, the command during the break after the 2.8 version will pass heavy databases, incremental replication.
Just when the main connection, the amount of full synchronization; end of the full synchronization, incremental synchronization. Of course, if necessary, slave at any time to initiate the full amount of synchronization. Redis strategy is, in any case, will first try to incremental synchronization, such as unsuccessful, requiring full amount of synchronous slave.

advantage:

Support replication master-slave, the host will automatically synchronize data to the slave, the separation can be read;
In order to read the operating pressure of the carrier division of Master, Slave servers can provide read-only operations services for clients, writing services still have to be completed by the Master;
Slave Slaves can also accept other connections and synchronization request, which can effectively partial pressure of the carrier synchronization of the Master;
Master Server is a non-blocking way for Slaves to provide services. So during the Master-Slave synchronization, the client still can submit queries or modification request;
Slave Server is based on the same non-blocking way to complete data synchronization. During synchronization, if the client submits a query request, Redis data before synchronization is returned;

Disadvantages:

Redis not have automatic fault tolerance and recovery, from a host machine downtime will result in the distal end portion of the read or write request fails, or the need to wait for the machine to restart the manual switching to restore the front end IP;
Host down, down the front part of the data has failed to synchronize to a slave, also introduce data inconsistencies after switching the IP, reduces the availability of the system;
If multiple Slave disconnected, you need to restart, try not to restart at the same time. As long as Slave start, and the host request will be sent sync sync the whole amount, when multiple Slave restart may result Master IO surge so downtime.
Redis is more difficult to support online capacity expansion, online capacity expansion reaches the upper limit will become very complicated in the cluster capacity;

Second, Sentinel mode

　　A first master, when the primary server goes down, the need to manually switching from a synchronous mode / copied from the server as the master, which requires manual intervention, cumbersome and laborious, but also cause a time service is unavailable. This is not a recommended way, more often, we give priority to sentry mode.

　　Sentinel mode is a special mode, first Redis Sentinel provides command, Sentinel is a separate process, as a process, it will operate independently. The principle is Sentinel by sending a command, the server waits for a response Redis to monitor multiple instances running Redis.

Sentinel mode of action:

By sending commands, so that the server returns Redis monitor its operation state, including the master server and from the server;
When the sentinel surveillance to master is down, it will automatically switch to the slave master, then publish subscribe model notice from the other server, modify the configuration file, so that they switch the host;

However Redis server to process a sentinel to monitor, but also may be a problem, for which we can use multiple sentinel monitoring. But also between the various monitoring sentinel, thus forming a multi-Sentinel mode.

Failover procedure:

　　Assume that the primary server goes down, Sentinel 1 to detect this result, the system does not perform failover process immediately, just 1 Sentinel subjective think the primary server is unavailable, this phenomenon is becoming subjective offline . When the latter also detected in sentinel primary server is unavailable, and the number reaches a certain value, it will be a vote between sentinel, the voting result is initiated by a sentinel, a failover operation. After the successful handover, will be released through a subscription model that allows each sentinel to monitor the realization of their own to switch from the host server, this process is called objective offline . For such clients, everything is transparent.

Sentinel configuration mode:

Configuring a primary two and three guards from the Redis server to demonstrate the process

Master and slave server configuration

# Makes Redis server across a network can access 
the bind 0.0.0.0 # Set Password 
requirepass " 123456 " # The following configuration related slaveof only configuration does not require configuration from the server, the primary server 
# specify the primary server 
slaveof 192.168.11.128 6379 # master password 
masterauth 123456

Configuring Sentinel

# Prohibit protected mode 
protected- the MODE NO
 # Configure the primary server is listening, here on behalf of sentinel monitor monitor, on behalf of the server name mymaster, you can customize, 192.168.11.128 representatives to monitor the primary server, 6379 on behalf of the port, 2 for only two or more than two sentries think when the primary server is unavailable, will perform failover operations. 
Monitor mymaster 192.168.11.128 6379 2 Sentinel # Sentinel Pass author-defined service password, mymaster is the service name, Redis server password is 123456 
# Sentinel auth-Pass <Master-name> <password> 
Sentinel auth - Pass mymaster 123456

Configuration 3 Sentry, Sentry configuration for each is the same. There is a sentinel.conf Redis file in the installation directory, copy a modification

start up

Note the order to start. The first is the host (192.168.11.128) Redis service of process, and then start the machine from the Redis service process, the service process starts last three sentries.

Sentry mode works:

Each Sentinel (Sentinel) process with the frequency of once per second, Slave sends a PING command from the server, and other Sentinel (Sentinel) process to the entire cluster Master primary server.
If an instance (instance) from the last effective command PING response time exceeds the value of the down-after-milliseconds option is specified, then this instance is marked Sentinel (Sentinel) process is subjective offline (SDOWN)
If a Master primary server is marked as subjective offline (SDOWN), then this is monitoring all Sentinel Master primary server (Sentinel) process to be sure the Master primary server offline indeed entered a subjective state once per second
When a sufficient number of the Sentinel (Sentinel) process (greater than or equal to the specified value profile) confirmed the primary server into the Master subjective offline state (SDOWN) within the specified time, the Master main objective server is marked as offline (ODOWN)
In general, each of the Sentinel (Sentinel) process will, the Slave sends an INFO command from the server at a frequency of once every 10 seconds in the cluster to all Master main server.
Master when the primary server is marked the Sentinel (Sentinel) process objective offline (ODOWN), Sentinel (Sentinel) process sends an INFO command from the server to the master server to all Slave Master downline frequency is changed from once every 10 seconds seconds.
Without a sufficient number of Sentinel (Sentinel) process agreed Master primary server goes offline, the objective offline status Master primary server will be removed. If the Master primary server to resend the PING command to the Sentinel (Sentinel) process returned valid responses, subjective offline status Master primary server will be removed.

advantage:

Sentinel model is based on a master-slave mode, the master from all the advantages of having a Sentinel model.
Can automatically switch from the main, the system is more robust, more available.

Disadvantages:

Redis is more difficult to support online capacity expansion, online capacity expansion reaches the upper limit will become very complicated in the cluster capacity.

Three, Cluster Cluster

　　Redis Sentinel model basically been highly available, separate read and write, but in this mode Redis each server stores the same data, it is wasteful of memory, so the added cluster Cluster mode on redis3.0, realized Redis distributed storage, which means that on each node Redis different memory contents.

Cluster configuration

Use the cluster, just to each node of the cluster-enable database configuration can be opened. Each cluster requires at least three main three run properly from talents.

Features cluster

All nodes are interconnected and redis (PING-PONG mechanism), the internal transmission speed using the binary protocol and bandwidth optimization.
fail through the cluster node that more than half of the node failure detection only takes effect.
Redis client node is connected, without an intermediate layer proxy. The client need not be connected to all cluster nodes, any node can be used to connect a cluster.

Clusters of work

　　Redis on each node, there are so two things, one slot (slot), it is the range: 0-16383. There is a cluster, it can be understood as a cluster management plug-ins. When we reach the Key access, according to the Redis crc16 algorithm we will come to a result that is the result of the modulo number 16384, so that each key will correspond to a hash slot number between 0-16383 by this value, corresponding to the node to find the corresponding slot, and then automatically jump directly to the corresponding node access operation.

　　In order to ensure high availability, redis-cluster clustering is introduced from the master mode, the master node corresponds to one or a plurality of slave nodes if the master node is down, when the node is enabled. When other master nodes ping a master node A, if more than half of the master node A communication timeout, so that the master node A is down. If the master node A and node A1 from it all down, then the cluster can no longer provide the service.

Three modes Redis ==> cluster

Guess you like