【redis 哨兵搭建】

安装和部署

部署拓扑结构

我们以以3个 Sentinel节点、1个主节点、2个从节点组成一个Redis Sentinel进行说明。

master: 127.0.0.1 6885 主节点

slave-1: 127.0.0.1 6886 slave-1 节点

slave-2: 127.0.0.1 6887 slave-2 节点

sentinel-1: 127.0.0.1 26885 sentinel-1 节点

sentinel-2: 127.0.0.1 26886 sentinel-2 节点

sentinel-3: 127.0.0.1 26887 sentinel-3 节点

集群结构:

部署Redis 数据节点

启动主节点

配置:

sen_master_6885.conf

port 6885

daemonize yes

logfile "/root/redis-6.2.6/log/6885.log"

dbfilename dump-6885.rdb

dir "/root/redis-6.2.6/data/"

启动主节点:

./redis-server ../conf/sen_master_6885.conf

[root@localhost src]# ps -ef | grep 68
root         168       2  0 05:38 ?        00:00:00 [irq/35-pciehp]
root        1968       1  0 05:38 ?        00:00:21 /usr/libexec/packagekitd
root        2368    2212  0 05:43 ?        00:00:00 /usr/libexec/xdg-permission-store
root        2683       1  0 05:43 ?        00:00:00 /usr/sbin/abrt-dbus -t133
root       21402       1  0 23:44 ?        00:00:00 ./redis-server *:6885
root       21414   21351  0 23:44 pts/2    00:00:00 grep --color=auto 68

确认是否启动。一般来说只需要ping命令检测一下就可以，确认 Redis数据节点是否已经启动。

[root@localhost src]# ./redis-cli -p 6885 
127.0.0.1:6885> keys *
(empty array)
127.0.0.1:6885> quit
[root@localhost src]# ./redis-cli -p 6885 ping
PONG

启动两个从节点配置

1. 两个从节点的配置是完全一样的，下面以一个从节点为例子进行说明，和主节点的配置，不一样的是添加了slaveof配置。

sen_slave_6886.conf

port 6886

daemonize yes

logfile "/root/redis-6.2.6/log/6886.log"

dbfilename dump-6886.rdb

dir "/root/redis-6.2.6/data/"

slaveof 127.0.0.1 6885

sen_slave_6887.conf 配置同理,修改端口即可

2. 启动两个从节点:

./redis-server ../conf/sen_slave_6886.conf

./redis-server ../conf/sen_slave_6887.conf

验证:

[root@localhost src]# ./redis-cli -p 6886 ping
PONG
[root@localhost src]# ./redis-cli -p 6887 ping
PONG

3. 确认主从关系

​ 主节点的视角,它有两个从节点，分别是127.0.0.1:6886和127.0.0.1:6887

./redis-cli -p 6885 info replication

[root@localhost src]# ./redis-cli -p 6885 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6886,state=online,offset=126,lag=1
slave1:ip=127.0.0.1,port=6887,state=online,offset=126,lag=1
master_failover_state:no-failover
master_replid:f5603cdcc7326c9d39cac434224e6c022dfc53dd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:126
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:126

​ 从节点的视角，它的主节点是127.0.0.1:6885

./redis-cli -p 6886 info replication

[root@localhost src]# ./redis-cli -p 6886 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6885
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_read_repl_offset:210
slave_repl_offset:210
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:f5603cdcc7326c9d39cac434224e6c022dfc53dd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:210
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:210

部署Sentinel节点

3个Sentinel节点的部署方法是完全一致的(端口不同)，下面以sentinel-26885节点的部署为例子进行说明。

配置Sentinel节点

sentinel_26885.conf

port 26885
daemonize yes
logfile "/root/redis-6.2.6/log/26885.log"
dbfilename dump-26885.rdb
dir "/root/redis-6.2.6/data/"
sentinel monitor mymaster 127.0.0.1 6885 2
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 1000

1 ) Sentinel节点的默认端口是26379，我们改为26885。

2 ) sentinel monitor mymaster 127.0.0.1 6885 2配置代表sentinel-26885节点需要监控127.0.0.1:6885 这个主节点，2代表判断主节点失败至少需要2个Sentinel节点同意，mymaster是主节点的别名，其余Sentinel配置将在下一节进行详细说明。

