0

これは、会社間でメッセージを送信する方法に基づいています。会社 S (サプライヤー) が会社 (B) からの注文を単純な HTTP ベースの方法でポーリングする必要があると判断した場合、最適な実装は何でしょうか。

  • B 社は Web サーバーを実行しており、この Web サーバーのバックエンド データベースは耐久性があると仮定します。S でのストレージ プロセスと、それらが状態を保持できるかどうかについて可能な限り仮定を行う必要があります (例: 既に送信された GUID のリスト)。
  • B と S の間のインターネット接続は不安定です。
  • ある時点で B と S の間のすべての注文を転送する必要があることを意味する結果整合性に到達する必要があります。

そのようなシステムを実装するためのベストプラクティスは何ですか?

4

5 に答える 5

3

この種の問題に対するアプローチの 1 つは、ある種のキュー製品を使用することです。IBM の人間として、私はすぐに MQ を検討します。しかし、私は実際には MQ 担当者ではないので、あなたと同じように、あなたがとっているサービス ベースのアプローチに満足するでしょう。

考えられるアプローチは 2 つあります。1 つはWS Reliable Messagingを使用することです。これは、信頼性の問題を Web サービス インフラストラクチャに押し込みます。もう 1 つは、シンプルだが信頼性の低いサービスの上に独自の信頼性の高いプロトコルを手動で追加することです。

私は WS Reliable Messaging を使用したシステムの実装について実際に真剣に取り組んだ経験がありません。動作させることはできると思いますが、参加者をある程度制御する必要があります。特定のITショップが実装を手に入れることを保証し、ベンダー間の相互運用性が問題になる可能性があります。両端の SW スタックをより細かく制御できるほど、WS Reliable Messaging を使用する傾向が強まります。[WS Atomic Transaction についても言及する必要があります。これは、現実的なサービスを構築するためにも使用できます。同じ相互運用の問題が適用されます。]

では、ロール・ユア・オウンはどうですか？ここで重要なのは、すべてのサービスをべき等にすることです。2 つのシステムにまたがるトランザクションの保証がないため、特定のサービス呼び出しが不明な結果で失敗する可能性があると想定する必要があります。

B は、S が注文を受けたことを確認したいと考えているため、注文が転送されたときに B と S の両方で情報を更新する必要があります。

B は次のようなサービスを提供する必要があります。

 Give me the next order(s)

 I have stored {orders ...}

では、「次」をどのように定義すればよいでしょうか。最も単純なケースは、処理しているボリュームが転送の「スレッド」を 1 つ持つことができる場合にうまく機能します。次に、B は送信された注文を一度に 1 つずつチェックし、注文の ID は単調に増加します。次に、次のように単純化できます。

 I have stored order <65,004> please give me the next

これは冪等のリクエストであることに注意してください。安全に何度も繰り返すことができます。また、S は同じ注文を 2 回受け取る可能性を予測し、重複をチェックする必要があることに注意してください。

于 2010-10-27T06:55:30.443 に答える
1

おそらく探しているのは、2フェーズコミットです。これはインターネットでよく説明されています。たとえば、次のようになります。

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

その要点：

コミットプロセスは次のように進行します。

* Phase 1
      o Each participating resource manager coordinates local 
        operations and forces all log records out:
      o If successful, respond "OK"
      o If unsuccessful, either allow a time-out or respond "OOPS" 
* Phase 2
      o If all participants respond "OK":
            * Coordinator instructs participating resource managers to "COMMIT"
            * Participants complete operation writing the log record
              for the commit 
      o Otherwise:
            * Coordinator instructs participating resource managers to "ROLLBACK"
            * Participants complete their respective local undos

あらゆる種類のデータで機能するはずです。

于 2010-11-02T21:25:22.037 に答える
1

何に基づいて、ディナが言及しました。Web サービスは、上記の問題に対する完璧なソリューションです。レコードの数を定義するいくつかのプロトコルについて合意することができます。

S ---> D ( Call a service which would list record keys)
D----> S ( provide xml of keys)
S----> D ( Request each of the records)
D----> S ( Submit record)

同期後に新しいレコード エントリが作成された場合、Destination は、新しいレコードを処理するソースにデプロイされたサービスを呼び出すことができます。

