[安定性] day13高可用性についての思考のためのフレームワーク

kriszhang教師の共有からこの記事。高可用性アプローチのために、思考のフレームワークは、以下のように:

  • ガイドライン

  • ハイアベイラビリティ

    事前

    • 技術のコピー

    • 分離技術

    • クォータ技術

    • ディスカバリー・テクノロジー

    • 予定

    • 監視と警報

    • 降格

    • ロールバック

    • failXXXシリーズ

  • 高い同時実行

    • マルチスレッド

    • 拡張

    • キャッシュ

    • 非同期な

1、指針

引用した本は、原則のいくつかが、スキルがなくてもよいです。次のように私は原理を理解してください。

高並行性の原則:

  1. ステートレスデザイン:ので、状態のは、ロック操作を伴うロックと同時シリアル化するためにつながる可能性があります。

  2. 適度なサイズの維持:かどうか、サービスのスプリット、実際には、制御粒度サービスは、粒子サイズの分散同時増加要求を制御するため、または管理の観点の動作を改善します。

  3. キャッシング、キューイング、並行性と高い同時実行の設計で参照できる他の技術が、シーンに応じて使用する必要があります。

可用性の原則:

  1. 任意の配信システムはロールバックさせる能力を持っている必要があります。

  2. 外部システムは、ロスレスが低下するかどうか、低下するかどうかの正確な測定に依存しなければならない、そしてスイッチが劣化提供します。

  3. 外部露光システムインタフェースが制限を設定しておく必要があり、電流制限値は、正確で信頼性の高いようでなければなりません。

ビジネス設計の原則:

  1. 安全性:抗グリップ、抗スカルピング、繰り返しにアンチフォーム、などなど。

  2. 少なくとも消費者、消費電力や他のデザインの使用かどうかを検討すべきです

  3. ダイナミックなビジネスプロセス、ビジネスルールの動的な

  4. システムの所有者は、システム、バックアップシステム担当者、デューティ・システムを担当して

  5. システムのマニュアル

  6. バックグラウンド動作をさかのぼることができます

これらの原則は、より広い世界のほんの一部で、リーダーべきで、仕事や勉強に蓄積します。

 

2、高可用性

私たちは、自然の高可用性の要求で始まる:システム7 * 24時間対応の医療サービスを確保するため、高可用性が不確かで抵抗します。高可用性については、私たちが直面する問題は、不確実性に対して実際にすべての側面からの不確実性です。例えば、部屋全体の原因となります地震が中断され、どのように対処するには?例えば、コアシステムエンジニアの責任はどのように対処する、会社を去りましたか?別の例は、下流インタフェースにリンクされている、どのように対処するには?システムディスクは、データを失うリスクに直面して、壊れている、どのように対処するには?

私は、災害復旧の異なるレベルに対応し、我々は多かれ少なかれ自分の仕事に理解している、上記のような問題に対処する方法を考えて、そしてプロセスのこの不確実性、あること、災害復旧、その異なる「大惨事」。

不確実性のこれらの異なるレベルに対抗するために、コストの異なるレベルを支払うために利用できる必要があるため、また、標準でなければなりません。この規格は、我々は、多くの場合、N 9と言う、です。

Nが増加すると、コストの増加に対応は、それがビジネスニーズの可用性の基礎を達したか、コストを節約しようか!これは思考の値するトピックです。また、100%のマイナスN 9は、故障間のいわゆる平均時間(MTBF)は、多くの人々が唯一のトラブルシューティングの時間を無視して、それがこの中に間違っている、それらの9気に言いました:

あなたのトラブルシューティング速く、可能性が高いシステムの可用性。

コンセプトの可用性に上記プル何かが、それはあなたのスキルを下回っています。タオは、本はスキルの可用性の分類をしなかった開かれ、私は、サブクラスに「もの」を試すためにここにいます。障害の終了後(障害が発生する前に)事前の、事件問題で(システムや認知の障害に失敗)、(今回のトラブルシューティングに失敗)、その後(:ここでは「事は」分けの失敗であり、 )。

