Master-Slave通用基础框架

一、设计目的

       设计出一个通用的Master-Slave基础框架,然后可以基于这个框架来实现特定的业务需求,比如实现多节点并行计算等。


二、设计理念

       基于经典的命令模式,MasterSlave之间通过相互发送命令(Command)实现交互,命令是一个抽象的概念,Command可以用来分发任务,也可以用来传输数据这完全由业务来决定怎么处理框架只定义了一个实际的命令-心跳检测命令(Heartbeat Command)。可以通过定义自己的命令,并提供响应的命令处理器,来实现任何形式的业务。框架提供的核心功能其实只有,底层的网络通信,Master/Slave关系的维系,命令的分发功能。


三、详细设计


    1. 系统类图








核心接口和类:


名称

类型

方法

说明

Node

interface


扩展

Runnable接口

void init()

节点初始化

接口Node: 代表分布式节点,MasterSlave节点,分布式节点,MasterMasterNodelSlaveSlaveNode实现本接口

void start()

节点启动

void stop()

节点停止

void reset()

节点重启



名称

类型

方法

说明

MasterNode

class

实现Node接口

Master节点,负责管理Slave节点,分发命令给Slave


名称

类型

方法

说明

SlaveNode

class

实现Node接口

Slave节点,负责接收Master节点分发的命令,并执行命令,将结果封装成命令发送到Master节点



名称

类型

方法

说明

SlaveNode

class

实现Node接口

Slave节点,负责接收Master节点分发的命令,并执行命令,将结果封装成命令发送到Master节点





名称

类型

方法

说明

CommandProvider


interface

Command produce() 

产生Command

Command提供者接口,业务代码提供实现该接口的Provider因为采用Slave主动拉取Command的机制,CommandProviderSlaveNode用来生产Command


后面考虑支持Master主动推送CommandSlave.

List produce(long count) 

批量产生Commnad







名称

类型

方法

说明

NetWorkClient


interface

void init()

初始化

Slave端负责底层网络通信的,网络服务客户端,负责和Master节点通信。采用nio实现。

void start()

启动

void stop()

停止

void reset()

重启



名称

类型

方法

说明

Session


class

void init()

初始化会话

MasterSlave之间的会话,Master通过Session来跟中,管理SlaveSession通过一个线程来接收Command,执行Command,发送CommandSessionManager负责管理分配回收这个Session. SessionManager会定时转换Session的状态,如果Session的状态转换到MS_SESSION_STATE_DEAD 状态,就会在在下次被回收.但是如果Master接收到Slave的心跳命令,就会将Session的状态置为MS_SESSION_STATE_ALIVE ,以表示Slave还存活.

void start()

启动会话

void destroy()

销毁会话

void alive()

Master接收到Slave的心跳Command时,会将调用本函数,将当前的Session置为“存活”状态

void free()

释放会话,已被以后重新利用,并不是销毁,防止频繁创建,销毁会话(线程)

void isDead

会话是否已经“死掉”,这意味着Master长时间没有收到对应的Slave的心跳CommandMaster会认为这个Slave已经“死掉”。

void onRead()

NetWorkServer会在会话的Socket有数据可读时,会调用Session的这个函数,让Session接收Slave发送的数据包

void onWrite()

NetWorkServer会在会话的Socket可写时,调用Session的这个函数,Session可以将自己的数据输出缓存队列的数据通过网络发送到Slave

void run

Runnable接口的函数,循环从自己的输入缓存队列中解析出Command并通过CommandDispatcher分发Command并将结果Command写到自己的输出缓冲队列.

void transitState() 

根据Session当前的状态转换到下一个状态,SessionManager会有一个定时任务,负责调用本函数,来转换Session的状态.








名称

类型

方法

说明

SessionManager


interface

void init()

初始化

Master端负责底层网络通信的,网络服务器,负责和Slave节点通信。采用nio实现一个线程处理所有的网络操作。

void freeSession(Session session) 

释放Session,实际上是被回收,以备再分配

SessionnewSession(java.nio.channels.SocketChannel channel) 

分配Session

void destroy() 

SessionManager的销毁,会销毁所有的Session




名称

类型

方法

说明

Command


class

ByteBuffer

getPayLoad()

获得Comamnd的负载,业务相关的数据

MasterSlave之间交换的命令,业务可以定义的自己的Command并提供对应的Command处理器,Command可以用来分发任务,也可以用来传输数据,这完全由业务来决定怎么处理

void setPayLoad(ByteBuffer payLoad)

设置Comamnd的负载,业务相关的数据

Long getType()

获得Command的类型,业务可以定义自己的Command类型,并负责处理

void setType(Long type)

设置Command的类型,业务可以定义自己的Command类型,并负责处理

Session getSession()

Master,获得Command对应的Session

void setSession(Session session)

Master,设置Command对应的Session



名称

类型

方法

说明

CommandHandler


interface

Command handle(Command command) 

处理命令,并返回以Command封装的结果

负责处理Command的接口业务定义新的Command需要提供实现该接口的Command处理器



名称

类型

方法

说明

CommandDispatcher


interface

void int()

初始化

MasterSlave负责分发Command的接口,通过业务配置的命令路由表,分发Command到具体的Command处理器


Command

dispatch(Command command)

通过业务配置的命令路由表,分发Command到具体的Command处理器



      1. 时序图

Master工作时序图


