44

Facebookアプリケーションとクラウドコンピューティングの時代に、大規模なマルチプレイヤーゲームについて少し考え直しています。

既存のオープンプロトコルの上に何かを構築することになっていて、問題の範囲を特定するために、1,000,000人の同時プレーヤーにサービスを提供したいとします。

各プレーヤーに着信メッセージキュー（チャットなど）があり、平均してもう1つの着信メッセージキュー（ギルド、ゾーン、インスタンス、オークションなど）があるとすると、2,000,000のキューがあります。プレーヤーは一度に1〜10個のキューをリッスンします。各キューには、平均して1秒あたり1つのメッセージが含まれますが、特定のキューでは、レートがはるかに高く、リスナーの数が多くなります（たとえば、レベルインスタンスの「エンティティロケーション」キュー）。システムキューの待ち時間が100ミリ秒以下であると仮定しましょう。これは、軽度のアクション指向のゲームでは問題ありません（ただし、QuakeやUnreal Tournamentなどのゲームでは問題ありません）。

他のシステムから、単一の1Uまたはブレードボックスで10,000人のユーザーにサービスを提供することは、合理的な期待であることがわかっています（物理シミュレーションなど、他に費用のかかるものがないことを前提としています）。

したがって、クライアントが接続ゲートウェイに接続し、接続ゲートウェイがメッセージキューサーバーに接続するクロスバークラスターシステムでは、100個のゲートウェイマシンでゲートウェイごとに10,000ユーザーを取得し、100個のキューマシンでキューサーバーごとに20,000個のメッセージキューを取得します。繰り返しますが、一般的なスコーピングのためだけです。各MQマシンの接続数はごくわずかで、各ゲートウェイと通信するには約100です。ゲートウェイの接続数はかなり多くなります。クライアントの場合は10,100+すべてのキューサーバーへの接続です。（これに加えて、ゲームワールドシミュレーションサーバーなどの接続をいくつか追加しますが、今はそれを分離しておくようにしています）

これを最初から構築したくない場合は、既存のメッセージングおよび/またはキューイングインフラストラクチャを使用する必要があります。私が見つけることができる2つのオープンプロトコルはAMQPとXMPPです。XMPPの使用目的は、このゲームシステムに必要なものに少し似ていますが、オーバーヘッドは非常に顕著です（XML、詳細なプレゼンスデータ、およびその上に構築する必要のある他のさまざまなチャネル）。AMQPの実際のデータモデルは上記で説明したものに近いですが、すべてのユーザーは大規模なエンタープライズタイプの企業のようであり、ワークロードはリアルタイムのゲーム更新ではなくワークフローに関連しているようです。

誰かがこれらのテクノロジーまたはその実装について、あなたが共有できる日中の経験を持っていますか？

4

5 に答える 5

11

@MSalters

'メッセージキュー'について：

RabbitMQのデフォルトの操作は、まさにあなたが説明するものです：一時的なpubsub。しかし、UDPの代わりにTCPを使用します。

保証された最終的な配信およびその他の永続性と回復機能が必要な場合は、それも使用できます。これはオプションです。これがRabbitMQとAMQPの要点です。1つのメッセージ配信システムで多くの動作を行うことができます。

説明するモデルはデフォルトの動作です。これは一時的な「ファイアアンドフォーゲット」であり、受信者がどこにいてもメッセージをルーティングします。そのため、人々はRabbitMQを使用してEC2でマルチキャスト検出を行います。ユニキャストTCPpubsubを介してUDPタイプの動作を取得できます。きちんとね？

UDPに関して：

ここでUDPが役立つかどうかはわかりません。Naglingをオフにすると、RabbitMQの単一メッセージのラウンドトリップ遅延（client-broker-client）が250〜300マイクロ秒で測定されます。Windowsのレイテンシー（少し高かった）との比較については、こちらを参照してくださいhttp://old.nabble.com/High%28er%29-latency-with-1.5.1--p21663105.html

300マイクロ秒未満のラウンドトリップ遅延を必要とする多くのマルチプレイヤーゲームは考えられません。TCPで300usを下回る可能性があります。TCPウィンドウ処理は生のUDPよりもコストがかかりますが、UDPを使用して高速化し、カスタムの損失回復またはseqno / ack / resendマネージャーを追加すると、速度が再び低下する可能性があります。それはすべてあなたのユースケースに依存します。本当に本当にUDPや怠惰なackなどを使用する必要がある場合は、RabbitMQのTCPを取り除き、おそらくそれをやってのけることができます。

