messaging - ZeroMQ の本番環境は整っていますか?

Question

汎用メッセージング ミドルウェアとしての ZeroMQ について、どのような経験がありますか?

1. 目を見張るようなバグや明らかでない「機能」に遭遇しましたか? たとえば、2.0 ではメッセージが適切にフラッシュされませんでした。トラブルシューティング ガイドでは、「終了前」という最も恐ろしい回避策が示されているようsleep(1)です。
2. API はアプリケーションの複雑さを軽減しましたか、それとも面倒でしたか?
3. 後方互換性は頻繁に壊れていますか?

Answer 1

研究に使っているので「半生産」。これは素晴らしいフレームワークであり、完全に理解すれば、物事の設計方法は確かに理にかなっています。しかし、私はそれが本番環境に対応していると考えるにはあまりにも多くの問題にぶつかりました。私はjzmqを使用しているので、これのいくつかはそれに固有である可能性があります。

1. OS X/Eclipseでjzmqをセットアップするのは...快適ではありません。
2. アプリケーションを起動すると、ZeroMQ Cコードでアサーションエラーが発生することがあるため、この例外的な状態をチェックするものでアプリケーションをラップする必要があります。
3. 多くの場合、エラーは非常にわかりにくいものです。説明メッセージのない違法な州の例外が多すぎます。
4. TLSはサポートされていません。これは私にとってほとんど契約破りであり、多くのアプリケーションでの可用性を排除していることが簡単にわかりました。
5. ドキュメントは「オフ」です。公式ガイドは素晴らしいですが、特定の問題がある場合は、通常は役に立ちません。そして、グーグルで物事の答えを見つけるのにいつもより時間がかかります。ただし、メーリングリストはかなりアクティブです。

しかし、これは大きなことですが、それによってどれだけの工数が節約されたかは数えられません。この投稿には、それが人生をより快適にする方法のほんのいくつかの良い要約があります。

Answer 2

また、「半生産」環境 (DARPA のプロトタイピング) で ZeroMQ を使用しています。これまでのところ、特にそれらの猫が異なる言語で書かれており、異なるマシンに住んでいる場合は、「猫を結びつける」のに非常に優れています。利用可能なソケット イディオムを使用すると、分散コンピューティングの問題を非常に簡単に考えることができます。ZeroMQ の強みはエルゴノミクスです。堅実なメンタル モデルと豊富な言語バインディングです。

ただし、厳しいパフォーマンスの制約に直面している場合は、注意して進めてください。私はリアルタイム システムに取り組んでいますが、ZeroMQ は高性能ソリューションを目指していますが、プライムタイムの準備ができていないことがわかりました。現在のアーキテクチャには大きな可能性があると思います。いくつかの厄介なバグによって妨げられているようです。比較的短期間で 0.0 から 3.0 に移行するなど、急速に進化したライブラリからは、おそらくそれを期待していたはずです。それでも、自分の手で作ったプロトコル スタックの簡単な代替品を入手できると思ったのですが、すぐに契約を破ることができました。ZeroMQ を使用することにした場合は、トランスポート レイヤーの上で作業していることに注意してください。パフォーマンスが望ましくない場合は、それについてできることはほとんどありません。

そうは言っても、メーリング リストや IRC チャンネルでの雑談はとても素晴らしいものです。開発者は、完全に最先端のものを構築することに真に関心を持っているようです。彼らは、ライブラリが話題になり、真面目で興味深いことに慣れてきていることを気に入っています。彼らは忙しい人なので、たくさんの手を握ることを期待しないでください. ただし、実際に問題が発生した場合、彼らは何が起こっているのか知りたがります。

結論:日常の分散コンピューティングの問題に対する優れたスイス アーミー ナイフです。最先端のパフォーマンスを求めている場合は注意してください。少なくとも 1 つのメジャー リリースがオフになっています。それでも、このプロジェクトの未来は素晴らしいものになっているので、それを使用してサポートしてください。

Answer 3

免責事項: これは、AMQP や他の同様の製品を使用したことがない人からのものです。

悪いドキュメンテーションは悪いです。(.Net と C# のドキュメントがなければ、C# はまずいでしょう) したがって、ZMQ の使用方法を知っている場合は、ZMQ が最適かもしれませんが、存在するドキュメント (多くはありません) はかなり悪いものです (私たちはとてもスマート、これはとても良いです、Erlang、何とか何とか、ガイドの単一の n 対 n の例ではありません...)。
おっしゃる通り、ほとんどの OS プロジェクトにはドキュメントが不十分であるか、まったくありません。ええ、しかし、かなりの数の OS プロジェクトについては、大量のもの (チュートリアル、例など) をグーグルで検索できます。ZMQ では次のようになります。ゼロはドキュメント用です。Im は C++ 開発者なので、このように言います。ZMQ を使おうとする前は、boost のドキュメントは良くなく、インターネット上には例が比較的少ないと思っていました。しかし、ZMQ Boost と比較すると、ドキュメントは素晴らしく、例も豊富です。

編集: 物事をより楽しくするために (南北戦争:P): http://www.infoq.com/news/2012/03/Crossroads-IO

オリジナルの ZeroMQ の作成者である Martin Sustrik と Martin Lucina は、プロジェクトをフォークしてプロジェクトの制御を取り戻すことにしました。Crossroads I/O と名付けられた新しいプロジェクトは、長期的な財政的ニーズをより適切に満たすことができる商用エコシステムを促進するためにセットアップされています。

EDIT2: ガイド (「A Request-Reply Broker」の cpp バージョン) から例をコピーして実行しても機能しません。ライブラリ開発プロセスがいかに優れているかは、テストとしてのサンプルがないことからもわかります。:P
EDIT3: いくつかの例は v2.* にあります。最新バージョンは v3.2 です。繰り返しになりますが、これは保守されていない腐った OS プロジェクトのようなにおいがします。