Java での高い同時実行性を解決する方法-＆＃＆チュートリアル-php.cn

高同時実行性を解決するための Java の方法: 1. コードの最適化; 2. 静的 HTML; 3. サーバーからのイメージの分離; 4. キャッシュメカニズム; 5. データベースクラスター; 6. ロードバランシング; 7. CDN アクセラレーションテクノロジ。

Java での高い同時実行性を解決する方法

Java における高い同時実行性は常に対処しなければならない問題であり、どうやって解決すればよいでしょうか?参考までにいくつかの方法を紹介します。

(推奨チュートリアル: java コース)

高同時実行性を解決するための Java のメソッド:

1、から最も基本的なところから始めて、作成するコードを最適化し、リソースの不必要な無駄を削減します。

a. 新しいオブジェクトの頻繁な使用を避けるアプリケーション全体で 1 つのインスタンスのみが必要なクラスの場合は、シングルトンモードを使用できます。 String 接続操作の場合は、ツールクラスの静的メソッドを通じてアクセスできる StringBuffer または StringBuilder を使用します。

b. 間違った方法の使用を避け、条件判定にinstanceofを使用しないようにしてください。 Java では、Vector よりも優れたパフォーマンスを持つ ArrayList などの効率的なクラスを使用します。

2. HTML の静的化

リンクアドレスを通じてアクセスします。このリンクアドレスを通じて、サーバーの対応するモジュールがリクエストを処理し、対応する JSP ページに移動します。 . 最後に必要なデータを生成します。しかし、リクエストが数千万件あり、同時リクエストが多すぎるとサーバーへの負荷が増大し、最悪の場合サーバーがダウンしてしまいます。では、この状況を回避するにはどうすればよいでしょうか? test.do の最初のリクエストの結果を HTML ファイルに保存し、ユーザーが毎回この HTML ファイルにアクセスするようにすると、サーバーにアクセスする必要がなくなります。サーバーへの負荷は大きくなりません。削減？

静的ページを自動的に生成するにはどうすればよいですか? ユーザーがそのページにアクセスすると、test.html が自動的に生成され、ユーザーに表示されます。

3. 画像サーバーの分離

Web サーバーの場合、画像が最も多くのリソースを消費するため、画像をページから分離する必要があります。別の画像サーバー上にあります。このようなアーキテクチャにより、ページアクセスリクエストを提供するサーバーシステムへの負荷が軽減され、画像の問題によるシステムのクラッシュが確実に回避されます。画像サーバーでは、さまざまな構成を最適化できます。

4. キャッシュ

私が特に触れたキャッシュメカニズムは、Hibernate のキャッシュメカニズムです。毎回データベースからデータを取得することを避けるために、ユーザーが頻繁にアクセスするデータをメモリに置きます。キャッシュが非常に大きい場合でも、メモリ内のキャッシュをハードディスクに置くことができます。高度な分散キャッシュデータベースも使用されており、システムのストレス耐性を高めることができます。

5. 一括送信

あるプロジェクトを進めていると、一度に送信するパラメータの数が多すぎるため、データベースで送信できるパラメータの最大数が規定されています。一度に送信できるのは 30,000 件ですが、当時は 50,000 件のレコードがありましたが、どうやって送信するのでしょうか?エレベーターが一度に多くの人を乗せられない場合、重量超過のバグが報告されるため、人々はまとめて送られます。

別の試験システムでは、非常に多くの受験者が同時にデータベースに提出すると、データベースへの負荷が増大し、データベースがダウンすることがありました。その際に使用された方法は、ajax を使用することでした。待ち時間のない非同期送信により、受験者が送信ボタンをクリックすると自動的に回答が送信されるため、突然の停電などで受験者が以前に行った質問が失われることもありません。

6. データベースクラスター

複雑なアプリケーションとそれにアクセスする多数のユーザーに直面すると、1 つのデータセットでは需要をすぐに満たせなくなるため、データベースクラスターまたはライブラリテーブルハッシュを使用する必要があります。

