需要配合源码一起康~
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监控多个主节点：同一业务的多个主节点可接受
