利用redis-sentinel+consul实现redis高可用

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://dgd2010.blog.51cto.com/1539422/1745314

在前文《利用redis-sentinel+keepalived实现redis高可用》详细描述了利用redis-sentinel+keepalived实现redis高可用的方案。本文中redis-sentinel的应用场景也是一样的,也是提供Redis单实例服务,当某Redis(master)服务意外停掉或该服务所在的主机发生宕机故障或网络故障时,另一台Redis服务会由slave自动成为master,提供Redis读写服务。redis-sentinel的配置可以参考前文,本文略去,只讨论consul代替keepalived。

由于keepalived的应用场景有限,比如它的核心协议VRRP只能工作在局域网内,不能工作在局域网外(网间、广域网),而且在网络不受自己控制时基本不能用,除非设定好的VIP是供局域网使用。因此特别是在云计算环境中,使用云主机(例如阿里云ECS等)就不能用keepalived,因此只能寻找一个可替代keepalived的解决方案来替代它。Consul作为服务注册、服务发现的最佳选择,无疑可以很好的替代keepalived。

前文是用的keepalived提供一个VIP为上层应用提供访问入口,本文是将keepalived替换成consul,利用consul的DNS Interface为上层应用提供Redis(master)的IP。

前提条件:需要一个可用的consul集群,可以利用consul集群本身和配置文件注册服务,也可以用一台单独的主机注册,还可以用HTTP API向Consul注册。

为了获取Redis(master)的IP而不是Redis(Slave)的IP,可以用脚本检查实现,与keepalived脚本中相似,只是返回值将1设定成2,因为consul中返回值0是没问题(passed),1是警告(warning),2是严重(critical)。

下面是用一台单独的主机注册的例子。

json配置文件如下:


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

{

  "services": [

    {

      "id""redisnode1",

      "name""redis",

      "tags": [

        "master"

      ],

      "address""192.168.1.241",

      "port": 6379,

      "checks": [

        {

          "script""/usr/local/sbin/redis-cli -h 192.168.1.241 -p 6379 info | grep role:master || exit 2",

          "interval""5s"

        }

      ]

    },

    {

      "id""redisnode2",

      "name""redis",

      "tags": [

        "master"

      ],

      "address""192.168.1.242",

      "port": 6379,

      "checks": [

        {

          "script""/usr/local/sbin/redis-cli -h 192.168.1.242 -p 6379 info | grep role:master || exit 2",

          "interval""5s"

        }

      ]

    },

    {

      "id""redisnode3",

      "name""redis",

      "tags": [

        "master"

      ],

      "address""192.168.1.243",

      "port": 6379,

      "checks": [

        {

          "script""/usr/local/sbin/redis-cli -h 192.168.1.243 -p 6379 info | grep role:master || exit 2",

          "interval""5s"

        }

      ]

    }

  ]

}

注册是利用consul agent作为Client运行注册的,假设consul集群中某台Server的地址是192.168.1.245。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

mkdir -p /usr/local/consul/data /usr/local/consul/config   

cat >/usr/local/consul/config/rediscluster.json<<eof

{

  "services": [

    {

      "id""redisnode1",

      "name""redis",

      "tags": [

        "master"

      ],

      "address""192.168.1.241",

      "port": 6379,

      "checks": [

        {

          "script""/usr/local/sbin/redis-cli -h 192.168.1.241 -p 6379 info | grep role:master || exit 2",

          "interval""5s"

        }

      ]

    },

    {

      "id""redisnode2",

      "name""redis",

      "tags": [

        "master"

      ],

      "address""192.168.1.242",

      "port": 6379,

      "checks": [

        {

          "script""/usr/local/sbin/redis-cli -h 192.168.1.242 -p 6379 info | grep role:master || exit 2",

          "interval""5s"

        }

      ]

    },

    {

      "id""redisnode3",

      "name""redis",

      "tags": [

        "master"

      ],

      "address""192.168.1.243",

      "port": 6379,

      "checks": [

        {

          "script""/usr/local/sbin/redis-cli -h 192.168.1.243 -p 6379 info | grep role:master || exit 2",

          "interval""5s"

        }

      ]

    }

  ]

}

eof

