本文主要是介绍redis主从，哨兵，cluster集群，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

redis主从，哨兵，cluster集群

一，redis主从复制

1.主从复制概念

主从复制：将一台redis服务器的数据，复制到其他的redis服务器上；
其中，前者为主数据库，后者为从数据库，主数据库可以进行读写操作，当写操做导致数据变化时自动将数据同步给从数据库，而从数据库一般是只读的，并接收主数据同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。

2.主从复制作用

高可用基石:主从复制是哨兵和集群能够实施的基础；
数据冗余:实现了数据的热备份，是持久化之外的一种数据冗余方式；
故障恢复:当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，也是一种服务的冗余；
负载均衡:在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载;尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

3.主从复制流程

1.若启动一个Slave机器进程，则它会向Master机器发送一个sync_command命令，请求同步连接

2.无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照(RDB)保存到数据文件中(执行rdb操作)，同时Master还会记录修改数据的所有命令并缓存在数据文件中。（完全备份）

3.后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。
若Slave出现故障导致宕机，则恢复正常后会自动重新连接。

4.Master机器收到slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个slave发来的同步请求则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

二，哨兵模式

1.哨兵原理

哨兵的核心功能:在主从复制的基础上，哨兵引入了主节点的自动故障转移
哨兵(sentinel):是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的JMaster并将所有Slave连接到新的Master。所以整个运行哨兵的集群的数量不得少于3个节点。

2.哨兵作用

集群监控：负责监控Redis master和slave进程是否正常工作；
消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为告警通知给管理员；
故障转移：如果master 节点挂掉了，会自动转移到slave 节点上（offset 段偏移量）；
配置中心：如果故障转移发生了，通知client客户端新的master地址。

3.哨兵监控节点及哨兵间的监控流程

哨兵监控节点流程：
1.首先主节点的信息是配置在哨兵(Sentinel)的配置文件中；
2.哨兵节点会和配置的主节点建立起两条连接，分别为：命令连接和订阅连接
命令连接：和master建立连接关系；
订阅连接：持续性的从master节点处，获取redis集群信息
3.哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，
主节点会返回自己的run_id和自己的从节点信息（命令：redis-cli info replication）；
4.哨兵会对这些从节点也建立两条连接命令连接和订阅连接；
5.哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息 
run id(redis服务器id) 
role(职能)
从服务器的复制偏移量offset

哨兵间的监控：
1.通过命令连接向服务器的sentinelhello频道发送一条消息，内容包括自己的ip端口、run id、配置(后续投票的时候会用到)等；
2.通过订阅连接对服务器的sentinelhello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接受到；
3.解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来；
4.向观察到的其他的哨兵节点建立命令连接----没有订阅连接

4.哨兵模式下的故障迁移

