Redis进阶:Redis的哨兵模式搭建
哨兵机制介绍
单机版的Redis存在性能瓶颈，Redis通过提高主从复制实现读写分离，提高了了Redis的可用性，另一方便也能实现数据在多个Redis直接的备份。
上一篇文章我们通过配置Redis的主从复制机制来提高了Redis的可用性，但是一旦主节点出现问题，就需要运维手工切换主从服务节点，即增加了人工成本，且容易出错，而且无法自动化切换，Redis的哨兵机制就能实现自动的主从切换，以及实现对Redis服务的切换，那就让我们来感受下哨兵机制的强大吧。
准备条件
搭建主从服务
这一步在上篇文章以及详细介绍了，这里就简答提一下，细节具体可以翻看上一篇。
# 启动Redis 主从复制集群机制
[root@localhost redis-5.0.7]# src/redis-server redis6379.conf
[root@localhost redis-5.0.7]# src/redis-server redis6380.conf
[root@localhost redis-5.0.7]# src/redis-server redis6381.conf
查看主从复制集群
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=14,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=14,lag=0
master_replid:7af61d3aee64d388592c3dabb16cd9b4a2158d7e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14
可以看到，我们的主从服务（一主二从）已经搭建完毕。
准备哨兵配置文件
我们下载的Redis.tar.gz 解压后里面是有一个senitel.conf配置文件的，我们复制一个然后进行配置修改。
# 复制配置文件
[root@localhost redis-5.0.7]# cp sentinel.conf sentinel26379conf
# 修改sentinel26379conf配置文件
bind 0.0.0.0
port 26379
daemonize yes
pidfile /var/run/redis-sentinel26379.pid
logfile "/usr/local/redis/logs/sentinel-26379.log"
dir /tmp
# 哨兵 监控 主节点名称 IP地址 端口 判断失效的哨兵个数
sentinel monitor mymaster 127.0.0.1 6379 2
# 配置主服务的密码（如果主节点设置密码这块必须要进行配置）
sentinel auth-pass mymaster enjoyitlife
sentinel down-after-milliseconds mymaster 1000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 5000
将配置文件sentinel26379.conf 在复制两份，sentinel26380、sentinel26381.conf。这两个配置文件 值需要修改里的端口号就可以。
# sentinel26380 配置文件内容 26381配置文件就不在赘述了。
bind 0.0.0.0
port 26380
daemonize yes
pidfile /var/run/redis-sentinel26380.pid
logfile "/usr/local/redis/logs/sentinel-26380.log"
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 1000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 5000
sentinel auth-pass mymaster enjoyitlife
运行哨兵
运行哨兵
# 开启三个哨兵监控主节点
[root@localhost redis-5.0.7]# src/redis-sentinel sentinel26379.conf
[root@localhost redis-5.0.7]# src/redis-sentinel sentinel26380.conf
[root@localhost redis-5.0.7]# src/redis-sentinel sentinel26381.conf
也可以通过 redis-server /path/to/sentinel.conf --sentinel 运行哨兵。
查看哨兵状态
# 通过 ps指令
[root@localhost redis-5.0.7]# ps -ef | grep redis
root 7929 1 0 07:49 ? 00:00:01 src/redis-server 0.0.0.0:6379
root 7933 7772 0 07:49 pts/5 00:00:00 src/redis-cli -p 6379 -a enjoyitlife
root 7935 1 0 07:50 ? 00:00:01 src/redis-server 127.0.0.1:6380
root 7941 1 0 07:50 ? 00:00:01 src/redis-server 127.0.0.1:6381
root 7949 1 0 08:00 ? 00:00:00 src/redis-sentinel 0.0.0.0:26379 [sentinel]
root 7954 1 0 08:00 ? 00:00:00 src/redis-sentinel 0.0.0.0:26380 [sentinel]
root 7959 1 0 08:00 ? 00:00:00 src/redis-sentinel 0.0.0.0:26381 [sentinel]
root 7978 7686 0 08:01 pts/4 00:00:00 grep --color=auto redis
# 通过客户端 哨兵机制本质也是Redis服务的一种模式 可以通过客户端指令
[root@localhost ~]# cd /opt/software/redis/redis-5.0.7
[root@localhost redis-5.0.7]# src/redis-cli -p 26379
127.0.0.1:26379> INFO sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
可以看到至此，我们的哨兵机制已经正确搭建完毕，当前有三个哨兵，一主多从，3个服务节点。
哨兵机制验证
我们关闭主节点，然后等待1S后再进行查看。
# 关闭主节点
127.0.0.1:6379> SHUTDOWN
# 在从节点6380上进行查看
127.0.0.1:6380> INFO replication
# Replication
role:master
connected_slaves:0
master_replid:a83e3a8610f2a01691fd859143a4a7dc897b5916
master_replid2:7af61d3aee64d388592c3dabb16cd9b4a2158d7e
master_repl_offset:78278
second_repl_offset:69478
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:78278
可以看到现在的6380节点已经有从节点升级为了主节点。我们再次启动6379节点。
# 启动6379端口节点
[root@localhost redis-5.0.7]# src/redis-server redis6379.conf
[root@localhost redis-5.0.7]# src/redis-cli -p 6379 -a enjoyitlife
# 查看集群信息
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:107428
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a83e3a8610f2a01691fd859143a4a7dc897b5916
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:107428
此时即使6379端口节点恢复正常了，但是它已经失去了主节点的身份，目前降级为了从节点了。下面就哨兵机制的原理在进行说明下。
哨兵机制相关原理
主要功能
- 监控 检查主从服务节点是否服务正常
- 提醒 当被监控的节点出现问题时，哨兵机制可以发送通知
- 自动故障转移 主节点不可以用时，自动进行节点升级和故障转移。
- 提供配置 作为客户端的配置提供者。
故障转移流程
- 每个Sentinel每秒钟向主节点、从节点、其他sentinel实例发送PING命令。
- 如果一个Sentinel发现主服务节点不可用，会将主节点标记为主观下线，并通知其他Sentinel实例向主节点发送消息。
- 如果有足够数量的Sentinel实例，满足配置文件中需要的个数
sentinel monitor mymaster 127.0.0.1 6379 2这里配置的是2，那就将主服务标记为客观下线。 - Sentinel通过选举机制选举出一个Lead Sentinel，负责本次故障转移。
- Sentinle选择一个从服务节点，向其发送SALVE NO ONE 命令，使其升级为主节点。
- 通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新。
- 向从服务器发送 [SLAVEOF] 命令，让他们的主服务节点更新为上一步新主节点。
- 当所有从服务器都已经开始复制新的主服务器时， 复制本次故障转移的Sentinel 终止这次故障迁移操作。
注意要点
- Sentinel会在运行中自动的修改配置文件并进行持久化，主要涉及主从配置点。
- 每一次故障转移Sentinel都会用过选举机制选举从本次故障转移的领头Sentinel，从而有领头的Sentinel来负责故障转移过程。
- Sentinel之间通过订阅发布来进行消息传输。
- Sentinel机制很大程度依赖计算机时间，如果计算机出现故障，或者进程被阻塞，Sentinel可能也会出现故障，从而进入TLTL保护模式，进入TILT模式后，哨兵就不会在起作用。如果在30S内恢复正常，就会退出TITL模式。
以上就是Redis哨兵模式操作的相关介绍了，更多其他指令可以参考官网，Redis官网，谢谢阅读，希望对你有所帮助。