multithreading - Netty 多线程在 4.1 版本中被破坏？长查询后无法处理短查询？

Question

我只想设置一个非常普通的服务器：它必须接受连接并进行一些业务计算才能返回答案。计算可以很短也可以很长 -> 我需要某种 ThreadPoolExecutor 来执行这些计算。

在我们使用了很长时间的 netty 3 中，这很容易实现，只需在我的 BusinessHandler 之前在管道中使用 ExecutionHandler。

但是现在尝试在 netty 4 中设置相同的东西，我在文档中读到 ExecutionHandler 不再存在，并且在将我的 BusinessHandler 添加到通道管道时添加以指定 EventExecutor。

DefaultEventExecutorGroup applicativeExecutorGroup = new DefaultEventExecutorGroup(10);
...
ch.pipeline().addLast(applicativeExecutorGroup, businessHandler);

它适用于非常基本的场景（仅限短查询），但不适用于以下场景。原因是 DefaultEventExecutorGroup 不会选择一个空闲的 worker，而是基于循环的任何一个。

• 第一个请求 (R1) 来了，分配给 T1（DefaultEventExecutorGroup 的线程 1），并且需要很长时间（比如 1 分钟）。
• 然后接收到一些其他查询 Ri (i=2 到 10)。它们被分配了 Ti，并且也被成功处理。
• 但是当R11来的时候，又被分配了T1，由于DefaultEventExecutorGroup中实现了循环算法，查询排在了长长的R1之后。结果，它不会在一分钟之前开始处理，这显然是一个不可接受的延迟。在具体场景中，客户端永远不会得到答案，因为他们在我们开始处理之前等待答案超时。
• 并且这样继续下去。每 10 个查询一个查询将失败，因为在唯一繁忙的线程中排在长查询之后，而 Group 的所有其他线程只是空闲。

我的管道是否有另一种可以工作的配置？例如，是否存在 EventExecutor 的实现，它可以像标准 Executor 一样工作（选择一个免费的工作人员）。或者它只是 netty 4.1 中的一个错误？它看起来很奇怪，因为这对于任何服务器来说都是非常常见的场景。

谢谢你的帮助。

标签： multithreadingnetty

Answer 1

根据您上面的解释，我认为您想UnorderedThreadPoolEventExecutor用作DefaultEventExecutorGroup. 或者如果订购很重要NonStickyEventExecutorGroup。