最終的な一貫性のためのGUIの推奨？

Question

分散およびスケーラブルなアーキテクチャを使用する場合、最終的な一貫性が必要です。

グラフィカルに、この最終的な一貫性に対処する方法は？

ユーザーは保存をクリックし、結果を瞬時に確認するために使用されます...最終的に一貫性があり、不可能です。

このようなシナリオのGUIに対処する方法は？

質問は、デスクトップアプリケーションとWebアプリケーションの両方に適用されることに注意してください。

PS：私はMicrosoftプラットフォームで作業していますが、質問はあらゆるテクノロジーに当てはまると思います...

Answer 1

a タスクベースのUI このモデルに最適です。 UIからタスクを作成して実行します。また、タスクステータスモニターのようなものを用意して、タスクが実行されたときにユーザーを表示することもできます。

別のオプションは、クライアントから何らかのプーリングを使用することです。コマンドを送信し、コマンドが完了して新しいデータが利用可能になるまで、クライアントからプールします。ユーザーが新しいレコードを表示するときに保存を押すときから遅延が発生しますが、ほとんどの場合、ほとんど同期する必要があります。

別の（良い？）オプションは、失敗しないコマンドを想定/設計することです。これは些細なことではありませんが、クライアントにキャッシュを持ち、コマンドからデータをそのキャッシュに追加して、コマンドが実行される前であってもユーザーに表示できます。コマンドが予期しない状況で失敗した場合、数秒間ユーザーを誤解させるための良い「ごめんなさい」メッセージをデザインするだけです。

上記の方法を組み合わせることもできます。

通常、最終的な一貫性はビジネス/ドメインの問題のようなものであり、ドメインの専門家にそれを処理させる必要があります。

Answer 2

2つの方法があります：

1. ユーザーをだましてください（物事が起こったことを示すためだけに、彼らはまだ起こっていません）
2. システムがリクエストを処理し、バックグラウンドでポーリングを使用していること（良くない）またはSLAの価値を持つタイマーを使用していることを示します。

最初のオプションが好きです。

Answer 3

誰かがすでに述べたように、タスクベースのUIはこれに適しています。私がやることは、コマンドが伝播するために「時間を購入する」テクニックを採用することです。

たとえば、ユーザーがさまざまなアクションを実行できるリスト画面にいることを想像してください。その1つは、リストに新しいアイテムを追加することです。アイテムを追加することを選択した後、「次に何をしたいですか？」を表示できます。 「別のアイテムを追加する」、「このタスクを実行する」、「他のタスクを実行する」、「リストに戻る」ことができます。

彼らがオプションをクリックする頃には、データが更新されることを願っています。

また、タスクベースのUIを使用している場合は、タスク実行のパターンを分析し、これらの「次のことをしたい」画面を使用してUIを合理化できます。 Amazonの「他の人もこれらのアイテムを購入しました」と同様です。

Answer 4

他の回答は、一般的にCQRと最終的な一貫性を組み合わせて混ざり合っていると思います。タスクベースのUIはCQRに非常に適していますが、最終的に一貫した読み取りモデルで問題を解決しません。

まず、私はあなたの声明に挑戦したいと思います：

ユーザーは保存をクリックし、結果を瞬時に確認するために使用されます...最終的に一貫性があり、不可能です。

これで何をしますか？なぜ見ることができないのですか 結果 すぐに？ここでの問題はあなただと思います 結果の定義.

アクションの結果は、そのアクションが実行されたことです。これを示す方法はたくさんあります！それはあなたがどのような行動を完了したいかによって異なります。例：

• メールの送信：ユーザーが正しいメールアドレスを入力した場合、アクションが正常に完了することがほぼ保証されています。予期しない障害を防ぐためには、この種のアクションを同期的に行う必要がないため、耐久性のあるキューを使用する可能性があります。したがって、「電子メールが送信された」と言うだけです。通常、パスワードをリセットするように依頼すると、この種の応答が表示されます。

