どちらもほぼ同じ機能を提供します。高性能TCPサーバーを開発するためにどちらを選択する必要がありますか？長所と短所は何ですか？
参照リンク：
質問する
92339 次
7 に答える
215
MINAとNettyの野心は似ていますが、実際にはまったく異なるため、選択を慎重に検討する必要があります。MINAでたくさんの経験があり、Nettyで遊ぶ時間があったという点で幸運でした。特に、よりクリーンなAPIとはるかに優れたドキュメントが気に入りました。紙の上でもパフォーマンスは良く見えた。さらに重要なことに、Trustin Leeが私たちの質問に答えてくれることを知っていたので、彼は確かにそうしました。
Nettyではすべてが簡単であることがわかりました。限目。MINAですでに使用していたのと同じ機能を再実装しようとしていたときに、最初から再実装しました。優れたドキュメントと例に従うことで、はるかに少ないコードでより多くの機能を利用できるようになりました。
Nettyパイプラインは私たちにとってよりうまく機能しました。すべてがハンドラーであり、アップストリームイベント、ダウンストリームイベント、またはその両方を処理するか、より低レベルのものを消費するかを決定するのはあなた次第であるMINAよりも何とか単純です。「再生」デコーダーでバイトをゴブリングすることは、ほとんど喜びでした。また、パイプラインをオンザフライで簡単に再構成できることも非常に良かったです。
しかし、Nettyの最大の魅力であるimhoは、「1つのカバレッジ」を備えたパイプラインハンドラーを作成できることです。このカバレッジアノテーションについてはすでにドキュメントで読んだことがあるかもしれませんが、基本的には1行のコードで状態を示します。混乱やセッションマップ、同期などがなく、通常の変数（たとえば、「ユーザー名」）を宣言して使用することができました。
しかし、それから私たちは障害にぶつかりました。MINAの下にはすでにマルチプロトコルサーバーがあり、アプリケーションプロトコルはTCP / IP、HTTP、UDPで実行されていました。Nettyに切り替えたとき、SSLとHTTPSを数分でリストに追加しました。これまでのところ順調ですが、UDPに関しては、私たちが滑っていることに気づきました。MINAは、UDPを「接続された」プロトコルとして扱うことができるという点で私たちにとって非常に良かったです。Nettyの下では、そのような抽象化はありません。UDPはコネクションレス型であり、Nettyはそれをそのように扱います。Nettyは、MINAよりも低いレベルでUDPのコネクションレス型の性質をより多く公開します。NettyでUDPを使用して実行できることは、MINAが提供する高レベルの抽象化では実行できないことよりもありますが、これに依存しています。
「接続されたUDP」ラッパーなどを追加するのはそれほど簡単ではありません。時間の制約と、続行するための最善の方法はNettyに独自のトランスポートプロバイダーを実装することであるというTrustinのアドバイスを考えると、迅速ではないため、最終的にNettyを放棄する必要がありました。
したがって、それらの違いをよく見て、トリッキーな機能が期待どおりに機能していることをテストできる段階にすばやく到達してください。Nettyがその仕事をしてくれることに満足しているなら、私は躊躇せずにMINAを介してそれを実行します。MINAからNettyに移行する場合も同じことが当てはまりますが、2つのAPIは実際には大幅に異なるため、Nettyの仮想書き換えを検討する必要があります。後悔することはありません。
于 2010-03-01T12:22:36.753 に答える
140
更新：Nettyを使用するだけです。これは、プロトコルクライアントとサーバーの構築に必要なすべての機能を備えた成熟したプロジェクトになりました。強力なコミュニティがあり、企業に支えられたいくつかの積極的な貢献者がいます。また、「 NettyinAction」という本もあります。すでに多くの有名企業やプロジェクトに採用されています。Nettyとは異なり、Apache MINAは、プロジェクトを離れてからメンテナンスモードになっています。
MINAは、複雑さと比較的パフォーマンスの低下を犠牲にして、すぐに使用できる機能を備えています。これらの機能の一部は、ユーザーが必要としない場合でも削除するにはあまりにも緊密にコアに統合されていました。Nettyでは、MINAの既知の長所を維持しながら、このような設計の問題に対処しようとしました。
現在、MINAで利用できるほとんどの機能はNettyでも利用できます。私の意見では、NettyはMINAを最初から再構築し、既知の問題に対処しようとした結果であるため、Nettyはよりクリーンでより文書化されたAPIを備えています。重要な機能が不足していることに気付いた場合は、フォーラムに提案を投稿してください。私はあなたの懸念に対処させていただきます。
Nettyの開発サイクルが速いことに注意することも重要です。単純に、最近のリリースのリリース日を確認してください。また、MINAチームが大規模な書き直しであるMINA 3に進むことを考慮する必要があります。これは、APIの互換性が完全に失われることを意味します。
于 2010-01-04T15:14:20.713 に答える
23
2つの「GoogleProtobufferRPC」実装をパフォーマンステストしました。1つはNetty（netty-protobuf-rpc）に基づいており、もう1つはmina（protobuf-mina-rpc）に基づいています。Nettyは、すべてのメッセージサイズで一貫して高速（+-10％）になりました。これは、NettyWebサイトの全体的なパフォーマンスの主張を裏付けるものです。このようなRPCライブラリを使用するときは、コードからあらゆる効率を引き出したいので、Nettyに基づいてprotobuf-rpc-proを作成することになりました。私は過去にMINAを使用しましたが、2.0に関するドキュメントには大きな穴があり、APIの下位互換性が失われることは大きなマイナスです。
于 2010-09-26T21:52:21.300 に答える
16
MINAとNettyは当初、同じ作者によって設計および構築されました。それが彼らがお互いにとても似ている理由です。MINAは少し高いレベルで設計されており、機能が少し増えていますが、Nettyは少し高速です。全く違いはないと思いますが、基本的な考え方は同じです。
于 2009-11-26T11:09:43.840 に答える
9
Nettyサイトでは、いくつかのパフォーマンスレポートを見つけることができます。予想通り:-)彼らはNettyを最高のパフォーマンスを備えたフレームワークとして指摘しています。
Nettyを使用したことはありませんが、TCPプロトコルを実装するためにMINAを使用しました。エンコードとデコードの実装は簡単でしたが、ステートマシンの実装はそれほど簡単ではありませんでした。MINAは、ステートマシンを実装するときに役立つクラスをいくつか提供していますが、それらは使いにくいと感じました。最終的に、MINAを廃止し、プロトコルを最初から実装することにしました。驚くべきことに、より高速なサーバーで終了しました。
于 2009-10-28T20:57:08.527 に答える
6
Nettyを使用しています。
Twitterはまた、新しい検索システムを構築するためにNettyを選択し、それを3倍高速化しました。
Nettyは、よりクリーンなAPI、より優れたドキュメント、そしてさらに重要なことに、Twitterの他のいくつかのプロジェクトがこのフレームワークを使用しているため、MinaやJettyなどの他の競合他社よりもNettyを選択しました。
于 2014-07-03T04:17:49.770 に答える
4
私はこれまでMINAを使用してサーバーのような小さなhttpを構築したことがあります。私がこれまでに遭遇した最大の問題：
- それはあなたの「要求」と「応答」をメモリに保持します。私が使用するプロトコルはhttpであるため、これは問題にすぎません。ただし、これを回避するには、独自のプロトコルを使用できます。
- 大きなファイルを提供する場合に備えて、ディスクからストリームを提供するオプションはありません。ここでも、独自のプロトコルを実装することで回避できます
それについての良いこと：
- 多くの接続を処理できます
- ある種の分散作業システムを実装することを選択した場合、ノードの1つがダウンして接続が失われたことを知ることは、別のノードで作業を再開するのに役立ちます。
于 2009-11-05T01:15:40.477 に答える