問題タブ [message-queue]

jms に似た Windows サーバー上で動作するメッセージ キューイング システムを探しています。

IBM MQ は、kdb 拡張子を持つ奇妙な証明書形式を使用しています。

どうすればそれを開いて有効期限を変更できますか?

銀行環境で 2 つのコア システムを統合するメッセージング プラットフォームを検討しています。私たちはオープンソースのオプションを検討しています。どの製品を使用したことがあり、経験を共有できますか?

私は最近 Linux でメッセージ キュー (System V、しかし POSIX も問題ないはず) をいじっていますが、私のアプリケーションには完璧に思えますが、The Art of Unix Programming を読んだ後、それらが本当に良い選択であるかどうかはわかりません。 .

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

System V IPC の上位のメッセージ パッシング レイヤーは、ほとんど使用されなくなりました。共有メモリとセマフォで構成される下位層には、相互排他ロックと、同じマシン上で実行されているプロセス間でのグローバル データ共有が必要な状況下でも重要なアプリケーションがあります。これらの System V 共有メモリ機能は POSIX 共有メモリ API に発展し、Linux、BSD、MacOS X、および Windows でサポートされましたが、従来の MacOS ではサポートされませんでした。

http://www.faqs.org/docs/artu/ch07s03.html#id2923376

System V IPC 機能は、Linux およびその他の最新の Unix に存在します。ただし、これらはレガシー機能であるため、頻繁に実行されることはありません。2003 年半ばの時点で、Linux バージョンにはまだバグがあることが知られています。それらを修正するのに十分なほど気にする人は誰もいないようです。

最近の Linux バージョンでも、System V メッセージ キューにはまだバグがありますか? 著者が POSIX メッセージ キューは問題ないと言っているのかどうかわかりません。

ソケットは、ほとんどすべて (?) で優先される IPC のようですが、ソケットなどを使用してメッセージ キューを実装するのが非常に簡単であることがわかりません。それとも私が複雑に考えすぎているのでしょうか？

組み込み Linux を使用していることが関連しているかどうかわかりません。

私は、サーバーで処理するために、クライアントでかなりタイトなループで数千のメッセージを生成する可能性のあるアプリケーションに取り組んでいます。イベントのチェーンは次のようなものです。

1. クライアントはアイテムを処理し、ローカル キューに入れます。
2. ローカル キュー処理がメッセージを取得し、Web サービスを呼び出します。
3. Web サービスは、サーバー上のサービス バスにメッセージを作成します。
4. Service Bus はデータベースへのメッセージを処理します。

Web サービスには多くのクライアントが存在するため、すべての通信が非同期であるという考え方です。MSMQ がこれを直接実行できることは知っていますが、セキュリティなどを設定するためのその種の管理機能がクライアントに常にあるとは限りません。

私の質問は、各段階でのメッセージの粒度についてです。最も単純な方法は、クライアントで処理される各アイテムが 1 つのクライアント メッセージ/Web サービス呼び出し/サービス バス メッセージを生成することを意味します。それは問題ありませんが、可能であれば Web サービスの呼び出しをバッチ処理する方がよいことはわかっています。ただし、大粒度の Web サービス DTO とデータベースでの実行時間の短いトランザクションとの間にはトレードオフがあります。この特定のシナリオでは、すべてのアイテムが処理されるか、まったく処理されない「ビジネス トランザクション」は必要ありません。メッセージ サイズと Web サービス呼び出しの数とデータベース トランザクションの最適なバランスを実現することを目指しています。

何かアドバイス？

HTTP サービスのクライアントは、特定のコンテンツ タイプのデータを要求または送信することで、理解できるバージョン (および形式) を指定できます。HTTP プロトコルは、コンテンツ タイプが理解されていないことを報告するためのエラー コードを定義します。

メッセージング システム (JMS、MQ シリーズなど) には、メッセージ プロトコルのバージョンとコンテンツ フォーマットを記述する標準的な方法がありません。

信頼性の高い非同期メッセージングを介してアクセスされるサービスのバージョン管理をどのように実装しましたか?

いくつかの可能性:

• 送信者はバージョンをメッセージ プロパティとして示します
• キューまたはトピック名には、その宛先で受け入れられたメッセージのプロトコル バージョンが含まれます
• バージョンはメッセージのペイロードにあります

他の方法があると確信しています。どのようにしましたか？どのような利点と欠点が見つかりましたか?