これが、JonのユースケースにRabbitMQを推奨した理由を明確にするのに役立つことを願っています。

于 2009-12-18T20:23:09.823 に答える
11

実は今、そういうシステムを作っています。

私は、RabbitMQ、Qpid、ZeroMQを含むいくつかのMQのかなりの量の評価を行いました。これらのいずれかのレイテンシとスループットは、このタイプのアプリケーションには十分すぎるほどです。ただし、50万以上のキューの真っ只中にあるキューの作成時間は良くありません。特にQpidは、数千のキューの後で非常に深刻に低下します。この問題を回避するには、通常、独自のルーティングメカニズムを作成する必要があります（キューの総数が少なくなり、それらのキューのコンシューマーは、関心のないメッセージを受信します）。

私の現在のシステムはおそらくZeroMQを使用しますが、かなり限定された方法で、クラスター内で使用します。クライアントからの接続はカスタムシムで処理されます。私がlibevを使用して構築し、完全にシングルスレッドであるデーモン（そして非常に優れたスケーリングを示しています-問題なく1つのボックスで50,000の接続を処理できるはずです-しかし、私たちのシミュレーションティック率は非常に低く、物理学なし）。

XML（したがってXMPP）は、これにはあまり適していません。I/ Oにバインドされるずっと前に、CPU処理XMLをペグするため、これは必要なことではありません。現在、Google Protocol Buffersを使用していますが、これらは特定のニーズに適しているようです。クライアント接続にもTCPを使用しています。私は過去にこれにUDPとTCPの両方を使用した経験があり、他の人が指摘しているように、UDPにはいくつかの利点がありますが、操作するのは少し難しいです。

ローンチがもう少し近づいたら、詳細を共有できるようになることを願っています。

于 2010-02-03T18:15:41.483 に答える
5

ジョン、これはAMQPとRabbitMQの理想的なユースケースのように聞こえます。

AMQPユーザーがすべて大企業型の企業であるとあなたが言う理由はわかりません。お客様の半数以上が、大企業から小規模企業までの「ウェブ」スペースにいます。多くのゲーム、賭けシステム、チャットシステム、twitteryタイプのシステム、およびクラウドコンピューティングインフラストラクチャがRabbitMQから構築されています。携帯電話のアプリケーションもあります。ワークフローは、多くのユースケースの1つにすぎません。

ここで何が起こっているかを追跡しようとします。

http://www.rabbitmq.com/how.html（del.icio.usのユースケースのリストもクリックしてください！）

ぜひご覧ください。私たちは助けるためにここにいます。info@rabbitmq.comに電子メールを送信するか、twitter（@monadic）で私に連絡してください。

于 2009-12-18T14:01:40.390 に答える
3

私の経験は、非オープンな代替手段であるBizTalkを使用したものです。私たちが学んだ最も苦痛な教訓は、これらの複雑なシステムは高速ではないということです。そして、ハードウェア要件から理解したように、それは直接かなりのコストに変換されます。

そのため、コアインターフェイスのXMLに近づかないでください。サーバークラスターは、1秒あたり200万件のメッセージを解析します。これは、簡単に2〜20GB/秒のXMLになる可能性があります。ただし、ほとんどのメッセージは少数のキュー宛てに送信されますが、ほとんどのキューは実際にはトラフィックが少ないです。

したがって、COTSキューサーバーから始めて、ボトルネックが特定されたときに各キュー（タイプ）をカスタムキューサーバーに簡単に移動できるようにアーキテクチャを設計します。

また、同様の理由で、メッセージキューアーキテクチャがアプリケーションのすべての通信ニーズに最適であるとは限りません。「インスタンス内のエンティティの場所」の例を見てください。これは、メッセージの配信を保証したくない典型的なケースです。この情報を共有する必要がある理由は、それが常に変化するためです。したがって、メッセージが失われた場合、メッセージの回復に時間を費やしたくありません。影響を受けるエンティティの古い場所のみを送信します。代わりに、そのエンティティの現在の場所を送信する必要があります。技術的には、これはTCPやカスタムの損失回復メカニズムではなくUDPが必要であることを意味します。

于 2009-12-18T14:38:26.647 に答える
3

FWIW、中間結果が重要でない場合（ポジショニング情報など）、Qpidには、サブスクライバーに最新の値のみを配信できる「最終値キュー」があります。

于 2009-12-29T17:37:43.077 に答える