Master/Slave底层通信的体系权衡

本文探讨了Master/Slave分布式通信模块的设计,采用RPC协议进行节点间通信。重点介绍了Slave节点正常和非正常退出时如何通知Master,以及Master宕机时的容错策略,包括使用Zookeeper选举新Master、备用Master接管和Slave节点的心跳监测。强调了系统设计的整体把握和模块清晰性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

项目需要,在写Master/Slave底层分布式通信模块,它的体系结构图:


 
通信模式:可以选择Socket和或者Socket之上的RPC协议来进行,考虑到项目的需求,使用了RPC来支持Master和Slave之间的通信。

Master与Slave之间实现互联的功能并不难,但是Master与Slave之间的相互感知功能,Master节点的异常或者Slave节点的宕机,都是在设计时应该考虑的问题。

1)Slave节点正常退出之前,应该通知Master。这个功能通过Slave节点运行时添加Runtime.getRuntime().addShutdownHook(? extends Thread), 的方法来做处理, 在具体的Thread方法中仍然可以使用RPC来通知Master.

2) Slave节点非正常退出,这个原因可能是多方面的。这个由Master根据收到的Slave节点的心跳包的异常,比方说,Master原来是每10s收到一个心跳包,但是Slave A已经1分钟没有发送心跳包了,这时Master会把Slave节点从active列表中取出,然后通过发送ping来验证,Slave后面的端口是否还存在。

3)Master正常退出和非正常宕机,可以将这两点统一对待,因为Master一旦不工作,将会对整个系统的影响是毁灭性的,所以,必须提高LOG的级别为SERVER.

提供Master的容错能力可以通过以下步骤来做:

1) Master退出之后,使用Zookeeper选择一个新的Master,需要对于记录系统执行的详细状态,并持久化到文件中。

2) 准备一个Standby Master, 在开始阶段Standby Master不提供服务,等到一个Master宕机之后,Standby Master开始代替原Master进行工作。

3)Slave节点对于在心跳阶段条件轮询功能,探测Master节点的状态,探测Master节点not available,则对于slave与Master通信的线程,暂时suspend,等到新的master到来之后的notify。

 

实现一个系统,不仅仅是功能的实现,更多的时候,还有对于整体上的把握,要是每一个模块清晰,透彻,哪怕一个很复杂的功能实现,都要经过一步一步的剖析,直到每一块都是清晰可见

 

from:http://blog.sina.com.cn/s/blog_4a1f59bf0100nd6c.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值