资讯专栏INFORMATION COLUMN

基于 Netty 的帧调度策略,自行实现流量控制及可靠性通信

Anonymous1 / 2365人阅读

摘要:服务器大规模下发数据帧时,可进行有效的拥塞控制超时重发,可有效提升集群设备的可靠性,降低集群设备的研发难度。帧调度策略由于这些问题,故自行制定如下帧调度策略,实践表明,该策略可最大程度上解决以上问题。

「博客搬家」  原地址: 简书  原发表时间: 2017-07-19

最近正在做一个 Java 后端项目「大规模集群设备的管理平台」。使用 Spring 作为基础框架,使用 Netty 搭建 TCP 服务器与上万台设备组成的集群通信,使用基于 JavaFX 的图形界面应用程序模拟上万台设备的行为,并可对服务器进行压力测试。

本项目的基础实现架构已开源,访问以下地址获取:「GitHub」

Java 服务器中,由于众多硬件设备的数据帧处理能力较差可靠性较差,所以在 Netty 模块中使用的帧调度算法。服务器大规模下发数据帧时,可进行有效的拥塞控制、超时重发,可有效提升集群设备的可靠性,降低集群设备的研发难度。

1. Netty 模块和大规模集群设备通信遇到的问题

硬件设备的帧处理能力较差,单台设备最大处理能力为 20 帧/秒,服务器需进行流量控制,避免到达设备的处理极限。

硬件设备的可靠性较差,偶尔会出现丢帧的情况,故虽使用 TCP 协议,服务器仍需自行保证整个通信的可靠性。

2. 帧调度策略

由于这些问题,故自行制定如下帧调度策略,实践表明,该策略可最大程度上解决以上问题。

「注」本部分为源码「Netty服务器」部分的解释说明,需结合源码进行阅读。
源码从此处获取:「GitHub」
2.1 服务器发送 Message 指令策略

服务器 ServerTcpMessageHandler 对象首先检查链表双端队列「LinkedBlockingDeque」中待发送帧的数量,若数量大于限定数量,则将待执行指令「Message」传入时间轮进行等待,使之在预订的时间后执行。

2.2 Message 指令执行策略

待执行的指令 Message 有两种:

基本指令:普通帧生成指令,该指令分为以下 2 种:

复合指令:一条指令需要多个 CAN 帧才能完整表示

简单指令:一条指令生成一个 CAN 帧

WebMsgSpecial:包含特殊执行指令,该指令均内含一条普通指令,该指令分为以下 3 种:

广播发送:发送至一组或多组设备

紧急发送:将生成的 CAN 帧放置在队列首位,以便优先发送

不设置检错重发:该 CAN 帧无回复,或重复发送该帧易导致设备异常

Netty 通道「WebMsgOutBoundHandler」接收到待执行的指令 Message,根据 Message 指令进行执行,生成 CAN 帧并被 SendableMsg 对象包裹,具体执行策略如下:

若为基本指令:生成相对应的一个或多个 CAN 帧,并添加进入不同的 SendableMsg 对象,执行策略设为非紧急和开启检错重发机制。

若为 WebMsgSpecial 指令

若为广播指令:将内含 Message 根据广播指令生成多条其他 WebMsgSpecial 指令

若为其他指令:生成 CAN 帧和对应的 SendableMsg 对象的同时,将「紧急」和「检错重发」标识添加进 SendableMsg 对象

Netty 通道「WebMsgOutBoundHandler」接收到待执行的「执行通道」指令 SendableMsg,根据指令进行执行:

1) SendableMsg 指令执行策略

若为「紧急」指令,将内含的 CAN 帧放置在队列首位,以便优先发送
若为「不检错重发」指令,在内含的 CAN 帧被发送后,不执行「检错重发」操作
若为「普通」指令,执行「非紧急」操作和「检错重发」操作

2) 检错重发操作执行策略

在队列中选取首位 SendableMsg 对象,内含 CAN 帧被发送的同时,CAN 帧的「组号」、「设备号」和「功能位」组成 Key,CAN 帧作为 Value,添加进 HashMap 中,并在时间轮上设置「检错重发」策略,该策略在约定延迟时间后执行,之后在 TCP 通道发送该 CAN 帧。