启动Sentinel节点

Sentinel节点的启动方法有两种:

方法一,使用redis-sentinel命令:

./redis-sentinel ../conf/sentinel_26885.conf

方法二，使用redis-server命令加–sentinel参数:

./redis-server ../conf/sentinel_26885.conf --sentinel

两种方法本质上是—样的。

[root@localhost src]# ./redis-cli -p 26885 ping 
PONG

确认

​ Sentinel节点本质上是一个特殊的Redis节点，所以也可以通过info命令来查询它的相关信息，从下面info的Sentinel片段来看，Sentinel节点找到了主节点127.0.0.1:6885，发现了它的两个从节点。

./redis-cli -p 26885 info Sentinel

[root@localhost src]# ./redis-cli -p 26885 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:6885,slaves=2,sentinels=3

​ 当三个 Sentinel节点都启动后，同时发现Redis Sentinel一共有3个Sentinel节点。这里这里我们可以看到Sentinel节点能够彼此感知到对方，同时能够感知到Redis数据节点。

至此Redis Sentinel已经搭建起来了，整体上还是比较容易的,但是有2点需要强调一下:

1. 生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。

2. Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别,只不过是添加了一些Sentinel节点对它们进行监控。

配置说明

参数变化

​ 当所有节点启动后，配置文件中的内容会发生变化,体现在三个方面:

​ Sentinel节点自动发现了从节点、其余Sentinel节点。

​ 去掉了默认配置，例如 parallel-syncs、failover-timeout参数。

​ 添加了配置纪元相关参数。

启动之前：

port 26885
daemonize yes
logfile "/root/redis-6.2.6/log/26885.log"
dbfilename dump-26885.rdb
dir "/root/redis-6.2.6/data/"
sentinel monitor mymaster 127.0.0.1 6885 2
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 1000 

启动之后：

port 26885
daemonize yes
logfile "/root/redis-6.2.6/log/26885.log"
dbfilename "dump-26885.rdb"
dir "/root/redis-6.2.6/data"
sentinel monitor mymaster 127.0.0.1 6885 2
sentinel down-after-milliseconds mymaster 3000

sentinel failover-timeout mymaster 1000
# Generated by CONFIG REWRITE
protected-mode no
pidfile "/var/run/redis.pid"
user default on nopass ~* &* +@all
sentinel myid 1e57be59952991c9c1270d25539cddcba6544986
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel current-epoch 0
sentinel known-replica mymaster 127.0.0.1 6886
sentinel known-replica mymaster 127.0.0.1 6887
sentinel known-sentinel mymaster 127.0.0.1 26887 9175a26e2248b1db1e588f2c4f69bef2c44f3a37
sentinel known-sentinel mymaster 127.0.0.1 26886 0befaca85c7d715d53b6c7ed87eb84559e7a9bf3

配置文件会自动增加

# Generated by CONFIG REWRITE
protected-mode no
pidfile "/var/run/redis.pid"
user default on nopass ~* &* +@all
sentinel myid 1e57be59952991c9c1270d25539cddcba6544986
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel current-epoch 0
sentinel known-replica mymaster 127.0.0.1 6886
sentinel known-replica mymaster 127.0.0.1 6887
sentinel known-sentinel mymaster 127.0.0.1 26887 9175a26e2248b1db1e588f2c4f69bef2c44f3a37
sentinel known-sentinel mymaster 127.0.0.1 26886 0befaca85c7d715d53b6c7ed87eb84559e7a9bf3

常见配置说明

sentinel monitor

sentinel monitor host-name ip 端口 quorum

​ Sentinel节点会定期监控主节点,所以从配置上必然也会有所体现,本配置说明Sentinel节点要监控的是一个名字叫做，ip地址和端口为 的主节点。代表要判定主节点最终不可达所需要的票数。但实际上Sentinel节点会对所有节点进行监控，但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。

​ 参数用于故障发现和判定，例如将quorum配置为2，代表至少有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为Sentinel节点的一半加1。

​ 同时还与Sentinel节点的领导者选举有关，至少要有max(quorum,num(sentinels)/2+1)个Sentinel节点参与选举，才能选出领导者Sentinel，从而完成故障转移。例如有5个 Sentinel节点,quorum=4，那么至少要有max(quorum, num (sentinels)/2 +1)=4个在线Sentinel节点才可以进行领导者选举。

