博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Redis集群-哨兵机制
阅读量:6877 次
发布时间:2019-06-26

本文共 1771 字,大约阅读时间需要 5 分钟。

hot3.png

redis并没有提供自动master选举功能,

  • 而是需要借助一个哨兵来进行监控

哨兵的作用就是监控Redis系统的运行状况,

  • 它的功能包括两个
    • 监控master和slave是否正常运行
    • master出现故障时自动将slave数据库升级为master
  • 哨兵是一个独立的进程,使用哨兵后的架构图
    • 349626a5521a66ba1b6fbfa2a26105e6f30.jpg
    • 为了解决master选举问题,又引出了一个单点问题,
      • 也就是哨兵的可用性如何解决
      • 在一个一主多从的Redis系统中,
        • 可以使用多个哨兵进行监控任务以保证系统足够稳定
      • 时哨兵不仅会监控master和slave,
        • 同时还会互相监控
      • 这种方式称为哨兵集群
        • 哨兵集群需要解决
          • 故障发现、和master决策的协商机制问题
  • a17ed976cc1bbd77755c51bbd1c3f21655f.jpg
  • sentinel之间的相互感知
    • sentinel节点之间会因为共同监视同一个master从而产生了关联,
      • 一个新加入的sentinel节点需要和其他监视相同master节点的sentinel相互感知
        • 需要相互感知的sentinel都向他们共同监视的master节点订阅
          • channel:sentinel:hello
        • 新加入的sentinel节点向这个channel发布一条消息,
          • 包含自己本身的信息,
          • 这样订阅了这个channel的sentinel就可以发现这个新的sentinel
        • 新加入的sentinel和其他sentinel节点建立长连接
        • 95a3f9cc253be2d2ff410c0f02961d24ce5.jpg

master的故障发现

  • sentinel节点会定期向master节点发送心跳包来判断存活状态,
    • 一旦master节点没有正确响应,
    • sentinel会把master设置为“主观不可用状态”,
    • 然后它会把“主观不可用”发送给其他所有的sentinel节点去确认,
    • 当确认的sentinel节点数大于>quorum时,
    • 则会认为master是“客观不可用”,
    • 接着就开始进入选举新的master流程
      • 那谁来决策选择哪个节点作为maste呢?
        • 这里用到了一致性算法Raft算法、它和Paxos算法类似,都是分布式一致性算法。
        • 但是它比Paxos算法要更容易理解;
        • Raft和Paxos算法一样,也是基于投票算法,
          • 只要保证过半数节点通过提议即可;

配置实现

  • 在其中任意一台服务器上创建一个sentinel.conf文件,文件内容
    • sentinel monitor name ip port quorum
      • 其中name表示要监控的master的名字,这个名字是自己定义。
      • ip和port表示master的ip和端口号。
      • 最后一个1表示最低通过票数,
        • 也就是说至少需要几个哨兵节点统一才可以,
    • sentinel monitor mymaster 192.168.11.131 6379 1
    • sentinel down-after-milliseconds mymaster 5000
      • --表示如果5s内mymaster没响应,就认为SDOWN
    • sentinel failover-timeout mymaster 15000
      • --表示如果15秒后,mysater仍没活过来,
      • 则启动failover,从剩下的slave中选一个升级为master
  • 两种方式启动哨兵
    • redis-sentinel sentinel.conf
    • redis-server /path/to/sentinel.conf --sentinel
  • 哨兵监控一个系统时,
    • 只需要配置监控master即可,
    • 哨兵会自动发现所有slave
  • 这时候,我们把master关闭,等待指定时间后(默认是30秒),会自动进行切换
    • +sdown表示哨兵主观认为master已经停止服务了,
    • +odown表示哨兵客观认为master停止服务了。
    • 接着哨兵开始进行故障恢复,
      • 挑选一个slave升级为master
      • +try-failover表示哨兵开始进行故障恢复
      • +failover-end 表示哨兵完成故障恢复
      • +slave表示列出新的master和slave服务器,
        • 我们仍然可以看到已经停掉的master,
        • 哨兵并没有清楚已停止的服务的实例,
        • 这是因为已经停止的服务器有可能会在某个时间进行恢复,
          • 恢复以后会以slave角色加入到整个集群中

转载于:https://my.oschina.net/u/3847203/blog/3024539

你可能感兴趣的文章
spring core 笔记(一)
查看>>
一例mysql主从数据库,从库宕机后无法启动的解决方案
查看>>
WebView 设置软键盘弹出将屏幕上移
查看>>
通过xsl显示和输出XML数据2
查看>>
最简单的iOS网络请求
查看>>
Android软件开发之高斯模糊问题
查看>>
使用Idea14.1.4和maven3创建Javaweb项目
查看>>
golang实现文字云算法
查看>>
artTemplate 学习网址和书籍
查看>>
C++对象内存分配
查看>>
Cong!
查看>>
PHP语言拓展json模块
查看>>
spring 配置文件applicationContext.xml命名空间及标签解析
查看>>
我的友情链接
查看>>
回到顶部代码(兼容IE6)
查看>>
web.xml文件的作用
查看>>
iOS开发篇——OC延展类目协议介绍
查看>>
出来了,下雪了
查看>>
http://jquerymobile.com/ 手机特效制作
查看>>
Golang计算MD5
查看>>