通信は Web サービス エンジンを購入して処理されるため、メッセージ パラメータについて心配する必要はありません。セキュリティのためにSSLを追加できます。

乾杯！

于 2010-11-09T16:53:26.117 に答える
1

まず第一に、信頼できないリンクでは何も保証できません。二人の将軍の問題は、決定論的プロトコルと非決定論的プロトコルの両方についてこれを証明しています。あなたにできることは、信頼性の低さを許容できる程度に軽減することだけです。

あなたの場合、最も簡単な方法は、サーバーがポーリング要求を受信するxと、すべて同じGUID. 例えば。

S: B, anything new?
S: B, anything new?
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
...

Sは注文でスパムされる可能性がありますが、すべてのリクエストで # が送信されるため、大したことではありません。以前に見逃していた場合は、今取得しています。前にそれを取得できなかった場合は、ウーフー! 私たちは今それを持っています。システムは動作します！B私の例では、 がメッセージを送信する5回数に気付くでしょう。現実的なシナリオでは、必要な信頼性が得られるまで、おそらく何百回または何千回もメッセージを送信することになります。

上記のソリューションは処理と帯域幅を集中的に使用しますが、機能します。より巧妙な方法は、TCP と同じことを行うことです。つまり、スリーウェイ ハンドシェイクを行います。

S: Hello B. Are you there? -> SYN
B: Hello S, yep I'm here. What's up? -> SYN+ACK
S: Oh good, you're there. -> ACK
S: B, anything new?
B: Yes, S, I need a jacket (order #123).

しかし.. HTTPはすでにこれを行っています。そのため、何かがどこかに届かない場合は、わかります。接続タイムアウト、接続切断など。

ここで、これらのシナリオをアプリケーション レベル (WS-ReliableMessaging に入る) 内で書き直すことができますが、実際には TCP は既に信頼性があります。これらの SOAP(っぽい) フレームワークと偽のプロトコル (通常は HTTP の上で動作します) に対する一部の批評家は、それらが本質的に車輪 (および車輪の問題) をより高いレベルの抽象化で再発明していると非難します。

肝心なのは、信頼できるメッセージング システムを含め、どのシステムも失敗する可能性があるということです。

結果整合性に関する限り、混乱する可能性があると思います。結果整合性は、分散ストレージ システムにのみ適用されます。分散ストレージ システムでは、 の後、しばらくの間Write()で確定的に取得できない場合がありますRead()。これはあなたの問題のようには見えません。おっしゃることはわかりますが、eventually consistentシステムでは、ノード間に信頼できる (十分な) 接続が想定されています。あなたはその仮定をしません（私はそうすべきだと思いますが.. TCPはかなり信頼できます）。

于 2010-11-03T01:14:38.337 に答える
1

B社は受動的な参加者だと言いたいのだと思います。S (サプライヤー) には、B が投稿したすべての注文を取得する機能が必要です (結果整合性)。しかし、B は S がすでに持っている注文を必要とせず、気にもしません (コミットする必要はありません)。

会社 B が半正確な時計を持っている場合、イベントの解像度に応じて単調に増加する GUID として日付を使用できます。とにかくミリ秒の解像度が必要な場合はポーリングしたくありません。B のクロックのみを使用するため、同期について心配する必要はありません。B がすべての注文を発行した場合、S は最後に中断したところから注文を取得できます。

システムを簡単に実装するためのベスト プラクティスまたはベスト トレードオフを意味しているのかどうかはわかりません。ボリュームと応答時間によっては、とにかくポーリングする場合は動的システムにする必要はありません。注文をテキスト ファイル (タイムスタンプで命名) として日付で命名されたディレクトリにダンプし、それらをすべて (または選択的に) プルダウンします。それらを時間単位でディレクトリに保存することもできます。HTTP GET はべき等です。

それは醜いかもしれませんが、B 社にはあまり複雑さを期待していないように思えます。SSL と認証を使用すると、ロックダウンされて暗号化されます。

パフォーマンスが必要ない場合は、シンプルで問題ありません。複雑なプロトコルから実際に得られるものは何ですか?

于 2010-11-09T21:10:47.813 に答える