ビジネスモジュールとアプリケーションモジュール、または機能モジュールをアプリケーションにインストールしてデータを分離します。異なるモジュールは異なるデータベースまたはテーブルに対応し、特定の戦略に従って特定のページまたは機能をより小さなデータベースに分散します。

7. DB の最適化

a. データベースを設計するときは、後のメンテナンスも考慮する必要があります。データベースの 3 つのパラダイムは、データベースを設計するときに従うべき原則です。データベース。

b. インデックスの作成: インデックスの作成は適切である必要があります。テーブルが頻繁にクエリされ、追加や変更にはめったに使用されない場合は、追加や変更、削除操作のためにメンテナンスが必要なため、このテーブルのインデックスを作成できます。インデックスの効率は、インデックスがもたらす効率を大幅に上回っています。

c. テーブルフィールドのタイプの選択には、フィールドの長さとタイプなどが適切に含まれている必要があります。選択は、実際に保存されているデータに基づいて行う必要があります。長さは長すぎてはなりません。効率。

d. 主キーはこのテーブルを表し、外部キーはテーブルを関連付けるテーブルのグループを表すため、外部キーは注意して使用する必要があります。削除や変更などを行うときは、外部キーを関連付ける必要があります。。

e. データベース操作では、

PrepareStatement がプリコンパイルされているため、prepareStatement を使用し、ステートメントの使用量を減らすようにしてください。

接続は readOnly に設定されています。接続はライブラリへの接続であり、重量が大きいため、そのまま使用できます。

接続プールを使用すると、データベース内のデフォルトの接続数を変更できます。

8. 負荷分散

負荷分散は、高負荷のアクセスと多数の同時リクエストを解決する大規模な Web サイト向けのハイエンドソリューションになります。

負荷分散テクノロジーは長年にわたって開発されており、多くの専門的なサービスプロバイダーや製品から選択できますが、私は個人的にいくつかのソリューションに遭遇しており、そのうちの 2 つは参考として使用できます。

(1) ハードウェア 4 層スイッチング

4 層目のスイッチングでは、3 層目と 4 層目の情報パケットのヘッダ情報を利用して、適用間隔に応じた業務フローを識別し、全体の変換を行います。間隔セグメントビジネスフローは、処理のために適切なアプリケーションサーバーに割り当てられます。

第 4 層のスイッチング機能は、物理サーバーを指す仮想 IP のようなものです。送信されるサービスは、HTTP、FTP、NFS、Telnet、その他のプロトコルなど、さまざまなプロトコルに従います。これらのサービスには、物理サーバーに基づく複雑な負荷分散アルゴリズムが必要です。 IP の世界では、サービスタイプは端末の TCP または UDP ポートアドレスによって決まりますが、レイヤ 4 スイッチングでは、アプリケーションの範囲は送信元と端末の IP アドレス、TCP および UDP ポートによって決まります。

ハードウェア 4 層スイッチング製品の分野では、Alteon、F5 などの有名な製品がいくつかあります。これらの製品は高価ですが、お金を払う価値があり、提供できるものです。非常に優れたパフォーマンスと非常に柔軟な管理能力。「Yahoo China」には当初 2,000 台近いサーバーがありましたが、それを実行するために使用したのは 3 ～ 4 台の Alteons だけでした。

(2)、ソフトウェア 4 層スイッチング

ハードウェア 4 層スイッチの原理が誰もが知った後、OSI モデルに基づくソフトウェア 4 層スイッチングが登場しました。ソリューション実装の原理は同じですが、パフォーマンスはわずかに劣ります。ただし、ある程度のプレッシャーに耐えるのは簡単であり、ソフトウェアの実装方法は実際にはより柔軟であり、処理能力は完全に構成の習熟度に依存するという人もいます。

