2

私は、ユーザーがサイトで別のユーザーを見つけるための特定の基準を選択し、サイトが同じ基準の誰かを探している他の誰かとあなたをペアにするウェブサイトを持っています。「ペアリングされていない」（まだペアリングされていない）ユーザーのコレクションがあり、誰かがペアリングを要求するたびに、プログラムはコレクション内の次の使用可能なユーザーを一致基準でチェックし、ユーザーを削除します一致する場合は「unpaired」コレクションから、一致しない場合は「unpaired」コレクションにユーザーを追加します。

私の質問は、次の基準に基づいてこのタイプのコレクションを処理するための最良の方法は何ですか？

  • マッチングプロセスはリアルタイムで行われるため、SignalRなどを使用してリアルタイムのペアリングを処理しています
  • システムがシャットダウンされた場合、システムがシャットダウンされたためにペアになっていないユーザーを「検索」するユーザーがいないため、コレクションを保持する必要はありません。
  • サーバーをスケールアウトして複数のインスタンスがある場合、それらはすべて同じコレクションから引き出すことができる必要があります
  • 2人のユーザーが同時に要求した場合は、並行性に対処します（必要かどうかはわかりません）。

私がこれを考えたときに生じたいくつかの標準的な質問は次のとおりです。

  • ユーザーは絶えず追加および削除されているので、このためのデータベースも必要ですか？

  • ある種のストレージが必要な場合、mongodbのようなものが良いオプションでしょうか？なぜ？

  • コレクションをメモリに保存した場合、スケールアウトすると異なるインスタンス間で機能しませんよね？

4

1 に答える 1

0
  • 同時実行性に対処する必要があります。ペアリングするユーザーを見つけたら、そのユーザーをロックし、ペアリングされていないことを確認してからペアリングしてから、ロックを解除します。そうしないと、最初にペアリングされていないユーザーを最初に見つけるリスクがあり、それらをペアリングするときに、それらはすでに取得されています。
  • ペアリングでどのような副作用が発生するかは明らかではありませんが、現在を過ぎても気にしないようです（つまり、サーバーがダウンした場合、ペアリングは関係ありません）。これはメモリ内操作のように聞こえますが、ロギング/分析の目的でデータベースに永続化される可能性があります。
  • さまざまなインスタンスに関しては、それがメモリ内にある場合でも、サーバー全体で実行できます（map / reduce式はメモリ内で機能する可能性があり、おそらく他にもたくさんあります）。また、サーバー1の異なるサーバーAN、サーバー2のOZでユーザーをバケット化するソリューションを設計することもできます（データに意味がある場合）。また、ペアリングに必要なデータを最小限に抑え、ペアリング後に発生するすべてのことをどこにでもオフロードして、ペアリングだけを処理する単一のサーバー（必要に応じて強力）を使用することもできます。

申し訳ありませんが、データ/ユースケースをもう少し理解していない一般的なものです

于 2012-07-23T22:24:37.977 に答える