上記の分類によると、異なる相は異なる技術を持っている必要があります。

アドバンス:コピー、隔離、クォータ、前倒し、確認するために、
事件を:監視、アラーム
で物事:ダウングレード、ロールバック、危機管理計画、failXXXシリーズ
その後:リプレイ、思考、技術革新

 

事前

技術のコピー

自然はそれが氷河期で、あるいは隕石が地球に打撃を壊滅によって引き起こされるヒット、種はまだ無限の再現で、これは遺伝子重複の役割であるかどうか、技術のマスターコピーの価値があります。コピーは、不確実性に対する強力な武器、コンピュータシステムへの技術のコピーである高可用性のアップグレードをもたらすでしょう。

ステートレスサービスアプリケーションには状態がないため、水平方向のスケーリングすること、およびこれらのステートレスプロキシサーバ間のリバースプロキシを持つことになります統一された管理に1を、必要とすることができ、クラスタのコピーです。

エージェントは、マシンの問題で、それはオフラインになり、ハートビートメカニズムによって検出された場合、他の「コピー」マシンがサービスを提供し続けるために、記憶領域のコピーも、このような3つのセンターOB技術の3つから5つのコピーとして頻繁に使用される技術であり、 、mysqlのスタンバイスイッチング、RabbitMQのミラーキュー、ディスクのRAID技術、さまざまなパーティションのNoSQLコピー、など、など、ほぼすべてのシステムの、数多くあるコピーが存在する冗長の高可用性を確保する必要があります。

 

分離技術

隔離スレッド、プロセス分離、分離されたクラスタ、隔離室、アイソレーションを読み書き、分離運動、孤立爬虫類、ホット分離、分離ハードウェアリソース:分離に関する書籍の様々な言及。

動的リソースと静的リソースは何もなく、リソースの分類ではありません;暑いですアイソレーション私の意見では、これらのアイソレーションは、リソースの隔離が、関係なく、スレッド、プロセス、ハードウェア、コンピュータ室の、クラスタがリソースであることを実際に親切です熱い熱い資源と非資源の分離は、分離は、読み取りおよび書き込みが、リソースがそれにどれだけ、同じ2つのリソース、書き込み用と読書のための1。

したがって、分離された自然、実際には、リソースの独立した保護。各リソースは、独立した保護されているため、資源の一つは、それがサービス全体の可用性を向上させる他のリソースには影響しません、問題となっています。人間が長すぎるため隔離の使用、および農業の農業から、株式への投資、でもクローズド刑務所の受刑者は、分離された手術の影で見つけることができます。

 

クォータ技術

それによって全体的な可用性を向上させる、システムリソースの供給を保護するための技術を制限するクォータ。クォータは、入口流水線を調整することにより、供給不足に起因するサービス停止を回避すること流量制限技術です。

制限電流制限は、分散インフラニーズを持つクラスタを制限する、制限クラスタおよびスタンドアロンに分割され、制限単一の電流が必要とされません。単一制限十分なを使用してほとんどのビジネスシナリオは、(スパイクのように、など)特別なシーンでクラスタ全体の流れを制限する必要性を制限しました。我々はいくつかの点を考慮する必要がどこ加えて、制限:

どのように合理的な制限値を設定するには?電流制限を設定した後、適切に測定された全リンク電圧を通過する必要性は、ビジネスや運用・保守の経験の推定値と組み合わせて、CPUの容量、ディスク、メモリ、IOのトラフィックと他の指標との間の関係(必ずしも直線的な関係)の変化を評価されます、判断することができます。

どのように制限されたトラフィックのフローに対処するには?いくつかの治療法は、直接、軽度のコピーを持つユーザーに警告捨て1は、ありますが、第二、一般的に非破壊ダウングレードとして知られている、サイレント、キャッシュの内容でページを更新し、第三には、洪水のストレージ、一般的にトランザクションのシーンのために使用されている血液、への非同期バック。

