大規模なサーバーを作成しない方法

私の最後の記事を見ることができた人（そしてこのトピックに非常に関係している人）は、主に高負荷向けに設計されたMinecraftサーバーの実装を1年半以上開発していることを知っています。 ただし、私たちの作業では、いくつかのミニサーバーに標準サーバー（Bukkit）を使用して、さまざまなものを用意しています。 そして今、サーバーの次のバージョンに直面しましたが、これは以前のものよりも5倍悪化しました。私はもう我慢できず、この記事を書くことにしました。

この記事はトレーニング資料というよりも物語のようなものなので、有用なコーディングスキルを引き出すことはほとんどありませんが、誰かがそれを面白いと思うか、さらには役に立つと思うことを願っています。 しかし、多くのコードとサンプルを見に行く場合、記事を開かないでください、それはそれについてではありません。 これが次の記事になることを願っています。

Minecraftについて、特にそのサーバーについて何も知る必要はありません。この記事では、元のMinecraftサーバーがどのように機能するか、およびその「バインディング」であるBukkitについて説明したいと思います。 私はサーバー開発の完全な知識を持っているふりをしませんし、私のサーバーが正しく、何よりもうまく書かれていると主張しません。 私は、有名なMojangのサーバーで2年間働いた経験と、サーバーを開発して1年半の経験を共有しています。 ここに記載されている情報はすべて私の個人的な意見であり、この記事は私の視野を広げ、さらには研究することを目的としており、初心者と上級専門家の両方にとって興味深いものです。

最も純粋な（「バニラ」）Minecraftサーバー、またはむしろ、それが何をするのかから始めましょう。 これらはサーバーによって処理されます：

• チャンク -知らない人のために、Minecraftの世界全体が、設定に応じて16x16キューブの面積と高さを持つ部分に分割されています。 プレーヤーの可視範囲内のすべてのチャンクはサーバーのメモリに読み込まれ、HashMapに配置されます。各サーバーはチェックされ、各チャンクが処理されます。 この時点で、以下が実行されます。すべてのアクティブなチャンク（プレーヤーから特定の半径内にあるもの）が順番に選択されます。 チャンクごとに、天気が処理され（雪が降り、稲妻が当たる）、ブロックのランダム処理が行われます-チャンク全体から数十個のランダムブロックが選択され、これらのブロックを更新する必要があるかどうか（ブロックタイプごと）がチェックされ、選択されたブロックで特別な関数が呼び出されます
• タイルは、偶然ではなく、ティックごとに処理される特別なブロックです。 これらのブロックには、炉（燃えている材料の状態を更新し、残りの燃料を、他のブロックのダニのように偶然ではなく均等に行う必要があります）、スポーンモブ（周囲にモブをスポーンするブロック）、ポーションのポーションなどがあります物事。 これらはすべてリストに保存されます。リストには、チャンクのロード時または操作中の新しいタイルのインストール時に入力され、各サイクルを順番に繰り返します。
• 緊急ブロック -もちろん、それらはそのように呼ばれませんが、それにもかかわらず、これらは「緊急に」、つまり、次のサイクルまたはわずかな遅延で処理される必要があるブロックです（サイクルでも、すべてがサイクルで、時間でさえカウントされます） アッラー ）、そして偶然ではなく、なぜなら ランダムブロックは、平均して数分ごとに1回処理されます。 それらはおよそタイルとして処理されますが、処理が必要なサイクル数の後、遅延によってのみ示されます。 処理タスクは、通常、プレーヤーのアクションまたは他のブロックのためにサーバー操作中に生成されます。 特に、これはレッドストーンの処理方法であり、外部の変化、火のブロック、流れる水などに非常に迅速に応答する必要があります。
• ライトの更新 -Minecraftは、ブロックに分割された静的な照明を使用します。 各ブロックには15から0までの独自の照明レベルがあります。ブロックを変更する場合、照明を再計算する必要があります。アルゴリズムはそれほど複雑ではありませんが、再帰的です。また、ブロック（トーチ、火など）と空からの2種類の照明もありますつまり、変更ごとに2回計算する必要があります（世界に空がある場合は、Netherにはありません）。
• エンティティはほとんどすべてのオブジェクトです。 モブ、プレイヤー、床に横たわっているオブジェクト、カート、ボート、絵画、稲妻、矢印など。 それらはすべて1つの大きなリストに保存され、tick（）関数が1つずつ呼び出されます。その後、死亡したかどうか、死亡した場合はチェックされ、リストとサーバーのメモリからそれぞれ削除されます。
• モブのスポーンも別のアクションです。 Mobはプレイヤーから特定の半径でスポーンし、チャンク内のランダムポイントが選択され、さまざまな方向のいくつかのシフトに基づいて、Mobをそこに配置できるかどうかが選択され、作成されます
• プレーヤーの処理 - プレーヤーを送信したすべてのパッケージを処理する必要があることは明らかです。
• チャンクのロードと生成 -メモリにないチャンクブロックにアクセスする場合、ディスクからロードする必要があります。ディスク上にない場合は、生成する必要があります。 ハードドライブがほとんど常にボトルネックであることを説明する必要はありません。 チャンクの生成は、ロードよりもさらに複雑です。
• チャンク保存 -一般的なサーバー保存中、または単にチャンクが長時間使用されずアンロードできる場合、チャンクをディスクに保存する必要があります-ストリームに変換してファイルに書き込みます。

