哨兵的介绍
- 主要功能
(1)集群监控,负责监控Redis master和slave进程是否运行正常
(2)消息通知,如果某一个Redis出现故障,那么哨兵将负责发送消息作为报警通知管理员
(3)故障转移,如果某一个Redis实例出现故障,会自动转移到slave node上(故障转移时,判断一个master node是否宕机了,需要大部分的哨兵同意才行,应为哨兵也是分布式的)
(4)配置中心,如果故障转移发生了,通知client客户端新的master地址,哨兵本身也是分布式的,作为一个哨兵集群去运行,互相协同工)
- 哨兵的核心知识
(1)哨兵需要最少3个实例,来保证自己的健壮性
(2)哨兵+Redis的主从部署结构,是不能保证数据零丢失的,只能保证Redis集群的高可用性
(3)对于哨兵+Redis的主从部署结构,尽量在生产和测试环境都做足充分的测试才行
- 为什么哨兵必须晒2个节点以上才能正常工作
如果哨兵只有一个,此时就没有majority来允许故障转移了
哨兵切换导致数据丢失
(1)异步复制导致数据丢失
异步复制导致数据丢失的原因是master——》slave的复制是异步的,所以有可能有一部分数据还没有来得及复制到slave,master就已经宕机了,此时这些数据就会丢失。
(2) 脑裂导致的数据丢失
也就是说,某一个master所在的机器突然断开了网络连接,根其他的slave机器连接不上,但是实际上这时候master还活着,但是哨兵认为master已经宕机了,然后开始选举,将其他的slave选举为master,这个时候集群里就会有两个master,但是client可能还没有切换到新的master,还继续写向旧的master的数据可能也会丢失,因此旧的master再次回复的时候,会被作为一个新的slave挂在到新的master上去,自己的数据就会被清空,重新从新的master复制数据
解决数据丢了是的两个配置
min-slaves-to-write 1
min-slaves-max-lag 10
(1) 一旦slave复制数据和ack延时太长,就认为可能master宕机后损失的数据太多了,那么就拒绝写请求,这样就可以把master宕机时的部分数据未同步到slave导致丢失的数据降低到可控的范围之内。
(2)如果不能继续给指定数量的slave发送数据,而且slave超过10秒没有给自己的ack消息,那么直接拒绝客户端的写请求,这样脑裂后的旧master就不会接受新的数据,也就避免了数据丢,上面的配置也就确保了,如果跟任何一个slave丢失了连接,在10秒后发现没有slave给自己ack,那么就拒绝新的请求,因此在脑裂的情况之下,就会丢失10秒的数据。