これは、殺人につながることはありませんか?スタンドアローン殺人とリードを制限し、負荷の不均衡の状況の下で、それは殺人の傾向がある場合は特に、単一の電流制限値は低すぎる過失致死罪の場合もそう発生することがある設定されています。

 

ディスカバリー・テクノロジー

唯一のシステムのための現在の可用性を把握する能力は、効果的にシステムの可用性を向上させることはできません、でも、システムの可用性を低下させないでください。圧力試験と運動と最も一般的な技術を把握します。圧力測定と完全シングルリンクリンク圧力測定に測定された圧力、下流側のシステムの全体的なニーズを持つビスXI促進活動としてフルリンク、圧力測定値は、測定された圧力は、一般に、シングルリンク又はメーク検証でありますシンプルなスタンドアローンの抽出圧力の測定性能。

一般的なプロセスは、全リンク電圧測定される圧力測定と目標設定の評価、展開圧力測定変換、圧力テストスクリプト、テストデータ準備圧力、下流側のシステムの所有者に通知するための低流量検証リンク、予熱圧力測定の調製圧力測定、圧力測定結果の評価報告書、パフォーマンスの最適化。より多くの反復的なプロセス、これまで圧力測定対象まで。

サイズで割った一般的な運動:例えば、都市レベルの災害復旧エクササイズ、エクササイズルーム・レベルの災害復旧、災害復旧は、クラスタサイズ(DBクラスタ、キャッシュ・クラスタ、アプリケーションのクラスタリングなど)、単一レベルの障害注入、運動計画とその上を行使する。運動の役割を強調しすぎるのない、しかし、運動は、一般的に午前中に発生するだけでなく、本当に疲れる、トラブルシューティングとシステム所有者のニーズは、通常のシフトに従事。

 

予定

計画は、一般的に、早期の計画(事前の)と(問題で)危機管理計画に分かれています。このようなシステムのモードとして事前に早期実行計画は、一時的に省エネモードにピークから切り替わり、そのようなキー冗長切り替えとして主に止血のために使用緊急計画を、実行する前に、重要な瞬間。スイッチで一般的に使用するための技術的な計画は、スイッチの一般的な計画が押された押してください。また、計画は制限することができ、ロールバック、降格を組み合わせ、日常の運動プロジェクトとして使用することができます。

 

事件

障害がコアが障害を識別し、迅速かつ正確に要求する方法であり、この時間が対処する準備システムまたは知覚障害で発生した場合に入射します。

 

監視と警報

場合は、一般的な失敗、上司は主に3つの質問になります。なぜ彼らは見つけましたか?なぜ唯一の解決策は?影響範囲?治療がタイムリーでない場合は逆に、いくつかの顔を保存することができますどのくらいの時間を再セットをやって、すぐに出血した場合であっても、故障表面より大きなインパクト場合は、小さな障害は、あなたの仕事を失うことができます。早く早く私たちが目や警察を監視している問題を、解決することができ、障害を特定します。おなじみのアラームの監視、ずっとここで繰り返します。

 

で物事

障害が発生したときに何を意味するかの問題は、システムの可用性を確保するために、我々は、またはしなければならないことができます。分割格下げ、ロールバック、危機管理計画(大多数がない、上記を参照)、faillXXXシリーズ。

 

降格

リッチコンテンツをダウングレード、我々はリンクのみの観点から考える必要があります。ダウングレードは、本質的に一時的にシステム全体の可用性を確保し、いくつかの機能を放棄することにより、車両保険ハンサムを放棄しました。ダウングレードは、システム全体ではまだ使用可能ですが、トレードオフの関係が、その後、全番組の格下げのは非可逆でなければなりません。真のロスレスは、ユーザーエクスペリエンスそのままそのロスレスダウングレード手段をダウングレードしないとよく言わ存在することができます。