/bin/consul agent -advertise=$(ifconfig $(route -n | awk '/^0.0.0.0/ && /UG/ {print $NF}') | grep inet | egrep -v "(inet6|127.0.0.1)" cut -d ":" -f2 | cut -d " " -f1) -bind=$(ifconfig $(route -n | awk '/^0.0.0.0/ && /UG/ {print $NF}') | grep inet | egrep -v "(inet6|127.0.0.1)" cut -d ":" -f2 | cut -d " " -f1) -data-dir=/usr/local/consul/data -config-dir=/usr/local/consul/config -join 192.168.1.245

需要后台运行时可以添加nohup thiscommandline >/path/to/logfile 2>&1 &

注意:在consul json配置文件中,每个consul agent的service id都不能重复,name是强制要求的,必须要有,如果id省略,则跟name相同,其他的都是可选的,可有可无。但为了能够使用某条服务信息,就必须要有IP和port,当然port可以在应用中指定。check最好要有,否则当出现问题时不能从consul中取消注册。

注意:上述命令行中使用的是与默认网关同网段IP(公网IP地址),要求此地址与consul集群地址之间能互相访问。在启动consul agent之前可以下面两行命令中的一行确定是否满足此条件:


1

2

consul info -rpc-addr=192.168.1.245:8400   

consul members -rpc-addr=192.168.1.245:8400

在consul agent启动后,此时Redis的信息就会在consul中展示出来,包括UI、DNS Interface和HTTP API中都能查询到。使用Redis的应用应该将DNS指向consul集群的DNS地址,这样才能查询到Redis服务对应的IP。

通过consul HTTP API中提供的“curl http://192.168.1.245:8500/v1/catalog/service/redis”方法只能列举出当前service:redis中有哪些节点,但无法区分这些节点中哪些是正常工作的节点,哪些是有问题的节点,但DNS Interface方法“dig @192.168.1.245 -p 53 redis.service.dc1.consul. ANY”可以准确的将可用的节点的IP找到,如下图所示。

例如用redis-cli测试一下Redis集群。

文中只是利用consul的DNS Interface获取到了Redis集群的master的IP,并没有获取到port,尽管可以通过“dig @192.168.1.245 -p 53 redis.service.consul SRV”可以获取到port,但对于上层应用来说并不是很好做,毕竟大部分应用的域名解析是不会查询SRV记录的。本文的consul是Consul v0.6.0,目前有更新的版本0.6.3可以使用,https://www.consul.io/downloads.html ,consul可能还有其他比较好用的方法更好的获取服务的IP和Port,以后使用的过程中也会再补充。更多关于consul的信息可以参考consul的官方网站:https://www.consul.io/

注意:可能存在的问题。如果Redis master发生故障,原先的slave会变成新的master,DNS缓存可能不会刷新,这个在发生故障处理时需要注意清空上层应用的DNS缓存。

tag:Redis集群,Redis高可用,redis-sentinel,consul API,Redis主从复制

--end--

本文出自 “通信,我的最爱” 博客,请务必保留此出处http://dgd2010.blog.51cto.com/1539422/1745314

时间: 2024-09-28 16:11:09

利用redis-sentinel+consul实现redis高可用的相关文章

云数据库Redis版主从热备高可用方案

引言 高可用(High Available)是线上生产环境所必不可少的重要条件,阿里云数据库Redis版作为一款成熟稳定的数据库产品,针对Redis的特性也支持高可用,本文将介绍云Redis是如何实现这一方案. 架构 目前云Redis有主从版和集群版两种架构,本次主要针对主从版做HA的解析. 下图为主从版架构: 由图可知,云Redis实例有主备两个节点,平时只有Master提供服务,Slave只做热备不提供访问,Slave通过slaveof命令挂载到Master上,不断从Master接收数据,保

基于Redis Sentinel的Redis集群(主从Sharding)高可用方案(转)

本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在Redis2.4中,Redis2.8中Sentinel更加稳定),Redis集群是以分片(Sharding)加主从的方式搭建,满足可扩展性的要求: Redis Sentinel介绍 Redis Sentinel是Redis官方提供的集群管理工具,主要有三大功能: 监控,能持续监控Redis的主从实例是否正常

