8.Redsi Sentinel
Posted richiewlq
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了8.Redsi Sentinel相关的知识，希望对你有一定的参考价值。
<!doctype html>8.Redis Sentinel
Redsi Sentinel 26379
主从复制高可用
-
为主提供备份 读写分离 故障转移
- 手动故障转移
- 写能力和存储能力受限
-
手动故障转移
- slaveof
- no one
- slaveof new master
架构说明
-
自动故障转移
- 多个sentinel发现master 问题
- 选举一个sentinel作为领导
- 选举一个slave作为master
- 通知其余slave成为新的master的slave
- 通知客户端从变化
- 等待老的master复活成为新master的slave
-
监控多个集群
- master-name
配置启动
-
配置开启主从节点 自动发现从节点
- 配置主节点 redis-server redis-7000.conf
prot 7000
daemonize yes
pidfile /var/run/redis-7000.pid
logfile "7000.log"
dir "/opt/soft/redis/data" - 配置从节点
redis-server redis-7001.conf
redis-server redis-7002.conf
prot 7001
daemonize yes
pidfile /var/run/redis-7001.pid
logfile "7001.log"
dir "/opt/soft/redis/data"
slaveof 127.0.0.1 7000 - sentinel主要配置 sentinel.conf
prot ${prot}
daemonize yes
dir "/opt/soft/redis/data"
logfile "${port}.log"
sentinel monitor mymaster 127.0.0.1 700 2 # 2 指有两个sentinel发现故障 就进行故障转移
sentinel down-after-millisenconds mymaster 30000# 30s 连接不成功 故障转移
sentinel parallel-syncs mymaster 1 # 每次只能复制一个
sentinel failover-timeout mymaster 180000 #故障转移时间
- 配置主节点 redis-server redis-7000.conf
-
配置开启sentinel监控主节点(sentinel是特殊的redis)
-
实际应该多台机器
-
详细配置从节点
客户端连接
-
服务端高可用
-
客户端高可用
- 获取所有的sentinel节点集合 +masterName
- redis数据节点变化通知 发布订阅
-
客户端接入流程
- sentinel地址集合
- masterName
- 不是代理模式 ###jedis
-
jedis new JedisSentinelPool(masterName,sentinelSet,poolConfig,timeout);
redisSentinelPool.getResource();
// jedis command
jedis.close() 归还到池子
redis-py
form redis.sentinel import Sentinel sentinel = Sentinel([(‘localhost‘,26379),(‘localhost‘,26380),(‘localhost‘,26381),],socket_timeout=0.1) sentinel.discover_master("mymaster") sentinel.discover_slaves("mymaster")
故障转移演练
-
客户端高可用观察
-
服务端日志分析：数据节点和sentinel节点
-
单个定时任务
-
每10秒每个sentinel对master和slave执行info
- 发现slave节点
- 确认主从关系
-
每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
- 通过sentinel:hello频道交互
- 交互对节点的“看法”和自身信息
-
每1秒每一个sentinel对其他sentinel的redis执行ping
- 心跳检测，失败判定依据
-
-
-
主主下线和客观下线
-
配置
- sentinel monitor
- sentinel monitor mymaster 127.0.0.1 6379 2
- sentinel down-after-millisenconds # 主观判断
- sentinel down-after-millisenconds mymaster 30000
-
主观下线
- 每一个sentinel节点对Redis节点失败的“偏见”
-
客观下线
- 所有sentinel节点对Redis节点失败“达成共识”(超过quorum个统一)
- sentinel is-master-down-by-addr ###领导者选举
-
- 原因：只有一个sentinel节点完成故障转移
- 选举：通过sentinel is-master-down-by-addr命令都希望成为领导者
- 每个主观下线的sentinel节点向其他sentinel节点发送命令，要求将它设置为领导者
- 收到命令的sentinel节点如果没有同意其他sentinel节点发送的命令，name将同意该请求，否则拒绝
- 如果该sentinel节点发现自己的票数已经超过了sentinel集合半数且超过quorum，name它将成为领导者
- 如果此过程有多个sentinel节点成为领导者，那么将等待一段时间重新进行选举 ###故障转移
- 从slave节点选出一个“哈市的”节点作为新的master节点
- 对上面的slave节点执行slaveof no one命令让其成为master节点
- 向剩余的slave节点发送命令，让他们成为新master节点的slave节点，复制规则和parallel-syncs参数有关
- 更新对原来master节点配置为slave，并保持找对其“关注”，当其回复后命令他去复制新的master节点
合适的slave节点
- 选择slave-prioruty(slave节点优先级)最高的slave节点，如果存在则返回，不存在则继续
- 选择复制偏移量最大的slave节点（复制的最完整），如果存在则返回，不存在继续
- 选择runid最小的slave节点
常见开发运维问题
-
节点运维
-
下线原因分析
- 机器下线：例如过保等情况
- 机器性能不足：例如CPU 内存 硬盘 网络等
- 节点本身故障： 例如服务不稳定等
-
主节点
- sentinel failover
-
从节点
- 临时下线还是永久下线，例如是否做一些清理工作，但是要考虑读写分离的情况
-
sentinel节点：同上
-
节点上线
-
主节点
- sentinel failover 进行替换
-
从节点
- slaveof即可，sentinel节点可以感知
-
sentinel节点：
- 参开其他sentinel节点启动即可
-
-
-
高可用读写分离 客户端
-
通过循环连接sentinel集合 如果所有都能不能连接 异常
-
订阅sentinel 频道 +switch-master
-
收到+switch-master信息
- 重新进行连接sentinel
-
-
-
从节点的作用
-
副本：高可用的基础
-
扩展：读能力
-
故障转移 三个消息
- +switch-master ： 切换节点
- +convert-to-slave:切换从节点
- +sdown : 主观下线 ##总结
-
-
sentinel是redis高可用实现方案
- 故障发现，故障自动转移，配置中心，客户端通知
-
sentinel2.8版本开始正式生产可用，之前版本生产不可用
-
sentinel节点应该大于等于3且最好是奇数
-
sentinel中的数据节点和普通数据节点没有区别
-
sentinel 通过三个定时任务对主从和其余sentinel接的监控
-
sentinel对接点做判定时分为主观下线和客观下线
以上是关于8.Redsi Sentinel的主要内容，如果未能解决你的问题，请参考以下文章
SentinelSentinel整合RestTemplate&openFeign&Dubbo
SentinelSentinel整合RestTemplate&openFeign&Dubbo
SentinelSentinel整合RestTemplate&openFeign&Dubbo