特定の格下げは、層(上流および下流)、一時的な層または層Bが起動されていない、これはヒューズと呼ばれ、またはスタンバイ・チェーンと呼ばれる一時的な層(C)層(層C合理特定<B層)への呼び出しの間で起こります道路。

いずれの方法でも、あなたが問題に直面します:とき降格するかを決定するためにどのように、いつ回復?二つの一般的な方法があります、

一つは、アラーム監視による手動確認、フィードバック機構であり、手動識別障害、プッシュ手動で回収ロールバックするまで、分解しました。

閾値は、自動ロールバック回復に達したときに、第2の適応同定され、エラー周波数限界流量等タイムアウト最も一般的に使用される指標は、自動的にダウングレードします。

これらの2つの方法、頻繁に使用されている高可用性技術を比較する必要はありません。

また、我々はまた、分解し、依存関係の強さに注意を払います。強度依存性は、それがプロのプレゼンテーション「降格するかどうか」であり、上流と下流のリンク間の依存関係によって表されます。

私たちは、分解の本の中でいくつかの例を見てみましょう:

①ライトダウングレードは、実際の方法、一貫性のスイッチング損失を予備リンクを使用して、記憶層とアプリケーション層との間に劣化し、

②機能のダウングレード、部分的に無効には、アプリケーションが実際に融合した方法で、層及び機能モジュール層との間に劣化し、機能の一部が失われます。

③クローラダウングレードは、実際にページに含まれ損失とエンジンのインデックスを確立する、クローラの静的ページを案内するために、予備リンクスイッチングモードを使用して、アプリケーションおよび検索エンジンのクローラとの間に分解しました。

 

ロールバック

特定の変更を行うことが失敗した場合、最も安全で効果的な方法は、ロールバックにあります。ロールバック効果的ではあるが、しかし、単純ではない、ロールバック前提があるので:変更は、プロパティをロールバックする必要があります。

そして、それは多くの労力を費やすことで、性質が変化する特定の種類をロールバックすることができてみましょう。単純に、基本的なサービスのほとんどは、リリースロールバック(出版システムサポート)、コードライブラリのロールバック(GITファイルのバージョン管理)、などDBトランザクションのロールバック(DBトランザクションメカニズム)として、私たちは、この機能を良いパッケージを支援してきましたように。

私たちの日常業務の変更は、あなたの操作をロールバックするかどうかを判断し、すべての変更をロールバックできることを保証しようとする必要があります。あなたはアップデートを加熱することができる場合は、ロールバックすることができない場合は、システムの可用性を確保するか、最終的な一貫性の補償及びその他の付加的な手段(例えば、アプリケーションストアにアプリケーションを公開)。

failXXXシリーズ

障害がコールの下流で発生した場合、我々は一般的に、いくつかの治療法があります。

  1. failretry、すなわち障害のリトライ、バックオフ時間を満たすために必要、それ以外の効果は必ずしもすぐに再試行しません。

  2. フェイルオーバー、いわゆるフェイルオーバー。例えば、ロードバランサは、他のマシンプロバイダインタフェースリトライへのコールをRPCう失敗下流インタフェースを呼び出し、そのようなAデータベースにハングアップ、X、X適応冗長ライブラリのライブラリ・コールを呼び出すをyに切り換えられますこのライブラリ即ち、Yはfailloverライブラリ(水ベースのサービス)であってもよい、ライブラリ(ステートベースのサービス)により調製することができます。

  3. FailSafeの、即ち、沈黙は、下流リンクに一般的に依存している弱い、彼らはその後、実行フェイルセーフをフェールセーフ、フェイルオーバーを使用することができ、そして組み合わせることができ、例えば3回フェイルオーバーまたはフェイル。

  4. フェイルファースト、すぐに認識される問題のエンジニア、そしてタイムリーな人間の介入のためにすぐに、フェイルファースト主にエラーが発生しました。

  5. フェイルバック、遅延補償(フラッシュバック)、またはメッセージキューのタイミングは、一般的に使用スキャンすることができます。