1.主观下线
哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应
包括(PONGLOADINGMASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线

2.客观下线
当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。
如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRIO DOWN客观下线询问命令SENTINEL is-master-down-by-addr

3.master选举
在认为主节点客观下线的情况下，哨兵节点节点间会发起一次选举，命令为SENTINEL is-master-down-by-addr
只是runid这次会将自己的runid带进去，希望接受者将自己设置为主节点。
如果超过半数以上的节点返回将该节点标记为leacer的情况下，会有该leader对故障进行迁移

4.故障转移 
在从节点中挑选出新的主节点：通讯正常；优先级排序；优先级相同时选择offset最大的
将该节点设置成新的主节点SLAVEOF no one,并确保在后续的INGO命令时 该节点返回状态为master ；
将其他的从节点设置成从新的主节点复制，SLAVEOF命令；
将旧的主节点变成新的主节点的从节点

5.哨兵模式优缺点

优点：高可用，哨兵模式是基于主从模式的，所有主从模式的优点，哨兵模式都具有有;主从可以自动切换，系统更健壮，可用性更高；
缺点：redis比较难支持在线扩容，在群集容量达到上限时在线扩容会变得很复杂；写操作无法负载均衡； 存储能力受到单机的限制。

三，cluster集群

1.集群概念

集群，即Redis Cluster，是Redis 3.0开始引入的分布式存储方案。
集群由多个节点(Node)组成，Redis的数据分布在这些节点中。
集群中的节点分为主节点和从节点:只有主节点负责读写请求和集群信息的维护;从节点只进行主节点数据和状态信息的复制。

2.集群作用

(1)数据分区
数据分区(或称数据分片)是集群最核心的功能。
集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加;另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。
Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及;例如，如果单机内存太大，bgsave和bgrewrifeaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。
(2）高可用
集群支持主从复制和主节点的自动故障转移(与哨兵类似)﹔当任一节点发生故障时，集群仍然可以对外提供服务。

3.redis集群数据分片

集群内置了16384个slot(哈希槽)，并且把所有的物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个节点。
当需要在Redis集群存放一个数据(key-value)时，redis会先对这个key进行crc16算法，然后得到一个结果再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。
示例(三个节点) ：
节点A覆盖0-5460;
节点B覆盖5461-10922;
节点C覆盖10923-16383
即每个节点有5460个哈希槽

四，主从复制，哨兵，集群部署

1.主从复制部署

环境：
redis-master：192.168.11.14
redis-slave：192.168.118.128
redis-slave：192.168.118.132

1.关闭防火墙和安全组件（所有主机）
systemctl stop firewalld
setenforce 0

2.所有主机安装redis

3.修改Master节点Redis配置文件
vim /etc/redis/6379.conf
#70行，修改bind 项，0.0.0.0监听所有网段
bind 0.0.0.0
#137行，开启守护进程
daemonize yes
#172行，指定日志文件目录
logfile /var/log/redis_6379.log
#264行，指定工作目录
dir /var/lib/redis/6379
#700行，开启AOF持久化功能
appendonly yes

/etc/init.d/redis_6379 restart

4.修改Slave节点Redis配置文件
vim /etc/redis/6379.conf
#70行，修改bind 项，0.0.0.0监听所有网卡
bind 0.0.0.0
#137行，开启守护进程
daemonize yes
#172行，指定日志文件目录
logfile /var/log/redis_6379.log
#264行，指定工作目录
dir /var/lib/redis/6379
#288行，指定要同步的Master节点IP和端口
replicaof 192.168.221.20 6379
#700行，开启AOF持久化功能
appendonly yes

/etc/init.d/redis_6379 restart

5.验证主从效果
在Master节点上看日志
tail -f /var/log/redis_6379.log

redis-cli info replication

2.哨兵模式部署

在redis主从基础上搭建：
所有节点都需操作
vim /opt/redis-5.0.7/sentinel.conf
#17行，关闭保护模式
protected-mode no
#21行，Redis哨兵默认的监听端口
port 26379
#26行，指定sentinel为后台启动
daemonize yes
#36行，指定日志存放路径
logfile "/var/log/sentinel.log"
#65行，指定数据库存放路径
dir "/var/lib/redis/6379"
#84行，修改 指定该哨兵节点监控192.168.221.20:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel monitor mymaster 192.168.221.20 6379 2
#113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel down-after-milliseconds mymaster 3000
#146行，故障节点的最大超时时间为180000（180秒）
sentinel failover-timeout mymaster 180000

先启master，再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &

netstat -natp |grep 26379

查看哨兵模式

redis-cli -p 26379 info Sentinel

故障模拟
查看redis-server进程号
ps aux | grep redis
#杀死 Master 节点上redis-server的进程号，模拟故障
kill -9  33227		#Master节点上redis-server的进程号

3.cluster集群部署

redis的集群一般需要6个节点，3主3从
受资源限制，利用redis文件模拟六台redis主机

安装部署redis
cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}
每一个redis文件代表一台redis
ls redis-cluster/

vim /opt/redis.sh
#!/bin/bash
for i in {1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
Cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done
chmod +x /opt/redis.sh
source /opt/redis.sh
cd /etc/redis/redis-cluster/
ls *

chmod +x /opt/redis.sh

cd /etc/redis/redis-cluster/redis 6001
vim redis.conf
bind 127.0.0.1
#69行，注释掉bind项或不修改，默认监听所有网卡
protected-mode no
#88行，修改，关闭保护模式
port 6001
#92行，修改，redis监听端口，
daemonize yes
#136行，开启守护进程，以独立进程启动
cluster-enabled yes
#832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf
#840行，取消注释，群集名称文件设置
cluster-node-timeout 15000
#846行，取消注释群集超时时间设置
appendonly yes
#700行，修改，开启AOF持久化

其他5个配置文件除端口号外改动相同
cp redis.conf ../redis6002/
--->yes

#启动服务
cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf

#根据对应配置文件启动redis
vim /opt/redis_start.sh
#!/bin/bash
for d in {1..6}
do
cd /etc/redis/redis-cluster/redis600$d
redis-server redis.conf
done
ps -ef | grep redis

chmod +x /opt/redis_start.sh 
source /opt/redis_start.sh 

加入集群
redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1

总结

主从复制是为了数据备份，
哨兵是为了高可用，Redis主服务器挂了哨兵可以切换，
集群则是因为单实例能力有限，搞多个分散压力

主从模式：备份数据、负载均衡，一个Master可以有多个Slaves。
哨兵模式：sentinel发现master挂了后，就会从slave中重新选举一个master。
集群模式：cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。

sentinel着眼于高可用，Cluster提高并发量。

区别：
一、架构不同
redis主从：一主多从；
redis集群：多主多从；

二、存储不同
redis主从：主节点和从节点都是存储所有数据；
redis集群：数据的存储是通过hash计算16384的槽位，算出要将数据存储的节点，然后进行存储；

三、选举不同
redis主从：通过启动redis自带的哨兵（sentinel）集群进行选举，也可以是一个哨兵
选举流程：1、先发现主节点fail的哨兵，将成为哨兵中的leader，之后的主节点选举将通过这个leader进行故障转移操作，从存活的slave中选举新的master，新　　的master选举同集群的master节点选举类似；
redis集群：集群可以自己进行选举
选举流程：
1、当主节点挂掉，从节点就会广播该主节点fail；
2、延迟时间后进行选举（延迟的时间算法为：延迟时间+随机数+rank*1000，从节点数据越多，rank越小，因为主从数据复制是异步进行的，所以　　所有的从节点的数据可能会不同），延迟的原因是等待主节点fail广播到所有存活的主节点，否则主节点会拒绝参加选举；
3、参加选举的从节点向所有的存活的节点发送ack请求，但只有主节点会回复它，并且主节点只会回复第一个到达参加选举的从节点，一半以上的主节点回复，该节点就会成为主节点，广播告诉其他节点该节点成为主节点。

四、节点扩容不同
redis主从：只能扩容从节点，无法对主节点进行扩容；
redis集群：可以扩容整个主从节点，但是扩容后需要进行槽位的分片，否则无法进行数据写入。

这篇关于redis主从，哨兵，cluster集群的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！