Javaは、並行性の高いスパイクに対処します

ワン：問題

まず、検討する必要があり、高い同時実行に対処する方法です、友人を知るためにそこにある高並行性のボトルネックは確かに知っているデータは、データベース、売られ過ぎ、システムのクラッシュを動作させるための多数の要求に混乱となりますので、データベース内にあります、 MySQLのデッドロックのように。

2：アイデア

1.静的ページ：ページ全体をRedisの中に保存され、次回の訪問のRedisを読むためにページの値
CDN 2：主に静的リソースファイルは、画像など、CSS、JS、として、サイト全体を加速する（アリがチュートリアル行く参照）
3.数学符号ユーザ認証コード計算結果が同時に要求の数に低減することができ、圧力のRedisを減少は、MySQL、サーバ：。
4：株価指標は：これはRedisの在庫を識別することによって判断し、偉大な最適化され、このようなRedisの在庫を読むために中断不十分として、適切です。例：= map.get（goodsId）上ブーリアン、我々はキーによって読み取られたときに値がtrueのマップ場合、エラーがユーザ（「在庫不足」）（上）{返す場合に戻される Result.errorと、 .....}コードの唯一の2つの行を実行するための複数のリクエストにこの問題の後、以下の操作を入力することはできません。
5.動的なURLを生成：主に固定コモディティスパイクURLを通じて進めるため、悪意のあるユーザーを防ぐために、（この問題の安全面も、あなたは操作がない良いではない、次のこれらのセキュリティ対策を行っていない、軽視することはできません）
6. Redisのプレカット株式：商品のRedisでユーザースパイク（ここでは安心、Redisの、およびMySQLのデータが同期されている直接在庫スパイク時に保存されているのRedisを引く、その後、現在の在庫量を得るために行ってきました、ちょうどMQキュー操作に進みますが、次の完了しますインベントリデータは、MySQLを読まないように、単一、MySQLデータベースの数は、）を-1します。
7. MQメッセージ・キューは：それは、メッセージが消費者、事業運営にプロデューサが送信され、ユーザーがクリックは結果待ちをスパイクした後、生産者はその後、ポーリングクエリに行く、つまり、結果を知っている必要はありませんが、重要な中間体のメッセージですデータベース操作を繰り返し要求を回避することは、結果（非同期動作）を処理します。（ここで、ポーリングクエリが結果がクエリにキーによって、Redisのにスパイクした後、ポーリング時間成功したスパイクとなりますので、中に入るのRedisから直接クエリです）
nginxの8：私たちはTomcatのサーバーの数を増やすよりも、より高並行性を解決する良い方法。ユーザアクセス要求は、アイドル状態のTomcatサーバに提出することができた場合。
9.クラスタ・データベース、データベーステーブルのハッシュ

①大規模なサイトには、複雑なアプリケーションでは、データベースはすぐにアプリケーションを満たすことができなくなり、これらのアプリケーションはすぐに明らかにされるそして頻繁にアクセス、データベースのボトルネックに直面して、データベースを使用する必要があり、されているので、我々は使用する必要がありますデータベースまたはライブラリテーブルのハッシュ・クラスタ。

データベースクラスタの観点からマスター②、多くのデータベースは、独自のソリューションを持って、オラクル、Sybaseの他のものは、一般的にMySQLの/スレーブが提供する非常に良いプログラムを、持っている同様のプログラムである、あなたがDBの種類を使用し、対応を指しますソリューションを実現することができます。

③、上記データベースクラスタアーキテクチャので、膨張のコストは、DBタイプの使用を制限する条項の対象となり、私たちはシステムアーキテクチャを改善検討するアプリケーションの観点から必要、データベーステーブルのハッシュが一般的に使用され、最も効果的な解決策プログラム。

④我々は、機能モジュールを分離するためのアプリケーションやビジネスアプリケーションやデータベースをインストールし、そのようなユーザテーブルとページまたは機能上の特定の戦略も小さいハッシュデータベースに従って、異なるデータベースまたはテーブルに対応する異なるモジュール、ハッシュテーブル、ユーザIDに応じて、低コストでリフトシステムの性能ように、良好なスケーラビリティを有します。

10.ロードバランシング

ロードバランシングは、高負荷およびハイエンドのソリューションを使用して同時要求の数が多いアクセス対処する大規模なサイトです。

11.リバースプロキシ

直接サーバーにアクセスするためのサーバ、クライアントが直接サービスを提供していない、それはユーザーに結果を返し、その後、他のサーバーからリソースを取得します。

プロキシとリバースプロキシ：

プロキシサーバーは結果を返し、その後、私たちの訪問に代わってリソースへのアクセスです。たとえば、プロキシサーバーが外部ネットワークにアクセスします。私たちは、サーバーを訪問したときにリバースプロキシサーバーが正常で、サーバーは他のサーバー自身を呼び出します。

プロセスが完了し、ユーザーのためになるように、その後、負荷分散装置を介してユーザに返された後、そのリバースプロキシ、ロードバランシングデバイスを要求するユーザの要求に、負荷分散装置は、アプリケーションサーバプロセスを配布するためにアイドル要求を繰り返します後、分布は見えません。

リバースプロキシの実装

1）ユーザ要求を分配するロード・バランサの必要性は、ユーザは、アイドルを配信するサーバに要求します

2）サービスへのサーバの負荷分散装置に戻ります

3）負荷分散サービスは、サーバーにユーザーを返します。

私たちは、プロキシサーバーは、私たちのサービスのためのものです使用するためのイニシアチブをとる、独自のドメイン名を持っている必要はありません。自分のリバースプロキシサーバーを使用している、我々は知らない、独自のドメイン名を持っています。