Netty与Apache MINA


144

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

参考链接:

Apache MINA源代码

净资产来源


6
将Grizzly添加到比较中也将很有趣。
标记

灰熊是完全不同的野兽。两组讨论时,甚至有灰熊支持MINA的想法。
硬编码

1
@Hardcoded你说灰熊是完全不同的野兽,我是这个的新来者,能否请你指出它们之间的区别或给我一篇有关此的文章?我真的很感激。
arg20 2011年

1
Grizzly具有不同的背景,而我上次查看它时,它最适合基于HTTP的应用程序。我只是看了这些示例,却惊讶地发现它们使用的结构与MINA或Netty非常相似。因此,野兽就不再那么不同了
硬编码

Answers:


211

虽然MINA和Netty具有相同的抱负,但它们在实践中却大相径庭,因此您应谨慎考虑选择。我们很幸运,因为我们在MINA方面拥有丰富的经验,并且有时间陪伴Netty。我们特别喜欢更简洁的API和更好的文档。在纸上的表现似乎也更好。更重要的是,我们知道Trustin Lee将随时回答我们遇到的任何问题,他当然做到了。

我们发现Netty的一切变得更容易。期。当我们尝试重新实现与MINA相同的功能时,我们是从头开始的。通过遵循出色的文档和示例,我们最终以更少得多的代码获得了更多的功能。

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

但是Netty的最吸引人的地方是恕我直言,它具有创建“覆盖一个”的管道处理程序的能力。您可能已经在文档中阅读了有关coverage注释的信息,但是从本质上讲,它使您只需一行代码即可获得状态。由于没有混乱,没有会话映射,同步和类似的东西,我们只需要声明常规变量(例如“用户名”)并使用它们即可。

但是后来我们遇到了障碍。我们已经在MINA下拥有一个多协议服务器,其中我们的应用程序协议基于TCP / IP,HTTP和UDP运行。当我们切换到Netty时,我们在几分钟之内就将SSL和HTTPS添加到了列表中!到目前为止,一切都还不错,但是当涉及到UDP时,我们意识到我们已经滑倒了。MINA对我们非常友好,因为我们可以将UDP视为“连接”协议。在Netty下,没有这样的抽象。UDP是无连接的,Netty将其视为无连接。与MINA相比,Netty在更低的级别上暴露了UDP的更多无连接性。在Netty下使用UDP可以做的事情比在MINA提供的更高级抽象下不能做的事情要多,但是我们要依靠它。

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

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


3
回复:乔什(Josh)先前对Netty中不支持UDP的评论:我不明白为什么您不能使用几页手工编写的代码来完成所需的工作,而不是放弃Netty。UDP仍在其他端口上侦听。我一直在测试Netty与Nginx的比较,这给我留下了很深刻的印象(Netty在负载下得分大致相同,甚至更好)。

137

MINA具有更多现成的功能,但代价是复杂性和相对较差的性能。这些功能中的某些功能过于紧密地集成到内核中,即使用户不需要它们也无法删除。在Netty中,我试图解决此类设计问题,同时保留了MINA的已知优势。

当前,Netty中还提供了MINA中可用的大多数功能。在我看来,Netty具有更整洁,更文档化的API,因为Netty是尝试从头开始重建MINA并解决已知问题的结果。如果您发现缺少一项重要功能,请随时将您的建议发布到论坛上。我很高兴解决您的问题。

还需要注意的是Netty具有更快的开发周期。只需查看最近发行的发行日期。另外,您应该考虑MINA小组将进行重大改写MINA 3,这意味着他们将完全破坏API的兼容性。


21
哦,@ trustin是MINA和Netty的作者。
Jason Heo 2014年

@trustin,我发现Netty 5.0没有提供很多高级文档,并且当前的Web资料和其他版本不起作用。您有中级和高级Mina教程的任何推荐链接吗?谢谢
Korben

22

我对2个“ Google Protobuffer RPC”实现进行了性能测试,其中一个基于Netty(netty-protobuf-rpc),另一个基于mina(protobuf-mina-rpc)。Netty最终对于所有消息大小都始终保持更快(+-10%)的性能-这支持了Netty网站上的总体性能要求。由于您想在使用这样的RPC库时从代码中压缩所有效率,因此我最终基于Netty 编写了protobuf-rpc-pro。我过去曾使用过MINA,但发现他们关于2.0的文档存在很大漏洞,并且API向后兼容性的破坏也很大。


16

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


9

在Netty网站上,您可以找到一些性能报告。正如预期的那样:-)他们指出Netty是具有最佳性能的框架。

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


5

我更喜欢Netty。

Twitter还选择了Netty来构建其新的搜索系统,并将其速度加快3倍。

参考:Twitter搜索现在快3倍

我们选择Netty而不是它的其他一些竞争对手,例如Mina和Jetty,是因为它具有更干净的API,更好的文档,更重要的是,Twitter上的其他一些项目正在使用此框架。


4

我只用过MINA来构建像服务器这样的小型http。到目前为止,我遇到的最大问题是:

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

不错的事情:

  1. 可以处理很多连接
  2. 如果选择实现某种分布式工作系统,则知道节点中的一个节点何时发生故障并失去连接对于在另一个节点上重新启动工作很有用。

当您说“大文件流离磁盘”时,人们通常不会使用UDP吗?
djangofan 2011年

1
不。他们通过TCP使用内核sendfile(在Java中公开为FileChannel.transferTo)。
jbellis 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.