Redis-Sentinel(哨兵)

Redis Sentinel架构

故障转移

  • 1.多个sentinel发现并且确认master有问题

  • 2.选举出一个sentinel作为领导

  • 3.选举出一个slave作为master

  • 4.通知其余的Slave成为新的master的slave

  • 5.通知客户端主从变化

  • 6.等待老的master复活成为新的master的slave

redis sentinel部署

redis主节点

redis-server redis-6000.conf

主节点配置

port 6000
daemonize yes 
pidfile /var/run/redis-6000.pid
logfile "6000.log"
dir ./

redis从节点

redis-server redis-6001.conf / redis-6002.conf

从节点配置

port 6001/6002
daemonize yes 
pidfile /var/run/redis-6001/6002.pid
logfile "6001/6002.log"
dir ./
slaveof 127.0.0.1 6000

sentinel主要配置

port ${port}
dir ./
daemonize yes 
logfile "{port}.log"
sentinel monitor mymaster 127.0.0.1 6000 2      #要监控的主节点的名字IP和端口,2代表当多少sentinel发现master出问题才故障转移
sentinel down-after-milliseconds mymaster 30000     当30秒没有发现master有回复就证明有问题
sentinel parallel-syncs mymaster 1      #复制是并发的还是串形的,1为一次只复制一个
sentinel failover-timeout mymaster 180000       #故障转移时间

启动redis主从

启动哨兵

cat sentinel.conf |grep -v "#"|grep -v "^$" >conf/sentinel.conf

启动副哨兵

#如果是启动过的复制来的一定要删除ID那一项,启动会重新获取
port 任意端口号
dir "/root/redis-3.2.9"
daemonize yes
logfile "26380.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
# Generated by CONFIG REWRITE
sentinel current-epoch 0

客户端如何连接sentinel

客户端接入流程

  • 1.Sentinel地址集合

  • 2.maseterNmae

  • 3.不是代理模式

Python如何连接Sentinel

from redis.sentinel import Sentinel
sentinel = Sentinel([("localhost",26379),('localhost',26380),('localhost',26381)],socket_timeout=0.1)
sentinel.discover_master('mymaster')
sentinel.discover_slaves('mymaster')

三个定时任务

  • 1.每一个10秒每一个sentinel对master和slave执行info
    • 发现slave节点
    • 确认主从关系

  • 2.每2秒每一个sentinel通过master节点的channel交换信息(pub/sub)
    • 通过sentinel:hello频道交互
    • 交互对节点的看法和自身的信息交换

  • 3.每一秒每个sentinel对其他sentinel和redis之心ping任务

主观下线和客观下线

  • 主观下线:每一个sentinel节点对Redis节点失败的”偏见”

  • 客观下线:所有的sentinel节点对是失败”达成共识”(超过一定的数量无法PING通就强制下线)

  • sentinel is-master-downby-addr

sentinel monitor <MasterName> <ip> <port> <quorum>      #监控的IP、端口、投票数目
sentinel down-after-milliseconds<MasterName> <timeout>      #主观下线的配置、master名称、和超时时间

领导者选举

  • 原因:只有一个sentinel节点完成故障转移

  • 选举:通过sentinel is master-down-by-addr命令都希望成为领导者

    • 1.每一个做主观下线的sentinel节点发送命令,要求将它设置为领导者
    • 2.收到命令的sentinel节点如果没有同意其他sentinel节点发送的命令,那么就将同意请求,否则会拒绝
    • 3.如果某一个节点sentinel节点发现自己去的票数已经超过sentinel集合半数且超过quorum的数量,那么就成为新的领导者
    • 4.如果此过程中有多个sentinel节点成为了领导者,那么将等待一段时间重新进行选举

故障转移

  • 1.从salve节点中选出一个合适的节点作为新的master节点

  • 2.对上面的slave节点执行slaveof no one 命令让它成为master节点

  • 3.向剩余的slave节点发送命令,让他们成为新master节点的slave节点。复制规则和parllel-syncs参数有关

  • 4.更新对原来的master节点配置slave,并且保持对其”关注”,当它恢复后命令它去复制新的master节点

选择合适的slave节点

  • 1.选择slave-priority(slave节点优先级)最高级的slave节点,如果存在就返回,不存在则继续

  • 2.选择复制偏移量最大的slave节点(复制最完整的),如果存在就返回,不存在就继续

  • 3.选择runid最小的节点

常见的开发运维问题

  • 节点运维

  • 高可用读写分离

节点运维

  • 节点上线和下线

    • 主节点
    • 从节点
    • sentinel节点

主节点

1.机器下线:例如过保修的机器情况

2.机器性能不足够:CPU、内存、硬盘、网络等

3.节点自身故障:例如服务器不稳定

从节点

  • 从节点:临时下线还是永久下线,例如是否做一些清理的工作,但是要考虑读写分离的情况。

节点上线

  • 主节点:sentinel failover进行替换

  • 从节点:slaveof,sentinel集诶单可以感知

  • sentinel节点:参考其他sentinel节点启动即可

总结

  • Redis Sentinel是redis的高可用实现的方案:故障发现、故障自动转移、配置中心、客户端通知

  • Redis Sentinel从Redis2.8版本开始才正式生产可用、之前的版本不用

  • 尽量载不同物理机器上部署Redis Sentinel所有节点

  • Redis Sentinel中的Sentinel节点个数应该大于或等与3,最好为奇数

  • Redis Sentinel中的数据集诶单与普通数据节点没有区别

  • 客户端初始化时候连接的是Sentinel节点集合,不再是具体的redis节点,但是Sentinel的配置中心不再是代理

Redis-Sentinel(哨兵)》有1个想法

  1. Undeniably believe that which you said. Your favorite justification appeared to be on the net the simplest thing to be aware of. I say to you, I definitely get annoyed while people think about worries that they plainly don’t know about. You managed to hit the nail upon the top as well as defined out the whole thing without having side-effects , people could take a signal. Will likely be back to get more. Thanks

发表评论

电子邮件地址不会被公开。 必填项已用*标注