哨兵机制Sentinel
主从复制：读写分离，多读少写，单点故障（主机宕机，从机不能自动切换），负载压力（客户端请求，并发），数据集中存储（主从数据是完全一致）哨兵机制：主从故障转移，从切换为主，数据集中存储（主从数据是完全一致）
哨兵机制
哨兵机制的出现是为了解决主从复制的缺点，不能自动实现故障转移
哨兵模式是Redis的高可用解决方案之一，它旨在提供自动故障转移和故障检测的功能。在传统的Redis部署中，单个Redis节点可能成为单点故障，一旦该节点宕机，整个系统将不可用。为了解决这个问题，哨兵模式引入了多个Redis节点，其中一个节点被选为主节点，其他节点作为从节点。
哨兵机制作用
-
监控
-
不断的检查 master 和 slave 是否正常运行。
-
master 存活检测、master与slave运行情况检测。
-
-
通知（提醒）
-
当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
-
-
自动故障转移
-
断开 master 与 slave 连接，选取一个 slave 作为 master，将其他 slave 连接到新的 master，并告知客户端新的服务器地址。
-
哨兵模式场景应用
-
高可用性要求较高的场景：通过自动故障转移，确保服务的持续可用。
-
数据备份和容灾恢复：在主从复制的基础上，提供自动故障转移功能。
哨兵模式在主从复制模式的基础上实现了自动故障转移，提高了系统的高可用性。然而，它仍然无法实现数据分片。如果需要实现数据分片和负载均衡，可以考虑使用Cluster模式。
sentinel高可用
原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知
哨兵的定时监控任务
任务1：
每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务2：
每个哨兵节点每隔2秒会向redis数据节点的指定频道(主节点)上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
任务3：
每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
主观下线和客观下线
主观下线是指一个哨兵节点认为主节点不可用，但它并不确定其他哨兵节点是否也认为主节点不可用。当一个哨兵节点在一定时间(配置参数：down-after-milliseconds)内无法与主节点通信（比如发送PING命令没有收到响应），它会认为主节点下线。但在这个阶段，其他哨兵节点并不知道这个节点的状态，仅有一个哨兵主观地认为主节点宕机。
客观下线是指一个主节点被多数哨兵节点认定为不可用。当一个哨兵节点认为主节点宕机后，它会向其他哨兵节点询问对主节点的状态，并请求其他哨兵进行确认。当超过quorum（选举）个数（大多数至少需要半数加1）的哨兵节点都认为主节点不可用，那么主节点就会被判定为客观下线。客观下线意味着主节点的状态在整个哨兵集群中得到了确认。
主观下线和客观下线的引入是为了避免误判。如果只有一个哨兵节点认为主节点下线，那么很可能是网络抖动等原因导致的，此时并不应该进行故障转移。只有多数的哨兵节点都确认主节点下线，才能确保故障转移的正确性，保证整个集群的稳定性。
哨兵模式使用主观下线和客观下线状态的组合来实现可靠的主节点故障检测和故障转移，从而确保Redis集群的高可用性。
领导者哨兵选举流程
在多Sentinel模式下，各节点会相互监控主从节点的健康状态。当主节点发生故障时，首先由Sentinel节点之间基于Raft算法进行投票选举，按照谁发现主节点故障谁去处理的原则，选举出一个领头Sentinel节点（Leader Sentinel）。这个领头Sentinel节点负责进行故障转移操作。
-
每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
-
当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
-
如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
故障转移机制
故障转移过程中，领头Sentinel节点会根据一定的规则在所有从节点中选择一个最优的从节点作为新的主节点（Master）。一般会选择复制偏移量最大且优先级较高的从节点作为新的主节点。然后，领头Sentinel节点通过发布订阅功能，通知其他从节点更改配置文件，将它们的连接从原来的主节点转移到新的主节点上。
-
由Sentinel节点定期监控发现主节点是否出现了故障
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
-
当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移
-
故障转移详细流程-确认主节点
-
过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
-
选择salve-priority从节点优先级最高（redis.conf）的
-
选择复制偏移量最大，指复制最完整的从节点
-
-
由Sentinel3领导者节点执行故障转移，但是自动执行
-
将slave-1脱离原从节点，升级主节点
-
将从节点slave-2指向新的主节点
-
通知客户端主节点已更换
-
将原主节点（oldMaster）变成从节点，指向新的主节点
-
-
故障转移后的redis sentinel的拓扑结构图
部署哨兵
准备
先搭好一主两从redis的主从复制
一个哨兵
准备:
Sentinel.conf
mymaster 指的是主机的名字 192.168.184.34 6381 指的是集群中的IP地址和端口号1代表的是哨兵同意的个数
配置我们的sentinel.conf文件
sentinel monitor mymaster 192.168.184.34 6381 1启动
进入哨兵的可执行文件所在的目录
./redis-sentinel sentinel.conf
启动成功
测试
关闭主看从机是不是能够自动成为主
关闭主机
shutdown查看日志，如果主机变了之后，换成了其他两个从机
如果可以 哨兵就配置成功
一主二从三哨兵
配置文件
配置多个哨兵节点sentinel.conf，三个配置除端口外，其它一样。
复制解压目录下的sentinel.conf到安装目录下，修改sentinel.conf配置文件，几个哨兵，几个配置文件：
在redisserver文件夹下创建我们要配置的哨兵sentinel.conf文件
# 端口号
port 26379
# 后端启动
daemonize no
# 不受保护
protected-mode no
pidfile "/var/run/redis-26379.pid"
logfile "/opt/redis/26379.log"
# 监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
sentinel monitor mymaster 192.168.184.34 6382 2
dir "/opt/redis/redisserver/26379"其他的两个哨兵 在配置的时候只需要全局替换26379 就可以了
其他的操作和单个的哨兵是一样的
测试，还是使用命令关闭主机，看是否会换另一个从机
集群
Redis集群
背景
前面我们学习了Redis高可用的两种架构模式：主从模式、哨兵模式。
-
主从复制：单点故障、读写分离（主负责写，从负责读）、负载均衡（客户端请求，并发）
-
问题：不能自动故障转移（哨兵）、主从数据是完全一致（集群）
-
-
哨兵机制：故障转移（解决主从复制的问题，主机出现故障，从切换为主）
RedisCluster是redis的分布式解决方案，当主备复制场景，无法满足主机的单点故障时，需要引入集群配置，当一个服务挂了可以快速的切换到另外一个服务，当遇到单机内存、并发等瓶颈时，可使用此方案来解决这些问题。
什么是集群
由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集。
Redis集群是一种通过将多个Redis节点连接在一起以实现高可用性、数据分片和负载均衡的技术。它允许Redis在不同节点上同时提供服务，提高整体性能和可靠性。
Redis集群主要有三种模式：主从复制模式（Master-Slave）、哨兵模式（Sentinel）、Cluster模式。
-
广义的集群：只要是多台机器，构成一个分布式系统，就可以称为一个“集群”。主从结构，哨兵模式都是“广义的集群”
-
狭义的集群：redis提供的集群模式，这个集群模式主要解决存储空间不足的问题
Redis Cluster功能
-
数据自动分片
集群中每个节点都会负责一定数量的slot，每个key会映射到一个具体的slot，通过这种方式就可能找到key具体保存在哪个节点上了。
-
提供hash tags功能
通过hash tag功能可以将多个不同key映射到同一个slot上，这样就能够提供multi-key操作，hash tag的使用的方式是在key中包含“{}”，这样只有在“{...}”中字串被用于hash计算。
-
自动失效转移和手动失效转移
-
减少硬件成本和运维成本
Cluster 实现原理
分布式数据库
就把整个数据按分区规则映射到多个数据库节点，即把数据划分到多个节点上，每个节点负责整体数据的一个子集。比如我们库有900条用户数据，有3个redis节点，将900条分成3份，分别存入到3个redis节点
900-->一个数据库
900-->多个数据库
分区规则
常见的分区规则哈希分区和顺序分区，redis集群使用了哈希分区的“虚拟槽分区”方式。
虚拟槽分区(槽：slot)
数据：key-value
数据库：key值关联
RedisCluster采用此分区，所有的键根据哈希函数映射到0－16383槽内，共16384个槽位，每个节点维护部分槽及槽所映射的键值数据。
槽与节点的关系如下：
redis用虚拟槽分区使解耦数据与Redis数据库节点关系，节点自身维护槽映射关系，分布式存储。
redisCluster的缺陷
执行数据库操作时，一次操作，只能连接一个数据库
1) 键的批量操作支持有限，比如mset, mget，如果多个键映射在不同的槽，就不支持了
2) 键事务支持有限，当多个key分布在不同节点时无法使用事务，同一节点是支持事务
3) 键是数据分区的最小粒度，不能将一个很大的键值对映射到不同的节点
4) 不支持多数据库
5) 复制结构只支持单层结构，不支持树型结构。
集群环境搭建
配置三主三从
准备6 台服务器
在一台机器上设值三个不同的端口号
准备6 个不同的端口号
复制的配置文件做以下修改，以下以6379为例:
| 1 | port 6379 | 端口号 |
|---|---|---|
| 2 | daemonize yes | 让redis服务在后台启动 |
| 3 | pidfile /var/run/redis_6379.pid | Pidfile 文件中的端口号修改为本节点端口号 |
| 4 | cluster-enabled yes | 把#注释去掉， 开启集群 |
| 5 | cluster-config-file nodes_6379.conf | 把#注释去掉，集群的配置，配置文件首次启动自动生成 |
| 6 | cluster-node-timeout 15000 | 把#注释去掉，请求的超时时间，默认15秒，可自行设置 |
| 7 | appendonly yes | 开启aof日志aof 和rdb是redis同步内存中的数据到硬盘的两种方式 |
| 8 | Appendfilename "appendonly_6379.aof" | |
| 9 | protected-mode no | 关闭保护模式 |
选择一个目录准备6个文件夹
mkdir 7001 7002 7003 7004 7005 7006
7001的配置文件
include /opt/redis/redisserver/bin/redis.conf
port 7001
# 后端启动
daemonize yes
pidfile "/var/run/redis_7001.pid"
# 存放数据库的文件 rdb 模式
dbfilename "dump_7001.rdb"
# 工作目录
dir "/opt/redis/redisserver/rediscluster/7001"
logfile "/opt/redis/redisserver/rediscluster/7001/redis_err_7001.log"
cluster-enabled yes
cluster-config-file nodes-7001.conf
cluster-node-timeout 15000批量复制文件到目录里面
echo ./7002 ./7003 ./7004 ./7005 ./7006 | xargs -n 1 cp -v /opt/redis/redisserver/rediscluster/7001/redis.conf将六个redis全部启动
./redis-server ../rediscluster/7001/redis.conf进入redis-cli 所在的目录
配置节点，主节点和从节点
./redis-cli --cluster create --cluster-replicas 1 192.168.184.34:7001 192.168.184.34:7002 192.168.184.34:7003 192.168.184.34:7004 192.168.184.34:7005 192.168.184.34:7006 -a yyl
三主三从也就配好了
查看状态
192.168.184.34:7001 指的是集群中的节点
./redis-cli --cluster check 192.168.227.99:7001 -a cxy
优雅的关闭
集群配置好之后一定要优雅的关闭
如果不优雅的关闭 将会破环集群
使用客户端去关闭
./redis-cli -p 7001 shutdown
扫一扫
915
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