すべてが正常であり、犯罪者はいないように思われ、すべてが非常にうまく行われ、追加するものは何もありません。 ここでの問題はこれです：これらはすべて1つのメインスレッドで処理されます 。 最近のバージョンでは、Mojangはマルチスレッドについて少し読んで、別のストリームでディスクにチャンクを保存する方法を学びました。 もちろん、これは画期的なことです。これは、ボトルネックの地獄だったからです。かなり前に、サーバーは15分間保存されていましたが、この時点で完全にハングアップしました。 ただし、問題は解決しません。

ここで問題は何ですか？ 非常に多くのことが行われます。1つのスレッド内のアプリケーションのメインロジックは、プログラミングするのに非常に便利で、同期や並列アプリケーションの他の問題を心配する必要はありません。 ここでの問題は、サーバーに標準の20サイクルではなく40人を超える場合、70人であれば15人、100人であれば10人、信じられないほどの価値があることです。 これは、私が実際に強力な6コアCore i7および64GbのRAMを持っているという事実にもかかわらずです！ また、12のフローのうち2つが強制的に占有されている場合、これらのリソースをどこに配置する必要がありますか？

私は話を怠りません。例を挙げます。
サーバーには223人のプレイヤーがおり、視界の半径は非常に小さく選択されています。46577個のチャンク、524個の「緊急」ブロック、87個のレッドストーンとピストンブロック、11240個のエンティティアイテム、4274個のエンティティ動物、19個のカートとボート、717個の他のエンティティプレイヤー、これもエンティティであり、適切な処理が必要です。
私のサーバーは情報にタイルの数と軽い更新を表示しません（私はこれを必要としません）が、あなたはそれらがたくさんあると信じることができます。

動物だけを処理するのは非常に難しいプロセスです-彼らは定期的に方法を検索し、周りの他のエンティティを検索し、AI（最新バージョンではかなり高度）を持っているので、4,000匹の動物の処理はすでに多くの作業です。

約300万ブロック（ほぼ同じ数のランダムブロックが非常に多くのチャンクで処理される）を取得することも簡単な作業ではありません。

11,000個のアイテムを移動し、他のアクションを実行し、プレーヤーに更新を送信する必要があります。

そして、これはすべて50ミリ秒で実行する必要があります。そうしないと、速度がサイクルで計算されるため、すべてが遅くなり始めます。 サーバーが1秒あたりのサイクル数を減らす必要がある場合、たとえば、mobはゆっくりとぎくしゃくと動き始めます。 サイクルでの計算の利点は明らかです。サーバーがフリーズしたり、巨大なガベージコレクションが発生した場合（サーバーがJavaである場合）、次のサイクルで最大速度で移動するカートが高速で移動する小さなオブジェクトに変わることはありません。洗練されたアルゴリズム。

同時に、ブキットもあります！
Bukkitは、バニラサーバーのラッパーです。 プラグインを作成するためのAPIが追加され、プラグイン開発者にとって非常に便利で、本当に高品質になります。 しかし、大まかに言えば、すべてが悪化しているだけです。 プレーヤーが少し動いたか頭を向けたパケットを送信すると...イベントが作成され、それを処理するすべてのプラグインに送信されます。 同時に、モーション処理機能はすでにかなり複雑です。 ブロックを壊したりインストールしたりすると、同じことが起こり、プレイヤーやサーバーが作成する約100のアクション（手を振る、レッドストーンの状態を変える、水を流す、Mobをスポーンする、AI、数千のアクションなど）システムは優れていますが、すべてを処理するときに追加の呼び出しが大量に作成されます。

