单点故障(用通俗易懂的语言告诉你)

什么是单点故障?

假想,如果一颗大树,树根让人给刨了,设想,它的树叶还有活路,它的枝干还有意义么。

那么用稍微专业一点的说法:在分布式架构中通常会采用一种模式:主从模式;(一个主服务配合多个子服务完成业务处理工作,主服务的作用,主要通过接受用户请求,进行任务分发工作,然后子服务负责接收到任务,然后处理自己专职内的业务)如果主服务挂了,出现故障了,那么他将引发的是整个系统的瘫痪,所以我们称此现象为单点故障

 

那么上面所说的现象是很可怕的一件事情,都可以算是事故性问题了,那么我们肯定要有应对措施:

一般,我们此类的主服务,负责任务分发的,我们可以开启一个备用服务,与主服务功能一样。备用服务会定时向主服务发送一个请求,当主服务会进行响应的时候,则认为主服务还在正常运行;如果备用服务未接受到响应的时候,那么备用服务将立刻替代主服务工作,维持系统的正常运行。通常来说,我们是采用的ping丢包形式来判断服务是否正常运行。

 

但是仅仅通过ping丢包形式来判断一个服务是否正常运行是不严谨的,如果出现一些网络波动,或者主服务当时正在满核处理其他业务逻辑的时候,响应不够即时,那么这样会导致备用服务误认为主服务瘫痪,从而直接接替主服务工作,从而导致两个服务在执行任务分发工作。那么我们就需要对此用到分布式锁。

 

分布式锁

分布式锁的作用就是,当某一个请求产生高并发等操作时,会对其进行限定,保证其数据的准确性。通俗点讲就是:我在拜访一户人家的时候,我进门后立即把门关上,等我访问结束后,我出来,再把门打开,你们再去争,去抢,谁抢到了,再学我的步骤,挨次拜访。当然会出现一些锁超时的现象:拜访人家的时候,赖着不走了,也不出来,别人也进不去,那么这类人我们会强制将其拖走,继续进行有序拜访。对于分布式锁可以采用redis缓存共享实现。

 

那么我们通过分布式锁控制主服务的数量,保证其单一主服务。

此处分布式锁主要由Zookeeper实现,两个主节点会在Zookeeper注册一个节点,注册完成后,编号最小的节点,将会直接被任命为主服务,而其他的服务会被加锁而阻塞,在一旁备用。Zookeeper会给主服务不定时的ping包,主服务也会给Zookeeper响应包,当Zookeeper收到响应认为主服务正常运行,收不到那么立即大王爷继位,而那个没有响应的皇帝立即被T除,如果因为上面说到的满载,网络震荡等问题没有响应,那么也会认为你瘫痪,也会直接删除该主服务。如果当你这个主服务苏醒过来,(不断ping包,响应则认为苏醒)那么也可以作为备用主服务,继续注册,继续排队。

 

其实说了这么多,都是有一个中间件服务在控制整体服务的运行,比如消息队列(MQ)之类的控制服务的有序进行,不可并存等。

 

 

posted @ 2019-10-11 17:20  CHANGEMAX  阅读(490)  评论(0编辑  收藏