0

潜在的な問題 (一般):

ユーザー A が (ブラウザー/クライアント A を使用して) チャット メッセージを入力すると、メッセージはすぐにビューに追加され、サーバーにも送信されます。サーバーは、ビューの更新のためにそれをユーザー/クライアント B に送信します。しかし、その間にユーザー B がチャット メッセージを入力すると、すぐにビューに追加されます。ユーザー B のチャット履歴の最後のメッセージとしてメッセージ B があり、ユーザー A のチャット履歴の最後のメッセージとしてメッセージ A があります。これは、多くのユース ケースで問題となります。たとえば、人々がクイズで競い合い、誰が最初に正しい答えを投稿したかが重要である場合などです。

これはMeteorでどのように処理されますか?

考えられる解決策 (シーケンスの整合性が重要な Web アプリの場合):

すぐにクライアント ビューを更新しないでください。

サーバーはデータを中央モデルに追加し、すべてのクライアント (データを作成したユーザーのクライアントを含む) に配布します。

各クライアントはモデルとビューを更新し、「取得した更新要求を処理しました」という短いメッセージをサーバーに送信します。

サーバーは最後のそのようなシグナルを待ち (切断したユーザーを無視します) [1]、次のデータ (次の更新要求) の準備が整います。キューに項目がある場合は、それらを最初に処理します。

このように、最初にサーバーに到達したデータが優先され (すべてのクライアントで優先されます)、サーバーに少し遅れて到達したデータは、最初のデータが各クライアントに反映された後に処理されます。

(作成者のクライアントでビューの更新が少し遅れて発生するという事実 (データが最初にサーバーを通過するため) は、大きな問題ではないと思います。)

[1] (偶発的な切断が常に処理されるようにする)

トビ

4

1 に答える 1

0

私が理解しているように、流星で起こることはこれです（明らかに実行の順序に依存します）：

  1. ユーザーAがA_cクライアントでメッセージを作成します
  2. ユーザーAがA_sサーバー上にメッセージを作成します（これは自動的に行われます）
  3. ユーザーBがB_cクライアントでメッセージを作成する
  4. A_sはユーザーAとユーザーBの両方に配布され、AとBの代わりA_cになりますB_c。
  5. ユーザーBがB_sサーバー上にメッセージを作成します
  6. B_s両方のユーザーに配布されます。

したがって、おそらく何が起こるか（4または5が最初に発生するかどうかによって異なります）、Bは、メッセージがAの下にシャントされている間、少しちらつきが見られます。Meteor.methodおそらく、 （コレクションによって作成された暗黙的なものを使用するのではなく）sの使用をより具体的にすることで、より良い解決策に到達できます。

私見では、時々奇妙なちらつき（これはレイテンシーに応じて私が推測するエッジケースです）は、すべての場合に作成者のビュー更新に遅れをとるよりもはるかに優れた解決策です。

于 2012-08-21T04:01:16.927 に答える