上記2,4再試行戦略、すなわち、本の中で「タイムアウトおよび再試行」の章では、リトライを述べ、属します。再試行は疑問を持っている:バックオフ間隔はどのくらいですか?数回の再試行?一般的な一時的な下流のジッタの場合には、非常に短い時間で復元することができます。しかし、下流完全に利用できない、それはこのことを、成功しないだろうが、下流へのより多くの圧力を作成する方法を何回おそらく再試行であります場合は、吹きになされるべきです。

そのため、再試行の正しいセットの数は、バックオフ時間を選択し慎重に検討する必要があります。リソースは、下流の要求が戻るのを待っている - 私たちは、主の要求の蓄積を防ぐために、対処戦略だけ防止機構ではなく、故障でタイムアウトタイムアウト、について話しています。自己言うまでもなくの蓄積の結果は、右のタイムアウトを選択することがいかに重要である、と言うには?本はどのようにタイムアウトの各部分のconfigureへのリンクのみが言ったが、設定する必要がありますどのくらいかわからない、それが包括的に十分ではありません。

 

その後

リプレイ、思考、技術改造。多くは詳細に入るわけではありません。

 

2、高い同時実行

一年間お使いのシステムに一人だけのアクセスは、限り、個人の訪問が成功したとして、その後、「」可用性「あなたのシステムが100%であれば、実際には困難ではない、高可用性、の追求だけでは、想像している場合。

現実には、事業開発と、要求のますます大容量になり、その後、さまざまなシステム・リソースを有効にすると、潜在的なリスクが徐々に公開されることということです。

高い同時実行の条件の下で、システムの可用性を確保するための方法:そのため、困難の一つは、システムを作ることです。すでにスキルの可用性を確保するために何かを言ったように、このセクションでは、本タオと一緒に高い同時実行についての話を開きます。

オンラインショッピング - 図は、私たちの共通の生活場面です。レジ係が私たちのサービスであり、キュー内のすべての顧客が要求です。私たちの魅力の本質は、多くの人々が合理的な待機時間内に購入を完了して取得することです。

これをどのように行うには?一つは、彼らは時間の高速化ユニットは、サービスより多くの顧客にできるようになる扱うレジの処理速度を向上させることである。他にはしかし、マンパワー、ハンドルにレジを増加させることであり、我々は10キャッシャーを雇うだろう、10我々は(すべてのコストであれば)百を雇うには十分ではなかった。第三は、訪問の数を減らすことで、前のピークに(二重11のウォームアップなど)シャントフィルタは、前もって人々の一部を除外し、または実行することをウォームアップ活動、人々のニーズを満たすの最初の部分。だから、私たちは、次の側面から高い同時実行開始ほかならしたくありません。

キャッシング、非同期:処理速度を向上させる
マルチスレッド(マルチプロセス)、拡張:増加処理スタッフ
(物品はカバーしていない)前処理:訪問の回数を減らすために

処理速度を向上させます

キャッシュ

キャッシュは、異なるデバイスのアクセス速度に違いがあるため、処理速度を上げることができました。キャッシュのトピックは、重いの種類せずに数冊の本を引くことができます。CPUから常にワンダクライアントキャッシュは、最新の特殊なユーザー層によってすべての道側-追跡に下から、それぞれの層が存在する可能性があることも、キャッシュされている可能性があります。私たちは、単純なサーバ側のキャッシュを言って、ここではそんなに引っ張らないでください。今見ると、いくつかの異なった時点からキャッシュを見て:

①遠近効果から。割合が高い、良いこと?100の000店のデータ、1000年のキャッシュ、100%のヒット率の安定した、それは99,000店はロングテールのショップがありますされていると言っているわけではありませんか?キャッシュの影響評価は、単にヒット率を見ることができません。

