優れたサーバーアーキテクチャを一般的な方法で説明するために、最も基本的で重要なことは、何百万ものプレーヤーを問題なく同時にオンラインでサポートすることです 。これらの2つのポイントは、それぞれ高い同時実行性と高可用性に対応します。
この記事では、ゲームサーバーの高い同時実行性と高可用性を体系的に紹介します。
高同時実行性と高可用性は補完的なタスクです。オンラインで数百万人のプレーヤーを同時にサポートしているが、サーバーの安定した可用性を保証できない場合、高同時実行性のサポートについて話すことは不可能です。サーバーで問題が発生することが多い場合プレーヤーの数が多い場合、高可用性とは言えません。
1.水平方向の拡張
水平拡張は、高並行性と高可用性の基盤です。水平拡張をサポートすることにより、理論的には、高並行性をサポートするマシンを追加することで無制限の負荷容量を取得できます。これに基づいて、プロセスが異常な場合は、他のプロセスに置き換えることができます。サービスを提供します。高可用性を実現します。
次の図は例です。水平方向の拡張をサポートしないアーキテクチャの場合、ゲームサーバーにはすべてのプレーヤーにバトルサービスを提供するバトルプロセスが1つしかありません。ここには2つの問題があります。1。プロセスはコンピューティングのみを使用できます。最大で1台のマシンのリソース。パフォーマンスには上限があります。2.プロセスまたはマシン/ネットワークに異常がある場合、システム全体が利用できません。
水平方向の拡張はサポートしていません
水平方向の拡張には、2つの一般的な実装モデルがあります。
- ロビーサーバーはすべてのバトルプロセスに完全に接続されています。バトルサービスにアクセスする必要がある場合は、マネージャーでサービスのプロセスアドレスを確認してから、直接プロセスに移動する必要があります。（左の写真）
- 戦闘プロセスの前にルートを吊るします。ルートは各戦闘の戦闘プロセスを記録し、関連するリクエストは対応するプロセスに転送されます。（右の写真）
水平方向の拡張の2つのモデル
1.1ステートフルvs.ステートレス
状態がプロセスメモリに保存されるかどうかの観点から、サービスはステートフルとステートレスに分けることができます。
- ステートフルサービス：状態はプロセスメモリに保存されます。たとえば、バトルサービスはバトル情報（プレイヤーキャラクターの状態、暴徒の状態など）をメモリに保存し、プレイヤーの操作またはバトルロジックによってバトル情報が変更されます。ゲーム内の状態はより複雑であり、ビジネスの変更の頻度が比較的高いため、ゲームのビジネスのほとんどはステートフルサービスの形で提供されます。
- ステートレスサービス：サービスはプロセスのみを処理し、データは保存しません。通常、データはバックエンドデータベースに保存されます。このサービスのロジックには、通常、多くのデータベース操作があります。このタイプのサービスは、ゲームで一般的なリチャージやログインなど、インターネットやWeb業界で広く使用されています。（ステートレスサービスには、プロセスの実行中にメモリに適用する一時変数がある場合があります）
ステートレスサービス自体は状態を保存しないため、プロセスがクラッシュしても情報が失われることはありません。さらに、以下で紹介するように、ステートレスサービスは、ランダムに割り当てられたルーティング方法を使用するため、例外に対する耐性が高くなります。したがって、高可用性の観点から、ステートレスサービスの方が優れています。
ただし、ステートレスは状態を保存しないため、すべての状態操作はデータベース操作であり、開発コストが高くなり（コードの記述が複雑になり）、データベースへの負荷が大きくなります。したがって、ステートレスはすべてのサービスに適しているわけではありません。 simple明確なサービスの場合、フレンドサービスなどのステートレスを最初に使用できます。
1.2ルーティング戦略
ステートフルサービスとステートレスサービスの場合、それらは異なるルーティング方法を使用します。
ステートレスサービスの場合、通常、ランダム ルーティングが使用され ます。ランダムルーティング方法には大きな利点があります。プロセスがクラッシュしたりネットワークに障害が発生した場合は、このプロセスをルーティングから削除するだけで済みます。後続のリクエストには影響しませんが、現在のプロセスにのみ影響します。処理ロジック。
ステートフルサービスのルーティングでは、各リクエストを処理するプロセスを指定する必要があります。他のプロセスには、関連する状態情報がないため、処理できません。たとえば、上記のバトルサービスでは、ルーティングはバトルIDに基づいて関連するリクエストを処理し、対応するバトルプロセスに送信できます。ルーティングは通常、 モジュラス または コンシステントハッシュを 使用し、障害によって引き起こされるジッターを防ぐために、モジュロの代わりにコンシステントハッシュを使用します。
1.3例を挙げてください
次の図は、ゲームアーキテクチャの簡略化されたモデルです。実際のサーバーは、これよりもはるかに複雑です。ここでの主な目的は、例を示すことです。
クラスターは、水平方向の拡張をサポートするステートフルサービス、水平方向の拡張をサポートするステートレスサービス、および水平方向の拡張をサポートしないシングルポイントサービスの3つのカテゴリに分類できます。
その中で、ステートフルサービスとステートレスサービスの水平展開をサポートするプロセスの数がプロジェクトの90％を占める可能性があり、シングルポイントサービスはほとんどありません。この種のアーキテクチャでは、ゲームの負荷制限のボトルネックはシングルポイントサービスにあり、シングルポイントサービスロジックは比較的単純で、負荷制限は非常に高くなります。また、水平展開をサポートするサービスプロセスの異常は、可用性の高いこのプロセスのサービスを受けるプレーヤーにのみ影響します。
ステートフルサービス
私たちのゲームのサーバークラスターでは、プロセスの約3分の2がプレーヤーの個人ロジックを処理するプロセスです（プレーヤークラスター、多くのゲームプロジェクトはロビーサーバーと呼ばれます）。各プロセスは、プレーヤーのビジネスロジックの一部を処理し、シェーディングを通じてプレーヤーをさまざまなプレーヤープロセスに分散します。
パーソナルロジックプロセスの数を増やすことでサーバー容量を増やすことができ、プロセスの継続的な増減、つまり動的な拡張と縮小をサポートします。、これらのプロセスは同等であり、異なるプロセス間に強い依存関係はありません。プロセスがクラッシュしても、他のプロセスのプレーヤーには影響しません。
プレイヤープロセスに加えて、この方法で設計できるバトルプロセス、ファミリープロセス、およびその他の同様のプロセスがあります。
上記はすべてステートフルサービスです。各プレイヤー/ファイト/ファミリーがどのプロセスにあるかを記録する必要があります。さらに、プロセスが異常な場合、他のプレイヤー/ファイト/ファミリーには影響しませんが、現在のプロセス/ファミリーは利用できなくなり、一部のデータが失われます。
ステートレスサービス
ログイン、支払い、友達、一部のリーダーボードなど、一部のサービスにはステートレス実装を使用しています。ステートレスサービスは、ステートフルサービスよりも例外や単純な動的拡張および縮小モデルに適しているため、新しいサービスにはステートレスサービスの使用を優先し、状態がより複雑な場合はステートフルサービスの使用を検討します。
シングルポイントサービス
プレーヤーマネージャー、クラスターマネージャー、ファミリーマネージャーなど、ゲームサービスにシングルポイントサービスが存在することは避けられません。これらのサービスにはスケーラビリティがなく、ゲームサーバーのボトルネックになっています。また、高可用性はありません。例外が発生すると、ゲームクラスター全体が使用できなくなります。
シングルポイントサービスロジックは一般的に単純であり（複雑なロジックは水平方向の拡張をサポートする必要があります）、パフォーマンスの負荷は一般的に高くなります。たとえば、現在のゲームの評価とオンラインの控えめな見積もりは50ワットである必要があります。現時点では、一部のシングルポイントサービスが完全に読み込まれ、ゲームを拡張し続けることができなくなると考えています。
また、シングルポイントサービスの数が少なく、異常の可能性も低いです。私たちのゲームはほぼ2年間オンラインであり、マシンのダウンタイムは2回しか発生していません。これは、シングルポイント以外のプロセスに影響し、ゲームクラスター全体の可用性には影響しませんでした。
もちろん、単一のサービスポイントを変更して水平方向の拡張をサポートすることもできます。これはワークロードの問題です。理論的には、単一のポイントを完全に排除できるというものですが、ほとんどのプロジェクトでは、コストパフォーマンスは高くなく、重要性はほとんどありません。
2、高い同時実行性
水平方向の拡張スキームは、上記で紹介した高い同時実行性（スケーラブルなスケーラビリティーとも呼ばれます）をサポートするための主な手段です。
以下では、主に水平統合と高並行性以外のソリューションと注意が必要な点を紹介します。
2.1垂直方向の拡張とパフォーマンスの最適化
収容力を向上させるには、一般的に2つの解決策があります。
- 水平拡張：機械の数を増やすことにより、運搬能力を高めます。
- 垂直方向の拡張：機械の構成を増やすことにより、収容力を増やします。1台のマシン/スレッドがより多くのプレーヤーを運ぶことを許可します。
垂直方向の拡張は、特定のシナリオでも役立ちます。一般的に、前述のシングルポイントの場合、除去が容易でない場合や除去コストが高い場合は、このロジックを垂直方向に拡張して注目度の高いマシンに配置し、シングルポイントロジックの負荷を増やすことができます。
さらに、C ++で高消費モジュールを作成するなど、戦闘服のパフォーマンスを最適化することがよくありますが、通常、ロビーユニフォームの耐荷重能力を向上させる主要な手段としては使用しません。これについては詳しく説明しません。一方では常に上限があり、質的に変更することは困難です。一方、ゲームの最適化スキームは大きく異なり、すべてコードレベルの最適化です。
サーバー側の最適化の目標は、1台のマシンでより多くのプレーヤー/ロジックを実行できるようにする垂直拡張の目標と似ています。
2.2システムの単一点と論理の単一点を排除する
上記で紹介したシングルポイントの排除は、主にシステムのシングルポイントです。つまり、1つのプロセスではなく、複数のプロセスを使用してサービスを提供します。
システムの単一点を排除することの前提は、論理的な単一点を排除することです。
例：武器をドロップするとき、武器を識別するために武器の一意のIDを生成する必要があります。このIDは、論理的な単一ポイントを作成する自動インクリメントIDを使用できます。
この場合、ゲーム内の武器生成の頻度が非常に低い場合、この解決策も可能ですが、武器生成の頻度が高い場合、ゲーム内のすべてのロジックを1つの場所に移動して、これを適用する必要があるためです。 ID、ボトルネックになる可能性があります。この場合、通常、自己インクリメントIDの代わりにuuidを使用できます。（このシナリオは、DBの自動インクリメント列でも一般的であるため、通常、自動インクリメントを少なくすることをお勧めします）
2.3データベースホスティング
オンラインのプレーヤー数が特定のレベルに達すると、バックエンドデータベースに大きなプレッシャーがかかることがよくあります。
一般的に、データベース自体は水平方向に拡張する機能を備えており、データベースサブテーブルなどのソリューションを追加することで、環境収容力を向上させることが容易になります。ただし、データベース構造を設計する際には、インデックスやシャドウキーなどの問題も考慮する必要があります。そうしないと、データベースのパフォーマンスに深刻な影響を及ぼします。さらに、データベースの同時読み取りおよび書き込み機能を検討してください。たとえば、mongoのMMAPv1ストレージエンジンはドキュメントレベルのロックであり、WiredTigerストレージエンジンはコレクションレベルのロックです。2つの同時実行機能は非常に優れています。違います。
ゲームロジックは一般的に複雑で、データの読み取りと書き込みの量が多くなります。プレーヤー情報が変更されるたびにデータベースの読み取りと書き込みが行われると、データベースへのプレッシャーが大きくなります。したがって、ゲームプレーヤーサービスは一般的にステートフルサービスです。プレーヤーはオンライン時にデータベースからメモリにデータを読み取ります。オンライン期間中のデータの読み取りと書き込みはすべてメモリを直接操作し、オフライン時または期間後にデータベースにアクセスします。時間の。このソリューションにより、データベースの読み取りおよび書き込み操作が大幅に削減され、データベースへの負荷が大幅に軽減されます。
データの読み取りおよび書き込み操作の頻度が低い一部のサービスでは、サービスをステートレスにして、読み取りおよび書き込みのたびにデータベースを操作することを検討できます。
2.4マルチクラスターおよびクロスクラスター
ゲームサーバーが特定の規模に達すると、多くの場合、クラスターにデプロイする必要があり、シナリオはクラスターによって解決されます。
- 単一クラスターの負荷容量には上限があります。たとえば、skynetは256プロセスのみをサポートします。
- マルチゾーンサーバーの要件。各クラスターはゲームのゾーンサーバーに対応します。ゲームがマルチリージョンサーバーをサポートし、サーバー間の通信なしで完全に分離されている場合、高い同時実行性を実現するのははるかに簡単です。
- グローバルサービス、一部のクラスターはプレイヤーのエリアに展開することを望んでいます。たとえば、アメリカのプレイヤーが使用する戦闘服は米国に配備され、東南アジアのプレイヤーが使用する戦闘服は東南アジアに配備され、特定の場所に配備されたロビーのユニフォームを共有します。
マルチクラスターで解決する必要のある問題の1つは、クラスター間通信の問題です。クラスターは通常、プロセス間で完全に接続されていますが、プロセスがクラスター間で完全に接続されている場合、トポロジは無秩序になり、接続数が爆発的に増加します。したがって、クラスター間の通信は通常、メッセージバスを使用します。クラスターはメッセージバスを介して通信します。
2.5一時的に高い同時実行性
ゲームビジネスのシナリオでは、プレイヤーのオンラインと時間、アクティビティなどは密接に関連しており、異なる時間のオンラインの数は数回から数十回異なる場合があります。
予想される高トラフィックについては、事前に容量を拡張することで伝送できます。「Ninzoのサーバー最適化」の「動的拡張と削減」を参照してください。
予期しない瞬間的な高い同時実行性の場合は、キューイングシステムを使用してシステムからのトラフィックをブロックし、動的拡張後にゆっくりとゲームに参加できます。
2.6戦闘シナリオでの高い同時実行性
このゲームには、大規模なMMOプレーヤーが国家戦争などの特定のシーンに集まる特別な同時実行シーンもあります。
このシナリオに完全な解決策はありません。収容力を可能な限り増やすことしかできません。一般的な改善策は次のとおりです。
- シーンをセルに分割し、さまざまなセルをさまざまなプロセスに配置します。bigworld / kbengineや最新のSpatialOSなど。
- 単一プロセスの収容力を向上させます。たとえば、ロジックの最適化、垂直方向の拡張、C ++を使用したゲームロジックの記述などです。C++とPythonの間には、パフォーマンスに桁違いの違いがあります。
- サービスのダウングレード：ゲームロジックを簡素化します。たとえば、国内戦争中は、シーンが活気に満ちているとプレイヤーが感じている限り、ほぼ同じです。実際、多くの戦闘ロジックが簡素化されています。
- サブサービス/サブライン/サブダンジョン：プレーヤーがビジネスで孤立できるようにします。
水の風：ゲームの数値システムの実現と進化
3、高可用性
可能な限り少ないシステムサービスを実行する過程での高可用性システムの追求は利用できません。
評価指標は、サイクル内のサービスの利用可能時間（SLA、サービスレベルアグリーメント）であり、計算式は、サービスの可用性=（サービスサイクルの合計分数-利用できないサービスの分数）/サービスサイクルの合計分数×100％です。 。
通常、2つの側面から評価されます。1。システムは完全に使用可能です。すべてのサービスはすべてのユーザーが利用できます。2.システムの全体的な可用性：一部のサービスまたは一部のユーザーは利用できませんが、システム全体は利用できます。
高可用性の目標は、システムの完全な可用性を追求し、全体的な可用性を確保することです。
大規模なクラスターでの例外
マシン障害、ネットワークジャム、切断などの異常な状況の可能性が低いため、サーバーはこれらの問題も考慮する必要があります。特に、小さな確率のイベントが高確率のイベントに蓄積される大規模なクラスターのシナリオでは、サーバーシナリオでは、高可用性は考慮しなければならない問題です。
高可用性とは、実際にはさまざまな異常状態を分離して処理することであるため、確率の低い異常イベントがゲームのサービス全体に影響を与えることはありません。
一般的な例外は次のとおりです。
- マシン/プロセス/ネットワークの異常：Alibaba Cloudマシンの可用性は99.975％と約束されています。つまり、各マシンは1時間以内に1年間使用できなくなることが保証されています。クラスタが100台のマシンを使用している場合、理論的には最悪のケースは、3日ごとに1時間1台のマシンが使用できないことです。もちろん、実際の可用性は、Alibaba Cloudが約束したものよりもはるかに優れています。私たちのゲームには約100台のECSマシンがあり、1年にマシン障害のために2台のマシンが自動的に再起動し、継続的な可用性はありませんでした。
- Saasサービス/ DBの例外：Alibaba Cloudのmysqlやredisなどのクラウドサービスを多数使用しているため、これらのサービス自体にも可用性の問題があり、マスタースレーブの切り替えなどが発生します。私たちのゲームで遭遇する最も一般的な問題は、redisマスタースレーブスイッチがネットワーククラッシュを引き起こし、ネットワークの再接続を必要とすることです。
- ビジネスバグ：ビジネスバグの場合は、バグの影響を減らし、小さなバグがシステム全体を使用できなくなるのを防ぐようにしてください。
- 突然のパフォーマンスのホットスポット：プレーヤーの正常または異常な動作によって引き起こされる突然の忙しいビジネスは、主に上記の高い同時実行性の問題です。さらに、一部のプレーヤーの異常な動作（プラグイン\ DDOS攻撃など）については、システムの全体的な可用性に影響を与えないようにする必要があります。昔（伝説の時代）、一部のプラグインはサーバーを直接再起動できたのを覚えています。
3.1水平方向の拡張に基づく高可用性の実現
水平方向の拡張により、同時負荷容量が増加すると同時に使いやすさが向上する可能性があることは前述しましたが、焦点は異なります。同時実行性が高い場合、水平拡張とは、マシン/プロセスを追加することで容量を増やすことができることを意味します。高可用性の場合、マシン/プロセスが異常またはクラッシュしても、クラスターの全体的な可用性に影響を与えないことを意味します。
上記の水平展開で述べたように、水平展開をサポートするサービスの場合、サービスの異常状態は、このプロセスによって提供されるサービスと他のプロセスの通常の動作にのみ影響します。ステートレスサービスの場合、影響は小さくなり、実行中のプロセスにのみ影響します。
もちろん、これには次のような処理ロジックを作成する必要があります。
- 異常な監視：異常な監視により、通常はハートビートまたはメッセージタイムアウトメカニズムを使用して、異常をすばやく見つけることができます。
- 例外処理：たとえば、メッセージがタイムアウトした後の処理方法、注意を払うか無視するかなど。プロセスが利用できない場合は、このプロセスをクラスターから追い出す必要があります。
- サービスの回復：ステートレスの場合は、再起動するだけです。ステートフルの場合、状態を他のプロセスに移行してサービスを提供できます。サービスの復元（よりステートフルなサービス）には多くの落とし穴があります。サービスプレーヤーを直接キックオフしてから再度ログインするなどの一般的な復元スキーム。
- サービスの低下：サービスの低下と指定された機能の終了のための一般的なキューイングシステム。
上記のロジックの実装方法は実際には非常に複雑なので、ここでは詳しく説明しません。
サービスの分離とグレーリリース
開発プロセスでは、大きな機能を可能な限り小さなサービスに分割する必要があり、各サービスは小さな機能のみを担当します。Skynetは、より優れたサービスモデルも提供します。さまざまなサービスを1つのプロセスまたはさまざまなプロセスに配置できます。
前回の記事では、サービスの分離とグレースケールリリースについて紹介しました。また、問題が発生してもシステムの全体的な可用性に影響を与えないように、リスクの高いサービスを分離することも目的としています。
3.2マスタースレーブレプリケーション
ステートフルサービスの場合、水平展開をサポートするプロセスは、あるプロセスの例外がサービスを提供する他のプロセスに影響を与えないようにすることができますが、このプロセスがクラッシュすると、このプロセスによって提供されるサービスが使用できなくなり、データなどの問題が発生します。メモリの損失。
これを解決するための一般的な解決策は、マスタースレーブレプリケーションです。マスタースレーブレプリケーションはデータベースで非常に一般的であり、データベースの高可用性を確保するための一般的なソリューションです。
マスタースレーブレプリケーションでは、1つ以上のスレーブノード（スレーブ）をマスターノードの後ろに吊るし、マスターノードはステータス/データをスレーブノードにリアルタイムでレプリケートします。通常、マスターノードがサービスを提供します。マスターノードに問題が発生すると、スレーブノードがマスターノードになり、サービスを提供し続けます。マスターノードはほとんど実際にデータをスレーブノードに複製するため、データが失われないことをほぼ保証できます。
したがって、ステートフルサービスまたはシングルポイントサービスの可用性をさらに向上させたい場合は、マスタースレーブレプリケーションスキームを使用できます。
ゲームサーバーはこのソリューションを使用してより少ないビジネスロジックを記述し、一部のクラスター管理ノード（非ビジネスロジック）はこのソリューションを使用します。
さらに、共通のデータベース（mysql / mongo / redis）には独自のマスタースレーブレプリケーションがあるため、ステートレスサービスは実際にデータベースに状態を管理させ、データが失われないデータベースマスタースレーブレプリケーションの機能を取得します。 。
3.3クラウドサービスの例外処理
ECSマシンに加えて、redis / MySQL / MongoなどのDBやELKと同様のログサービスなど、AlibabaCloudのさまざまなSAASサービスを幅広く使用しています。
これらのサービスのほとんどは、マスタースレーブ切り替えなどの高可用性ソリューションをサポートしていますが、マスタースレーブ切り替えを実行するときのシステムへの影響を考慮する必要があります。
MysqlとRedisでは、マスタースレーブスイッチまたはゲートプロキシに障害が発生すると、ネットワーク接続が切断されるため、ネットワークの中断を処理し、ロジックで再接続する必要があります。ネットワークの切断と再接続のフェーズでは、特定のdb要求が必然的に失敗し、この異常な問題にも対処する必要があります。
データランディングシナリオでは、各db要求が成功したかどうかを判断する必要があります。成功しなかった場合は、再試行して要求のべき等性を確認し、要求が複数回実行されないようにします。
第4に、高い同時実行性と高可用性の目標
高い並行性と高可用性を実現するために、開発コストが比較的高く、ほとんどのプロジェクトで人的資源に制限はありません。したがって、関連する作業を行うときは、過剰に設計し、ビジネスニーズを包括的に考慮し、期待を持ち、開発コストを負担する必要があります。
実際、私が話している開発コストは、プログラム開発の量が多いだけでなく、システムが複雑になるほど問題が発生しやすくなることです。テスト、保守、反復するのに十分な人員がない場合は、より良いです。それを達成するためのより簡単な方法を使用すること。問題の可能性は低くなります。
もちろん、プロジェクトチームが国王の栄光であり、平和のエリートである場合、高い同時実行性と高可用性の要件は非常に高く、人員はほぼ無制限です。この段落は無視してください。
何百万もの同時オンライン
ゲーム業界では、100万の同時オンラインがゲームサーバーアーキテクチャの同時目標と一般に見なされており、100万の規模もほとんどのゲーム（キングとチキンを除く）の上限です。
したがって、ゲーム前のアーキテクチャの設計、計画、およびストレステストでは、ベンチマークとしての数百万の同時オンラインに基づいて、さまざまなシステムに必要な容量を見積もることができ、この容量に達するには十分です。
たとえば、私たちのゲームでは、多くのシングルポイントとパフォーマンスのボトルネックがありますが、私たちの見積もりによると、これらのシングルポイントが存在する場合でも、100wにマシンサポートを追加することで同時にオンラインにすることができます。次に、これらの単一のポイントとボトルネックは私たちの期待の範囲内であり、これ以上最適化することはありません。
ある日、オンラインで数千万のゲームを同時にサポートする必要がある場合、理論的にはシングルポイントを排除し、パフォーマンスのボトルネックを最適化することができますが、コストは大幅に増加します。
高可用 != 完全可用
サーバークラスターの高可用性の追求は、すべての例外に対して災害耐性を必要としません。それは不可能で非現実的です。
スカイネットの考えによれば、ノードがタイムリーに応答しない場合、ノードにアクセスするためのすべての要求はタイムアウトなしでブロックされます。ノードがダウンしている場合は、トレースを直接報告します。これは、Skynetがクラスター全体を認識し、フォールトトレラントメカニズムを備えていないことと同等です。コアノードに障害が発生した場合、クラスター全体が使用できなくなるはずです。
上で述べたように、全体として、事業開発中の思考の負担を効果的に減らすことができるスカイネットのアイデアに同意します。これに基づいて、いくつかの一般的な異常については、雪崩効果を回避するために影響を最小限に抑える必要があります。
テクノロジーを超えた高い同時実行性と高可用性
高い同時実行性と高可用性は、運用および保守機能、ハードウェアの状態、人員の品質、管理レベルなどの非テクノロジーとの関係も大きくなります。
高い同時実行性を解決するには、大規模なクラスターを展開する必要があります。これにより、運用および保守機能に対する要件が高くなります。ユーザー数が少なく、クラスターが小さい場合は、手動の操作と保守を使用できますが、クラスターの規模と複雑さが増すにつれて、手動の操作と保守はますます困難になり、ツールと自動化が必要になります。
ゲームシステムの問題の多くは、実際には、Zhan Shuangがオンラインになった後の特典の誤配信など、運用と保守、プロセス、および仕様の問題が原因で発生します。
したがって、高い同時実行性と高可用性を実現するには、運用と保守のツール、運用と保守の手順と仕様を人の操作と保守なしで適切に実行し、運用と保守をツール化して自動化する必要があります。また、大規模システムの安定運用には、要員の監視、警報、迅速な対応も必要条件です。
誰もが高い並行性を学び、使用するのに役立つことを願っています。私のお気に入りの友達は、ワンクリックと3つのリンクでお手伝いできます。ありがとうございます。