Redis Sentinel 高可用架构

这篇文章主要介绍Redis高可用架构 Redis Sentinel,分别从它是什么,为什么使用,自动化过程以及部署等几个方面说明。

Redis Sentinel 是什么?

Redis Sentinel是Redis的高可用实现方案,是一个分布式架构,包含了若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其他Sentinel节点进行监控,当发现节点不可用时,程序会进行自动化处理,不需要人工介入,从而高效解决了Redis的高可用问题。

为什么要使用?

传统的主从复制模式将主节点数据改变同步给从节点,这样作用有两个:

  1. 作为主节点出现故障的备份
  2. 降低主节点的「读」压力

在主从复制模式下,一旦主节点出现故障,这个过程中需要人工干预进行故障转移,由于人工干预实时性无法得到保证,并且操作过程也容易出现错误,增加了整个过程的不便。所以需要引入一个高可用的架构来自动化转移的整个过程。

自动化过程

转移过程同主从复制人工干预逻辑一样,这里面我们先看人工干预过程:

  1. 主节点(M)故障,从节点(S1,S2)复制中断。
  2. 执行slaveof no one 选一个S1从节点作为新节点。
  3. 更新客户端redis链接到新的主节点S1,重启
  4. 从节点S2开始复制主节点S1数据,等待曾经的主节点M恢复,去复制新的主节点S1数据。

Redis sentinel和主从模式区别只是增加Sentinel节点进行Redis节点监控。

sentinel 架构图

  1. 如图每个Sentinel节点通过定时监控发现主节点出现故障(主关下线)
  2. 多个Sentinel节点对主节点故障达成一致,选出一个领导者负责故障转移
  3. 转移数据过程同上面「人工干预」逻辑一致,只是是自动化的。
  4. 转移完成后,节点slave-1(或者slave-2)变为主节点,原来的master 变为从节点

从上面看出Redis Sentinel具有监控通知,主节点故障转移,提供配置(客户端连接Sentinel节点)等功能。

部署上线

这里我们部署架构使用3个Sentinel节点,1个主节点,2个从节点,组成Redis Sentinel架构。

  • 首先我们正常启动master,slave节点
  • 配置sentinel conf 文件

配置文件redis_sentinel.conf如下:

1
2
3
4
5
6
7
8
9
10
11
port 26379
bind 10.xx.xx.xx
sentinel monitor mymaster 10.xx.xx.xx 6379 2 # 表示配置需要监控10.xx.xx.xx:6379 2表示至少需要2个Sentinel节点统一, mymaster是主节点别名,防止挂了也可以找到主节点
sentinel auth-pass mymaster password # 需要的密码
sentinel config-epoch mymaster 0 #确认mymater SDOWN时长
sentinel down-after-milliseconds mymaster 5000 # mymaster多久不响应认为SDOWN
sentinel failover-timeout mymaster 60000 # 2次failover切换时间
dir "/etc/redis" # 定义目录存放
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
  • 做service启动脚本redis-sentinel.sh放在 /etc/init.d/ 并且该脚本可执行
1
sudo service redis-sentinel start

一些建议

  1. Redis Sentinel的所有节点应该分布在不同的物理机上。
  2. 部署至少三个且奇数个的Sentinel节点
  3. 客户端连接到sentinel节点上。
sitin wechat
扫一扫上面的二维码,订阅我的博客!