高性能网络的 Netty 替代品是什么？ [关闭]答案

【问题标题】：What are the Netty alternatives for high-performance networking? [closed]高性能网络的 Netty 替代品是什么？ [关闭]
【发布时间】：2014-07-13 09:58:57
【问题描述】：

我正在选择一个网络库来实现一个无法节省任何微秒的客户端/服务器系统。它将实现自己的协议来发送和接收消息。我正在寻找一个好的 NIO 框架，它可以让我轻松开发服务器和客户端，而不必过多担心低级选择器的细节。每个人都向我推荐 Netty，但我想在让我的团队使用框架之前尝试 2 或 3 个其他替代方案。我不太喜欢 Netty 的一件事是它如何使用自己的 ByteBuf 实现和引用计数来处理 ByteBuffers。任何人都可以分享您的想法和替代方案吗？

【问题讨论】：

推荐问题是题外话，赏金或无赏金。
@EJM 我刚打了 3k，它说“这个问题有一个开放的赏金，不能关闭。”它还阻止我标记...
Netty 和 Mina 都使用自己的 ByteBuffer 抽象。 Mina 3 移除了这种抽象，但它仍在进行中。 Netty 驱动 JBOSS，这是一个更复杂的反应器框架实现。 Mina 更简单，层次更低。
@AnubianNoob 我知道悬赏问题无法关闭。这就是我发表评论的原因。

标签： java networking real-time netty nio

【解决方案1】：

这是假设您真的想节省每一微秒。大多数应用程序没有这么严格的要求。

如果你想节省微秒，你会想使用忙等待非阻塞 NIO 来处理专用 CPU 上的线程。这不能很好地扩展，因为您需要有足够的 CPU，但可以最大限度地减少处理 IO 的延迟。我建议你也绑定隔离的 CPU 以最小化抖动。

您将希望避免使用选择器，因为它们会阻塞和/或创建相当多的垃圾，从而增加 GC 暂停。

此外，为了最大限度地减少延迟，您还需要使用低延迟、内核绕过网络适配器，例如 Solarflare。

您将需要使用推送解析器，以便可以在下载长消息时对其进行解码/解析。也就是说，您不想等到收到全部消息后再开始。

结合使用这些技巧可以为每个请求或入站事件节省 10 到 30 微秒的时间。

Netty 是一种更好的可扩展性解决方案，即更高的净吞吐量，但延迟成本很低，大多数基于支持 Web 服务的框架也是如此，毫秒延迟是可以容忍的。

【讨论】：

【解决方案2】：

我们开发了一个NIO networking library，它在环回过程中的执行时间不到 2 微秒，而不会为 GC 产生任何垃圾。正如 Peter Lawrey 所提到的，原生 JDK 选择器会产生大量垃圾，但我们通过实现我们自己的 epoll 选择器修复了所有这些垃圾泄漏。忙于等待选择器线程对延迟很有好处，但必须保持平衡，以免烧毁芯片或消耗大量能量。我们的选择器实现使用低级技巧来实现一种节能模式来处理这种平衡。

除了CoralReactor，你还可以看看Grizzly和Mina，但是我们还没有玩过这些框架。

对于一些 Netty TCP 性能基准，您可以查看here。

【讨论】：

我对此很感兴趣；然而，原生 JDK 每 30 左右的请求只产生约 150 MB 的垃圾。以 118 MB/s 的速度，每 2 分钟给予或接受。我希望看到针对 JDK NIO 而不是 Netty 的基准。
JDK NIO 中唯一会创建垃圾的部分与它在将选择事件移入和移出 Selector 时存储的 ArrayList/List 机制有关。这个垃圾量比较少。 Netty 和 Mina 然后在上面添加了数量荒谬的垃圾。 JDK NIO 还使用 synchronized 关键字做了很多可怕的事情，但那是另一个讨论。我完全赞成比 JDK 版本更好的 NIO；我只是想看看 NIO 本身的数量。
不是免费的，不是开源的，没有明确的许可。
基准测试应该使用一个唯一的客户端。

【解决方案3】：

如果您至少可以使用一些 Scala，Spray 是 Netty 的绝佳替代品。从长远来看，Play 框架例如打算从 Netty 迁移到 Spray。 Spray 提供不同级别的 TCP 抽象。它们是：

块级
请求级别（HttpRequest / HttpResponse）
编组对象级别

您对堆栈的挖掘越深，传递的信息就越原始。在块级 API 中，您非常接近原始字节缓冲区。我自己从未使用过这种低抽象级别，但我听到了一些好消息。

Spray 构建在 Akka IO 之上，而 Akka IO 又构建在 Java NIO 之上。所有功能都围绕着 Actor 抽象，这使得使用 Spray 构建并行应用程序变得容易。我认为聊天服务器将是一个完美的用例。由于 Akka 提供了 Java API，因此您应该能够将 Spray 与大多数此 API 一起使用。但是，您可能需要时不时地阅读一些 Scala 源代码。最终，Spray 将完全融入 Akka。

编辑：来自 Spray 网站的引述：“Spray 不再维护，并已被 Akka HTTP 取代。Playframework 从 Play 2.4.X 开始实验性地支持 Akka HTTP Server 后端。在 Play 2.6.X 版本中，播放完全迁移到 Akka HTTP 服务器后端。

【讨论】：