幸いなことに、一部のプラグイン開発者は、プラグインの重いロジックを別のスレッドにプルすることを学びました。 明るくて良い例は、OreObfuscatorおよびDynmapプラグインです。 最初はプレーヤーに送信されたブロックを不要なデータから「クリーン」にし、プレーヤーが壁をチートできないようにします。 これを別のスレッドで行い、パケットをキューに入れて、サーバーロジックとは別に処理します。 2つ目は、ブラウザーの動的マップを生成し、これも非常に高品質になりました。 一般的に、メインストリームをそれ以上ロードしないことを称賛します。

サーバーがサイクルごとに処理するものの数を減らすプラグインもあります。 近くにあるオブジェクトを結合し、mobをアンロードし、チャンクの処理を制限します。 これは非常にクールで、このプラグインなしではサーバーは実行できません-NoLagg。

正しいやり方 （私の意見では）
1年半前にオンラインが100人に成長し、速度が毎秒0.5〜1サイクルに低下したとき、私たちはこれすべてに長い間苦しみました。 サーバーの最適化を試み、コードを修正し、可能な限り削除を試み、サイクルではなく数秒で作業を変更しました（たとえば、炉で。これは数ヶ月後にBukkitにも追加されました）。 最終的に、私たちはひどいサーバーの不安定性を達成し、これらすべてを吐き出すことにしました。

必要なだけ多くのプレイヤーに快適なオンラインを提供できる唯一のオプションは、スケーラブルなサーバーでした。 プロセスのフローはスケーラブルではなく、一度に1つのプロセッサコアでしか動作せず、そのパフォーマンスはカーネルのパフォーマンスによって制限されることを説明する必要はないと思います。 プロセッサのコアは現在非常に生産的ですが、多くの作業があり、プロセッサはマルチコアを実行しています。マルチスレッドを実行しない時間ではありません。

既存のサーバーを複数のスレッドに分割することはできません。 マルチスレッドプログラミングはデリケートで複雑なものであり、使用するコードに関する多くの知識を必要とし、実際には既存のアプリケーションに組み込まれていません。 コードは最初から作成する必要があります。

したがって、サーバーは可能な限り多くのストリームに基づいて生まれました。世界は64x64チャンクの断片に分割され、各断片は1つのストリーム、緊急ブロックを処理する1つのストリーム、レッドストーンとピストンの1つのストリーム、Mobの1つのストリーム、オブジェクト用のストリーム、カート用のストリーム、世界に関する他のエンティティやその他の情報を処理するストリーム、光を再計算するストリーム、世界のさまざまな地域の4つのストリームが世界をディスクに保存する、1つのストリームが地図をレンダリングする、1つのストリームがサーバーとコマンドを維持する qコンソール、統計を更新します。 プレーヤーの場合、パケット処理を各プレーヤーの個別のスレッド、スレッドプール、または各プレーヤーの個別のスレッドに設定できるシステムが使用されます。 同時に、すべてをさらにいくつかのスレッドに分割できます。少なくとも20の異なるスレッドで同じタイプのオブジェクトを処理します。 ネットワークエンジンとしてのNetty（NIO）と同様に、標準のI / Oとは異なります。

すべての機能を備えていないこのようなサーバーの安定版を開発するには、経験がなくても私だけで約8か月かかりました。 すべてのコードは、すべてのデータへの非同期アクセス用に設計されています。 しかし、それは価値がありました-つい最近、私たちは一箇所に立ち、ラップを撮影し、撮影しただけでなく、レッドストーンで非常に大きなイベントを経験し、同時に快適に感じた559人の記録を樹立しました。

このf話の教訓は次のとおりです：あなたのプロジェクトが少なくとも何らかの形で人気があると予想し、サーバー上に少なくとも多くの人がいる可能性があると少なくとも理論的に考えられる場合...スケーラブルなアーキテクチャを作成することをskiしまないでください。

あなたの腐ったトマト、この記事を改善するための提案、そしていつか来る次の記事であなたが見たいもののための提案を楽しみにしています。

思考の流れには、次のようなスペルミスが含まれる場合があります 一息で書かれました。