Netty与Apache MINA
他们都提供大致相同的function。 我应该select哪一种开发我的高性能TCP服务器？ 有什么优点和缺点？
参考链接：
Apache MINA （ 来源 ）
Netty （ 来源 ）
虽然MINA和Netty有着相似的野心，但在实践中它们是完全不同的，你应该仔细考虑你的select。 我们很幸运，因为我们在MINA方面有很多经验，有时间和Netty一起玩。 我们特别喜欢清洁的API和更好的文档。 纸上的performance也似乎更好。 更重要的是，我们知道李笃宁将会回答我们的任何问题，他当然也会这样做。
在Netty中我们发现一切都更简单。 期。 当我们试图重新实现与MINA相同的function时，我们从头做起。 通过遵循优秀的文档和示例，我们以更多的function获得了更多，更less的代码。
Netty Pipeline对我们来说效果更好。 它比MINA简单一些，一切都是一个处理程序，由您来决定是处理上游事件，下游事件，还是消耗更多低级别的东西。 在“重放”解码器中吞噬字节几乎是一种乐趣。 能够很容易地重新configurationpipe线也是非常好的。
但是，Netty的明星吸引力是能够创build一个“覆盖一个”的pipe道处理程序。 您可能已经阅读过有关此覆盖范围注释的文档，但本质上它使您能够在一行代码中进行说明。 没有搞乱，没有会话映射，同步和类似的东西，我们只是能够声明正则variables（比如“username”）并使用它们。
但是，我们遇到了障碍。 我们已经有一个MINA下的多协议服务器，我们的应用协议运行在TCP / IP，HTTP和UDP上。 当我们切换到Netty时，我们在几分钟内就将SSL和HTTPS添加到了列表中！ 到目前为止这么好，但是当谈到UDP时，我们意识到我们已经滑落了。 MINA对我们非常好，因为我们可以将UDP视为“连接”协议。 在Netty之下，没有这样的抽象。 UDP是无连接的，Netty就这样对待它。 Netty比MINA在更低的层面暴露了更多UDP的无连接性质。 在Netty下你可以用UDP做的事情，你不能在MINA提供的更高级别的抽象之下，而是我们所依赖的抽象。
添加“连接的UDP”包装器或者其他东西并不那么简单。 考虑到时间的限制以及Trustin的build议，最好的办法就是在Netty中实施我们自己的运输提供商，这不会很快，所以最终我们不得不放弃Netty。
所以，仔细观察它们之间的差异，并快速进入可以testing任何棘手function的阶段。 如果你对Netty能够完成这项工作感到满意，那么我会毫不犹豫地把它放在MINA上。 如果你正在从MINA移动到Netty，那么同样适用，但值得注意的是，这两个API真的有很大的不同，你应该考虑Netty的虚拟重写 – 你不会后悔的！
MINA具有更多开箱即用的function，代价是复杂性和相对较差的性能。 其中一些function被集成到内核中，即使用户不需要也不能移除。 在Netty中，我试图解决这样的devise问题，同时保留MINA的已知优势。
目前，MINA中的大多数function都可以在Netty中使用。 在我看来，Netty具有更清晰和更有logging的API，因为Netty是从头开始重buildMINA并解决已知问题的结果。 如果您发现某个重要function缺失，请随时将您的build议发布到论坛上。 我很乐意解决你的问题。
Netty有更快的开发周期也是很重要的。 只需查看最近版本的发布date。 另外，您应该考虑MINA团队将进行重大改写，即MINA 3，这意味着他们将完全破坏API兼容性。
我的性能testing了2个“Google Protobuffer RPC”实现，其中一个基于Netty（netty-protobuf-rpc），另一个基于mina（protobuf-mina-rpc）。 对于所有的消息大小，Netty的速度一直都比较快（+ – 10％） – 这支持了Netty网站的整体性能声明。 既然你想在你使用这样一个RPC库的时候把代码中的每一点效率都挤出去，那么我最终就会写出基于Netty的protobuf-rpc-pro 。 我过去曾经使用过MINA，但是发现他们的2.0版本的文档有很大的漏洞，而且API的向后兼容性的破绽大减。
MINA和Netty最初是由同一个作者devise和build造的。 这就是为什么他们彼此很相似。 MINA的devise稍高一点，function稍多些，而Netty速度稍快。 我觉得没有太大的区别，基本概念是一样的。
在Netty网站你可以find一些性能报告 。 正如所料:-)他们指出Netty是性能最好的框架。
我从来没有使用Netty，但我已经使用MINA来实现一个TCP协议。 编码和解码的实现很简单，但是状态机的实现并不那么容易。 MINA提供了一些类来帮助你实现状态机，但是我发现它们很难使用。 最后，我们决定放弃MINA，并从零开始实施协议，令人惊讶的是我们以更快的服务器结束。
我更喜欢Netty。
Twitter也select了Netty来构build新的search系统，并将速度提高了3倍。
参考： Twittersearch现在是3倍速度
我们selectNetty作为其他竞争对手的一部分，比如Mina和Jetty，因为它有一个更清洁的API，更好的文档，更重要的是因为Twitter上的其他几个项目正在使用这个框架。
我只使用MINA来构build一个小型的http服务器。 到目前为止我遇到的最大的问题是：
- 它将在内存中保存你的“请求”和“响应”。 这只是一个问题，因为我select使用的协议是http。 你可以使用自己的协议来解决这个问题。
- 如果您想提供大文件，则无法select从磁盘提供stream。 再次可以通过实施自己的协议来解决
好的事情：
- 可以处理很多连接
- 如果您select实施某种分布式工作系统，那么知道您的某个节点何时closures并丢失连接对于重新启动另一个节点上的工作很有用。
