Redis high availability principle master-slave sentinel cluster

Redis Support master-slave replication in manual version , Monitor using sentinel mode Redis colony ,master The master-slave switchover will be performed automatically when the machine goes down , sentry sentinel It's an independent process , For high availability , Sentinels are also clustered , Abreast of the times redis-cluster It is a decentralized cluster with multiple masters and slaves , Support horizontal scaling , It includes the automatic switching and master-slave replication functions of the first two methods , The configuration is also simpler .

One 、 Master slave copy

working principle

Slave Start successfully connected to master A... Will be sent later sync command 

Master Receive the command to start the background save process , At the same time, collect all received commands for modifying the dataset ,  After the background process is finished ,master Transfer the entire data file to slave, To complete a full synchronization 

 Copy in full ： and slave The service receives the database file data , Save it and load it into memory .

 Incremental replication ：Master Continue to pass all new collected modification commands to slave, Complete synchronization 

 But just reconnect master, One full synchronization （ Copy in full ) Will be executed automatically 

To configure : slaveof host port

Two 、 sentry

https://blog.csdn.net/zhanghuiqi205/article/details/112169486

To configure

sentinel monitor mymaster 192.168.14.101 6379 2 #  vote master The number of downtime 

working principle

One 、 Three scheduled tasks

1、 Every sentinel Yes master and slave perform info command , The first is to find slave node , The second is to determine the master-slave relationship 
2、 Every sentinel adopt master Of channel Publish and subscribe to exchange node information and self information , Judge whether the supervisor is offline or objective 
3、 Every sentinel For others sentinel and redis perform ping command , For heartbeat detection , As a basis for survival 

Two 、 Supervisor offline and objective offline

 Subjective offline ： At present sentinel Examples suggest that master Service not available 
 Objective offline ： Multiple sentinel Examples suggest that master Service not available , here master Become a subjective offline state 

3、 ... and 、 Fail over

Failover is caused by sentinel The leader node ( Just one sentinel node ), About sentinel The selection of leader nodes is also the same for each sentinel To the other sentinel The node sends the command that I want to be a leader , More than half sentinel Node consent , And it's bigger than quorum , Then he will be the leader , If there are more than one sentinel All became leaders , There will be elections in the future

Failover steps

1、 from slave Select the appropriate node as master node 
	slave-priority The smaller, the higher the priority 
	 Copy offset offset The higher the priority, the higher （ The more complete the data ）
	runId The smallest slave node （ The earlier it starts ）
2、 Execute the selected above slaveof of no one
3、 Send commands like the remaining nodes , Let them be the new master Of slave node 
4、 Update the original master The node is configured as slave node , Restore to copy new master Node information of 

Advantages and disadvantages

 advantage ： Enhanced version of master-slave replication , Automatic master-slave switching 
 shortcoming ： Online expansion is troublesome ; Only the master node provides services , It does not support high concurrency 

summary

sentinel Clusters are independent threads , Be able to monitor redis colony , Find out master Automatic switching after downtime .

3、 ... and 、 colony

https://blog.csdn.net/xueguchen/article/details/109847085

principle

 Divide all data into 16384 Slots slots, Each node is responsible for some slots . Slot information is stored in each node .

 Use crc16 Algorithm hash Also on 16384 Take the mold to get the specific slot position , The client can cache the slot information after sending the request .

 When the node finds that the slot information is not under its own management , The jump instruction will be sent to carry the node address of the target operation , The client jumps to the correct node for operation , And update the local slot mapping table .

 The cluster node adopts gossip Protocol to communicate 
goosip Protocol contains multiple messages , Include ping,pong,meet,fail etc. 
 The advantage is that the update of metadata is scattered , Not in one place , Hit all nodes one after another , Reduce network burden .（ Select the node that has not communicated for the longest time , Carry a small amount of other information , Therefore, there is a certain interaction delay ）
meet: send out meet To add new nodes , Let new nodes join the cluster 
ping: each other ping Exchange your own state and the maintained cluster state 
pong: Yes ping and meet The return of the message , Include your own status and information , It can also be used for broadcasting and updating 
fail: After a node finds that other nodes are down , send out fail Notify other nodes 

JedisCluster client

When initializing , Pick one at random node, initialization hashslot The mapping table , Create one for each node at the same time JedisPolol Connection pool . Each time based on JedisCluster operation , Now local computing key Of hashSlot And find the corresponding node .