哨兵

1、哨兵的介绍

sentinal，中文名是哨兵

哨兵是redis集群架构中非常重要的一个组件，主要功能如下

（1）集群监控，负责监控redis master和slave进程是否正常工作
（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上
（4）配置中心，如果故障转移发生了，通知client客户端新的master地址

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了

目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单

2、哨兵的核心知识

（1）哨兵至少需要3个实例，来保证自己的健壮性
（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
（3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

3、为什么redis哨兵集群只有2个节点无法正常工作？

哨兵集群必须部署2个以上节点

如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1

±—+ ±—+
| M1 |---------| R1 |
| S1 | | S2 |
±—+ ±—+

Configuration: quorum = 1

master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移

同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移

但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行

es集群也必须是三个节点

4、经典的3节点哨兵集群

   +----+| M1 || S1 |+----+|

±—+ | ±—+
| R2 |----±—| R3 |
| S2 | | S3 |
±—+ ±—+

Configuration: quorum = 2，majority

如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移

同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移

数据丢失的情况

主备切换的过程，可能会导致数据丢失

（1）异步复制导致的数据丢失

因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了

（2）脑裂导致的数据丢失

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着

此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master

这个时候，集群里就会有两个master，也就是所谓的脑裂

此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了

因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

解决异步复制和脑裂导致的数据丢失

min-slaves-to-write 1
min-slaves-max-lag 10

要求至少有1个slave，数据复制和同步的延迟不能超过10秒

如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

如果master不接受请求，又如何解决呢？
应用端做降级或者做缓存队列

上面两个配置可以减少异步复制和脑裂导致的数据丢失

（1）减少异步复制的数据丢失

有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

（2）减少脑裂的数据丢失

如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失

上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求

因此在脑裂场景下，最多就丢失10秒的数据

哨兵工作机制

1、sdown和odown转换机制

sdown和odown两种失败状态

sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机

odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机

sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机

sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

2、哨兵集群的自动发现机制

哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在

每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置

每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在

每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

3、slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上

4、slave->master选举算法

如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来

会考虑slave的一些信息

（1）跟master断开连接的时长
（2）slave优先级
（3）复制offset
（4）run id

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

（1）按照slave优先级进行排序，slave priority越低，优先级就越高
（2）如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
（3）如果上面两个条件都相同，那么选择一个run id比较小的那个slave

5、quorum和majority

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换

如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

6、configuration epoch

哨兵会对一套redis master+slave进行监控，有相应的监控的配置

执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

7、configuraiton传播

哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制

这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的

其他的哨兵都是根据版本号的大小来更新自己的master配置的

哨兵部署

前提需要至少三个节点都部署redis，之前node1、node2上已经部署redis了，现在在node3上也部署上redis

1、哨兵的配置文件

在每个节点上创建目录

[root@node1 src]# mkdir -p /etc/sentinel/5000
[root@node1 src]# mkdir -p /var/sentinel/5000
[root@node1 src]# mkdir -p /var/log/sentinel/5000

每个节点都将sentinel.conf拷贝到指定目录下

[root@node1 src]# cp /root/redis-3.2.8/sentinel.conf /etc/sentinel/5000.conf

在node1上

vi /etc/sentinel/5000.conf

daemonize yes
logfile /var/log/sentinel/5000/sentinel.log
port 5000
bind 10.1.218.22
dir /var/sentinal/5000
sentinel monitor mymaster 10.1.218.22 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

在node2上vi /etc/sentinel/5000.conf

daemonize yes
logfile /var/log/sentinel/5000/sentinel.log
port 5000
bind 10.1.218.26
dir /var/sentinal/5000
sentinel monitor mymaster  10.1.218.22 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

在node3上 vi /etc/sentinel/5000.conf

daemonize yes
logfile /var/log/sentinel/5000/sentinel.log
port 5000
bind 10.1.218.24
dir /var/sentinal/5000
sentinel monitor mymaster 10.1.218.22 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel auth-pass mymaster 123456必须放在sentinel monitor mymaster 10.1.218.22 6379 2后面

