バックグラウンド
ビジネスの急速な発展はデータスケールの急速な拡大につながり、スタンドアロンデータベースはインターネットビジネスの発展に対応できませんでした。
データを単一のデータノードに一元的に保存する従来のスキームは、容量、パフォーマンス、可用性、および保守性の観点から、インターネットの大規模なデータシナリオに対応することは困難でした。
容量に関しては、単一マシンデータベースの容量は限られており、拡張することは困難です。
パフォーマンスの観点から、ほとんどのリレーショナルデータベースはB +ツリータイプのインデックスを使用するため、データ量が特定のしきい値を超えた後、インデックスの深さが増すと、ディスクへのランダムIOの数が増えます。パフォーマンスの問題につながります。
可用性の観点から、サービスは通常ステートレスになるように設計されているため、必然的にシステムのストレージプレッシャーがデータベースレベルに集中し、単一のデータノードまたは単純なマスタースレーブアーキテクチャがますます増えています。耐え難い。
運用・保守の観点から、データが1つのノードに集中している場合、データ量の増加に伴い、データのバックアップとリカバリの時間コストも制御できなくなります。同時に、データ損失の影響を受ける領域が拡大します。
マスタースレーブレプリケーション
- メインライブラリは、トランザクション操作（クエリ以外の操作）をbinlogに記録します
- リレーログを介してライブラリからのデータを同期し、データの同期を実現します
binlogログ形式
- 行には、オンラインテキスト情報などを含むデータベース操作の詳細なレコードが記録されます。ファイルは大きいです。
- ステートメントは、トランザクションに関連するSQLファイルを記録します。
- 行とステートメントの2つのファイル形式に基づいて混合。
非同期レプリケーション
2000年に、MySQLバージョン3.23.15は、非同期レプリケーションを使用したレプリケーション機能を導入しました。ネットワークまたはマシンに障害が発生すると、データに一貫性がなくなります。
準同期レプリケーション
2010年、MySQL 5.5では準同期レプリケーションが導入されました。準同期レプリケーションとは、スレーブノードがackを返す限り、マスターノードがトランザクションをコミットできることを意味し、データベース内の少なくとも1つのノードがデータ同期を完了していることを確認します。
グループコピー
2016年、MysQLは5.7.17でInnoDBグループレプリケーションを導入しました。このソリューションは、グループ内レプリケーションを実現し、データの整合性を確保するためのpaxosプロトコルに基づいています。paxosプロトコルのコアは、選挙の半分以上です。
マスタースレーブレプリケーションの問題
- マスタースレーブレプリケーションが遅延し、「書き込み後に読み取り」データに一貫性がなくなります。ライブラリからの読み取りに失敗し、メインライブラリに移動してSQLを再度実行すると、パフォーマンスの問題が発生します。ビジネス層は、システムのコア機能が使用可能であることを確認し、コア機能のCRUD操作をメインライブラリにルーティングします。短期間のデータの不整合があったとしても、非コアビジネス機能はほとんど効果がありません。
- ルーティングの問題の場合、ビジネス層はSQLに基づいてさまざまなデータベースにルーティングする必要があります。SLAVEノードにルーティングする場合は、システムの負荷分散も確保する必要があります。ビジネス層は、フレームワーク（sharding-jdbcなど）を介して、または手動で実装されます。これは、ビジネスにとってより煩わしいものであり、既存の古いシステムは変換に適していません。データベースミドルウェア（mycat、sharding-proxyなど）を介して実現するには、ミドルウェアをデプロイする必要があり（ミドルウェアはSQL標準を実装します）、ルールはミドルウェアで構成され、実行中にもう1つのネットワーク転送があります。
- データベースの高可用性を確保するための一連の高可用性ソリューションを通じて、システムの高可用性を保証することはできません
高可用性データベース
高可用性とは何ですか？
高可用性とは、サービスが利用できない時間を短縮することを意味します。これは通常、SLA（サービスレベルアグリーメント）によって測定されます。
1年= 365日= 8760時間
99 = 8760 * 1％= 8760 * 0.01 = 87.6時間
99.9 = 8760 * 0.1％= 8760 * 0.001 = 8.76時間
99.99 = 8760 * 0.0001 = 0.876時間= 0.876 * 60 = 52.6分
99.999 = 8760 * 0.00001 = 0.0876時間= 0.0876 * 60 = 5.26分
なぜ高可用性が必要なのですか？
フェイルオーバーにより、フェイルオーバー機能に加えて、ビジネス側の接続プールのハートビート再試行が提供され、切断と再接続、中断のないビジネスを実現し、RTO（目標復旧時間）とRPO（目標復旧時点）の目標を削減します。
- ディザスタリカバリ：コールドスタンバイとホットスタンバイ。コールドスタンバイとホットスタンバイの違いは、運用中にサービスが提供されるかどうかです。
- マスターとスレーブの場合、簡単に言うと、マスターノードがダウンし、特定のスレーブノードが自動的にマスターに切り替わります。
- クラスタの観点からは、個々のノードがダウンしていても、通常どおり外の世界にサービスを提供できます。
一般的な戦略：
- マルチインスタンス展開
- コンピュータルーム全体に展開する
- 2か所の3つのセンター向けのディザスタリカバリと高可用性ソリューション。
手動スイッチ
つまり、マスターノードがダウンしている場合は、スレーブノードを手動で変更してマスターノードにします。
既存の問題：
- 一貫性のないデータである可能性があります
- 手動による介入が必要
- コードと構成が煩わしいため、他のノードを構成し、アプリケーションデータソースの構成を変更する必要があります。
MHA
MHAのフルネームはMySQLマスター高可用性です。これはFacebookエンジニアの松信義典によって開発されたMySQL高可用性フレームワークです。Perl言語に基づいて開発されており、通常30秒以内にマスターとスレーブを切り替えることができます。マスターノードは、切り替え中にSSHを介してコピーされます。
MHAは、MySQLメインデータベースの高可用性を担当します。メインデータベースに障害が発生すると、MHAは、元のメインデータベースに最も近い番号の候補ノードを新しいマスターノードとして選択し、以前とは異なるBinlogを完成させます。マスターをダウンします。データが完成した後、VIPは新しいメインライブラリにドリフトするように書き込まれます。具体的なアーキテクチャ図は次のとおりです。
利点
- 特定の障害に応じた自動検出とフェイルオーバーを実現できます
- 優れたスケーラビリティ、データノードの数は任意に拡張できます
短所：
- 極端な場合、スプリットブレインが発生し、複数のマスターが表示されることがあります。
- SSH情報を設定する必要があります。
- 少なくとも3つ必要です。
MGR
MGRはデータベースでサポートされています。プラグインを構成するだけで済みます。マスターノードに障害が発生すると、マスターになるスレーブが自動的に選択されます。手動による介入は必要ありません。データの整合性を確保するために、グループレプリケーション（paxosアルゴリズム）に基づいています。
MGRの特徴
- 分散Paxosプロトコルに基づいて高い整合性を実現し、データの整合性を確保するためのレプリケーションを実現します。
- 高いフォールトトレランス、自動検出メカニズム、ほとんどのノードがダウンしている限り、データベースは引き続き機能し、防爆メカニズムが組み込まれています。
- 高いスケーラビリティ。新しいノードを追加した後、データが他のノードと一致するまで、自動的に増分同期を実現します。
- 柔軟性の高いシングルマスターモードとマルチマスターモードが用意されています。シングルマスターモードはマスターノードのダウンタイムをサポートし、マスターを自動的に選択します。マルチマスターモードはマルチノード書き込みをサポートします。
MySQL InnoDb Cluster、複数のコンポーネントで構成される完全なデータベース高可用性ソリューションフレームワーク
- DB拡張と障害移行を提供するMySQLグループレプリケーション
- 軽量ミドルウェアであるMySQLルーターは、アプリケーション接続ターゲットのフェイルオーバーを提供します。
- MySQLシェル、新しいMySQLクライアント、複数のインターフェイスモード、グループレプリケーション、ルーターを設定できます。
オーケストレーター
レプリケーショントポロジの調整、自動フェイルオーバー、手動切り替え機能などをサポートするMySQLの高可用性およびレプリケーショントポロジ管理ツールは、UIを直接ドラッグすることで、マスタースレーブ切り替えを実現できます。
サブライブラリとサブテーブル
サブライブラリサブテーブルは通常、垂直サブライブラリと水平サブテーブルを指します。垂直サブテーブルの場合、実際には幅の広いテーブルを小さなテーブルに分割します。技術的な課題はそれほど多くありません。ここでは、焦点を当てます。垂直サブライブラリと水平サブテーブル。
垂直サブライブラリ
垂直サブデータベースとは、データベースの垂直セグメンテーションを指し、通常、ビジネスの規模に応じて分割されます。
たとえば、一般的なマイクロサービスアーキテクチャでは、システムはビジネスの側面に応じて垂直方向に分割され、複数のサービスに分割されます。たとえば、eコマースWebサイトは、注文、製品、メンバーシップ、支払い、その他のサービスに分割できます。
垂直サブデータベースの後、ビジネスはより単純になり、責任は単一になり、データベース容量の問題の一部は同時に解決できますが、次のように新しい技術的な複雑さももたらします。
- 分散トランザクション、データベース間のトランザクション操作には分散トランザクションのサポートが必要です。そうしないと、システムはデータの不整合の問題に直面します。解決策1、XAトランザクションを採用します。XAトランザクションはデータベース自体が仕様をサポートし、強い整合性特性を備えていますが、パフォーマンスは比較的劣ります。XAトランザクションは、高いパフォーマンスを追求するシナリオには適していません。2番目の解決策は、柔軟なトランザクションを使用することです。柔軟なトランザクションとは、データベースがローカルトランザクションを保証し、グローバルトランザクションの実現がビジネスレイヤーによって実現されることを意味します（スケジュール補償、再試行補償、手動介入など）。一般的な解決策柔軟なトランザクションには、TCC、使用率が含まれます。メッセージキューはトランザクションを実装します。
- 結合の問題、サブデータベースの後、テーブルが異なるデータベースに分散し、SQLを直接使用してJOIN操作を実行することは不可能であり、ビジネス層はそれ自体で集計操作を実装する必要があり、開発コストが増加します。
レベルスコア表
水平シャーディングとは、一定のルールに従ってテーブルを複数のテーブルに分割することです。分割後のテーブルの構造は分割前とまったく同じですが、データが複数のテーブルに分散しているため、データシャードになることもあります。
テーブルを水平に分割することにより、単一のテーブルの容量とパフォーマンスの問題が解決されます。しかし同時に、レベルスコアリングテーブルの後に、主に次のように、新しい技術的な複雑さが導入されました。
- ルーティングの問題：ビジネス層がSQLを介してデータベースに対してDML操作を実行する場合、どのテーブルを照会する必要がありますか？オプション1：範囲ルーティング。テーブルは、テーブル内の列（シャーディングキー）の値の範囲に応じて分割されます。たとえば、メインテーブルは作成時間に応じて複数のテーブルに分割され、各月のデータは別のテーブルに保存されます。範囲ルーティングではデータ分散が不均一になる場合がありますが、テーブルの数は簡単に拡張できます。オプション2：ハッシュルーティング。テーブルの列とフラグメントの数に基づくモジュロ演算（field_value％table_num）。ハッシュルーティングは、範囲ルーティングの反対です。テーブルの数が増えると、データは再配布されますが、データはより均等に配布されます。
- テーブルが分割された後、データが複数のテーブルに分散されるため、結合の問題。JOINの条件ステートメントにシャーディングキーがない場合は、すべてのシャーディングされたテーブルを再度JOINする必要があります。この操作にはパフォーマンスの問題があります。 。
- カウントの問題、テーブルが分割された後、合計を記録するためにテーブルをカウントする必要がある場合は、すべてのテーブルをトラバースしてから結果を要約する必要があります。これは別の要約テーブルで解決できますが、このソリューションには挿入または削除のたびに、サマリーテーブルを更新する必要があります。一度更新しないと、データの不整合が発生します。
- 問題による順序付け。テーブルが分割された後、並べ替える必要がある場合は、すべてのテーブルをトラバースしてから、コードレイヤーで並べ替える必要があります。この操作では、一見パフォーマンスに問題があります。
サブデータベースおよびサブメーターソリューション
- ビジネスコードレイヤーが解決され、ルーティングはSQLを介して手動で処理できますが、ビジネスとの結合は非常に深刻であり、保守が容易ではありません。これは通常、成熟したオープンソースプロジェクトsharding-jdbcの統合など、jarパッケージを統合することで解決されます。
- データベースミドルウェア、データベースミドルウェアはデータベースに対応するSQL標準を実装し、ルーティングルールはデータベースミドルウェアで構成され、ビジネスコード操作データベースミドルウェアとデータベースの直接操作に違いはありません。
総括する
シングルノードデータベースからマスタースレーブレプリケーション、データベースの高可用性、サブデータベースとサブテーブルまで、データパフォーマンス、容量、高可用性、運用と保守などの問題を解決しますが、分散トランザクションをもたらす、複雑なSQLの操作が難しい、SQLルーティングおよびその他の問題。
アーキテクチャ設計は、現在のビジネス開発に沿った「シンプルさ」、「適合性」、「進化」の原則に従う必要があります。したがって、システム設計ではサブデータベースとサブテーブルを考慮する必要はありませんが、ある程度は必要です。データのパフォーマンスのボトルネックがある場合、システムは変更および最適化されます。
元のリンク：https：//juejin.cn/post/6932298813453369358
この記事がお役に立てば幸いです。私の公式アカウントに注意を払い、キーワード[インタビュー]に返信して、Javaコアナレッジポイントとインタビューギフトパッケージをまとめてください。共有する技術的な乾物記事と関連資料がもっとあります。一緒に学び、進歩しましょう！