非同期キュー コンシューマー スレッドのアルゴリズムをまとめるのに問題があります。これは、長時間実行する (少なくとも数秒) 作業を行うためにディスパッチする必要がある単一のキューからアイテムを読み取るものです。

基本的に、キューは次のようになります: A、A、A、A、A、B、B、A、B、A、A、A、A、A、C、B、A。

すなわち。A メッセージは、他のメッセージよりもはるかに一般的です。

私たちのシステムでは、異なるメッセージ タイプごとに異なる同時実行値があります。たとえば、一度に実行できるのは 3 x A メッセージのみですが、5 x B および 4 x C メッセージを一度に実行できます。

私の現在の (壊れた) アルゴリズムは、実際のペイロードを実行する前に、各ジョブの本体が十分なリソースが利用可能になるのを待って、キューの先頭から読み取り、各ジョブをスレッドプールにディスパッチする単一のスレッドを持つことです。

これは、十分な量の A メッセージが最初に到着すると、スレッド プールのキューが「いっぱいになる」可能性があり、B+C メッセージは必要以上に長く枯渇することを意味します。

これまでのところ、メッセージの種類ごとに個別のスレッド プールを用意することを考えてきました (種類の数はかなり少ない) が、それだけ多くのスレッドを保持することの効率が心配です。

これを改善する方法について何か提案はありますか?

一部のアクターをキューであるかのように扱うことに関して何らかの制限があるプログラムでアクターを使用したいと思います。たとえば、変更イベントが適用される外部システムと、外部システムのデータのキャッシュがあるとします。だから私は2人の俳優を持っています:

1. ChangeApplicationActor
2. CacheActor

の一部として、外部システムのChangeApplicationActorエンティティに変更を適用するときに、イベントを送信して に同期Xするよう伝えたいと考えています。CacheActor

しかし、私には2つの要件があります。

1. には内部状態があり、理想的にはその命令を順番CacheActorに処理したいSync
2. の同じ値に対するCacheActor2 つの命令を含む の受信トレイになってしまった場合、2 番目の命令は無視したいと思います (つまり、 の任意の値に対して保留中の命令は 1 つだけにする必要があります) 。Sync(x)xSyncx

アクターを強制的にシングルスレッドにする方法はありますか? アクターのメールボックスにアクセスして、重複したイベントを削除する方法はありますか? CacheActoras, um, not an Actorの実装を避けることはできませんか?

非常に長いループを含むメソッドでテスト サービスを作成しました。タイムアウト トランザクションが発生すると、メソッドの実行がフラッシュされることを期待していましたが、そうではありません。クライアントはタイムアウトしますが、処理はサーバーで続行されます。

それを止める方法はありますか？メソッドコードを変更せずに？

次に例を示します。この例では、キュー バインディングを使用して QueueRequest メソッドを呼び出し、10 秒後にトランザクションが中止されます。この時点で再試行が発生し、同じ問題が発生します。数回再試行した後、メッセージが有害でドロップされた場合でも、サーバーは 100% の CPU 作業を行い、複数のスレッド/インスタンスでループを実行しようとします。

メッセージ ポンプ スレッド プール アーキテクチャに基づくアプリケーションがあります。ブロックする可能性のあるアクションがある場合は常に、「完了/トリガー evnet でのコールバック」アクションとして実装されるため、実行中のスレッドがストールすることはありません。

この手法はほとんどの場合に適していますが、コードが非常に複雑になり、非常に不便になる場合があります。

私ができるようにしたいのは、関数を待機中の前後の部分に分割することなく、透過的な方法で待機中にイベントを処理し続けることです。

どうすればいいですか？

私は2つの選択肢を念頭に置いていました：

1. 待機中に実行中の関数内からメッセージ ループを実行します。
2. 待機中に新しい作業スレッドを作成し、再開時に (適切な方法で) 終了します。

いくつか例を挙げると、どちらのオプションにも欠点があります。

1 の場合:

• スタック オーバーフローが発生する可能性があります。
• デッドロック状態になる可能性があります。
• 内側のメッセージが 2 番目のイベントの完了を待機する結果となり、その間に外側のイベントが完了すると、外側の関数は 2 番目のイベントが完了するまで続行できず、この状況が拡大する可能性があります。

オプション 2 は、単純にますます多くのスレッドを作成することになります。

もちろん、私が思いもよらなかった他のオプションがあるかもしれません。

編集:言語は C++ であるため、簡単な (移植可能な?) 方法で関数をステップアウトおよびステップインすることはできません。プラットフォームは Windows (API) ですが、関係ないと思います。