Java Netty 与 Apache MINA

Netty vs Apache MINA

提问by GabiMe

They both provide roughly the same functionality. Which one should I choose to develop my high-performance TCP server? What are the pros & cons?

它们都提供大致相同的功能。我应该选择哪一个来开发我的高性能 TCP 服务器？有什么优点和缺点？

Reference links:

参考链接：

Apache MINA(source)

Apache MINA（源代码）

Netty(source)

Netty(来源)

采纳答案by Josh

While MINA and Netty have similar ambitions, they are quite different in practice and you should consider your choice carefully. We were lucky in that we had lots of experience with MINA and had the time to play around with Netty. We especially liked the cleaner API and much better documentation. Performance seemed better on paper too. More importantly we knew that Trustin Lee would be on hand to answer any questions we had, and he certainly did that.

虽然 MINA 和 Netty 有着相似的抱负，但它们在实践中却大不相同，您应该仔细考虑您的选择。我们很幸运，因为我们在 MINA 方面有很多经验，并且有时间和 Netty 一起玩。我们特别喜欢更简洁的 API 和更好的文档。纸面上的表现似乎也更好。更重要的是，我们知道 Trustin Lee 会随时回答我们的任何问题，而他确实做到了。

We found everything easier in Netty. Period. While we were trying to reimplement the same functionality we already had on MINA, we did so from scratch. By following the excellent documentation and examples we ended up with more functionality in much, much less code.

我们发现在 Netty 中一切都变得更容易了。时期。当我们试图重新实现我们已经在 MINA 上拥有的相同功能时，我们是从头开始的。通过遵循优秀的文档和示例，我们最终以更少的代码获得了更多的功能。

The Netty Pipeline worked better for us. It is somehow simpler than MINAs, where everything is a handler and it is up to you to decide whether to handle upstream events, downstream events, both or consume more low-level stuff. Gobbling bytes in "replaying" decoders was almost a pleasure. It was also very nice to be able to reconfigure the pipeline on-the-fly so easily.

Netty 管道对我们来说效果更好。它在某种程度上比 MINA 更简单，在 MINA 中，一切都是一个处理程序，由您决定是处理上游事件、下游事件，还是使用更多的低级事件。在“重播”解码器中吞噬字节几乎是一种乐趣。能够如此轻松地即时重新配置管道也非常好。

But the star attraction of Netty, imho, is the ability to create pipeline handlers with a "coverage of one". You've probably read about this coverage annotation already in the documentation, but essentially it gives you state in a single line of code. With no messing around, no session maps, synchronization and stuff like that, we were simply able to declare regular variables (say, "username") and use them.

但是，恕我直言，Netty 的明星吸引力在于能够创建具有“一个覆盖范围”的管道处理程序。您可能已经在文档中阅读了有关此覆盖率注释的内容，但本质上它在一行代码中为您提供了状态。没有混乱，没有会话映射，同步和类似的东西，我们可以简单地声明常规变量（比如“用户名”）并使用它们。

But then we hit a roadblock. We already had a multi-protocol server under MINA, in which our application protocol ran over TCP/IP, HTTP and UDP. When we switched to Netty we added SSL and HTTPS to the list in a matter of minutes! So far so good, but when it came to UDP we realised that we had slipped up. MINA was very nice to us in that we could treat UDP as a "connected" protocol. Under Netty there is no such abstraction. UDP is connectionless and Netty treats it as such. Netty exposes more of the connectionless nature of UDP at a lower level than MINA does. There are things you can do with UDP under Netty than you can't under the higher-level abstraction that MINA provides, but on which we relied.

但后来我们遇到了障碍。我们在 MINA 下已经有一个多协议服务器，我们的应用程序协议运行在 TCP/IP、HTTP 和 UDP 上。当我们切换到 Netty 时，我们会在几分钟内将 SSL 和 HTTPS 添加到列表中！到目前为止一切顺利，但是当谈到 UDP 时，我们意识到我们已经滑倒了。MINA 对我们很好，因为我们可以将 UDP 视为“已连接”协议。在 Netty 下没有这样的抽象。UDP 是无连接的，Netty 就是这样对待它的。Netty 在比 MINA 更低的级别上暴露了更多 UDP 的无连接特性。在 Netty 下使用 UDP 可以做的事情比在 MINA 提供的更高级别抽象下不能做的事情，但我们依赖于它。

It is not so simple to add a "connected UDP" wrapper or something. Given time constraints and on Trustin's advice that the best way to proceed was to implement our own transport provider in Netty, which would not be quick, we had to abandon Netty in the end.

添加“连接的UDP”包装器或其他东西并不是那么简单。鉴于时间限制和 Trustin 的建议，最好的方法是在 Netty 中实现我们自己的传输提供程序，这不会很快，我们最终不得不放弃 Netty。

So, look hard at the differences between them and quickly get to a stage where you can test any tricky functionality is working as expected. If you're satisfied that Netty will do the job, then I wouldn't hesitate to go with it over MINA. If you're moving from MINA to Netty then the same applies, but it is worth noting that the two APIs really are significantly different and you should consider a virtual rewrite for Netty - you won't regret it!

因此，请仔细查看它们之间的差异，然后快速进入可以测试任何棘手功能是否按预期工作的阶段。如果您对 Netty 将完成这项工作感到满意，那么我会毫不犹豫地选择 MINA。如果您从 MINA 迁移到 Netty，那么同样适用，但值得注意的是，这两个 API 确实有很大不同，您应该考虑对 Netty 进行虚拟重写 - 您不会后悔的！

回答by jassuncao

In Netty site you can find some performance reports. As expected :-) they point out Netty as the framework with the best performance.

在 Netty 站点中，您可以找到一些性能报告。正如预期的那样:-) 他们指出 Netty 是性能最好的框架。