Linux 上で一般的に使用されている LVS を使用して、ソフトウェアの 4 層スイッチングを解決できます。LVS は Linux 仮想サーバーであり、ハートビートラインに基づいたリアルタイムの災害対応ソリューションを提供し、堅牢性を向上させます。また、柔軟な仮想 VIP 構成および管理機能も提供するため、分散システムに不可欠な複数のアプリケーション要件を同時に満たすことができます。

典型的な負荷分散戦略は、ソフトウェアまたはハードウェアの 4 層スイッチングに基づいて Squid クラスターを構築することです。このアイデアは、検索エンジンを含む多くの大規模 Web サイトで採用されています。このアーキテクチャは、低コスト、高パフォーマンス、強力なスケーラビリティにより、いつでもアーキテクチャにノードを追加または削除することが非常に簡単です。

大規模な Web サイトの場合、上記の各方法を同時に使用できます。ここでの紹介は比較的簡単です。特定の実装プロセスの多くの詳細については、全員が徐々に慣れて理解する必要があります。場合によっては、小さなsquidパラメータまたはApacheパラメータ設定がシステムのパフォーマンスに大きな影響を与える可能性があります。

9. ミラーリング

ミラーリングは、パフォーマンスとデータセキュリティを向上させるために大規模な Web サイトでよく使用される方法です。ミラーリングテクノロジは、さまざまなネットワークアクセスプロバイダーや地理的な問題を解決できます。 ChinaNet と EduNet の違いなど、ユーザーのアクセス速度の違いにより、多くの Web サイトが教育ネットワーク内にミラーサイトを構築するようになり、データは定期的またはリアルタイムで更新されます。ミラーリングの詳細なテクノロジに関しては、ここではあまり詳しく説明しませんが、専門的な既製のソリューションアーキテクチャと製品が多数あります。 Linux 上の rsync やその他のツールなどのソフトウェアを使用して安価に実装する方法もあります。

10. 最新: CDN 高速化テクノロジー

CDN とは何ですか?

CDN の正式名称は、コンテンツ配信ネットワークです。その目的は、既存のインターネットにネットワークアーキテクチャの新しい層を追加して、Web サイトのコンテンツをユーザーに最も近いネットワークの「エッジ」に公開し、ユーザーが近くで必要なコンテンツを取得できるようにし、Web サイトの応答速度を向上させることです。ユーザーの Web サイトへのアクセス。

CDN は、ミラーリングよりもインテリジェントであるため、ミラーリングとは異なります。つまり、CDN = よりインテリジェントなミラーリング、キャッシュ、トラフィック迂回という比喩を使用することもできます。したがって、CDN はインターネットネットワーク内の情報フローの効率を大幅に向上させることができます。技術的には、ネットワーク帯域幅の狭さ、ユーザーのアクセス数の多さ、コンセントの偏在などに起因する問題を総合的に解決し、ユーザーのWebサイトへのアクセスの応答速度を向上させます。

CDN のタイプ特性:

CDN の実装は、ミラーリング、キャッシュ、専用線の 3 つのカテゴリに分類されます。

ミラーサイトは最も一般的で、コンテンツを直接公開でき、静的および準動的データの同期に適しています。ただし、新しいサーバーの購入と保守のコストは比較的高く、ミラーサーバーをさまざまな地域に設置し、管理と保守のために専門の技術者を配置する必要があります。大規模な Web サイトの場合、更新のための帯域幅のコストも大幅に増加します。

キャッシュ、低コスト、静的コンテンツに適しています。インターネット統計によると、80% 以上のユーザーが Web サイトのコンテンツの 20% に頻繁にアクセスします。このルールの下では、キャッシュサーバーは顧客の静的リクエストのほとんどを処理できますが、元のサーバーはノンストップのリクエストの約 20% のみを処理する必要があります。リクエストと動的リクエストをキャッシュすると、クライアントリクエストの応答時間が大幅に短縮され、元のサーバーの負荷が軽減されます。

CDN サービスは通常、全国の主要ノードにキャッシュサーバーを配置します。

専用回線を使用すると、ユーザーはデータソースに直接アクセスし、データの動的な同期を実現できます。