Netty VS Apache MINA

在 Netty 网站你可以找到一些性能 报告。正如预期的那样: ——他们指出 Netty 是性能最好的框架。

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

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

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

它的好处是:

1. 可以处理很多连接
2. 如果您选择实现某种类型的分布式工作系统，那么知道您的一个节点何时停止并失去连接对于重新启动另一个节点上的工作是有用的。

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

更新: 只需使用 Netty。它现在是一个成熟的项目，具有构建协议客户机和服务器所需的所有花哨功能。它有强大的社区与几个积极的贡献者支持的企业。它还有一本书，“ Netty 在行动”。已经是 被许多知名公司和项目采用了。与 Netty 不同，ApacheMINA 自从我离开项目以来一直处于维护模式。

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

目前，MINA 的大部分功能都可以在 Netty 使用。在我看来，Netty 有更干净和更文档化的 API，因为 Netty 是试图从头开始重建 MINA 并解决已知问题的结果。如果您发现一个基本的功能缺失，请随时张贴您的建议到论坛。我很乐意回答你的问题。

同样重要的是要注意 Netty 有更快的开发周期。简单来说，查看最新版本的发布日期。此外，您应该考虑 MINA 团队将继续进行重大的重写，MINA 3，这意味着他们将打破 API 的兼容性完全。

虽然 MINA 和 Netty 有相似的雄心壮志，但是他们在实践中是完全不同的，你应该仔细考虑你的选择。我们很幸运，因为我们有很多与 MINA 的经验，并有时间与内蒂周围发挥。我们特别喜欢更干净的 API 和更好的文档。理论上的表现似乎也更好。更重要的是，我们知道，李将手头回答任何问题，我们有，他肯定这样做。

我们发现在 Netty 一切都容易多了。就这样。当我们试图重新实现与 MINA 相同的功能时，我们是从头开始的。通过遵循优秀的文档和示例，我们最终在更少的代码中实现了更多的功能。

内蒂管道对我们更有利。它在某种程度上比 MINA 更简单，在 MINA 中，所有事情都是一个处理程序，由您决定是处理上游事件、下游事件，还是同时处理这两种事件，或者使用更多的低级事件。在“重播”解码器中吞噬字节几乎是一种乐趣。能够如此轻松地在运行中重新配置管道也非常好。

但 Netty 的明星吸引力在于，它能够创建“覆盖面为1”的管道处理商。您可能已经在文档中读到过这个覆盖注释，但实际上它只在一行代码中给出了状态。没有混乱，没有会话映射，没有同步之类的东西，我们只需声明正则变量(比如“用户名”)并使用它们。

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

添加“连接的 UDP”包装器或其他东西并不那么简单。由于时间有限，而且根据特拉斯廷的建议，最好的办法是在 Netty 建立我们自己的运输供应商，这不会很快，我们最终不得不放弃内蒂。

因此，仔细研究它们之间的差异，并迅速进入一个阶段，在这个阶段中，您可以测试任何棘手的功能是否按预期工作。如果你满意内蒂将做这项工作，那么我会毫不犹豫地与它在米纳。如果您正在从 MINA 转移到 Netty，那么同样的情况也会发生，但是值得注意的是，这两个 API 确实有很大的不同，您应该考虑为 Netty 进行虚拟重写——您不会后悔的！

我对两个“ Google Protobuffer RPC”实现进行了性能测试，其中一个基于 Netty (Netty-Protobuf-RPC) ，另一个基于 mina (Protobuf-mina-RPC)。Netty 最终在所有消息大小上都一直更快(+-10%) ，这支持了 Netty 网站上的整体性能声明。由于您希望在使用这样一个 RPC 库时从代码中挤出每一点效率，所以我最终编写了基于 Netty 的 Probuf-RPC-Pro。我过去使用过 MINA，但是发现他们的2.0版本的文档有很大的漏洞，而 API 的向下兼容是一个很大的负数。

我用 Netty。

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

档号: Twitter 搜索现在快了3倍

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