在约定延迟时间内,Netty 的 InBound 处理通道收到特定 CAN 帧的回复,则将特定 CAN 帧的「Key, Value」对从 HashMap 中移除。

在约定时间后,执行时间轮「检错重发」策略:

检测 HashMap 中相应 CAN 帧的「Key, Value」对:

若为空,则服务器收到该 CAN 帧的回复,该策略终止

若不为空,则服务器未收到该 CAN 帧的回复,查看 SendableMsg 对象的执行次数

若次数大于 3 次,Netty 模块向 Server 模块发送设备通信故障 Message,将该设备设为异常状态。

若次数小于 3 次,根据 SendableMsg 指令的内含操作重新执行。

3. 参考资料

本项目的「GitHub」

Netty 源码解读之时间轮算法实现-HashedWheelTimer

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/68247.html

相关文章

  • HTTP/2 技术调研和性能分析

    摘要:消息与逻辑请求或响应消息对应的完整的一系列帧。声明数据流依赖关系指出,应尽可能先向父数据流分配资源,然后再向其依赖项分配资源。数据流应先于和获得完整资源分配和应先于和获得相同的资源分配和应基于其权重获得比例分配。 转载自 | 小米运维(公众号 ID:MI-SRE)showImg(https://segmentfault.com/img/bVbbesG?w=344&h=344); HTT...

    hlcfan 评论0 收藏0
  • 后端好书阅读与推荐(续三)

    摘要:后端好书阅读与推荐系列文章后端好书阅读与推荐后端好书阅读与推荐续后端好书阅读与推荐续二后端好书阅读与推荐续三这里依然记录一下每本书的亮点与自己读书心得和体会,分享并求拍砖。然后又请求封锁,当释放了上的封锁之后,系统又批准了的请求一直等待。 后端好书阅读与推荐系列文章:后端好书阅读与推荐后端好书阅读与推荐(续)后端好书阅读与推荐(续二)后端好书阅读与推荐(续三) 这里依然记录一下每本书的...

    lauren_liuling 评论0 收藏0
  • 后端好书阅读与推荐(续三)

    摘要:后端好书阅读与推荐系列文章后端好书阅读与推荐后端好书阅读与推荐续后端好书阅读与推荐续二后端好书阅读与推荐续三这里依然记录一下每本书的亮点与自己读书心得和体会,分享并求拍砖。然后又请求封锁,当释放了上的封锁之后,系统又批准了的请求一直等待。 后端好书阅读与推荐系列文章:后端好书阅读与推荐后端好书阅读与推荐(续)后端好书阅读与推荐(续二)后端好书阅读与推荐(续三) 这里依然记录一下每本书的...

    ckllj 评论0 收藏0
  • 后端好书阅读与推荐(续三)

    摘要:后端好书阅读与推荐系列文章后端好书阅读与推荐后端好书阅读与推荐续后端好书阅读与推荐续二后端好书阅读与推荐续三这里依然记录一下每本书的亮点与自己读书心得和体会,分享并求拍砖。然后又请求封锁,当释放了上的封锁之后,系统又批准了的请求一直等待。 后端好书阅读与推荐系列文章:后端好书阅读与推荐后端好书阅读与推荐(续)后端好书阅读与推荐(续二)后端好书阅读与推荐(续三) 这里依然记录一下每本书的...

    jcc 评论0 收藏0
  • Java面试 32个核心必考点完全解析

    摘要:如问到是否使用某框架,实际是是问该框架的使用场景,有什么特点,和同类可框架对比一系列的问题。这两个方向的区分点在于工作方向的侧重点不同。 [TOC] 这是一份来自哔哩哔哩的Java面试Java面试 32个核心必考点完全解析(完) 课程预习 1.1 课程内容分为三个模块 基础模块: 技术岗位与面试 计算机基础 JVM原理 多线程 设计模式 数据结构与算法 应用模块: 常用工具集 ...

    JiaXinYi 评论0 收藏0

发表评论

0条评论

Anonymous1

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<