1

トポロジの簡単な概要:

nServiceBus サーバーにコマンドを送信する Web サイト。nServiceBus サーバーはコマンドを受け取り、正しい pub/sub イベントを発行します。このサービスには、コマンドに応答して DB に対して何らかの処理を実行できるメッセージ ハンドラーもあります。たとえば、次のようになります。

1 ユーザーが Web サイトに登録します。 2 Web サイトは nServicebus コマンドを別のサーバーの nServicebus サービスに送信します。3 nServicebus サーバーには、その特定のタイプのコマンドのハンドラーがあり、データベースに何かを記録し、ウェルカム メールを送信します。

このアーキテクチャを導入して以来、DB でデッドロックが発生し始めました。データベースサーバーのMSDTCまで追跡しました。データベース サーバーでそのサービスをオフにすると、nServicebus がエラーをスローし始めます。これは、nServiceBus がトランザクションに DB 更新を登録していることを示しています。

私はこれが発生することを望んでいません。DB の障害を自分で処理したいのですが、メッセージが nServicebus プロキシ サービスに確実に配信されるようにするトランザクションのみが必要です。Web から 2 つのサーバーを経由して DB に戻ってトランザクションを行う必要はありません。

助言がありますか？

編集: この投稿はいくつかの手がかりを提供しますが、それが適切な続行方法であるかどうかは完全にはわかりません.. NServiceBus - メッセージ ハンドラーでの TransactionScopeOption.Suppress の使用に関する問題

EDIT2: DB をトランザクションの範囲外で動作させたい理由は、これらのコマンドを別のサーバーで「非同期に」処理して、Web サイトの速度を低下させたり、ユーザーがこれらの長い間待機したりしないようにするためです。集約コマンドの実行。DB がトランザクションの範囲内にある場合、元のコマンドがディストリビューターに送信された時点で Web サイトでの実行がブロックされますか? このシナリオに適した nServicebus アーキテクチャはありますか? コマンドをすばやく起動して Web サイトに制御を戻すことで、ユーザーはすぐに先に進み、集計カウントの更新や電子メールの送信などの長時間実行される DB コマンドを待つ必要がなくなります。

4

1 に答える 1

2

NServiceBus トランザクションのコンテキスト外で DB を動作させることはお勧めしません。代わりに、トランザクションの分離レベルを下げてみてください。これは、次のように呼び出すことで実行できます。

.IsolationLevel(System.Transactions.IsolationLevel.ReadCommited)

流暢な構成で。v2.6 では、これを .MsmqTransport() の後に配置する必要があります。v3.0 では、この呼び出しをほとんどどこにでも置くことができます。

EDIT2 への応答:

NServiceBus を使用するだけで、他のサーバーで実行されるトランザクションのレベルに関係なく、Web サイトの速度を低下させないという目的を達成できます。トランザクションの使用は、障害が発生した場合にメッセージが失われないこと、および独自の重複排除ロジックを記述する必要がないことを保証することです。

于 2012-03-22T07:24:55.010 に答える