I.概要
高並行システムは、このような第二の同時ミドルウェア・システム、ゲートウェイシステム毎日百億要求メガビットとして、異なる、第二の瞬時あたりの要求の数千人の大きなプロモーションシステムの何百ものスパイク。彼らは高い同時実行に対処する場合、異なるシステム独自の特性を持つそれぞれが、そのアーキテクチャに対処するため、同じではありません。
また、並行性の高いシナリオでの注文システム、商品システム、在庫管理システムアーキテクチャ設計で、このような電子ビジネスプラットフォームは、異なっているため、異なるものの舞台裏事業。
記事には、このような質問への答えが考えている、それは複雑なアーキテクチャ設計を必要としない提供します。
第二に、最もシンプルなシステムアーキテクチャの1
お使いのシステムは、単にデータベースに接続し、その背後にあるマシン上に展開され始めていると仮定すると、データベースは、単一のサーバーにデプロイされます。たとえば、お使いのシステム展開マシンは4コア8Gで、データベース・サーバは、16コア32Gです。
このとき、異なるシステムの状況に応じて差別化加入者10万人、登録者数、日活のユーザーの合計にあなたのシステムを想定し、我々はより客観割合、それの10％、毎日のアクティブユーザー10000を取ります。28には、法律の定めるところにより、毎日のピークは4時間をカウントし、アクティブユーザーのピークはそれが4時間でアクティブ8,000人で、80％を占めました。次に、あなたのシステム上の誰もが要求を開始し、我々は彼が正しいと20回の日を数えます。その後も4時間以内（14400秒）を平均化する毎秒もわずか16万回、毎秒10個の要求8000-開始した要求のピーク。同時実行性の高い完全な権利、シェアを取りますか？次に、システム・レベルは、第2の要求あたり10回でデータベースにそのようなCRUD等を行うよう要求ごといくつかのデータベース操作を呼び出します。だから我々は、これはデータベース層は右、また、1秒間に30のリクエストの場合であることを、最初の要求は、データベースがそれを要求した3回に対応取りますか？この構成データベースサーバーのサポートによると、全く問題ありません。ビュー示すと、上述したシステムは、これは以下の通りです。
最も簡単なシステムアーキテクチャの一つ
第三に、システムクラスタの展開
登録ユーザーの量を500万台に上昇し、50倍に増加など、ユーザーが急速な成長を開始すると仮定すると。この時点日活50万ユーザー、秒あたりの要求のピーク時には、システムは、500 / sです。そして、第二の数あたりのデータベース要求は何が起こるか、この時間、1500 / sのでしょうか？
お使いのシステム内の処理は、いくつかのビジネスロジック、ビジネス・ロジックが重いシステムの一種である、より複雑である場合は、上記のマシン構成によると、その後、比較的時間のかかるCPUです。
この時点で、毎秒4コア8G要求はマシンが500 / sに達したとき、あなたが高いCPUがマシンをロードしていることがわかります可能性があります。次に、データベース・レベルは、上記構成の点で、実際には、実質的にその後まだ許容1500 / S要求圧力ピーク。
これは、データベースのディスク負荷、ネットワーク負荷、CPU負荷、メモリ負荷マシンを観察するために主に、当社のオンライン経験に基づいて、構成データベースには、1500 / sの要求に圧力下に問題はありません。
だから今は、最初は、あなたのシステムクラスタの展開をサポートすることで、事を行う必要があります。あなたは、負荷分散層の前にハングアップすることができ、要求は、均一なシステムレベルのヒット、システムは、複数のクラスタ化されたマシンを使用することができ、より高い同時実行性の圧力をサポートしています。
例えば、システムは、機械の配置、各マシンのみ250リクエスト/秒のものとします。その結果、2台のマシンが大幅にCPUの負荷を軽減します、この最初の「高い同時実行」は、第1のカバーにそれを生きる上ではないのですか？
でも、これが行われていない場合は、極端な場合には、その単一のマシンの負荷が高いと高いが、要求に対応するための十分なリソースを持つことができないマシン上でシステムを展開することが可能である、との要求も、システムのダウンタイムの、こだわって表示されたとき問題のクラス。
だから、簡単な概要は、まず最初に行うには、システムはさらに、床を打つ要求します、層の負荷分散を追加することです。
複数のマシンのクラスタの展開、カン朱予備同時圧力を使用してシステム層。このアーキテクチャ図では、次のように次のようになります。
負荷分散層を追加します
第四に、データベースのサブライブラリーの別々の読み取りおよび書き込みサブテーブル+
、利用者の数は増加し続けていることを仮定すると、千万の登録ユーザーに達し、その後、毎日一万人のユーザーの日常生活です。したがって、この時間は、システム・レベルの要求量が第2 / sで、システムレベルごとに1000に達するだろう、あなたは道、とにかく、前負荷分散層が均一に分散フローの過去によって拡張をクラスタ化し続けることができます。
しかし、要求の量が許容可能なレベルデータベース3000 / sで、この小さな問題に到達します。同時要求のデータベースレベルが倍増し、この時点で、あなたは、オンラインデータベースの負荷が増加しているでしょう。たびに、圧力のピークは非常に高く、ディスクIO、ネットワークIO、メモリ消費量、CPUの負荷となり、私たちは、データベースサーバがカン朱ができることを非常に心配しています。
一般的には、一般的な構成のためのオンラインデータベースの種類は、上の例の構成ではない3000 /秒以上によると、同時読み取りおよび書き込みを一緒にすることをお勧めします。データベースすぎる圧力ので、最初の問題は、データベースの負荷の性能が高すぎるへの影響、ピーク・システムの性能が低下することができるです。もう一つ、圧力は、データベースがハングアップするかもしれない、あまりにも素晴らしいです。
したがって、この場合には、システムがサブライブラリーの別々の読み取りを行うと、+書き込みにサブテーブルを持っている必要があり、それがデータベースの複数のサービスに配備複数のライブラリ、プライマリ・データベースの書き込み要求ベアラのためのライブラリを分割することです。各一次ライブラリーは、その後、リードベアラによって要求されるライブラリから、ライブラリからの少なくとも1つに取り付けられています。
このとき、同時読み取りのレベルとは、データベースが同時書き込みが1000 /秒を占め/秒、3000で書くと仮定して、同時読み取りは、2000 /秒を占めました。サブライブラリーは、サブテーブルは、書き込み要求の両方をサポートするために、データベース・サーバ上のプライマリ・データベースを展開するために使用されると、各サーバは、500 / sの同時ホストされている書き込み。それぞれは、ライブラリーからの2回の同時読み取りが1000 / sの各ライブラリからライブラリサーバーの展開からメインライブラリーサポートされていますマウント。
要約、並行処理の量は成長し続けたときに、私たちはデータベースレベルで焦点を当てる必要があります：サブライブラリーのサブテーブル、独立した読み取りおよび書き込み。このとき、図1に示す構造は次のとおりです。
データベースレベル
第六に、導入されたキャッシュ・クラスタ
登録ユーザーの量が増えている場合は、ノンストップマシンを追加することができ、このようなシステムレベルとして、常にマシンを追加して、あなたは、より高い要求を同時に運ぶことができます。サブライブラリーサブテーブルを通じてますます高く、プラス拡張上のデータベース・サーバーの書き込み並行データベースレベルは、より多くのを読んで、データベース・レベルで同時場合、マシンの拡大を支援する場合、拡張ライブラリからの多くを追加します。
しかし、大きな問題があります：データベース自体は、実際にはそれほど一般的に数千人のために、第2のあたり、同時データベースシングルキャリアを話すと、マシンが使用するデータベースが比較的高い知名度あり、高い同時要求を運ぶために使用されていません、より高価なマシンが、コストが高いです。あなたは、単にマシンの追加を停止した場合、実際には、それは間違っています。だから、多くの場合、キャッシュシステムが生まれ、高い同時実行を運ぶことで、設計キャッシュのこの部分で並行性の高いアーキテクチャを有します。
数万毎秒実施同時単量、数百秒あたり数千から、データベースシステムよりも能力を保有する同時高い負荷が1〜2桁よりも高くします。そのため、システムの事業特性に応じて、以下の読み取りとより多くの要求、キャッシュ・クラスタの導入を書くの種類の。
具体的には、キャッシュ・クラスタへの書き込み時にデータのデータベースを作成し、その後、読み取り要求のほとんどをホストするためにキャッシュ・クラスタを使用すると同時に、です。この場合は、キャッシュ・クラスタによって、マシンは高い並行性を運ぶより少ないリソースを使用することができます。
「データベース・レベル.JPG」、読み取り要求は、/ sの毎秒現在それぞれが1000 / sの要求を読んますが、毎秒1800回が可能であり、読み出し要求が直接キャッシュではありません読み取ることができます運ぶライブラリから2 2000どのようにデータの変更。一度キャッシュ・クラスタ・ケースを導入し、これは抗ダウンすることができ1800 / sの読み出し要求を、読み出し要求、データベースレベルでは200 / sに落ちました。このとき、図1に示す構造は次のとおりです。
キャッシュ・クラスタ
アーキテクチャ上の利点は何ですか、それは？
将来的には、システムは、毎秒何千回もの数十に到達するための要求を読み取って、おそらく80％〜90％がキャッシュ・クラスタによって読み取られ、クラスタ内のキャッシュは、秒あたりの要求を読んでスタンドアローンもマシンの数万人をサポートすることができますので、消費する機械いくつかのリソースは、2つまたは3つのマシンに十分であろう。データベースが交換された場合、それは10から増加するライブラリを維持するために必要な場合があり、同時カン朱の数万人に20台のマシンは毎秒読んで、コストが非常に高いです。
簡単に言えば検討して、キャリアハイの同時別のポイントをまとめました。
- 拡張ではない盲目的データベースは、データベース・サーバは高価であり、それ自体が高い同時実行を運ぶために使用されていません。
- 少ない書き込み要求、キャッシュ・クラスタの導入、キャッシュ・クラスタでの読み取り要求のカン朱多数の続きを読みます。
第六に、メッセージングミドルウェアクラスタの導入
あなたはすべての書き込みはもちろん、すべての主要な図書館の床の着陸データベースを要求したと言うなら、問題はありませんが、圧力た場合、それのより多くを書くこと？例えば、毎秒データの数万を書くために、行うには、この時間は、メインのライブラリーに加えて機械を停止しているのですか？もちろん、あなたがすることができますが、同じトークン、マシンのリソースを消費することは素晴らしいですが、これは、意思決定のデータベース・システムの機能です。
同じリソースの下では、あまりにも重く、複雑なデータベースシステムは、数千/秒程度の伝送容量によって複雑。この時点で、他の技術の一部を導入する必要があります。例えば、MQクラスターであるミドルウェア技術を、メッセージング、彼は負荷シフトの効果を達成するために、書き込み要求の非同期処理を行うために非常に良いです。
あなたは、今二1000 / sの書き込み要求時間があると言うならば、そのような要求は、要求されている500回では、データベースに書き込まれた直後に来なければならないが、別の500は、非同期書き込み要求が数秒から数十あるいは数分の待ち時間である可能性がありデータベース内に落下した後。このとき、メッセージがMQの非同期書き込みを許可するミドルウェアクラスタ毎秒500件のリクエストを導入することができ、その後、MQをシフト負荷に基づいて作られました。消費者のうち円滑100 / sは、データベースに分類することができる速度で、例えば、この時間を大幅にデータベースを書き込むための圧力を減少します。このとき、図中のアーキテクチャは次のようになります。
メッセージングミドルウェアクラスター
我々は最初のメッセージングミドルウェアシステム自体だけでなく、高い同時実行のために生まれた、上記のアーキテクチャ図を参照してください、そしてので、通常、単一のレベルのサポート数十または同時要求の数百もあります。
だから、また彼自身のキャッシュシステムで、高い同時要求をサポートするために、非常に少ないリソースを使用することができ、高い同時実行の一部をサポートするためにそれを使用するデータベースのその部分は直接高同時実行をサポートするよりも、非同期書き込みは問題ありませんができます機械の使用回数を減らすために要求。
負荷シェービング及びメッセージング・ミドルウェア後、このような後、100 / sの書き込み速度と安定性を持つデータベース、受信した書込要求データベースレベルの圧力として、500 / S + 100 / S = 600 /秒までになることはありませんなぜ？
あなたはデータベースへの圧力を減少させることがわかっていない、参照してください？
これまでのところ、以下の手段が、我々は、データベース上の負担を軽減し、最小限のマシン・リソースカン朱の最大圧力要求にできるだけ多くのシステムアーキテクチャを持っている必要があります。
- システムクラスタ
- データベースレベルのサブライブラリーの別々の読み取りおよび書き込みサブテーブル+
- どのくらいの書面による要求を読み取るため、キャッシュ・クラスタの導入
- 高圧のために、メッセージングミドルウェアクラスタの導入を書かれています。