关于Redis哨兵模式的原理,我在进阶篇的《分布式框架之高性能:Redis哨兵模式》已经详细讲解过了,不熟悉的读者可以先去了解下。
本章,我将带领大家部署一个3节点的哨兵集群,并介绍如何基于哨兵进行故障转移,以及一些企业级的配置方案。
一、哨兵部署
我们先来构建一个哨兵集群,一般哨兵集群至少需要三个独立的机器节点,这样才能保证哨兵自身的高可用。我在前几个章节已经带领大家部署了一主二从的Redis架构。本章,我们就在之前的ressmix-dsf01、ressmix-dsf02、ressmix-dsf03上分别部署一个哨兵,运行在5000端口,整个架构逻辑图如下:
1.1 哨兵配置
我以ressmix-dsf01节点为例,进行部署。哨兵的配置文件位于Redis安装包的根目录下,名叫sentinel.conf。我们先创建两个目录:
#存放哨兵配置文件
mkdir /etc/sentinal
#哨兵的工作目录
mkdir -p /var/sentinel/5000
#存放哨兵日志
mkdir -p /var/log/sentinel/5000
然后,把配置文件复制到/etc/sentinal目录,并重命名为5000.conf。接着,修改配置文件中的如下参数:
port 5000
bind 192.168.0.107
daemonize yes
logfile /var/log/sentinel/5000/sentinel.log
dir /var/sentinel/5000
sentinel monitor mymaster ressmix-dsf01 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel auth-pass mymaster ressmix
我来解释下比较重要的几个参数:
- port 5000:就是哨兵自身运行的端口,默认是26379,我们修改成了5000;
- bind 192.168.0.107:默认情况下,哨兵只能从127.0.0.1访问,我们修改成机器的IP,这样哨兵之间可以互相通信;
- dir /var/sentinal/5000:哨兵自身的工作目录;
- sentinel monitor mymaster ressmix-dsf01 6379 2:这里的mymaster就是哨兵要监控的集群名称,可以自定义,我这里命名为”mymaster“。ressmix-dsf01是这个集群中的Master节点的IP,我这里直接用主机名,6379就是Master节点的运行端口。最后一个2表示quorum,也就是当有quorum个哨兵认为主节点客观下线时,就开始哨兵Leader选举,进行故障转移,由于我们一共有三个哨兵,所以按照大多数原则,quorum=(3/2)+1=2;
- down-after-milliseconds:表示如果哨兵超过这个时间都没法跟Redis主节点取得联系,那就可能认为这个redis实例挂了,即主观下线;
- parallel-syncs:表示发生故障转移时,选举了新的Master节点,那同时挂载多少个Slave节点去同步数据,我这里用默认值1个;
- failover-timeout:表示哨兵Leader进行故障转移的超时时间,如果超过这个时间还没做完故障转移,就会重新选举哨兵Leader主持故障转移,默认3分钟;
- 最后,如果Master节点设置了认证口令,一定不要忘记在哨兵配置
sentinel auth-pass
中都加上密码。
全部配置完成后,我们执行以下命令启动哨兵:
redis-server /etc/sentinal/5000.conf --sentinel
如下图所示,哨兵发现了Master的两个Slave节点,并且也发现了另外两个哨兵,哨兵之间会互相通过我在进阶篇中讲到过的消息发布/订阅机制进行通信:
1.2 哨兵状态
我们可以通过命令检查下哨兵的状态:
redis-cli -h 192.168.0.109 -p 5000
查看集群中的Master节点状态:
192.168.0.109:5000> sentinel master mymaster
1) "name"
2) "mymaster"
3) "ip"
4) "192.168.0.107"
5) "port"
6) "6379"
7) "runid"
8) "5cb6aed556e853b886a0722170ef024aebc1ace4"
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "362"
19) "last-ping-reply"
20) "362"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "4481"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "285881"
29) "config-epoch"
30) "0"
31) "num-slaves"
32) "2"
33) "num-other-sentinels"
34) "2"
35) "quorum"
36) "2"
37) "failover-timeout"
38) "180000"
39) "parallel-syncs"
40) "1"
查看集群中的Slave节点的状态:
192.168.0.109:5000> SENTINEL slaves mymaster
1) 1) "name"
2) "192.168.0.109:6379"
3) "ip"
4) "192.168.0.109"
5) "port"
6) "6379"
7) "runid"
8) "fe25299543962d47a64197664b281ce0d9e49410"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "612"
19) "last-ping-reply"
20) "612"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "9237"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "340548"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "192.168.0.107"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "77323"
2) 1) "name"
2) "192.168.0.110:6379"
3) "ip"
4) "192.168.0.110"
5) "port"
6) "6379"
7) "runid"
8) "168c3cb9c0162f91c6a047e8b20c0b1562356a2f"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "612"
19) "last-ping-reply"
20) "612"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "9237"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "340842"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "192.168.0.107"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "77323"
查看监控这个集群的其它哨兵的状态:
192.168.0.109:5000> SENTINEL sentinels mymaster
1) 1) "name"
2) "cd48456d2f4342db47efb9f33bf679aa5b611e56"
3) "ip"
4) "192.168.0.110"
5) "port"
6) "5000"
7) "runid"
8) "cd48456d2f4342db47efb9f33bf679aa5b611e56"
9) "flags"
10) "sentinel"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "72"
19) "last-ping-reply"
20) "72"
21) "down-after-milliseconds"
22) "30000"
23) "last-hello-message"
24) "221"
25) "voted-leader"
26) "?"
27) "voted-leader-epoch"
28) "0"
2) 1) "name"
2) "7ed8bb8d42e7d443aa90d3d2cfabc9dbd8f77217"
3) "ip"
4) "192.168.0.107"
5) "port"
6) "5000"
7) "runid"
8) "7ed8bb8d42e7d443aa90d3d2cfabc9dbd8f77217"
9) "flags"
10) "sentinel"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "72"
19) "last-ping-reply"
20) "72"
21) "down-after-milliseconds"
22) "30000"
23) "last-hello-message"
24) "254"
25) "voted-leader"
26) "?"
27) "voted-leader-epoch"
28) "0"
二、容灾演练
哨兵集群部署完成后,我们可以进行下容灾演练,看看哨兵是不是真的做到了故障自动转移。现在,我这边d的Redis主从架构是下面这样的:
Master,部署在ressmix-dsf01: 192.168.0.107
Slave1,部署在ressmix-dsf02: 192.168.0.109
Slave2,部署在ressmix-dsf03: 192.168.0.110
2.1 故障转移
我先把Master节点kill -9掉,然后把它的pid文件(/var/run/redis_6379.pid)也删除掉,用来模拟Master节点挂掉。等待30s后,T通过日志可以发现哨兵进行了故障自动转移,下面是ressmix-dsf01节点上的哨兵日志:
1385:X 25 Apr 2020 14:16:45.880 # +sdown master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:45.935 # +odown master mymaster 192.168.0.107 6379 #quorum 3/2
1385:X 25 Apr 2020 14:16:45.935 # +new-epoch 1
1385:X 25 Apr 2020 14:16:45.935 # +try-failover master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:45.971 # +vote-for-leader 7ed8bb8d42e7d443aa90d3d2cfabc9dbd8f77217 1
1385:X 25 Apr 2020 14:16:45.973 # 8e23c3b5d6d9edc4dbb845dc8b8e858e4ce2142c voted for 8e23c3b5d6d9edc4dbb845dc8b8e858e4ce2142c 1
1385:X 25 Apr 2020 14:16:46.020 # cd48456d2f4342db47efb9f33bf679aa5b611e56 voted for 7ed8bb8d42e7d443aa90d3d2cfabc9dbd8f77217 1
1385:X 25 Apr 2020 14:16:46.037 # +elected-leader master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.037 # +failover-state-select-slave master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.090 # +selected-slave slave 192.168.0.110:6379 192.168.0.110 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.090 * +failover-state-send-slaveof-noone slave 192.168.0.110:6379 192.168.0.110 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.148 * +failover-state-wait-promotion slave 192.168.0.110:6379 192.168.0.110 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.913 # +promoted-slave slave 192.168.0.110:6379 192.168.0.110 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.913 # +failover-state-reconf-slaves master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:46.932 * +slave-reconf-sent slave 192.168.0.109:6379 192.168.0.109 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:47.127 # -odown master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:16:47.915 * +slave-reconf-inprog slave 192.168.0.109:6379 192.168.0.109 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:19:46.900 # +failover-end-for-timeout master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:19:46.900 # +failover-end master mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:19:46.900 * +slave-reconf-sent-be slave 192.168.0.109:6379 192.168.0.109 6379 @ mymaster 192.168.0.107 6379
1385:X 25 Apr 2020 14:19:46.900 # +switch-master mymaster 192.168.0.107 6379 192.168.0.110 6379
1385:X 25 Apr 2020 14:19:46.900 * +slave slave 192.168.0.109:6379 192.168.0.109 6379 @ mymaster 192.168.0.110 6379
1385:X 25 Apr 2020 14:19:46.900 * +slave slave 192.168.0.107:6379 192.168.0.107 6379 @ mymaster 192.168.0.110 6379
可以看到,新的Master节点变成了192.168.0.110,也就是ressmix-dsf03。我们可以通过命令info replication
看下,它的角色已经变成了Master:
192.168.0.110:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:07383ad9fb832365fc67b9a578c54a36a21ff274
master_replid2:f5180409b8a45a9f71eed3c8241bcedbc8986a48
master_repl_offset:354070
second_repl_offset:297908
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:354070
2.2 故障恢复
然后,我们再恢复ressmix-dsf01上的redis节点,这样它就会被作为Slave节点加入到集群中。我们可以通过任一哨兵看下集群的状态:
192.168.0.109:5000> SENTINEL slaves mymaster
1) 1) "name"
2) "192.168.0.107:6379"
3) "ip"
4) "192.168.0.107"
5) "port"
6) "6379"
7) "runid"
8) "e7ec2725eca9313417e6823ebf00ac3867c74abc"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "383"
19) "last-ping-reply"
20) "383"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "2896"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "34123"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "192.168.0.110"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "418255"
2) 1) "name"
2) "192.168.0.109:6379"
3) "ip"
4) "192.168.0.109"
5) "port"
6) "6379"
7) "runid"
8) "fe25299543962d47a64197664b281ce0d9e49410"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "300"
19) "last-ping-reply"
20) "300"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "300"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "585068"
29) "master-link-down-time"
30) "616000"
31) "master-link-status"
32) "err"
33) "master-host"
34) "192.168.0.110"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "297907"
三、总结
本章,我讲解了Redis哨兵模式的搭建,通过实战我们可以对Redis高可用的原理有更深的认识,读者可以尝试在本机按照我所述的步骤动手搭建,加深印象。
Java 面试宝典是大明哥全力打造的 Java 精品面试题,它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题,而是一套完整的 Java 知识体系,一套你 Java 知识点的扫盲贴。
它的内容包括:
- 大厂真题:Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
- 原创内容:Java 面试宝典内容全部都是大明哥原创,内容全面且通俗易懂,回答部分可以直接作为面试回答内容。
- 持续更新:一次购买,永久有效。大明哥会持续更新 3+ 年,累计更新 1000+,宝典会不断迭代更新,保证最新、最全面。
- 覆盖全面:本宝典累计更新 1000+,从 Java 入门到 Java 架构的高频面试题,实现 360° 全覆盖。
- 不止面试:内容包含面试题解析、内容详解、知识扩展,它不仅仅只是一份面试题,更是一套完整的 Java 知识体系。
- 宝典详情:https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
- 宝典总览:https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
- 宝典进展:https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw
目前 Java 面试宝典累计更新 400+ 道,总字数 42w+。大明哥还在持续更新中,下图是大明哥在 2024-12 月份的更新情况:
想了解详情的小伙伴,扫描下面二维码加大明哥微信【daming091】咨询
同时,大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ,回复【面试题】 即可免费领取。