标签：redis 哨兵 cluster 集群 master 节点 主从
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,集群,master,节点,主从 来源： https://www.cnblogs.com/qfzr2508/p/16173838.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。