redis 学习笔记(4)-HA高可用方案Sentinel配置

上一节中介绍了master-slave模式,在最小配置:master.slave各一个节点的情况下,不管是master还是slave down掉一个,"完整的"读/写功能都将受影响,这在生产环境中显然不能接受.幸好redis提供了sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决 每个sentinel会向其它sentinal.master.slave定时发送消息,以确认对方是否"活

Redis开发运维实践高可用和集群架构与实践(四)

11.1.4 高可用和异常测试 11.1.4.1 测试环境介绍 sentinel的消息可以通过sentinel日志(/redis/log/sentinel.log)以及sentinel:hello订阅此频道进行查看. 11.1.4.2 手动切换测试 集群情况,2.128为主 发起主动切换: 查看sentinel日志: 在2.129上看,集群已经切换过来: 11.1.4.3 主实例宕测试 接上,此时master为2.129,找出redis实例的pid,然后kill: 此时查看sentinel日志:

Redis开发运维实践高可用和集群架构与实践(二)

11.1.2 环境搭建 11.1.2.1 部署架构 部署架构上采用三台机器,一个Master接受写请求,两个Slave进行数据同步,三台机器上都部署sentinel(一般为奇数个,因为需要绝大部分进行投票才能failover).(官方示例)具体架构如下图: 注意:如果有条件可以将sentinel多部署几个在客户端所在的应用服务器上,而不是与从节点部署在一起,这样避免整机宕机后sentinel和slave都减少而导致的切换选举sentinel无法超过半数. 11.1.2.2 网络规划 redis高

Redis开发运维实践高可用和集群架构与实践(一)

11.1 主从复制-sentinel架构 11.1.1 高可用原理 11.1.1.1 发现原理 Sentinel发现分为发现从服务器和发现其他sentinel服务两类: Sentinel实例可以通过询问主实例来获得所有从实例的信息 Sentinel进程可以通过发布与订阅来自动发现正在监视相同主实例的其他Sentinel,每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 __sentinel__:hello 频道, 查找之前未出现过的 sentinel进程. 当一个 Sentin

Nginx反向代理,负载均衡,redis session共享,keepalived高可用

相关知识自行搜索,直接上干货... 使用的资源: nginx主服务器一台,nginx备服务器一台,使用keepalived进行宕机切换. tomcat服务器两台,由nginx进行反向代理和负载均衡,此处可搭建服务器集群. redis服务器一台,用于session的分离共享. nginx主服务器:192.168.50.133 nginx备服务器:192.168.50.135 tomcat项目服务器1:192.168.50.137 tomcat项目服务器2:192.168.50.139 redis服

Redis开发运维实践高可用和集群架构与实践(五)

11.1.5 其他问题 11.1.5.1 只读性 主从复制架构下,默认Slave是只读的,如果写入则会报错: 127.0.0.1:6379> set foo bar (error) READONLY You can't write against a read only slave. 注意这个行为是可以修改的,虽然这样的修改没有意义: 127.0.0.1:6379> CONFIG SET slave-read-only no OK 127.0.0.1:6379> set foo bar

Redis开发运维实践高可用和集群架构与实践(三)

11.1.3 维护操作 11.1.3.1 完整启动 supervisord -c /redis/conf/redis-supervisord.conf 会自动拉起本机的redis和sentinel 11.1.3.2 启停redis supervisorctl -c /redis/conf/redis-supervisord.conf start redis supervisorctl -c /redis/conf/redis-supervisord.conf stop redis supervi

利用阿里云容器服务实现高可用抢红包应用

红包是春节习俗,原本是讨个吉利的意图.在互联网技术高度发展的今天,用手机抢红包已经成为一种文化.一种生活方式:据支付宝统计的数据显示,2016年2月7日除夕夜,支付宝共四轮"咻一咻"互动平台的总参与次数达到了3245亿次:在21点09分,用户的参与热情达到了顶峰,"咻一咻"峰值一度达到210亿次/分钟. 业务需求催生技术升级,随着红包业务的大众化.普遍化,我们对高可用.可扩展.按需提供服务的技术架构要求越来越高.下面介绍一种基于阿里云容器服务及相关云产品组成的高可用