8

クライアントがリクエストを入れることができるキューを作成したいのですが、リソースが利用可能になったときにサーバーワーカースレッドがリクエストを引き出すことができます。

Firebase にデータを注入し直さなければならない外部キュー サービスではなく、Firebase リポジトリでこれを行う方法を模索しています。

セキュリティと検証ツールを念頭に置いて、私が考えていることの簡単な例を次に示します。

  • ユーザーはリクエストを「キュー」バケットにプッシュします
  • サーバーはリクエストを取り出して削除します ( 1 つのサーバーだけがリクエストを受け取るようにするにはどうすればよいですか? )
  • サーバーはデータを検証し、プライベート バケットから取得します (または新しいデータを挿入します)
  • サーバーはデータやエラーをユーザーのバケットにプッシュします

ここに画像の説明を入力

これが役立つ可能性がある場所の簡単な例は、認証です。

  • ユーザーが認証要求をパブリック キューに入れる
  • 彼のログイン/パスワードは彼のプライベート バケット (彼だけが読み書きできる場所) に入れられます
  • サーバーは認証リクエストを取得し、ログイン/パスワードを取得し、サーバーのみがアクセスできるプライベート バケットに対して検証します。
  • サーバーはトークンをユーザーのプライベート バケットにプッシュします

(確かに、パブリック キューにはまだセキュリティの抜け穴がいくつかあります。この時点で調査しているところです)。

その他の使用例:

  • 読み取り専用ステータス キュー (ユーザー ステータスはプライベート バケットを介して伝達され、サーバーはパブリックに対して読み取り専用であるパブリック バケットに書き込みます)
  • メッセージ キュー (メッセージはユーザー経由で送信され、サーバーはメッセージがドロップされるディスカッション バケットを決定します)

質問は次のとおりです。

  1. これは、今後のセキュリティ計画にうまく統合できる優れた設計ですか? 検討されている代替アプローチにはどのようなものがありますか?
  2. すべてのサーバーがキューをリッスンするようにするにはどうすればよいですか? ただし、各要求を取得するのは 1 つのみです。
4

2 に答える 2

8

うわー、素晴らしい質問。これは社内で説明した使用パターンであるため、実装の経験についてお聞かせください(support@firebase.com)。ここにあなたの質問に関するいくつかの考えがあります:

認証

主な目標が実際の認証である場合は、セキュリティ機能を待つだけです。:-)特に、独自のバックエンドサーバー、Firebaseユーザーストア、またはサードパーティプロバイダー(Facebook、Twitterなど)がサポートする認証を実行できるようにする予定です。

負荷分散されたワークキュー

認証に関係なく、Firebaseをある種のワークロードバランシングシステムのバックボーンとして使用するための興味深いユースケースがあります。そのために、あなたが取ることができるいくつかのアプローチがあります:

  1. 説明したように、すべてのサーバーがアイテムを監視および削除する単一のワークキューを用意します。これは、トランザクションを使用して実行できます()アイテムを削除します。transaction()は競合を処理するため、1つのサーバーのトランザクションのみが成功します。1つのサーバーが2番目のサーバーをワークアイテムに打ち負かした場合、2番目のサーバーはトランザクションを中止し、キュー内の次のアイテムで再試行できます。このアプローチは、サーバーを追加および削除すると自動的にスケーリングされるため便利ですが、Firebaseサーバーへのラウンドトリップを行って、他の誰もキューからアイテムを取得していないことを確認する必要があるため、トランザクションの試行ごとにオーバーヘッドが発生します。ただし、ワークアイテムの処理にかかる時間がFirebaseサーバーへのラウンドトリップにかかる時間よりもはるかに長い場合、このオーバーヘッドはおそらく大きな問題ではありません。サーバーがたくさんある場合(つまり、競合が多い場合)や小さな作業項目がたくさんある場合は、オーバーヘッドがキラーになる可能性があります。
  2. 多数のワークキューからランダムに選択するようにクライアントに負荷分散をプッシュします。(たとえば、/ queue / 0、/ queue / 1、/ queue / 2、/ queue / 3があり、クライアントにランダムに1つを選択させます)。次に、各サーバーは1つのワークキューを監視し、すべての処理を所有できます。一般に、これはオーバーヘッドが最小になりますが、サーバーを追加/削除するときにシームレスに拡張されません(サーバーがオンラインになったときにサーバーが更新するワークキューの別のリストを保持してから、クライアントを作成する必要があります)。リストを監視して、選択できるキューの数などを確認します。

個人的には、最適なパフォーマンスが必要な場合は、オプション2に傾倒します。しかし、#1はプロトタイピングが簡単で、少なくとも最初は問題ないかもしれません。

一般的に、あなたのデザインは間違いなく正しい方向に進んでいます。実装を試したり、問題が発生したり、APIに関する提案がある場合は、お知らせください(support@firebase.com :-)!

于 2012-06-28T18:25:19.643 に答える