②リカバリ戦略から。キャッシュ・ストレージ・デバイスと同じデータベースを使用する場合は、引数のないリサイクルが(再起動やダウンタイムがない限り、それ以外のデータがまだ有効である)が存在しない、唯一のホットデータを格納し、回復の問題に置き換えることを場合。二つの方法でリサイクル、一方が他方には、時間のクォータで、クォータです。また、LRU、FIFO、LFUいくつかの方法があります。

キャッシュ使用パターンから③の角度は:ユーザが直接キャッシュとDBを操作し、ユーザーを直接キャッシュに、キャッシュはDBBヘルプお読み。

④キャッシュ分類の観点から。Javaの内のヒープバッファ、キャッシュ、ディスクキャッシュ、分散キャッシュ、マルチレベルキャッシュ外部Javaヒープ。

⑤角度を使用して、キャッシュから。ヌル、質問を貫通群れの問題を雷が鳴っ、ホットな問題、キャッシュコヒーレンシの問題をキャッシュ、読み取りと書き込みの拡散問題......

⑥更新。更新情報を読み取り、書き込みのアップデート、非同期更新されます。

キャッシュ・クラスタは、データの同時実行性に大きなビジネスシナリオの高レベルと組み合わせて、オフサイト、マルチクラスタ配置を伴う場合は、我々はより多くの複雑な問題が発生しますが、ここではそれらをリストしていません。

 

非同期な

ここでは、いくつかの非同期的な意味合いです

一つは、どのT1 + T2 + T3 + ..... + TNからの総応答時間が最大値(T1、T2、T3 ...、TN)となるであろう非同期の複数の同時コールに同期呼び出しでありますまた、非同期のスケジューリングとして知られています。

第二は、性能を向上させるためにasyc IO IOプロセスを使用して、オペレーティング・システム・レベルです。

第三の要求は、典型的には、キューミドルウェアを使用して、後の非同期処理を「ダンプ」されています。非同期のどちらのレイアウト、あなたはCompletableFutureを使用することができ、非同期IOは、一般的なフレームワークパッケージを行っている、とキューイングミドルウェアは、最も一般的に使用される技術の一つである我々の焦点の目的です。

サービスは、システムが使用するのに適している、ミドルウェア前提、すなわち、非リアルタイムまたは準リアルタイムシステムを使用して遅延処理キューを可能にします。主な機能:非同期処理(スループットの向上)、クリッピング洪水(保証安定性)、データ同期(整合性最終組立)、デカップリング(知覚下流加入する必要はありません)。

  • バッファキュー:キューは、一般的にリングバッファ、バッファサイズのコントロールを使用します。

  • タスクキュー:タスクのスケジューリングシステムは、一般的に、このようなスレッドプール、撹乱として、使用します

  • メッセージキュー:一般的には、メッセージングミドルウェア、異なるビジネスシナリオは、異なるミドルウェアの機能を必要とし、いくつかは、高いスループットを必要とし、などいくつかの必要性のサポートサービス、および複数のクライアントをサポートするためにいくつかの必要性、および特定のプロトコルをサポートするためにいくつかの必要性、キューは個人的に、完全に統合メッセージング機能を通信局の提供で統一した後、オンデマンド選択の多様性を提供するために、良い感じ、大とメッセージキューを開発しようとします。

  • リクエストキュー:キューがリクエストを処理している、プロセスエンジンのようなビットは、次のような、チームにいくつかの前処理および後処理のチームを行うことができ、電流制限、フィルタリングなど

  • データバスキュー:そのような運河、同期のための(不均一または均一)DATAX他のデータとして。

  • 優先キュー:通常大きなルート・スタックを実装します

  • キューをコピーします:キュー・サポート・再生した場合、キューにいくつかの冗長性をコピーします。

  • ミラーキュー:キューシステムは、一般的に、高可用性のスイッチングを行うために使用されます。

    時には、レプリケーションを行うために部屋の向こうクラスタ全体で、より多くの消費者支出の増加配信容量を提供します。