sentinel down-after-milliseconds

sentinel down-after-milliseconds host-name times

​ 每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复,则判定节点不可达，(单位为毫秒)就是超时时间。这个配置是对节点失败判定的重要依据。

​ down-after-milliseconds虽然以为参数，但实际上对Sentinel 节点、主节点、从节点的失败判定同时有效。

sentinel parallel-syncs

sentinel parallel-syncs <host-name> <nums>

​ 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。

​ 如果这个参数配置的比较大，那么多个从节点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和磁盘IO开销。

sentinel failover-timeout

sentinel failover-timeout <host-name> <times>

failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段:

a)选出合适从节点。

b)晋升选出的从节点为主节点。

c)命令其余从节点复制新的主节点。

d)等待原主节点恢复后命令它去复制新的主节点。

failover-timeout的作用具体体现在四个方面:

1. 如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。

2. 在b)阶段时，如果Sentinel节点向a)阶段选出来的从节点执行slaveof no one一直失败（例如该从节点此时出现故障)，当此过程超过failover-timeout时，则故障转移失败。

3. 在b)阶段如果执行成功，Sentinel节点还会执行info命令来确认a)阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failover-timeout时，则故障转移失败。

4. 如果c)阶段执行时间超过了failover-timeout(不包含复制时间),则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从节点去同步最新的主节点。

监控多个主节点

Redis Sentinel可以同时监控多个主节点。

​ 配置方法也比较简单，只需要指定多个masterName来区分不同的主节点即可，例如下面的配置监控monitor master-1(10.10.xx.1:6379)和monitor master-2 (10.10.xx.2:6379)两个主节点:

#监控master-business-1

sentinel monitor master-1 10.10.xx.1 6379 2

sentinel down-after-milliseconds master-1 60000

sentinel failover-timeout master-1 180000

sentinel parallel-syncs master-1 1

#监控master-business-2

sentinel monitor master-2 10.16.xx.2 6380 2

sentinel down-after-milliseconds master-business-210000

sentinel failover-timeout master-business-2180000

sentinel parallel-syncs master-business-21

部署建议

1 ) Sentinel节点不应该部署在一台物理“机器”上。

​ 这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器，它们虽然有不同的IP地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现Sentinel节点集合真正的高可用,请勿将Sentinel节点部署在同一台物理机器上。

2）部署至少三个且奇数个的Sentinel节点。

​ 3个以上是通过增加 Sentinel节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基础上节省一个节点。这是因为：

A、在节点数量是奇数个的情况下， 集群总能对外提供服务（即使损失了一部分节点）；如果节点数量是偶数个，会存在集群不能用的可能性（脑裂成两个均等的子集群的时候）。

B、假如集群1 ，有3个节点，3/2=1.5 , 即集群想要正常对外提供服务（即leader选举成功），至少需要2个节点是正常的。换句话说，3个节点的集群，允许有一个节点宕机。

​ 假如集群2，有4个节点，4/2=2 ,即想要正常对外提供服务（即leader选举成功），至少需要3个节点是正常的。换句话说，4个节点的集群，也允许有一个节点宕机。

​ 那么问题就来了， 集群1与集群2都有允许1个节点宕机的容错能力，但是集群2比集群1多了1个节点。在相同容错能力的情况下，本着节约资源的原则，集群的节点数维持奇数个更好一些。

4）只有一套Sentinel，还是每个主节点配置一套 Sentinel ?

Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点。

​ 那么在实际生产环境中更偏向于哪一种部署方式呢，下面分别分析两种方案的优缺点。

方案一，一套Sentinel，很明显这种方案在一定程度上降低了维护成本，因为只需要维护固定个数的Sentinel节点，集中对多个Redis数据节点进行管理就可以了。但是这同时也是它的缺点，如果这套 Sentinel节点集合出现异常，可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据节点较多，会造成Sentinel节点产生过多的网络连接，也会有一定的影响。

方案二，多套Sentinel，显然这种方案的优点和缺点和上面是相反的，每个Redis主节点都有自己的Sentinel节点集合，会造成资源浪费。但是优点也很明显，每套Redis Sentinel都是彼此隔离的。

​ 如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使用方案一、否则一般建议采用方案二。