このシリーズの以前の記事の分析と設計の後、独自のSDKサーバーの開発に成功しました。独自のデバッグ環境ではすべてが正常に動作しますが、もちろん、このSDKサーバーを正式な本番環境に展開することはできません. 正式な大規模プロジェクトの経験が少ない学生は、パフォーマンスの最適化と展開およびオンライン関連の設計が重要であることを知っておく必要があります.サービスにとって重要 ターミナルプロジェクトの重要性。これらの設計は、これまでの分析設計では考慮されていません。では、 SDKサーバーのようなアプリケーション シナリオでは、どの関連する最適化と設計に焦点を当てる必要がありますか?
データ アクセスの最適化
私たちのアプリケーション シナリオでは、ストレージを使用する必要があるシナリオは、主に次の処理にあります。
l 構成情報を取得する
受信したリクエストごとに、ソース ゲーム チャネルなどのさまざまな情報に従って、対応する構成情報を取得し、それを処理する必要があります。構成情報は頻繁にアクセスされますが、基本的に読み取り専用であり、処理中に変更されることはありません。
l 注文情報へのアクセス
支払いによって生成された注文メッセージの場合、サーバーの処理には注文の作成、注文のクエリ、注文ステータスの変更などが含まれます。データの処理には保存と読み取りが含まれ、2 つの操作の頻度は基本的に同じです。 .
l ログ情報の保存
受信したリクエストと生成されたエラーについて、サーバーはログを保存する必要があります.このアクションは純粋な書き込み操作であり、操作の頻度は比較的高くなります.
これらのタイプのデータについては、当社の処理戦略も異なります。
変更が少ない構成情報などの頻繁にアクセスされるデータは、アクセスをできるだけ高速化するために、通常はメモリに格納することを選択します。ただし、構成情報を構成ファイルとして保存すると、柔軟に管理することができません。さらに動的読み込みの構成要件を考慮すると、ここではメモリ キャッシュを使用してアクセスできます。つまり、アプリケーションの起動時に外部ストレージ ( DB ) から構成が読み込まれ、メモリに格納されて呼び出され、更新フラグをチェックすることで構成が定期的に更新されます。
注文情報は重要な構造化情報であり、間違いなくDBに格納する必要があります。しかし、以前のテキストで分析された支払い到着要求プロセスを振り返ってみると、このプロセスが処理効率に対して非常に高い要件を課していることがわかります。クエリの比較と配信プロセス全体を最短時間で完了できない場合、チャネルはゲーム サーバーの処理がタイムアウトしたと判断し、チャネルの注文再送信メカニズムをトリガーします。最悪の場合、前の処理プロセスが終了する前に、チャネルの次の再送信要求が再び到着し、システムの処理効率が急速に低下したり、クラッシュしたりする可能性があります。したがって、 DB のクエリ プレッシャーに耐えるために、注文用のキャッシュを構築する必要があります。これに関して、Redis Memcacheなどの市場に出回っている一般的なキャッシュ製品はこの要件を満たすことができ、特定の設計はここでは繰り返されません。
ログ情報は書き込み専用ですが、読み取り専用ではありません。すべてのログがDBに格納されると、 DBのパフォーマンスはスペースと効率の点で間違いなく不必要に消費されます。通常、ログをファイルの形式で保存することを選択します。さらに、この書き込み操作は非同期で処理する必要があります。そうしないと、パフォーマンスが大幅に低下します。非同期処理については後述する。
非同期処理
後でできることは後で行う必要があり、非同期処理はこの原則に基づいています。サーバー設計に固有のものとして、次のロジックを非同期操作として設計できると結論付けることができます。
l すべてのロギング操作
l DBへのほとんどの書き込み操作（注文ステータスの変更/注文情報の保存などを含む）
通常、読み取り操作は同期操作であり、 「クエリ リクエストが受信されたというメッセージを返し、クエリ結果を非同期的に提供する」という注文をクエリするリクエストを要求することはできません。
l 配信プロセス中に、 HTTP要求操作がゲーム サーバーと通信しました。
実際、非同期操作はSDK側またはゲーム側で実現して目的を達成できますが、ゲーム サーバー側で実装する方が合理的です。
具体的な非同期実装方法については、開発言語やツールの実装が異なるため、ここでは詳しく説明しません。
クラスター展開
Web サイトへの同時アクセスが多いシナリオでは、負荷分散テクノロジを使用して、アプリケーション用の複数のサーバーで構成されるサーバー クラスターを構築し、同時アクセス要求を複数のサーバーに分散して処理し、単一のサーバーの応答が遅くならないようにします。過度の負荷圧力により、ユーザー要求の応答遅延特性が改善されます。
クラスター展開と負荷分散テクノロジを使用する場合、繰り返し要求のフィルタリング、トランザクション処理ロジック、およびその他の設計など、アプリケーションを設計する際に並行処理の技術的な詳細に注意を払う必要があります。原則として、複数のサーバーの同時処理によって引き起こされるこれらの問題に注意を払うだけで十分です。
コードの最適化
コードの最適化の部分を最後に書いているのは、この部分が時代遅れのことでしかないからで、読者の皆さんも似たような最適化作業をされたことがあると思います。接続プール リソースの再利用、データ構造の最適化、ガベージ コレクション メカニズムの使用などが含まれます。ここでは、使用する開発ツールや言語に応じて、読者が実際に操作する必要があります。
サーバー設計のアイデアとアーキテクチャに関する一連のテキストはこの記事で終わります。次に、いくつかのテキストとコードを使用して、この一連のテキストで設計されたサーバーを実際に実装する方法を説明します。そして、実際のコーディングで遭遇する設計上の問題をどのように解決するか。そして、実際に問題を解決する過程で、より詳細な最適化方法についてさらに議論します。
このプロジェクトはオープン ソース化されています。興味がある場合は、独自の調査を行うか、プロジェクトを参照して独自の集計 SDK
プロジェクト アドレスを作成してください: https://code.csdn.net/typesdk_code
プロジェクト アドレス: https:// github.com/typesdk