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

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

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

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

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

硬件设备的帧处理能力较差，单台设备最大处理能力为 20 帧/秒，服务器需进行流量控制，避免到达设备的处理极限。
硬件设备的可靠性较差，偶尔会出现丢帧的情况，故虽使用 TCP 协议，服务器仍需自行保证整个通信的可靠性。

2. 帧调度策略

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

「注」本部分为源码「Netty服务器」部分的解释说明，需结合源码进行阅读。
源码从此处获取：「GitHub」

2.1 服务器发送 Message 指令策略

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

服务器发送 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