- 高い同時実行性の原則は、
状態の
ない状態には適用されないため、水平方向の拡張に便利です
。ステートフル構成では、構成センターを通じてステートレス構成を実現できます。
実践：Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、
Xdiamond、等の
スプリット
システムの寸法：などのショッピング、決済、受注などのシステム機能、ビジネスの分割に応じて
。システム機能のきめ細かい分割：機能寸法
読み取りと書き込みの寸法：スプリットの読み取りと書き込みの比率の特性に応じて;続きを読む、マルチレベルキャッシュを検討する;続きを書く、
サブライブラリサブテーブルの
AOPディメンションを考慮したテストを許可する：商品⻚⽐などの⾏AOPに分割されたアクセスパターン
は、CDN、⻚⾯レンダリングシステムに分割できます、CDNは⼀システムAOP
モジュールの次元です：Webコード構造の全体的な分割、サービス、DAO
サービス指向の
サービス指向の進化：インプロセスサービス-スタンドアロンリモートサービス-クラスター手動登録サービス-自動登録および
検出サービス-サービスのグループ化、分離、ルーティング-サービスガバナンスで
は、サービスのグループ化、分離、電流制限、ブラックリスト、タイムアウト、再試行メカニズム、ルーティング、障害
補償などを検討します。
実践：Nginx、HaProxy、LVSなどを利用して負荷分散を実現します、ZooKeeper、Consul
など、サービスの自動登録と検出を実現します。
メッセージキューターゲット
：サービスデカップリング（1対多の消費）、非同期処理、トラフィックのピークシェービングバッファリングなど。
マスフローバッファリング：一貫性を犠牲にして、最終的な一貫性（ケース：在庫控除、控除は
Redisで行われるようになり、控除ログを記録し、合格バックグラウンドプロセスは控除ログをDBに適用します）
データ校正：非同期メッセージメカニズムでのメッセージ損失の問題を解決します。
データの不均一性。
データの不均一性：メッセージキューメカニズムを介してデータの変更を受信し、元の
データを保存します。クローズドデータループ：複数のデータソースをシールドし、データを不均一に保存してクローズドを形成します。 -ループ
キャッシュシルバーブレット
ユーザーレイヤー：
DNSキャッシュ
ブラウザーDNSキャッシュ
オペレーティングシステムDNSキャッシュ
ローカルDNSサービスプロバイダーキャッシュ
DNSサーバーキャッシュ
クライアント側キャッシュ
ブラウザーキャッシュ（有効期限、キャッシュ制御、最終変更、Etag）*アプリ
クライアントキャッシュ（js / css / image ...）
プロキシレイヤー：
CDNキャッシュ（通常、ATS、Varnish、Nginx、Squidなどに基づいて構築され、エッジ
ノード-サブレベルノード-ミドルノード-オリジンサイト）インターフェイス
レイヤー：
例としてNginx ：
Proxy_cache：プロキシキャッシュ、/ dev / shmまたはSSDに保存できます
FastCGIキャッシュ
Nginx + Lua + Redis：
例としてビジネスデータキャッシュPHP：
Opcache：キャッシュ
用のアプリケーションレイヤーをOpcodeしますPHP ：
静的
ビジネスデータキャッシュ（Redis / Memcached /ローカルファイルなど）
メッセージキュー
データレイヤー：
NoSQL：Redis、Memcache、SSDBなど
。MySQL：Innodb / MyISAMなど。クエリキャッシュ、キーキャッシュ、Innodb
バッファサイズなど。
システムレイヤー：
CPU：L1 / L2 / L3キャッシュ/ NUMA
メモリ
ディスク：ディスク自体キャッシュ、 dirty_ratio / dirty_background_ratio、アレイカード独自の
キャッシュの
同時実行性 - 高いユーザビリティの原則
ダウン
グレードダウングレードスイッチの集中管理：スイッチ構成情報を各
アプリケーションにプッシュ、ダウングレード可能なマルチレベル読み取りサービス：読み取り専用ローカルキャッシュ
スイッチフロントエンドにダウングレードされたサービス呼び出しなど：Nginx + lua（OpenResty）などトラフィックを迂回させるためのダウングレード戦略。
これに基づいて、グレースケール戦略を作成できます。
ビジネスダウングレード：高い同時実行性、コア機能の確保、セカンダリ機能を同期戦略から非同期戦略に変更、または
機能のブロック
フロー制限
：悪意のあるリクエストの防止** *またはピークを越えたシステム
実践：
キャッシュへの悪意のあるトラフィックのみ要求へのアクセスは
、それが処理nginxの限度利用を流し適用するには、バックエンドに浸透
nginxのは、ポリシーやゴミを拒否使用して、悪質なIPはiptablesの
カット交通
シールドマシンの障害：これを行うために
練習を：
DNS：DNSPODなどのドメイン名解決を変更するとバックアップIPが追加され、通常のIPに障害
が発生すると、自動的にバックアップアドレスに切り替わります。効果的な方法は遅くなります
HttpDNS：によって実装される正確なトラフィックスケジューリングをバイパスするためオペレーターLocalDNSLVS
/ HaProxy / Nginx：障害のあるノード
を削除してロールバックします。
リリースバージョンに障害が発生した場合は、いつでも以前の安定したバージョンにすばやくロールバックできます。 - ビジネス設計原則
反再設計べき
等設計
プロセス定義
ステートマシン
バックシステム操作の状態は、バックアップに注釈を付けるドキュメントの
オフィスシステム承認をフィードバックできます。 - 結論
既存の問題の計画と将来の計画を立てるために、最初に計画と設計を行う必要があります。
技術的負債は遅かれ早かれ返済されます。 - 分散型とクラスターの違い：
分散型とは、さまざまな場所にさまざまなビジネスが分散していることを指します。クラスターとは
、同じビジネスを実現するために複数のサーバーをクラスタリングすることを指します - 分散トランザクション：
- 第2段階での提出：
a。コンセプト：参加者はコーディネーターに操作の成功または失敗を通知し、コーディネーター
はすべての参加者のフィードバック情報に基づいて各参加者が操作を送信するかどうかを決定します。
b。機能：主に分散トランザクションの独創性を確保します。最初の段階は準備段階で、2番目の
段階はコミット段階です
。c。欠点：参加者のすべてのリソースをロックするだけでなく、調整もロックする必要があります。リソース、コストが
大きいです。一文の要約は次のとおりです。2PCは非常に非効率的であり、高い同時実行性には不向きです。 - 3フェーズコミット：
a。コンセプト：3フェーズコミットプロトコルは、コーディネーターと参加者の両方にタイムアウトメカニズムを導入し、
2フェーズコミットプロトコルの最初のフェーズを2つのステップに分割します。照会、次にリソースのロック、最後に
、実際に送信されます。このように、3フェーズの送信には、CanCommit、PreCommit、および
DoCommitの3つの段階があります。
b。短所：PreCommitに入った後、コーディネーターが中止要求を送信する場合、
1つのコホートのみが中止操作を受信して実行すると仮定すると
、システムステータスが不明な他のコホートは、3PCに従ってコミットを続行することを選択します。 、システムステータスが
一貫していません。 - 柔軟なトランザクション：
a。概念：いわゆる柔軟なトランザクションは、テーブルをロックすることを比較的強制される厳格なトランザクションです。以下のフロー：
サーバーAのトランザクションがスムーズに実行されると、トランザクションAが最初に送信されます。トランザクションBも
スムーズに実行されると、トランザクションBも送信され、トランザクション全体が完了します。ただし、YESトランザクションBの失敗
が失敗し、Bでトランザクションがロールバックされ、トランザクションAがコミットされた場合は
、トランザクションの補償操作がAに対して送信されているため、実行する必要があります。操作の逆操作を実行し、に戻りません。実行前
のトランザクションAのステータス。
b。デメリット：ビジネスは煩わしく、代償的な操作が必要です。普遍性に欠け、大規模に宣伝することはできません
。 - 最終的なメッセージ整合性ソリューションのRabbitMQ実装：
a。実装：確認の送信+メッセージの永続性+コンシューマーの確認。 - 分散開発を使用する場合：
a。利点：
i。モジュールの分離：モジュールの分割、インターフェイス通信の使用、モジュール間の結合の削減
ii。プロジェクトの分割、異なるチームが異なる部下の責任を負うプロジェクト：プロジェクトを複数の
サブプロジェクトに分割する、およびさまざまなチームがさまざまなサブプロジェクトを担当します
。iii。プロジェクトのスケーラビリティを向上させる：関数を追加するときは、別のサブプロジェクトを追加して呼び出すだけで済みます。
他のシステムの接続は問題ありません。
iv。分散展開：分散展開は柔軟に実行できます。v。
コードの再利用性の向上：サービスレイヤーと同様に、分散RESTサービス
アーキテクチャを使用しない場合は、モバイルWAPモールのWeChatで利用できます。 mall、pc、android、iosは
、サービス層ロジックを作成する必要があります。開発量が多く、保守やアップグレードが困難です。現時点では、
分散型RESTサービス方式を採用でき、サービス層があります。公に使用することができます。
a。短所：
i。システム間の相互作用で
は、アクセス開発のワークロードを増やすためにリモート通信を使用する必要があります
。ii。ネットワーク要求に遅延があります。iii。トランザクション処理はより面倒であり、分散トランザクションを使用する必要があります。 - cdn（さまざまな場所での
マルチアクティビティ）1。さまざまな場所でのマルチアクティビティ：さまざまな場所でのマルチアクティビティとは、さまざまな場所に分散している複数のサイトが同時に外の世界にサービスを提供するビジネスシナリオを指します
。さまざまな場所でのマルチアクティビティは、高可用性アーキテクチャ設計の一種です。従来のディザスタリカバリ設計との主な違い
は、すべてのサイトが同時に外部サービスを提供する「マルチアクティビティ」です。
2. 2
サイトの災害耐性切り替えスキーム：災害耐性は、さまざまな場所での複数のアクティビティの最も重要な部分です。例として、2つの都市での複数のアクティビティのアーキテクチャ図を取り上げます。
完全なビジネスシステムが2つの都市に展開されています（都市1は中国南部1地域にあり、都市2は中国東部1地域にあります）。
注文ビジネスは「user_id」％100に従って分類されます。通常の状況では：
[ 00〜49 ]すべての読み取りと書き込みは都市1のデータベースインスタンスのメインデータベースにあります。
[50〜99]サブページの読み取りと書き込みはすべて、都市2のデータベースインスタンスのメインデータベースにあります。
「都市1のメインデータベースインスタンス」と「都市2のメインデータベースインスタンス」は、DTS双方向レプリケーションを確立し
ます。
異常が発生した場合は、ディザスタリカバリの切り替えが必要です。考えられるシナリオは4つあります
。2番目と3番目の異常な状況はすべて2番目のケースで処理されるため、すべての
APPサーバーの異常、すべてのデータベースの異常、および都市全体の異常であるかどうかにかかわらず、都市レベルの
災害復旧計画に従って、直接切り替えます。 APPサーバーとデータベースを別の都市に。
3.複数の都市と異なる場所：
複数の都市と異なる場所、複数のジョブモードとは、3つ以上の都市の異なる場所に複数のジョブを展開することを指します。このモード
では、中央ノードとユニットノードがあります。
中央ノード：ユニットノードの増分データを中央ノードにリアルタイムで同期する必要があり、中央ノードは
すべての分散増分データを他のユニットノードに同期することを意味します。
セルノード：ブランチの読み取りと書き込みに対応するノード。ノードは、ブランチの増分を
中央ノードに同期し、中央ノードから他のパーティションの増分データを受信する必要があります。
次の図は、3つの都市のマルチアクティビティアーキテクチャの図です。中国東部1が中央ノードであり、中国南部1と中国北部1が
ユニットノードです。
9.分散環境でダウンタイムに対処するにはどうすればよいですか？
1.ダボ：サーバーがダウンしていて、zkが一時的に削除されています。
2. Springcloud：リースを再入力するために30秒ごとに1ホップ検出を送信します。クライアントが
リースを複数回更新できない場合、90秒以内にサーバー登録センターから削除されます。
3. Apmモニタリング：
10。