9

Facebookライブストリームプラグインのように見えるGoogleAppEngine（Python）を使用してマルチユーザーリアルタイムアプリケーションを構築しています： https ：//developers.facebook.com/docs/reference/plugins/live-stream/

つまり、同じWebページの1〜1 000 000人のユーザーが、他のすべてのユーザーに即座に通知されるアクションを実行できます。グループチャットのようなものですが、たくさんの人と...

私の質問：
-App Engineはそのような数に拡張できますか？
-はいの場合、どのようにデザインしますか？
-いいえの場合、あなたの提案は何ですか？

現在、これは私の設計です： -App
Engine Channel APIを使用しています
-接続されているすべてのユーザーをmemcacheに保存します-
アクションが実行されるたびに、通知タスクがタスクキューに追加されます
-タスクはすべてのユーザーを取得することで構成されますmemcacheから通知を送信します。

私のボトルネックが課題にあることを私は知っています。全員が同じタスク/リクエストを通じて通知されます。現在、30人のユーザーが接続している場合、約1秒続くため、10万人のユーザーの場合、どれくらいの時間がかかるか想像できます。

これをどのように修正しますか？

どうもありがとう

4

1 に答える 1

11

ユーザーごとに 1 秒あたり何回の更新が予想されますか? 各ユーザーが 1 時間に 1 回だけ更新する場合、1 時間に 10^12 のメッセージを送信することになります。メッセージを送信するたびに、さらに 1,000,000 件の送信が発生します。これは 1 秒あたり 2 億 7,700万メッセージです。別の言い方をすれば、すべてのユーザーが 1 時間にメッセージを送信すると、1 秒あたり 277 の受信メッセージ、つまり 2 億 7700 万の送信メッセージになります。

したがって、基本設計に欠陥があると思います。しかし、「同じメッセージを多くのユーザーにブロードキャストするにはどうすればよいか」という根底にある問題は依然として有効であり、私はそれを取り上げます。

お気づきのとおり、各呼び出しには約 50 ミリ秒かかるため、Channel API はブロードキャストには適していません。複数のタスクを並行して実行することで、これを回避できます。

このような場合 --まったく同じステートレス データを必要とする多数のクライアントの場合、Channel API ではなくポーリングを使用することをお勧めします。これは、すべてのクライアントがまったく同じ情報を受け取るためです -- 個別のメッセージを送信する必要がないためです。各クライアントに。許容できる平均待ち時間 (例: 1 秒) を決定し、その 2 倍の速度 (例: 2 秒) でポーリングします。非常に軽量な memcache を利用したサーブレットを作成して、最新のデータ ブロックを取得し、クライアントが重複排除できるようにします。

于 2011-12-03T17:58:59.787 に答える