Slave工作时序图


      1. 状态迁移图

        Session一共有5种状态,设计这么多的中间等待状态,或许没有这必要。

        Session分配时默认状态为alive,存活状态,然后SessionManager的定任务会定时将Session的状态沿着alive->waiting_0->waiting_1->waiting_2->dead路线迁移,但是同时Master在收到Slave的心跳Command时会将Session的状态置为alive.SessionManager的定任务会在Session的状态被置为dead后,下一次定时任务执行是回收该Session,即认为相应的Slave已经“死掉”。



四、实现


请参考代码


五、代码

请见附件

 ms.zip   

六、总结

     目前只实现了基础的功能,还有很有一些值得去思考与实现的,如:

  1. Slave的管理,包括Slave的存活,负载,等管理。

  2. 到底是Master主动将Command推送到Slave, 还是Slave主动拉,这也是值得考虑的,不过这个实现起来还是比较简单的,目前采用Slave主动拉的机制,主要考虑到这样实现更简单也更健壮。

  3. Command分配策略的考虑,是将一个Command分配给一个Slave呢,还是一个Command可以分配个多个Slave呢,这个可以考虑用策略模式来处理。

  4. CommandHandler支持异步,这个通过回调可以很好的处理。

  5. Master单点故障的问题,怎么考虑,怎么处理

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: AXI4是一种高性能、高带宽的接口协议,在使用时会用到AXI4 Master和AXI4 Slave两个模块。对于AXI4 Master和AXI4 Slave的源代码对应分析,需要从两个模块的功能和架构入手。 AXI4 Master是连接处理器、DMA、FPGA以及其他数据源的主机总线接口,主要用于发送读/写事务请求,以及接收响应数据。其源代码的实现需要遵循AXI4协议的规定,包括发出READ/WRITE数据请求等操作。 而AXI4 Slave是连接存储器、FIFO、寄存器、设备控制器等外设的从机总线接口,主要负责响应AXI4 Master的读/写事务请求。其源代码的实现需要实现AXI4 Slave接口的各类功能,例如收到接收到READ/WRITE数据请求时进行响应的机制等。 总的来说,AXI4 Master和AXI4 Slave的源代码对应分析需要具有扎实的计算机系统结构基础、嵌入式系统开发经验及VHDL或Verilog语言编程技能。在使用时,需要遵循AXI4协议规定,进行必要的代码优化,以提高系统的性能和稳定性。 ### 回答2: AXI4是一种高性能、低功耗、低复杂度的总线协议,被广泛用于FPGA和SoC芯片中。在AXI4中,MasterSlave是两个重要概念,Master可以去向Slave发起读写请求,Slave提供相应的数据或状态返回。 在AXI4 Master Slave源码对应分析中,我们需要先了解AXI4协议的基本原理和结构。AXI4的数据传输包括地址、数据和控制信号三个部分。其中,地址和控制信号一般由Master控制发送,数据由Slave提供返回。MasterSlave之间的通讯可以通过总线信号实现,如时钟、使能、读写标志等。 在源码分析过程中,我们需要先理清楚设计的框架结构和各个模块之间的关系。一般来说,一个AXI4 Master Slave的设计包括MasterSlave两个主模块,以及一些必要的逻辑模块。Master可以是一个外部设备,如CPU,也可以是FPGA内部的逻辑模块;同样地,Slave也可以是一个外部设备,如存储器,也可以是FPGA内部的逻辑模块。在设计内部逻辑模块时,需要考虑合理的接口设计和信号传输方式,以充分利用AXI4协议的特点,实现高效稳定的数据传输。 在进行源码分析时,需要对每个模块的具体功能做详细的了解,如输入输出端口、状态寄存器、控制信号等。此外,还需要仔细考虑各个模块的时序要求,以避免数据传输时的不一致和错误。在分析过程中,可以借助FPGA开发工具的仿真功能,对源码进行模拟验证,以确保设计的正确性和可靠性。 总之,AXI4 Master Slave源码对应分析是一个相对较为复杂和细致的工作,需要对AXI4协议有深刻理解和丰富的实践经验,同时还需要熟练掌握FPGA开发环境和设计工具的使用。只有通过不断地实践和积累,才能在设计中发挥出AXI4协议的最大潜力,实现高性能、低功耗的数据传输。 ### 回答3: AXI4是ARM公司推出的一种高性能片上总线协议,支持多核、功耗优化、多带宽等特性,应用广泛。本文将对AXI4 MasterSlave源码进行分析。 AXI4 Master部分的源码是通用的,可以配置成读写、反悔等各种操作,实现起来比较简单。具体实现代码可以参考Xilinx公司提供的axi_master_burst.v文件。 AXI4 Slave部分的源码比较复杂,需要支持读写反悔各种操作,还要处理数据乱序、地址捕获等问题。通常是通过Finite State Machine(有限状态机)来实现AXI4 Slave端的逻辑。具体实现代码可以参考Xilinx公司提供的axi_slave_lite.v文件。 AXI4协议中的控制信号包括:地址、数据、控制、状态和辅助等。其中,地址信号用于指定操作的地址,控制信号用于指定读写类型等操作,状态信号用于反映操作是否完成,辅助信号提供了一些附加信息。 AXI4 MasterSlave源码是嵌入式系统设计中非常重要的实现部分,掌握其实现原理对于理解AXI4协议及其应用场景非常有帮助。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值