node1上连接redis-cli

[root@node1 init.d]# redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> exit
[root@node1 init.d]# redis-cli -h node1
node1:6379> keys *
(error) NOAUTH Authentication required.
node1:6379> auth 123456
OK
node1:6379> keys *
1) "key2"
2) "key4"
3) "key6"
4) "key1"
5) "key3"
node1:6379> 

扩展

每一个哨兵都可以去监控多个maser-slaves的主从架构

因为可能你的公司里，为不同的项目，部署了多个master-slaves的redis主从集群

相同的一套哨兵集群，就可以去监控不同的多个redis主从集群

你自己给每个redis主从集群分配一个逻辑的名称

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5sentinel monitor mymaster 127.0.0.1 6379

类似这种配置，来指定对一个master的监控，给监控的master指定的一个名称，因为后面分布式集群架构里会讲解，可以配置多个master做数据拆分

sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

上面的三个配置，都是针对某个监控的master配置的，给其指定上面分配的名称即可

上面这段配置，就监控了两个master node

这是最小的哨兵配置，如果发生了master-slave故障转移，或者新的哨兵进程加入哨兵集群，那么哨兵会自动更新自己的配置文件

sentinel monitor master-group-name hostname port quorum

quorum的解释如下：

（1）至少多少个哨兵要一致同意，master进程挂掉了，或者slave进程挂掉了，或者要启动一个故障转移操作
（2）quorum是用来识别故障的，真正执行故障转移的时候，还是要在哨兵集群执行选举，选举一个哨兵进程出来执行故障转移操作
（3）假设有5个哨兵，quorum设置了2，那么如果5个哨兵中的2个都认为master挂掉了; 2个哨兵中的一个就会做一个选举，选举一个哨兵出来，执行故障转移; 如果5个哨兵中有3个哨兵都是运行的，那么故障转移就会被允许执行

down-after-milliseconds，超过多少毫秒跟一个redis实例断了连接，哨兵就可能认为这个redis实例挂了

parallel-syncs，新的master别切换之后，同时有多少个slave被切换到去连接新master，重新做同步，数字越低，花费的时间越多

假设你的redis是1个master，4个slave

然后master宕机了，4个slave中有1个切换成了master，剩下3个slave就要挂到新的master上面去

这个时候，如果parallel-syncs是1，那么3个slave，一个一个地挂接到新的master上面去，1个挂接完，而且从新的master sync完数据之后，再挂接下一个

如果parallel-syncs是3，那么一次性就会把所有slave挂接到新的master上去

failover-timeout，执行故障转移的timeout超时时长

3、启动哨兵进程

在node1、node2、node3三台机器上，分别启动三个哨兵进程，组成一个集群，观察一下日志的输出

redis-sentinel /etc/sentinal/5000.conf

node1返回

8943:X 24 Jun 09:54:12.068 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
8943:X 24 Jun 09:54:12.068 # Sentinel ID is a22349e2da0f3e2ed6369649b4c0463a2f473a4e
8943:X 24 Jun 09:54:12.068 # +monitor master mymaster 10.1.218.22 6379 quorum 2
8943:X 24 Jun 09:54:12.069 * +slave slave 10.1.218.24:6379 10.1.218.24 6379 @ mymaster 10.1.218.22 6379
8943:X 24 Jun 09:54:12.111 * +slave slave 10.1.218.26:6379 10.1.218.26 6379 @ mymaster 10.1.218.22 6379
8943:X 24 Jun 09:57:12.879 * +fix-slave-config slave 10.1.218.26:6379 10.1.218.26 6379 @ mymaster 10.1.218.22 6379
8943:X 24 Jun 09:57:12.880 * +fix-slave-config slave 10.1.218.24:6379 10.1.218.24 6379 @ mymaster 10.1.218.22 6379

node2:

