コンポーネントによるポーリングの回避

Question

相互に通信する必要のある個別のコンポーネントを作成したら、システムプログラミングの領域に入り、プロセスの任意のステップでエラーが発生する可能性があると想定する必要があります。ウィンドウからtry-catchブロックをスローし、エラー処理のための堅牢な代替手段を自分で開発する必要があります。

両方ともREST apisを備えた2つのシステムがあります。両方のシステムには、ユーザーが情報を追加/更新するために使用できるGUIがあります。情報が一方のシステムに追加されると、もう一方のシステムに伝達される必要があります。統合されています。分単位でポーリングし、追加/編集を取得して、1つのシステムから別のシステムに変換するソフトウェア（仲介者）。各呼び出しは、最後に成功した実行のタイムスタンプを追跡します。このようにして、システムのいずれかの部分に障害が発生した場合、問題が修正されたときに中断したところから再開できます。

世論調査ベースのアプローチについて悪いことを聞いたことがあります。つまり、実際に作業があるかどうかに関係なく実行されるという事実です。プッシュベースのアプローチは、オンデマンドでトリガーされるため、より効率的であると聞いています。

プッシュベースのアプローチがどのように機能したかを理解しようとしています。どちらかのシステムが追加/編集をプッシュしようとすると、もう一方のシステムがダウンしているために失敗する可能性があると想定する必要があります。他のシステムの問題が修正された後、再開するには、どちらのシステムも独自の発信キューを維持する必要があるように思われます。

プッシュアプローチを使用すると仲介者が排除されるように思えますが、他のシステムへのメッセージを管理するために、各システムでより多くの責任を負います。これは、懸念を分離するためのクリーンな方法ではないようです。現在、両方のシステムが仲介者の責任を引き受ける必要があります。

プッシュベースのアーキテクチャの仲介者をどのように再設計するかわかりません。仲介者自身が失敗した場合、メッセージが失われるリスクがあります。

ポーリングなしでシステムの相互作用を管理するために使用できるフォールトトレラントアーキテクチャはありますか？世論調査ベースの仲介者を考案/実装したときに、より良い代替案を見逃したかどうかを理解しようとしています。ソフトウェアは仕事をしますが、いくらかの待ち時間があります。

jhr · Accepted Answer

あなたの質問とコメントからすでに与えられた他の答えまで、私はあなたが2つのことに取り組んでいるように感じます：1）仲介者を排除すること、2）あなたの投票メカニズムをプッシュメカニズムに変換すること。私はそれらを別々に見ることができると思います。ポーリングからプッシュへの変更から始めましょう。

一般的に、私はイエスだと思います。プッシュはポーリングよりも優れています。私があなたのインフラストラクチャを正しく理解していれば、関係するシステム間で同期するものを探すために両方向にポーリングする仲介者がいます。すでになんらかのキューイングが行われていると思います。仲介者がAからのいくつかのイベントをポーリングし、Bがダウンしている場合、Bが再びアップするまで、それらのイベントを保持して再送信します。私がこれが正しいかどうかはわかりませんが、そうだとすれば、プッシュメカニズムへの切り替えはかなり単純で、メリットは明らかです。イベントを仲介者にプッシュするだけです。既存のキューを使用し、すぐにBにプッシュするか、適切と判断したときにプッシュします。さて、これがあなたの状況に適しているかどうかは、主に予想されるイベントの量と同期間に許可される最大遅延など、多くのことに依存します。現在、最大の遅延で任意の数のイベントが同期されます。 1分。プッシュを使用すると、遅延が大幅に減少する可能性がありますが、一方で、多くのイベント（以前はまとめて処理されていた）が多数の単一プッシュをもたらす場合、負荷が増加する可能性があります。これらはすべて仲介者が処理でき、処理する必要があります。

ここで仲介者を排除しようとすると、すべてのキューイングはシステムAとB内に存在する必要があります。それが実行可能かどうかは、AとBが現在行っていることに大きく依存します。それは彼らの責任を超えているかもしれません。また、同期の現在非常に一定のオーバーヘッドは、前述のように異なる場合があります。仲介業者は、負荷の軽減にも適している可能性があります。着信イベントを転送するメカニズムは、それらをバッチで送信するように設定できます。次に得られるものは、イベントを持つことができるシステムAとBであり、それらを押し出してすぐに忘れてしまいます。彼らにとってそれは素晴らしくてシンプルです。次に、仲介者は、最大遅延、最大イベント数などのさまざまな設定に応じて、それらのイベントを他のそれぞれのシステムに同期できます。

私が何を手に入れているのかはきっとわかると思いますが、あなたが探しているものとは違うかもしれません。しかし、このように考えると役立つかもしれません。明確にできるか教えてください。

eldon111 · Answer

仲介者が現在、前回の成功した実行の時間に基づいてデータをプルしている場合、仲介者を切り取るために、個々のシステムはプッシュアーキテクチャで同じことを行うことができます。はい、各システムはこれを追跡する必要がありますが、これは単一のタイムスタンプであり、完全なメッセージキューではありません。

Thomas Junk · Answer

他のシステムの問題が修正された後、再開するには、どちらのシステムも独自の発信キューを維持する必要があるように思われます。

はい、キューイングはそのようなシナリオに適したソリューションです。これがキューの作成目的です。コンシューマのメッセージをキューに入れます。しかし、システムがits own outgoing queue。

簡単な設定は、2つのサービス[〜＃〜] a [〜＃〜]とがあることです。 [〜＃〜] b [〜＃〜]、どちらもIncoming Messagesキュー。これらのキューはmailboxesのように機能します。 [〜＃〜] a [〜＃〜]はBの受信トレイにメッセージを送信します-）およびその逆。キューが行うこと、彼らが最も得意とすること：それらのメッセージをキューに入れること。

メッセージがそのようなキューのコンシューマーに到着する条件は次のとおりですa）開始時に、サービスはコンシューマーとして登録し、「メールボックス」にメッセージがあるという情報を取得します。したがって、サービスは「受信トレイ」が空になるまで1つずつポップし、b）新しいメッセージが到着するたびに、サービスは通知を受け取り、受信トレイが空になるまで未読メッセージをポップします。

2つのメッセージキューでシステムを分離します。 fire-and-forget-mannerでメッセージを送信します。受信者が生きているかどうかの質問は、送信者を悩ませません。キューは、現在のmiddlewareが行うことを実行しますが、より簡単な方法です。

障害点は、直接の受信者からシフトします。サービス[〜＃〜] a [〜＃〜]、キューイングインフラストラクチャへのサービス（復元力/冗長性を構築する必要がある= フォールト-トレラント。

各呼び出しは、最後に成功した実行のタイムスタンプを追跡します。どちらの方向の通信にも1つのタイムスタンプがあります。このようにして、システムのいずれかの部分に障害が発生した場合、問題が修正されたときに中断したところから再開できます。

上記のシナリオのキューはスタックのように機能し、順序を維持します。

また、分散システムであるため、対処する必要があります [〜＃〜] cap [〜＃〜] ;簡単に言うと、2つの非同期サービスがあり、どちらも同時にクエリされる可能性があるという問題です。