分布式系统服务单点问题的探讨( 二 )


那么怎么解决可能会出现多个的问题?
换个角度看,该问题其实就是怎么去裁决,哪个节点是的问题 。
方案一:引入第三方的服务进行裁决 。
我们可以引入,由进行裁决 。同样,我们启动两个主节点,“节点A”和节点B 。它们启动之后向去注册一个节点,假设节点A注册的节点为,节点B注册的节点为,注册完成后进行选举,编号小的节点为真正的主节点 。那么,通过这种方式就完成了对两个进程的调度 。
有一套机制,可以保证不会出现多个的情况,具体可以参考:
方案二: 通过选举算法和租约的方式实现的选举
对于方案一的缺点主要要多维护一套的服务,如果原本业务上并没有部署该服务的话,要增加该服务的维护也是比较麻烦的事情 。这个时候我们可以在业务进程中加入的选举方案 。目前有比较成熟的选举算法,比如Paxos和Raft 。然后再配合租约机制,就可以实现的选举,并且确保当前只有一个的方案 。但是,这些选举算法理解起来并不是那么地容易,要实现一套完善的方案也是挺难的 。所以不建议重复造轮子,业内有很多成熟的框架或者组件可以使用,比如微信的 。
【分布式系统服务单点问题的探讨】比如上图的方案中,三个节点其实都是对等的,通过选举算法确定一个 。为了确保任何时候都只能存在一个,需要加入租约的机制 。一个节点成为后,和非节点都会进行计时,在超过租约时间后,三个节点后可以发起“我要成为”的请求,进行重新选举 。由于三个节点都是对等的,任意一个都可以成为,也就是说租期过后,有可能会出现切换的情况,所以为了避免的频繁切换,节点需要比另外两个节点先发起自己要成为的请求(续租),告诉其他两个节点我要继续成为,然后另外两个节点收到请求后会进行应答,正常情况下另外两个节点会同意该请求 。关键点就是,在租约过期之前,非节点不能发起“我要成为”的请求,这样就可以解决频繁切换的问题 。