24511:X 24 Jun 09:57:19.314 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
24511:X 24 Jun 09:57:19.314 # Sentinel ID is a22349e2da0f3e2ed6369649b4c0463a2f473a4e
24511:X 24 Jun 09:57:19.314 # +monitor master mymaster 10.1.218.22 6379 quorum 2
24511:X 24 Jun 09:57:19.317 * +slave slave 10.1.218.24:6379 10.1.218.24 6379 @ mymaster 10.1.218.22 6379
24511:X 24 Jun 09:57:19.345 * +slave slave 10.1.218.26:6379 10.1.218.26 6379 @ mymaster 10.1.218.22 6379

node3:

19205:X 24 Jun 09:57:57.183 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
19205:X 24 Jun 09:57:57.183 # Sentinel ID is a22349e2da0f3e2ed6369649b4c0463a2f473a4e
19205:X 24 Jun 09:57:57.183 # +monitor master mymaster 10.1.218.22 6379 quorum 2
19205:X 24 Jun 09:57:57.185 * +slave slave 10.1.218.24:6379 10.1.218.24 6379 @ mymaster 10.1.218.22 6379
19205:X 24 Jun 09:57:57.248 * +slave slave 10.1.218.26:6379 10.1.218.26 6379 @ mymaster 10.1.218.22 6379

我们发现哨兵之间并没有互相发现，这是怎么回事？
因为我部署了node1的5000.conf以后，就将该文件通过scp的方式 ，复制到了node2和node3上；

解释如下

哨兵主从切换
那么哨兵节点直接是如何自动发现的呢，或者说从哪里可以体现出来哨兵节点之间的自动发现呢？
既然会自动识别，因此就怀疑，哨兵节点启动之后，会将自动将这些信息记录到配置文件中去，试了一把，果不其然。

如下是在Redis主从复制的基础上，依次启用三个哨兵节点的后，sentinel.cnf的变化情况
可以发现，当启用了三个哨兵节点之后，sentinel.cnf配置文件会被自动重写，主要有一下几点：

增加了一个sentinel myid （标识哨兵节点的唯一性）
自动追加哨兵节点本身的信息（这样哨兵节点之间就会相互自动发现），以及redis数据服务的slave的信息
如下是启动哨兵以后，在5000.conf中自动生成的
#Generated by CONFIG REWRITE
sentinel known-slave mymaster 10.1.218.26 6379
sentinel known-slave mymaster 10.1.218.24 6379
sentinel known-sentinel mymaster 10.1.218.22 5000 a22349e2da0f3e2ed6369649b4c0463a2f473a4e
sentinel known-sentinel mymaster 10.1.218.26 5000 4ef7ba90b64db79cd484de0696c185659e0e1062
sentinel current-epoch 0

自动移除主节点的密码
dir 的相对路径被修改为绝对路径
可见，Redis的哨兵不仅是Redis自动故障转义，而且实现了哨兵节点自己的高可用。同时对于密码之类的信息，也是在哨兵节点初始化之后自动移除。

myid介绍
哨兵的myid是当哨兵启动服务的时候，redis自动生成的，且生成位置在配置文件的末尾：

重新调整部署以后

日志里会显示出来，每个哨兵都能去监控到对应的redis master，并能够自动发现对应的slave

哨兵之间，互相会自动进行发现，用的就是之前说的pub/sub，消息发布和订阅channel消息系统和机制

4、检查哨兵状态

redis-cli -h 192.168.31.187 -p 5000

sentinel master mymaster
SENTINEL slaves mymaster
SENTINEL sentinels mymaster

SENTINEL get-master-addr-by-name mymaster

例如

