33

.NET 2.0以降を実行しているWindowsでの耐久性のあるメッセージングにキューイング製品を使用する場合、現在MSMQに代わるものはどれですか。ActiveMQ（http://activemq.apache.org/ ）を知っており、WSMQ（ http://wsmq.netを指す）への参照を見たことがありますが、サイトがダウンしているようです。

他に選択肢はありますか？

4

8 に答える 8

20

ここでは「ベストプラクティス」のアドバイスではないかもしれません...しかし、実際のニーズと経験に基づいています。分散システムがあり、10台のクライアントごとに60個のボックスがすべてタスクXを実行し、キューから次のタスクを取得する必要があります。キューは他の1つの「クライアント」から供給されています...

プロセス間通信を使用し、MSMQを使用し、サービスブローカーを試しました...アプリケーションの制御をMicrosoftに譲渡しているため、長期的には機能しません。あなたのニーズが満たされている限り、それは素晴らしい働きをします。サポートされていないものが必要なときは地獄になります。

私たちにとって最善の解決策は次のとおりです。SQLデータベーステーブルをキューとして使用します。間違い（ロック）をするので、そこで車輪の再発明をしないでください。それを行う方法についての情報があります。それは非常に簡単で、24時間あたり200Kを超えるメッセージを処理しました（60x10 = 600のキューへの同時読み取りと書き込み）。これは、残りのアプリケーションを処理する同じSQLサーバーに追加されます...

MSMQが機能しないいくつかの理由：

  1. キューのロジックをFIFOではなく、「最も古いREDメッセージ」や​​「最も古いBLUEメッセージ」などに変更する必要がある場合は、変更できません。（私は人々が言うことを知っています、あなたは赤いキューと青いキューを持つことによってそれを行うことができます..。しかし、キューの数/タイプがアプリケーションの管理方法に基づいて動的であり、毎日変化する場合はどうなりますか？）

  2. これにより、単一障害点と展開の悪夢が追加されます（キューは単一障害点であり、これらの種類の費用を支払うエンタープライズソフトウェアでメッセージの読み取り/書き込みなどを行うためにすべてのボックスに適切なアクセス許可を設定する必要があります） 。SQLサーバー...すべてのクライアントはすでにDBから書き込み/読み取りを行っており、もう1つのテーブルにすぎません。

于 2008-09-01T08:15:33.563 に答える
11

Java JMS メッセージング仕様の実装である Tibco EMS について、いくら言っても言い尽くせません。Tibco EMS は、WinCE 上の Compact Framework .NET を含む .NET クライアントの優れたサポートを提供します。(C クライアント ライブラリもあります。)

したがって、Windows、Unix (AIX/Solaris)、Linux、または Mac OS X で実行されるメッセージング コードを含む異種分散アプリケーションを構築している場合は、Tibco EMS が最適です。

ここで私の記事をチェックしてください：

分散ソフトウェア開発に JMS を使用する

以前はマイクロソフトで働いていて、そこで MSMQ の実装を行っていました。しかし、ご存知のように、Microsoft は Windows だけに関心を持っています。彼らは、MSMQ クライアントを他のプラットフォームに提供するためにサード パーティに依存していました。Tibco EMS との出会いは、はるかに優れた経験でした。Tibco が Microsoft よりもはるかにメッセージングを理解していることは明らかでした。また、Tibco は、多様なクライアント バインディング自体をサポートすることに力を入れています。そのため、最終的に製品名を Tibco JMS から Tibco EMS (Enterprise Messaging Service) に変更しました。

また、Tibco EMS を中心に異種ソフトウェア システムを構築しました。Tibco EMS メッセージングを介して Java/JBoss 中間層と対話するロールド C# .NET Winform クライアント。(また、Compact Framework .NET Tibco クライアントを使用する WinCE 産業用組み込みコンピューターもあります。)

私の JMS 著作へのリンク

于 2008-12-24T07:44:53.203 に答える
10

ここでは、RabbitMQ フレームワークが見落とされているようです。それでも気になる方は、.NET 2.0 コード ベースがあり、netMsmqBinding に似た WCF バインディングが付属しています。バインドには当然、少なくとも .NET 3.0 が必要であり、組み込みの netMsmqBinding よりも多くの機能を備えています。その上、Mono フレンドリーです。一見の価値があります。

于 2011-04-15T13:02:58.943 に答える
7

SQL 2005のサービスブローカーはどうですか？

于 2008-09-01T07:51:25.367 に答える
3

コストが問題にならない場合（Express SKUもあります）、800,000ポンドのゴリラを見てください。WebSphere MQ（MQシリーズ）。これは実質的にすべてのプラットフォームで実行され、非常に多くの異なるキューマネージャーとメッセージングパターンをサポートしているため、ここにそれらをリストすることは実際には適切ではありません。

于 2008-09-07T05:51:05.807 に答える
3

ActiveMQ を使用しないのはなぜですか? :)

于 2008-10-17T09:52:28.533 に答える
1

高可用性が重要な場合は、AmazonSQSを検討する価値があります。メッセージが物理的に異なる場所から送信された場合、追加のオーバーヘッドはそれほどありません。安くてスケーラブル！

于 2008-10-26T09:06:19.037 に答える
1

Redis は、このプラットフォームのもう 1 つのホットな品種です。Set ベースのキューイングの実装と Pub/Sub パターンを確認してください。それは有望に見えます

于 2011-01-28T14:38:58.683 に答える