Node.js はゲームのバックエンド開発に適していますか? _node.js

ウェブサイトサーバーとゲームサーバーはどのように接続されていますか?

1. まず、MMORPG について見てみましょう。

RPG サーバーがどれほど単純であっても、同じシーンに数百人がいる場合、各クライアントは他の全員の操作情報を受信する必要があります。

第二に、ユーザーの操作が非常に頻繁であり、一般的なサーバーは長時間の接続を保持する傾向があります。さらに、これらのリンクは頻繁に対話し、明確な永続的なパーティション分割戦略がないため、多くの場合、同じシナリオを 1 台の物理マシンでしか実行できません。

第三に、クライアント ゲームは通常、クライアントに論理演算を実装することを敢えてしません。ユーザーが数分でゲームを解読し、金貨を交換し、装備を 2 つ購入することがよくあります。そのため、このマップサーバーはマップ内の全プレイヤーの動作を検証し、モンスターAIやドロップ率などの一連のビジネスロジックを計算する必要があります。

従来のゲーム サーバーと Web サーバーの間には明らかな違いがあり、長い接続、マルチブロードキャスト、複雑なビジネス ロジック、制限されたパーティショニング戦略などの独自のビジネス要件があることがわかります。

2. ゲームサーバーに対する同時実行の利点を見てみましょう。

同時実行性は実際にはプログラム ロジック プロセスであり、マルチコアの物理サポートを必要としません。一般的な意味は、複数の独立したロジック フローを同時に実行しているように見せることです。オペレーティング システム レベルの同時実行性は、マルチプロセス マルチスレッド モデルです。 OS にクロック割り込み、IO ブロッキング、その他の問題を処理させます。

サーバーの場合、タスクがほとんどの時間を IO に費やす場合、同時実行メカニズムにより、マップ サービス全体が IO アクセスによってブロックされるのを防ぐことができます。タスクがブロックされている場合は、予備のコンピューティング リソースを他のタスクに割り当てます。この場合、同時実行性はサーバーの効率と応答時間に有益です。

プログラマーにとって、独立したロジック フローは、信頼性が高く、シンプルで、疎結合されたコンテキストでタスクを完了できることを意味します。

OS ハンドラーのロジックの切り替えはカーネル内で繰り返し実行される必要があるため、これでは遅すぎると考える人もいます。そのため、ユーザー空間にいくつかのスレッドを作成し、プロセス内の複数のロジック フローを制御します。言語の記述能力には限界があるので、C/Cでそんなものを書いて使うのは面倒です。その結果、Erlang、Go、Lua のコルーチン構文シュガーが誕生しました。

Node.js は基本的に複数の論理フローを単独で制御しますが、この論理フローは io のステータスと優先度に基づいて分散されます。実際の実装では、単一タスクが io を呼び出すと、それを停止し、io 完了シグナルが送信されたときに、それを再起動する、ノンブロッキングの非同期 io を使用しようとします。

タスクを実行するたびに、タスクが完了するか IO 呼び出しが発生するまで、他のプログラム フローに積極的に切り替えることはありません。したがって、このタスクに多くの計算が含まれる場合、マップ プロセス全体がここでブロックされます。

node.js は非同期であるため、IO 完了信号を監視するためにコールバックを常に記述する必要があります。単一タスクの論理フローは複数回中断されます。タスクが非常に複雑になると、いわゆるコールバック地獄が発生し、デバッグや開発に大きな支障をきたします。

3. 上記の理由により、プロトタイプ以外の MMORPG サーバー開発では node.js を使用することはお勧めしません。

4. モバイル ゲームはネットワークの問題に限定されているため、最近登場したモバイル ゲーム サーバーは、node.js に非常に適しています。 。サーバー側は Web サーバーと変わらないほど単純化されており、ビジネス ロジックもデータを処理して保持するだけで済みます。