[root@node3 sentinel]# redis-cli -h node2 -p 5000
node2:5000> SENTINEL get-master-addr-by-name mymaster
1) "10.1.218.22"
2) "6379"
node2:5000> SENTINEL slaves mymaster
1)  1) "name"2) "10.1.218.24:6379"3) "ip"4) "10.1.218.24"5) "port"6) "6379"7) "runid"8) "e6e11857378029c1757152714f76507acb334abb"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) "1026"19) "last-ping-reply"20) "1026"21) "down-after-milliseconds"22) "30000"23) "info-refresh"24) "9612"25) "role-reported"26) "slave"27) "role-reported-time"28) "812951"29) "master-link-down-time"30) "0"31) "master-link-status"32) "ok"33) "master-host"34) "10.1.218.22"35) "master-port"36) "6379"37) "slave-priority"38) "100"39) "slave-repl-offset"40) "724577"
2)  1) "name"2) "10.1.218.26:6379"3) "ip"4) "10.1.218.26"5) "port"6) "6379"7) "runid"8) "56911144abfe42127ffe0dc8ac6a1b13020c370d"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) "1026"19) "last-ping-reply"20) "1026"21) "down-after-milliseconds"22) "30000"23) "info-refresh"24) "9613"25) "role-reported"26) "slave"27) "role-reported-time"28) "812951"29) "master-link-down-time"30) "0"31) "master-link-status"32) "ok"33) "master-host"34) "10.1.218.22"35) "master-port"36) "6379"37) "slave-priority"38) "100"39) "slave-repl-offset"40) "724577"
node2:5000>

容灾演练

将node1的redis停止，查看node1上的哨兵日志

4829:X 24 Jun 10:58:06.079 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
4829:X 24 Jun 10:58:06.079 # Sentinel ID is a22349e2da0f3e2ed6369649b4c0463a2f473a4e
4829:X 24 Jun 10:58:06.079 # +monitor master mymaster 10.1.218.22 6379 quorum 2
4829:X 24 Jun 10:58:36.120 # +sdown sentinel 80d9134bbff31498d749340637dbb089045bdc1e 10.1.218.24 5000 @ mymaster 10.1.218.22 6379
4829:X 24 Jun 11:16:44.378 # -sdown sentinel 80d9134bbff31498d749340637dbb089045bdc1e 10.1.218.24 5000 @ mymaster 10.1.218.22 6379
4829:X 24 Jun 11:43:40.302 # +sdown master mymaster 10.1.218.22 6379
4829:X 24 Jun 11:43:40.357 # +odown master mymaster 10.1.218.22 6379 #quorum 2/2
4829:X 24 Jun 11:43:40.357 # +new-epoch 1
4829:X 24 Jun 11:43:40.357 # +try-failover master mymaster 10.1.218.22 6379
4829:X 24 Jun 11:43:40.431 # +vote-for-leader a22349e2da0f3e2ed6369649b4c0463a2f473a4e 1
4829:X 24 Jun 11:43:40.441 # 4ef7ba90b64db79cd484de0696c185659e0e1062 voted for 4ef7ba90b64db79cd484de0696c185659e0e1062 1
4829:X 24 Jun 11:43:40.466 # 80d9134bbff31498d749340637dbb089045bdc1e voted for 4ef7ba90b64db79cd484de0696c185659e0e1062 1
4829:X 24 Jun 11:43:41.089 # +config-update-from sentinel 4ef7ba90b64db79cd484de0696c185659e0e1062 10.1.218.26 5000 @ mymaster 10.1.218.22 6379
4829:X 24 Jun 11:43:41.089 # +switch-master mymaster 10.1.218.22 6379 10.1.218.26 6379
4829:X 24 Jun 11:43:41.090 * +slave slave 10.1.218.24:6379 10.1.218.24 6379 @ mymaster 10.1.218.26 6379
4829:X 24 Jun 11:43:41.090 * +slave slave 10.1.218.22:6379 10.1.218.22 6379 @ mymaster 10.1.218.26 6379
4829:X 24 Jun 11:44:11.119 # +sdown slave 10.1.218.22:6379 10.1.218.22 6379 @ mymaster 10.1.218.26 6379

此时node1上的5000.conf slave信息变更为