I never used Netty, but I already used MINA to implement a TCP protocol. The implementation of encoding and decoding was easy, but the implementation of the state machine was not so easy. MINA provides some classes to aid you when implementing the state machine, but I found them kind of hard to use. In the end we decided to ditch MINA and implement the protocol from scratch, and surprisingly we ended with a faster server.

我从来没有用过 Netty，但我已经用 MINA 实现了一个 TCP 协议。编码和解码的实现很容易，但是状态机的实现却没有那么容易。MINA 提供了一些类来帮助您实现状态机，但我发现它们有点难以使用。最后，我们决定放弃 MINA 并从头开始实施该协议，令人惊讶的是，我们以更快的服务器结束。

回答by gomesla

I've only ever used MINA to build a small http like server. The biggest problems I've run into with it so far:

我只使用过 MINA 来构建一个小型的 http 之类的服务器。到目前为止我遇到的最大问题：

1. It will hold your "request" and "response" in memory. This is only an issue because the protocol I choose to use is http. You could use your own protocol however to get around this.
2. No option to provide a stream off disk in case you want to serve up large files. Again can be worked around by implementing your own protocol

1. 它将在内存中保存您的“请求”和“响应”。这只是一个问题，因为我选择使用的协议是 http。但是，您可以使用自己的协议来解决此问题。
2. 如果您想提供大文件，则没有提供磁盘流的选项。再次可以通过实现您自己的协议来解决

Nice things about it:

关于它的好东西：

1. Can handle a lot of connections
2. If you choose to implement some sort of distributed work system then knowing when one of your nodes goes down and loses connection is useful for restarting the work on another node.

1. 可以处理很多连接
2. 如果您选择实施某种分布式工作系统，那么了解您的一个节点何时出现故障并失去连接对于重新启动另一个节点上的工作非常有用。

回答by Hardcoded

MINA and Netty were initially designed and build by the same author. That's why they are so similiar to each other. MINA is designed at a slightly higher level with a little more features, while Netty is a little faster. I think that there's not much difference at all, the basic concepts are the same.

MINA 和 Netty 最初是由同一作者设计和构建的。这就是为什么它们彼此如此相似。MINA 的设计水平稍高一些，功能更多一些，而 Netty 的速度稍快一些。我认为根本没有太大区别，基本概念是相同的。

回答by trustin

MINA has more out-of-the-box features at the cost of complexity and relatively poor performance. Some of those features were integrated into the core too tightly to be removed even if they are not needed by a user. In Netty, I tried to address such design issues while retaining the known strengths of MINA.

MINA 具有更多开箱即用的功能，但代价是复杂性和相对较差的性能。其中一些功能与核心集成得太紧密，即使用户不需要它们也无法删除。在 Netty 中，我试图在保留 MINA 已知优势的同时解决此类设计问题。

Currently, most features available in MINA are also available in Netty. In my opinion, Netty has cleaner and more documented API since Netty is the result of trying to rebuild MINA from scratch and address the known issues. If you find that an essential feature is missing, please feel free to post your suggestion to the forum. I'd be glad to address your concern.

目前，MINA 中可用的大多数功能在 Netty 中也可用。在我看来，Netty 拥有更清晰和更多文档化的 API，因为 Netty 是尝试从头开始重建 MINA 并解决已知问题的结果。如果您发现缺少基本功能，请随时将您的建议发布到论坛。我很乐意解决您的疑虑。

It is also important to note that Netty has faster development cycle. Simply, check out the release date of the recent releases. Also, you should consider that MINA team will proceed to a major rewrite, MINA 3, which means they will break the API compatibility completely.

同样需要注意的是，Netty 的开发周期更快。只需查看最新版本的发布日期即可。此外，您应该考虑到 MINA 团队将进行重大重写，即 MINA 3，这意味着他们将完全破坏 API 兼容性。

回答by pjklauser

I performance tested 2 "Google Protobuffer RPC" implementations where one was based on Netty (netty-protobuf-rpc) and the other based on mina (protobuf-mina-rpc). Netty ended up being consistently faster ( +- 10% ) for all message sizes - which backs up the overall performance claim on the Netty web site. Since you want to squeeze every bit of efficiency out of your code when you use such an RPC library, i ended up writing protobuf-rpc-probased on Netty. I have used MINA in the past, but find their documentation of the 2.0 stuff has big holes, and the breaking of API backward compatibility a big minus.

我对 2 个“Google Protobuffer RPC”实现进行了性能测试，其中一个基于 Netty (netty-protobuf-rpc)，另一个基于 mina (protobuf-mina-rpc)。对于所有消息大小，Netty 最终始终更快（+- 10%）——这支持了 Netty 网站上的整体性能声明。由于在使用这样的 RPC 库时您想从代码中挤出每一点效率，因此我最终编写了基于 Netty 的protobuf-rpc-pro。我过去使用过 MINA，但发现他们的 2.0 文档有很大的漏洞，API 向后兼容性的破坏是一个很大的缺点。

回答by Tho

I prefer Netty.

我更喜欢 Netty。

Twitter also chose Netty to build its new Search System and sped it up to 3x faster.

Twitter 还选择 Netty 来构建其新的搜索系统，并将其速度提高了 3 倍。

Ref: Twitter Search is Now 3x Faster

参考：Twitter 搜索现在快 3 倍

We chose Netty over some of its other competitors, like Mina and Jetty, because it has a cleaner API, better documentation and, more importantly, because several other projects at Twitter are using this framework.

我们选择 Netty 而不是它的其他一些竞争对手，如 Mina 和 Jetty，因为它具有更清晰的 API、更好的文档，更重要的是，因为 Twitter 的其他几个项目正在使用这个框架。