需要配合源码一起康~
9.1 哨兵基本概念
官网手册yyds:https://redis.io/docs/manual/sentinel/
redis主从模式,如果主挂了,需要人工将从节点提升为主节点,通知应用修改主节点的地址。不是很友好,so Redis 2.8之后开始提供哨兵架构来解决该问题,有一些哨兵节点监控redis节点,如果发生一些异常,可以做一些干预。
Redis sentinel是Redis主从版本的高可用实现方式
9.1.1 主从版本存在的问题
redis主从版本会将主节点的数据同步给从节点。从节点的作用:
- 如果主节点挂了,从节点可以提升为主,继续提供服务
- 但这个过程需要运维人员操作:主节点出现故障,需要手动将一个从节点提升为主;需要修改应用方的主节点地址;需要命令其他从节点去复制新的主节点
- 从节点可以扩展主节点的读能力
9.1.2 主从版本的故障转移流程
- 主挂了,客户端连接不到,找到运维人员
- 运维人员查看从节点的复制情况,选择一个最新同步的从节点,执行 slaveof no one使其成为主节点
- 运维人员执行slaveof new-master-host port,使得别的从节点复制新的主节点
- 更改客户端的主节点信息,重新连接新的主
在这个过程中,需要运维人员来做操作,时效性和准确性都比较难保证。sentinel应运而生,能够自动完成故障发现和故障转移
9.1.3 sentinel的实现方式
redis sentinel是一个分布式架构,包含若干sentinel节点和redis数据节点。sentinel的大致步骤:
- 每个sentinel节点会对数据节点和其余sentinel节点进行监控(心跳包)。
- 如果发现节点不可达,会对节点做下线标识。
- 如果被标记的是主节点,会与其他sentinel节点进行协商(投票)。
- 多数sentinel节点认为主节点不可达(防止误判),会选择一个sentinel节点做故障转移。
- 同时客户端连接的sentinel节点,从中获取新的主节点信息
9.2 sentinel的安装和部署
9.2.1 确定拓扑
9.2.2 部署数据节点
第一步:启动主节点
- 使用redis-server启动,可以在配置文件中增加daemonize yes设置启动的redis开启守护进程模式(redis会在后台运行)
- 当daemonize选项设置成no时,当前界面将进入redis的命令行界面,exit强制退出或者关闭连接工具(putty,xshell等)都会导致redis进程退出。
- 确定数据节点是否启动,可以redis-cli连接之后输入ping
第二步:启动从节点
- 使用redis-server启动,在配置文件中增加slaveof host port
第三步:确定主从关系
- 在主节点上执行info,可以看到从节点的信息
- 在从节点上执行info,可以看到主节点的信息
9.2.3 部署sentinel节点
第一步:确定sentinel节点配置(下方有参数详解)
# 监控主节点的地址和端口,判断主节点失败需要至少2个sentinel
# sentinel monitor <master-group-name> <ip> <port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 监控主节点的配置项
# sentinel <option_name> <master_name> <option_value>
# 60s master不可达就认为它坏掉了
sentinel down-after-milliseconds mymaster 60000
# 故障转移超时时间
sentinel failover-timeout mymaster 180000
# 同时配置使用新master的replicas数目
sentinel parallel-syncs mymaster 1
第二步:启动sentinel节点
redis-sentinel /path/to/sentinel.conf
# 或者
redis-server /path/to/sentinel.conf --sentinel
第三步:确认sentinel节点
$ redis-cli -p 5000
127.0.0.1:5000> sentinel master mymaster
1) "name"
2) "mymaster"
3) "ip"
4) "127.0.0.1"
5) "port"
6) "6379"
7) "runid"
8) "953ae6a589449c13ddefaee3538d356d287f509b"
# 或者
$ redis-cli -p 5000
127.0.0.1:5000> info Sentinel
第四步:测试sentinel
# 可以让主节点30s不可达
redis-cli -p 6379 DEBUG sleep 30
9.2.4 配置优化
# 监控主节点的地址和端口,判断主节点失败需要至少2个sentinel
# sentinel 节点会从主节点获取从节点和其他sentinel的信息
# 完成故障转移,还需要有半数以上投票选出执行故障转移的领导,所以投票者为max(quorum, num(sentinel)/2+1)
sentinel monitor <master-group-name> <ip> <port> <quorum>
# 60s master不可达就认为它坏掉了
# 这个参数对判断sentinel节点、主节点、从节点同时有效
sentinel down-after-milliseconds mymaster 60000
# 同时配置使用新master同步的replicas数目
# 因为从节点同时向主节点发起复制,会对主节点的机器造成一定的网络和磁盘开销。如果这个值为1,有3个replicas,则会轮询展开复制
sentinel parallel-syncs mymaster 1
# sentinel对一个节点故障转移失败,下一次再对该节点的故障转移时间将是failver-timeout时间的2倍
# 对要提升为主的从节点执行slaveof no one一直失败,如果这个时间超过failver-timeout,则故障转移失败
# 如果slaveof no one执行成功,但在新主上执行info确认身份命令超过failver-timeout未响应,则故障转移失败
# 如果在其他从节点上执行slaveof host port让其更新主节点,命令超过failver-timeout未响应,则故障转移失败(sentinel最终还是会配置从节点去同步最新主节点)
sentinel failover-timeout mymaster 180000
# acl需要配置账户、密码;如果不支持acl直接配置密码
sentinel auth-user <master-group-name> <username>
sentinel auth-pass <master-group-name> <password>
127.0.0.1:6379> ACL SETUSER sentinel-user ON >somepassword allchannels +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill
# 当一些警告级别的事件发生(节点的主观下线、客观下限等),会触发对应路径的脚本,并向脚本发送一些信息
# 参数这样: +sdown/odown <master-name> <ip> <port> sdown客观下线 odown主观下线
# 当配置之后,脚本会收到每个sentinel节点传过来的事件参数(如主观下线:+sdown master mymaster host port)
sentinel notification-script <master-name> <script-path>
# sentinel完成故障转移之后,会把故障转移的结果发给对应的脚本
# 参数这样:<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# role: sentinel的角色,leader/observer
# from:原主节点 to:新主节点
sentinel client-reconfig-script <master-name> <script-path>
脚本相关
- 脚本需要有可执行权限
- 脚本开头必须是shell开头#!/bin/sh
- 脚本的最大执行时间是60s
- 脚本exit 1结束,重试执行;exit 2结束不会重试;正常exit 0
# notification-script
#!/bin/sh
python notify_redis.py $*
# notify_redis.py
import sys
def main(args):
for arg in args:
if arg == "+odown":
print "HEY SOMETHING IS UP WITH REDIS"
email_text_or_whatever_thing_you_wanna_do()
main(sys.argv)
监控多个主节点
指定多个masterName来区分不同的主节点
调整配置
# 只对当前的sentinel节点有效,如果执行成功会立即刷新配置文件
sentinel set xx
9.2.5 部署注意事项
sentinel节点的高可用:至少三个且奇数个数的sentinel
一套sentinel监控一个主节点:隔离性好,但会造成资源浪费;
一套sentinel监控多个主节点:同一业务的多个主节点可接受