20

AWS でチャット サービスをスケーリングするための最適なソリューションを考え出そうとしています。私はいくつかの潜在的な解決策を思いつきました：

  1. Redis Pub/Sub - ユーザーがサーバーへの接続を確立すると、そのサーバーはそのユーザーの ID をサブスクライブします。誰かがそのユーザーにメッセージを送信すると、サーバーはユーザーの ID を使用してチャネルへの公開を実行します。ユーザーが接続しているサーバーがメッセージを受信し、適切なクライアントにプッシュします。

  2. SQS - ユーザーごとにキューを作成することを考えました。ユーザーが接続しているサーバーは、そのキューをポーリング (または SQS ロングポーリングを使用) します。新しいメッセージが発見されると、サーバーからユーザーにプッシュされます。

  3. SNS - 100 トピックの制限を発見するまで、私はこのソリューションを本当に気に入っていました。ユーザーごとに 100 人のユーザーしかサポートしないトピックを作成する必要があります。

AWS を使用してチャットをスケーリングできる他の方法はありますか? SQS アプローチは実行可能ですか? AWS がメッセージをキューに追加するのにどれくらいの時間がかかりますか?

4

6 に答える 6

10

チャット サービスの構築は、思ったほど簡単ではありません。

私は完全なXMPPサーバー、クライアント、および SDK を構築しており、発生する微妙で困難な問題のいくつかを証明できます。ユーザー同士が顔を合わせてチャットできるプロトタイプは簡単です。アカウントの作成、セキュリティ、検出、プレゼンス、オフライン配信、およびフレンド リストを備えたフル機能のシステムは、はるかに困難です。それを任意の数のサーバーに拡張することは特に困難です。

PubSub は、チャット サービスを構築する従来の手段ではなく、チャット サービス ( XEP-60 を参照) によって提供される機能です。魅力はわかりますが、PubSub には欠点もあります。

あなたへのいくつかの質問:

  1. これをWeb上で行っていますか？ユーザーは接続してロングポーリングを行う予定ですか、それとも Web ソケット ソリューションはありますか?

  2. ユーザー数は？ユーザーあたりの接続数は? 読み取りに対する書き込みの比率？

  3. そのように SQS を使用するというあなたのアイデアは興味深いものですが、おそらく拡張できません。チャット サーバーに 5 万人以上のユーザーがいるのは珍しいことではありません。各ユーザーの各 SQS キューをポーリングしている場合、それに近づくことはできません。サーバーごとにキューを用意したほうがよいでしょう。サーバーはそのキューのみをポーリングします。次に、ユーザーが使用しているサーバーを特定し、メッセージを適切なキューに入れるのはあなたの責任です。

私はあなたが次のようなものに行きたいと思うでしょう：

  1. バックエンドの大きな RDS データベース。
  2. クライアント接続を処理する一連のフロントエンド サーバー。
  3. すべてを追跡し、メッセージを適切な場所にルーティングするいくつかの中間層 Java / C# コード。

チャット サーバーの構築の複雑さを理解するには、XMPP RFC を読んでください: RFC 3920 RFC 3921

于 2013-05-08T22:20:12.607 に答える
4

私はSNSを使ってチャットサーバーを構築することを考えましたが、あなたが説明したように、ユーザーごとに1つのトピックを行うのではなく、チャットシステム全体で1つのトピックを行い、各サーバーがトピックにサブスクライブするようにします。ロング ポーリングまたは Web ソケット チャット システム。その後、イベントが発生すると、SNS 通知のペイロードでデータが送信されます。次に、サーバーはこのペイロードを使用して、キュー内のどのクライアントが応答を受信する必要があるかを判断し、関係のないクライアントはそのままにします。私は実際にこのための小さなプロトタイプを作成しましたが、多数のユーザーに対して十分に堅牢であるかどうかを確認するための大量のテストを行っていません.

于 2014-05-12T14:24:02.283 に答える
2

私がそのようなことを実装する方法（フレームワークを使用していない場合）は次のとおりです。

ユーザーからのメッセージを受け入れるWebサーバー（ec2上）があります。この Web サーバーで Autoscalling グループを使用します。ウェブサーバーは、簡単にスケーリングできる Amazon RDS 上の任意の DB を更新できます。

独自のデータベースを使用している場合は、sqs を使用して (すべてのリクエストを同じキューに送信することにより) Web サーバーからデータベースを分離することを検討してください。その後、キューを消費するコンシューマーを設定できます。このコンシューマーは自動スケーリング グループの背後に配置することもできるため、キューが X メッセージよりも大きい場合はスケーリングされます (アラームで設定できます)。

sqs は通常、非常に高速に更新されます。つまり、1 秒未満です。（送信した瞬間からキューに表示される瞬間まで）、それ以上になることはめったにありません。

于 2013-05-24T14:28:00.483 に答える
1

数か月前に新しい AWS IoT サービスが WebSockets、Keepalive、Pub/Sub のサポートを開始したため、エラスティック チャットを簡単に構築できます。AWS IoT は、JavaScript を含むさまざまな言語用の多数の SDK を備えたマネージド サービスであり、管理なしで巨大な負荷 (数十億のメッセージ) を処理するために構築されました。

更新の詳細については、次を参照してください。

https://aws.amazon.com/ru/about-aws/whats-new/2016/01/aws-iot-now-supports-websockets-custom-keepalive-intervals-and-enhanced-console/

編集：

SQS の最終更新 (2016/11): メッセージを厳密な順序で処理し、先入れ先出し (FIFO) キューを使用して 1 回だけ処理する必要があるアプリケーションに、Amazon Simple Queue Service (SQS) を使用できるようになりました。FIFO キューは、メッセージが送受信される順序が厳密に保持され、各メッセージが 1 回だけ処理されるように設計されています。

ソース: https://aws.amazon.com/about-aws/whats-new/2016/11/amazon-sqs-introduces-fifo-queues-with-exactly-once-processing-and-lower-prices-for-標準キュー/

さて、SQS + SNS を実装するのも良い考えのようです。

于 2016-08-05T20:26:22.970 に答える