• ユーザープロファイルでいくつかの情報を更新する：クライアントの新しいデータを検証した後、おそらくコマンドも成功するでしょう。データベースエラーだけが発生する可能性があるため（データベースを使用する場合）。繰り返しますが、これも耐久性のあるキューを使用して軽減できます。この場合、更新されたフィールドを同じ形式で表示するだけです。 SPAの良いプラクティスは、Reduxのように、クライアント側に包括的なデータストアを用意することです。この場合、コマンドを送信し、クライアント側のストアを更新することでサーバーを安全に更新できます。これにより、UIが最新のデータを表示するようになります。 免責事項：いくつかの回答は、この手法を「ユーザーをtrickしている」と呼んでいますが、この定義には同意しません。

• エラーが発生しやすいコマンドがある場合は、WebSocketsやサーバー側のイベントなどの他の回答で既に説明されているテクニックを使用して、エラーを伝達することができます。これには、かなり多くの追加作業が必要です。コマンドを送信して、コマンドを同期して返信または実行するのを待つこともできます。 「これはCQRではない」と言う人もいますが、これは挑戦される別の教義にすぎません。コマンドが前のポイント（クライアント側のデータストア）と組み合わせて実行を完了したことを確認することは、良いソリューションになります。

読み取りモデルから常にゼロ以外のデータを表示できる100％の弾丸証明手法があるかどうかはわかりません。 CQRSの原則に反すると思います。リアルタイムのイベントを使用しても、モデルを書くことが更新されたことを示すイベントのみが取得されます。それでも、あなたの予測は失敗し、これに反応することはまったく別の話です。

しかし、私はこの問題にそれほど集中しません。実際、よくテストされた予測とほぼ保証されたコマンドが非常にうまく機能するということです。状況の90％でのエラー処理の場合、これらのエラーから回復するために、手動または半多数のプロセスがあるだけで十分です。最後の10％については、「ごめんなさい、アクションXXXが実行できなかった」というサーバーからプッシュされた一般的な「エラー」メッセージを組み合わせることができます。レア。

Answer 5

前述のように、ユーザーに リクエスト (指図） 認められた （正常に 発行済み）。ある程度の障害の場合、システムはこれをに伝える必要があります リクエスター, 、次のことによって

• Eメール;
• SMS;
• カスタム受信トレイ （例えば、SO受信トレイのように）;
• なんでもいい。

たとえば、メールクライアント /サービス：

• 間違った住所にメールを送信しています。
• メールサービスには、「電子メールが正常に送信されました:)」と書かれています。
• 数分後、私はサービスからメールを受け取りました：「電子メールは配信できませんでした」。

最近の失敗についてユーザーに知らせる素晴らしい方法だと思います 彼がアプリケーションをナビゲートしている間、彼にエラーパネルを提示することです. 。その警告などを却下するためには、ユーザージェスチャーが必要になる場合があります。

例えば：

Answer 6

私はユーザーをだましたり、他のアクションを犯すのをブロックしたりすることはありません。読み取り側によって認められた後、UIに向かってデータをストリーミングするために行きたいです。これらの2つのケースを考えてみましょう。

1. ユーザーはデータを保存し、結果を期待します。接続はサーバーに向けて確立されます。彼らが読み取り側によって認められた後、それらはUIに向かってストリーミングされ、UIは更新されています。

2. ユーザーはデータを保存し、Webページを更新します。リロードすると、データがデータストアから取得され、ストリーミングのための接続が確立されます。その間に読み取り側がデータストアを更新しなかった場合、まだ開いたストリームがあり、データが読み取り側に到達した後にUIを更新する必要があります。

なぜ読み取り側からストリーミングし、書き込み側から直接ではないのですか？単純に、それは読み取り側に到達したことの確認です。技術的な側面から、 サーバーセントイベント 使用することができます。

不利益：

結果は、読み取り側によってすぐに反映されません。しかし、少なくとも、ほとんどの場合、ユーザーはUIにブロックされることなく自分の仕事を続けることができます。