需要配合源码一起康~

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 主从版本的故障转移流程

1. 主挂了，客户端连接不到，找到运维人员
2. 运维人员查看从节点的复制情况，选择一个最新同步的从节点，执行 slaveof no one使其成为主节点
3. 运维人员执行slaveof new-master-host port，使得别的从节点复制新的主节点
4. 更改客户端的主节点信息，重新连接新的主

在这个过程中，需要运维人员来做操作，时效性和准确性都比较难保证。sentinel应运而生，能够自动完成故障发现和故障转移

9.1.3 sentinel的实现方式

redis sentinel是一个分布式架构，包含若干sentinel节点和redis数据节点。sentinel的大致步骤：

1. 每个sentinel节点会对数据节点和其余sentinel节点进行监控（心跳包）。
2. 如果发现节点不可达，会对节点做下线标识。
3. 如果被标记的是主节点，会与其他sentinel节点进行协商（投票）。
4. 多数sentinel节点认为主节点不可达（防止误判），会选择一个sentinel节点做故障转移。
5. 同时客户端连接的sentinel节点，从中获取新的主节点信息

9.2 sentinel的安装和部署

9.2.1 确定拓扑

9.2.2 部署数据节点

第一步：启动主节点

1. 使用redis-server启动，可以在配置文件中增加daemonize yes设置启动的redis开启守护进程模式（redis会在后台运行）
   1. 当daemonize选项设置成no时，当前界面将进入redis的命令行界面，exit强制退出或者关闭连接工具(putty,xshell等)都会导致redis进程退出。
2. 确定数据节点是否启动，可以redis-cli连接之后输入ping

第二步：启动从节点

1. 使用redis-server启动，在配置文件中增加slaveof host port

第三步：确定主从关系

1. 在主节点上执行info，可以看到从节点的信息
2. 在从节点上执行info，可以看到主节点的信息

9.2.3 部署sentinel节点

第一步：确定sentinel节点配置（下方有参数详解）

# 监控主节点的地址和端口，判断主节点失败需要至少2个sentinel
# sentinel monitor    
sentinel monitor mymaster 127.0.0.1 6379 2# 监控主节点的配置项
# sentinel   
# 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 mymaster1) "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    # 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  
sentinel auth-pass  
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     sdown客观下线 odown主观下线
# 当配置之后，脚本会收到每个sentinel节点传过来的事件参数（如主观下线：+sdown master mymaster host port）
sentinel notification-script  # sentinel完成故障转移之后，会把故障转移的结果发给对应的脚本
# 参数这样：      
# role: sentinel的角色，leader/observer
# from：原主节点 to：新主节点
sentinel client-reconfig-script  

脚本相关

1. 脚本需要有可执行权限
2. 脚本开头必须是shell开头#!/bin/sh
3. 脚本的最大执行时间是60s
4. 脚本exit 1结束，重试执行；exit 2结束不会重试；正常exit 0

# notification-script
#!/bin/sh
python notify_redis.py $*# notify_redis.py
import sysdef 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监控多个主节点：同一业务的多个主节点可接受