之前配置的主机ip也自动切换了
sentinel monitor mymaster 10.1.218.26 6379 2# Generated by CONFIG REWRITE
sentinel known-slave mymaster 10.1.218.24 6379
sentinel known-slave mymaster 10.1.218.22 6379
sentinel known-sentinel mymaster 10.1.218.22 5000 a22349e2da0f3e2ed6369649b4c0463a2f473a4e
sentinel known-sentinel mymaster 10.1.218.24 5000 80d9134bbff31498d749340637dbb089045bdc1e
sentinel current-epoch 1

epoch 由0递增为1
node2,和node3上也都有变更，这里就不截图显示了

连接node2，查看最新的master节点

[root@node1 sentinel]# redis-cli -h node2 -p 5000
node2:5000> SENTINEL get-master-addr-by-name mymaster
1) "10.1.218.26"
2) "6379"
node2:5000> 

然后将node1中的redis再次启动，发现node1中的redis当做slave使用了

注意重新选举redis master，会自动更改redis_6379.conf中的 master ip 和连接密码，所以为了让所有节点都能被选举为主节点，且保证主节点的安全性，每个节点都要配置requirepass 和masterauth

另外，5000.conf和redis_6379.conf 中配置的bind 之前都只配置了机器IP，但是这种方式会导致，连接redis-cli 必须制定-h 参数，连接哨兵，也必须指定 redis-cli -h ip地址 -p 5000，我们把所有机器的bind 都改成

bind 当前ip 127.0.0.1
例如bind 10.1.218.22 127.0.0.1
这样既支持外网访问，也可以连接redis或者哨兵服务器时，无需指定-h参数

哨兵节点管理

1、哨兵节点的增加和删除

增加sentinal，会自动发现

删除sentinal的步骤

（1）停止sentinal进程
（2）SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致

2、slave的永久下线

让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行

3、slave切换为Master的优先级

slave->master选举优先级：slave-priority，值越小优先级越高

4、基于哨兵集群架构下的安全认证

每个slave都有可能切换成master，所以每个实例都要配置两个指令

master上启用安全认证，requirepass
master连接口令，masterauth

sentinal，sentinel auth-pass

停止redis和哨兵

[root@node1 ~]# redis-cli -a 123456 shutdown
[root@node1 ~]# ps -ef |grep redis
root 11608 1 0 13:27 ? 00:00:14 redis-sentinel 10.1.218.22:5000 [sentinel]
root 27010 32211 0 14:17 pts/4 00:00:00 grep --color=auto redis
[root@node1 ~]# redis-sentinel shutdown
27358:X 24 Jun 14:17:59.380 # Fatal error, can’t open config file ‘shutdown’
[root@node1 ~]# redis-cli -p 5000 shutdown
[root@node1 ~]# ps -ef |grep redis
root 28325 32211 0 14:18 pts/4 00:00:00 grep --color=auto redis
[root@node1 ~]#

3.亿级流量电商详情页系统实战--哨兵相关推荐

1. 亿级流量电商详情页系统实战：缓存架构+高可用服务架构+微服务架构

   <缓存架构+高可用服务架构+微服务架构>深入讲解了亿级流量电商详情页系统的完整大型架构.同时最重要的是,在完全真实的大型电商详情页系统架构下,全流程实战了整套微服务架构,包含了基于领域驱动 ...

2. 大型电商架构亿级流量电商详情页系统实战--redis基础票

   亿级流量电商详情页系统实战-缓存架构+高可用服务架构+微服务架构 01_高并发高可用复杂系统中的缓存架构有哪些东西 (1)如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据 ...

3. 19.亿级流量电商详情页系统实战---总结

   文章目录 1.亿级流量电商网站的商品详情页系统架构 2.redis企业级集群架构 3.多级缓存架构设计 4.数据库+缓存双写一致性解决方案 5.缓存维度化拆分解决方案 6.缓存命中率提升解决方案 7. ...

4. 大型电商架构亿级流量电商详情页系统--实战 服务降级

   86_电商网站的商品详情页缓存服务业务背景以及框架结构说明 我们这个课程,基于hystrix,如何来构建高可用的分布式系统的架构,项目实战 模拟真实业务的这么一个小型的项目,来全程贯穿,用这个项目中的 ...