消費者は、キュープルモードまたはプッシュモードの終了を選択しています。単一の支持整然としたキューのプル、サポートするためにハードにプッシュ、プルモードがリアルタイムモードが高くなってプッシュし、進行を制御することができます。消費パターンに加えて、他の質問のスルーをキューに入れ、他の書籍を参照してください、あまりここで説明します。

ここでは、非同期の説明することを追加します。増加させることができるスループット同期、非同期転送、同期、非同期転送は、信頼性を高めることができます。

増加処理スタッフ

 

マルチスレッド

マルチスレッド(マルチプロセス)技術は、技術、最も可能性の高い我々も広く使用されている一般的に考えることです「処理スタッフ増やすこと」です。それは、Webサービス・コンテナ、ゲートウェイ、RPCサーバー、メッセージキューの消費量と送信者であり、従ってマルチスレッド技術の使用を持っているかどうか。利点は、多くの説明を必要としません。

ここで、我々は低すぎる場合、スレッドの数が多すぎる場合は、システムリソースを食べることができるスレッドの問題の数を設定する一つの重要な事を言うと、マルチスレッドの利点を再生することはできません。

一般的な設定、参照治療、同時ピーク、平均同時実行の平均長さは、速度、最大許容応答時間、CPUコア等をブロッキングし、次にスレッドの数を計算するために、いくつかの計算を実行し、コア最大ときキューサイズを遮断します。

このアルゴリズムは、自己グーグルことができます。

 

拡張

状態サービスがない場合には、拡大が同時スキルの量を増加させる最も明らかな効果の遠1によるものとすることができます。

一時的な同時実行性の問題がある場合は、直接すぐに拡張工事の受注を言及することができます。しかし、最大の問題は時間の大きなプロモーションをサポートする場合は、拡張の費用は、数十万のすべての変わり目に物理マシンを考えているが、通常使用率がほぼゼロである、それは本当に無駄です。

だから、容量が必要とされているいくつかのクラウドの弾力性、ボロー他の誰かのマシン(アリ雲)があるでしょうし、その後戻っても切れ;およびオフラインユニット、リソースをフルに活用して混合。

拡張モードの観点から、垂直に拡張(スケールアップ)、横拡張(スケールアウト)。

垂直拡張は、スタンドアロン処理能力、憎悪ハードウェアを増加させることであるが、すべての後に、ハードウェアの機能は、限定されるもので、白はなく、マシンの数の増加に伴い、機械、憎悪機の数の増加であること膨張のレベルは、単一のアプリケーションの同時実行は、必ずしも線形関係それとないが、この時点では、スプリットのサービスを使用する必要があります。

データの観点から、膨張は膨張ステートレスとステートフル膨張に分けることができます。

ステートレス拡張は、一般的に我々のアプリケーション・サーバーの拡張を意味し;存在状態は、一般に、データストレージ拡張の拡張を意味している、またはデータのコピーがそのシャーディング、または全コピーNコピー、そのコピーの複数の異なるコピーに分割されます。

信頼性の断片化が発生した問題をされてシャーディング、一般的に転送、焼き直し、断片化のコピーを行い、発生した問題のコピーが一貫性である、一般的なパクシ、いかだなどとして、コンセンサスアルゴリズムを実行します。

 


=>より多くの記事を参照してください「中国のインターネットビジネスの展開アーキテクチャガイド」 https://blog.csdn.net/Ture010Love/article/details/104381​​157

=>もっとストーリー業界アーキテクチャと業界標準の情報は、マイクロチャネル公衆番号に注意を払うしてください。

公共いいえ:もっとリアルタイムの動的な心配
これ以上の世間の注目:ソフトウェアの真実と光

 

公開された172元の記事 ウォンの賞賛388 ビュー180 000 +

おすすめ

転載: blog.csdn.net/Ture010Love/article/details/104392447