2009-10-28 116 views
138

它们都提供大致相同的功能。我应该选择哪一种开发我的高性能TCP服务器?有什么优点&缺点?Netty vs Apache MINA

参考链接:

Apache MINAsource

Nettysource

+5

将灰熊添加到比较中也会很有趣。 – Mark 2009-10-28 16:07:00

+0

灰熊是一个完全不同的野兽。当两个小组谈论时,甚至有人对灰熊支持MINA的想法。 – Hardcoded 2009-11-26 13:00:32

+1

@Hardcoded你说灰熊是一个完全不同的野兽,我是一个新来者,请你指出不同之处或给我一篇文章阅读?我真的很感激它。 – arg20 2011-07-22 23:14:06

回答

197

虽然MINA和Netty有着相似的野心,但它们在实践中完全不同,您应该仔细考虑您的选择。我们很幸运,因为我们有很多MINA的经验,并且有时间和Netty一起玩。我们特别喜欢清洁的API和更好的文档。纸上的表现看起来也更好。更重要的是,我们知道,李舜臣将会回答我们的任何问题,他当然会这样做。

我们在Netty中发现了一切都比较容易。期。虽然我们试图重新实现与MINA相同的功能,但我们从头开始。通过遵循优秀的文档和示例,我们得到了更多的功能,代码更少。

Netty Pipeline对我们来说效果更好。它比MINA简单一些,其中一切都是处理程序,由您决定是处理上游事件,下游事件,还是消耗更多低级别的东西。在“重放”解码器中吞噬字节几乎是一种乐趣。能够轻松地重新配置管线也非常好。

但是,Netty,imho的明星吸引力是能够创建具有“覆盖范围”的管道处理程序。您可能已经阅读过有关此覆盖范围注释的文档,但实质上它使您可以在单行代码中进行说明。没有任何混乱,没有会话映射,同步和类似的东西,我们只是能够声明常规变量(比如“username”)并使用它们。

但是后来我们遇到了障碍。我们已经在MINA下有一个多协议服务器,其中我们的应用协议运行在TCP/IP,HTTP和UDP上。当我们切换到Netty时,我们在几分钟内将SSL和HTTPS添加到列表中!目前为止这么好,但是当谈到UDP时,我们意识到我们已经滑落了。 MINA对我们非常好,因为我们可以将UDP视为“连接”协议。在Netty之下,没有这种抽象。 UDP是无连接的,Netty会这样对待它。 Netty在比MINA低的层次上暴露了UDP的更多无连接性质。在Netty下你可以用UDP做的事情比你在MINA提供的更高级别的抽象下无法做到,但我们依赖它。

添加“连接的UDP”包装器或者其他东西并不那么简单。考虑到时间上的限制,并根据Trustin的建议,最好的办法是在Netty中实施我们自己的运输提供商,这不会很快,我们最终不得不放弃Netty。

因此,请仔细观察它们之间的差异,并快速进入可以测试任何棘手功能的预期阶段。如果你对Netty能够完成这项工作感到满意,那么我会毫不犹豫地通过MINA。如果你正在从MINA移动到Netty,那么同样适用,但值得注意的是,这两个API真的有很大的不同,你应该考虑Netty的虚拟重写 - 你不会后悔的!

+3

回复:Josh之前对Netty中对UDP缺乏支持的评论:我不明白为什么你不能用几页手工代码来做你需要的,而不是放弃Netty。无论如何,UDP正在监听不同的端口。我一直在测试Netty和Nginx,我对它印象非常深刻(Netty在负载下得分相同或更好)。 – 2011-06-15 09:16:44

9

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

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

4

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

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

    1. 可以处理大量的连接
    2. 的。如果您选择实施某种形式的分布式工作系统,然后知道什么时候:同样可以实现自己的协议

    好东西的被合作周围您的某个节点关闭并失去连接对重新启动另一个节点上的工作很有用。

+0

当你说“为大文件流式传输磁盘”时,人们通常不使用UDP吗? – djangofan 2011-12-24 18:21:08

+1

否。他们通过TCP使用内核sendfile(在Java中以FileChannel.transferTo公开)。 – jbellis 2012-11-27 14:30:55

15

MINA和Netty最初是由同一作者设计和构建的。这就是为什么他们彼此很相似。 MINA的设计略高一点,功能稍多一些,而Netty速度稍快。 我认为没有太大差别,基本概念是相同的。

130

MINA具有更多开箱即用的功能,其代价是复杂性和相对较差的性能。其中一些功能被集成到内核中,即使用户不需要它们也不能移除。在Netty中,我试图解决这些设计问题,同时保留MINA的已知优势。

目前,MINA中的大多数功能都可以在Netty中使用。在我看来,Netty具有更清晰和更有记录的API,因为Netty是尝试从头开始重建MINA并解决已知问题的结果。如果您发现缺少重要功能,请随时将您的建议发布到论坛上。我很乐意解决您的问题。

也值得注意的是,Netty的开发周期更快。只需查看最近版本的发布日期。此外,您应该考虑MINA团队将继续进行重大改写,即MINA 3,这意味着他们将完全破坏API兼容性。

+19

噢,@trustin是MINA和Netty的作者。 – 2014-02-07 04:59:00

+0

@trustin,我发现Netty 5.0没有提供很多高级文档,当前的web材料与其他版本不起作用。你有任何推荐链接的中级和高级米娜教程?谢谢 – Korben 2015-06-10 01:13:01

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向后兼容性的破坏是一大缺点。

5

我更喜欢Netty。

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

编号:Twitter Search is Now 3x Faster

我们选择了Netty了一些其他的竞争对手,像米娜和码头的,因为它有一个更简洁的API,更好的文档,更重要的,因为在Twitter的其他几个项目都是使用这个框架。