5. 大型电商架构亿级流量电商详情页系统实战-缓存架构+高可用服务架构+微服务架构（七）

   文章目录 八十九.高并发场景下恐怖的缓存雪崩现象以及导致系统全盘崩溃的后果 九十.缓存雪崩的基于事前+事中+事后三个层次的完美解决方案 九十一.基于hystrix完成对redis访问的资源隔离以避免缓 ...

6. 大型电商架构亿级流量电商详情页系统--实战 缓存同步，热点key统计 降级

      35 我们之前的三十讲,主要是在讲解redis如何支撑海量数据.高并发读写.高可用服务的架构,redis架构 redis架构,在我们的真正类似商品详情页读高并发的系统中,redis就是底层的缓存 ...

7. 6.亿级流量电商详情页系统实战

   1.上亿流量的商品详情页系统的多级缓存架构 很多人以为,做个缓存,其实就是用一下redis,访问一下,就可以了,简单的缓存 做复杂的缓存,支撑电商复杂的场景下的高并发的缓存,遇到的问题,非常非常之多, ...

8. 1.亿级流量电商详情页系统实战--主节点部署redis

   文章目录 实现流程图 缓存架构范围 集群环境搭建 1.在虚拟机中安装CentOS 2.配置网络 3. 配置hosts 4. 关闭防火墙 5.配置yum 6. 在每个CentOS中都安装Java和Per ...

9. 亿级流量电商详情页系统实战-1.小型电商网站的商品详情页的页面静态化架构以及其缺陷

   1.电商网站按规模分类 电商网站里,大概可以说分成两种: 小型电商 简单的一种架构方案,页面静态化的方案 大型电商 复杂的一套架构,大电商,国内排名前几的电商,大型的详情页架构页面静态化,全量的页面静 ...

最新文章

1. 【译】在Asp.Net中操作PDF – iTextSharp -利用块，短语，段落添加文本
2. golang 获取struct类型_聊聊golang的类型断言
3. integer比较_每日一题：Integer、int 的区别
4. 是哪个机场_南宁和昆明哪个更强？南宁城建强于昆明，昆明经济强于南宁
5. php发送验证码短信,php发送短信验证码
6. 431.chapter2.configure database mail
7. android之相机开发
8. Ubuntu下的文件安全删除工具
9. (转)JDK 1.5中的ENUM用法
10. Entity Framework 学习中级篇2—存储过程(上)（转）
11. Spark shuffle：hash和sort性能对比
12. python创建自定义函数is_number()来判断一个字符是否是数字
13. nvme装系统不能自引导_新买的固态硬盘用AHCI不能装系统，而用IDE却可以？问题就在这里...
14. 虚拟机中qemu模拟开发板启动过程，使用nfs挂载根文件系统
15. 源码推荐：多图无缝滚动控件，多视图控制器间切换
16. 计算机组成与结构1800题,最新版数据结构1800题含完整答案详解
17. 远方的人 -- 龙瑜
18. java cms 垃圾回收_了解Java垃圾自动回收
19. Matlab中ind2rgb函数用法
20. 赛尔号什么时候支持html5,赛尔号：最初的5只年费精灵，总被云玩家吊打，其实他们很强...

热门文章

1. ThinkPHP3.2.3新特性之：数据库设置
2. Android 顶部标题栏ActionBar详解
3. C语言入门高级教学（上）
4. 数据清洗- Pandas 清洗“脏”数据（一）
5. 关于计算机二级的论文5000字,计算机二级论文摘要怎么写 计算机二级论文摘要范文参考...
6. xcode 8.1: bundle format unrecognized, invalid, or unsuitable
7. 视频教程-微信小程序系统教程python版[3/3阶段]_微信小程序支付-手游开发
8. 触景无限“点睛计划”免费帮助传统企业完成智能化升级
9. css font-family的字体英文对照
10. 产品主义：以品牌为导向，以产品为核心