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官网，谢谢阅读，希望对你有所帮助。