既存システムのボトルネックの分析により、中心的な欠陥が分散した順序データ キャッシュに集中しており、それがデータの両端での不整合につながることが判明しました。各注文アプリケーションはデータベースに直接接続されているため、スケーラビリティが生じます。実践を通じて、データ アクセス層を抽象化して統合するためのミドルウェアを作成し、データベース デプロイメント アーキテクチャのミラーに基づいて注文キャッシュを構築してホット データを均一に管理し、異なるエンド間の差異を解決しました。
データ分析後の注文システムは通常、読み取りが多くなり、書き込みが少なくなります。ホットクエリのデータを共有してDBの負荷を軽減するには、図3.1に示すようにキャッシュを導入するのが効果的です。ユーザーのリクエストが来ると、キャッシュが最初にクエリされ、キャッシュされたデータが存在する場合は結果が直接返され、キャッシュにヒットしなかった場合は DB がクエリされ、構成ポリシーに従って DB 結果データが検証されます。検証に合格すると、DB データはその後のクエリで使用するためにキャッシュに書き込まれ、それ以外の場合はキャッシュに書き込まれず、最後に DB クエリの結果を返します。
図 3.1 オーダー キャッシュの基本設計
新しいキャッシュ コンポーネントを導入した後のハードウェア オーバーヘッドについては、元々散在していたハードウェア リソースを集約することで削減できます。総コストがかかる一方、一元管理すると使いやすさやデータの整合性の問題も生じるため、既存システムの容量評価、トラフィック見積もり、キャッシュテーブル値の分析を十分に行う必要があります。アクセス量の多いホット データ テーブルのみをキャッシュします。適切なキャッシュ構造設計、データ圧縮、およびキャッシュ削除戦略を通じて、キャッシュ ヒット率を最大化し、キャッシュ容量、ハードウェア コスト、可用性の間で適切なトレードオフを実現できます。
従来のキャッシュ設計では、1 つのデータベース テーブル レコードが 1 つのキャッシュ データに対応します。注文システムでは、1 つの注文に対して複数のテーブルをクエリすることが非常に一般的です。従来の設計を採用すると、テーブルの数に応じてユーザー クエリ内の Redis アクセス数が増加します。この設計では、ネットワーク IO が大きく、時間がかかります。消費する、長い。テーブル ディメンションのトラフィック データを調べたところ、いくつかのテーブルが一緒にクエリされることが多く、クエリ トラフィックの 90% を超えるテーブルが 30% 未満であることがわかりました。ビジネスの観点からは、それらは同じものに分類できます。図 3.2 では、キーとして注文番号、フィールドとしてフィールド名、値としてフィールド データを使用するなど、ハッシュ構造に基づいて格納されます。
この方法では、単一テーブルであっても複数テーブルクエリであっても、各注文は Redis に 1 回アクセスするだけで済むため、キーが減り、複数テーブルクエリの数が減り、パフォーマンスが向上します。同時に、値は protostuff に基づいて圧縮されるため、Redis のストレージ容量とその後のネットワーク トラフィックのオーバーヘッドも削減されます。
図 3.2 ドメインベースのストレージ構造の簡単な説明
ロスレス ホット マイグレーションを実現する方法は、プロジェクト全体 最も困難な場所。事前作業としては、まずデータベース層とビジネス層のアプリケーションを分離し、プロセス設計を行えるようにするためのミドルウェアの開発を完了します。次に、抽象的な Dao 層がドメイン化を実装し、データ ドメイン層がアプリケーションにデータ サービスを提供し、そのドメインの下に SQLServer と MySQL の 2 つのデータベースが適応され、均一にパッケージ化されます。これに基づいて、次のプロセス設計に対してロスレス サーマル マイグレーションを実装できます。
SQLServer と MySQL のデュアル データベースはオンラインであり、二重書き込み、プライマリ SQLServer 書き込み、および同期書き込みセカンダリ MySQL を実装しています。SQLServer 操作が失敗すると、操作全体が失敗し、二重書き込みトランザクションも失敗します。ロールバックされます。
SQLServer と MySQL の間に同期ジョブを追加して、SQLServer の最新の時間枠で変更されたデータをリアルタイムでクエリし、MySQL のエントリの一貫性を確認します。差異は次のように追跡できます。これは、この期間中に双方の間で予期せぬ不一致が発生した場合、特に SQL Server アプリケーションへの直接アクセスがまだある場合に特に役立ちます。
このミドルウェアは、あらゆるメジャー クエリ ディメンションをサポートする構成システムで設計されており、構成に従ってデータ ソースを SQLServer または MySQL に正確に送信し、それをロードするかどうかを制御できます。読み取り後に注文キャッシュに保存されます。初期設定では、2 つのデータベース間のデータの不一致によって引き起こされるキャッシュ データのジャンプを回避するために、SQLServer データ ソースのみをロードします。初期段階では、グレースケールを設定し、少数の非コア テーブルを MySQL に直接接続して検証し、信頼性を確保できます。遅延データの一貫性の期待が達成されると、指定されたデータベースに対して注文キャッシュを自由にロードできます。
データのクエリ時にデータの整合性を確保した後、トラフィック ポリシーは、図 3.3 の制御可能なディメンションに基づいてデータベースへの単一書き込みをサポートします。実際のプロジェクトでは、シングルライトは主にテーブル ディメンションで実装されており、指定したテーブルがシングルライト MySQL で構成されている場合、そのテーブルに関係するすべての CRUD 動作はキャッシュ ロード ソースを含めて MySQL に送られます。
最後に、外部から送信される注文メッセージはミドルウェアを介して統合され、すべてのメッセージはミドルウェアの CUD 操作に基づいて送信され、物理データベースとは何の関係もありません。 、メッセージのデータ ソースは透過的であり、上記にリンクできます。すべてのプロセス操作とデータ リンクは一貫性を保ちます。
図 3.3 運用プロセスの概要
本番データからデータへの理解 ウェアハウス ODS 層データの移行は、下流ユーザーには透過的 ここでは、従来のデータ ウェアハウスの階層システムについて簡単に紹介します。通常、データ ウェアハウスは主に 5 つの層に分かれています: ODS (オリジナル データ層)、DIM (ディメンション)、EDW (エンタープライズ データ ウェアハウス)、CDM (共通モデル層)、ADM (アプリケーション モデル層)、
以下に示すように:
図 3.4 データ ウェアハウスの階層構造
図 3.4 からわかるように、データ ウェアハウスの各層は ODS 層のデータに依存しており、データ プラットフォームのすべてのアプリケーションに影響を与えないように、元の注文ライブラリを変換するだけで済みます。ODS レイヤーのデータ ソースは SQLServer から MySQL ライブラリに移行できます。
図から、移行はデータソースを変更するだけで済むことが直感的にわかります。それほど面倒ではありませんが、データ品質を確保するために、次のような多くの準備作業を行っています。 : DBA は事前に本番データを本番に同期します。MySQL データベース、MySQL データのリアルタイム同期、本番の両側でのデータ整合性検証、MySQL 側の ODS 層へのデータ同期、ODS 層のデータ整合性検証、および元の ODS 層同期ジョブデータソースの切り替えなど
その中で、本番環境の両側でのデータ整合性チェックとデータ ウェアハウスの ODS 層でのデータ整合性チェックは、最も複雑で時間がかかります。データ ソースを切り替える前に、フィールドに一貫性がある必要があります。ただし、実際の運用では完全に一致するわけではありません。時刻型、浮動小数点値の精度、小数点以下の桁数などは、実際の状況に応じて適切に処理してください。
以下はプロセス全体の概要です:
まず、オンライン データの整合性検証のために、SQLServer データと MySQL データを比較するオンライン同期ジョブを開発しました。 、不一致が見つかった場合、MySQL データは SQLServer データに基づいて更新され、両側のデータの一貫性が保証されます。
2 番目に、オフライン データの整合性検証のために、データ ウェアハウスの同僚と協力して MySQL 側のデータを ODS レイヤーに同期し (SQLServer か MySQL テーブルかを区別するためにデータベース名を使用します)、スケジュールされたタスクを組み合わせます。 SQL Server 側のタスクは、時間内で可能な限り一貫している必要があります。双方のデータが準備された後、オフライン データ検証スクリプト ジェネレーターを開発し、データ ウェアハウスのメタデータに基づいて各テーブルの同期ジョブを生成し、スケジューリング プラットフォームにデプロイしました。
同期タスクは、両側の ODS 層同期データに依存します。T1 データ同期が完了すると、一貫性チェックが実行され、一貫性のない注文番号が一貫性のない詳細テーブルに記録されます。不整合なデータ量がカウントされ、結果が統計テーブルに保存されます。次に、セルフサービス レポート プラットフォームでレポートを作成し、矛盾したテーブルの毎日の統計と矛盾の量をメールボックスに送信します。矛盾したテーブルのトラブルシューティングを毎日行って、問題を発見し、比較戦略を調整し、比較ジョブを更新します。 。一般的なプロセスは次のとおりです。
図 3.5 全体的な一貫性検証プロセス
最後に、オンライン データとオフライン データの一貫性が徐々に高まるにつれて、データODS 層ジョブに同期された元の SQLServer のソースが MySQL に切り替えられました。ここにいる学生の中には、「なぜ MySQL 側の ODS 層のテーブルを直接使用しないのですか?」という疑問を持つ人もいるかもしれません。その理由は、統計によると、元の ODS レイヤー テーブルに依存するジョブが数千個存在するためで、依存するジョブを MySQL 側の ODS テーブルに切り替えると、変更作業負荷が非常に高くなるため、元の ODS を直接切り替えます。レイヤ同期データ ソースを MySQL にインポートします。
実際の運用では、すべてのデータソースを一度にカットすることはできません。3 回のバッチに分けて実行します。最初のバッチとして、重要度の低いテーブルを十数個見つけます。カット後、2 週間実行してフィードバックを収集します。ダウンストリームデータの問題について。サンプルの最初のバッチは 2 週間後に正常に分析され、下流のレポートでデータの問題は発生しませんでした。これはサンプル データの品質の信頼性を証明しています。次に、残りの数百のテーブルを重要度に応じて 2 つのバッチに分割し、完了するまで切断を続けます。
この時点で、データ ウェアハウス層での注文データベースの SQLServer から MySQL への移行が完了しました。
実際、どんなに綿密な分析と設計を行ったとしても、実行プロセス中にさまざまな課題に遭遇することは避けられません。古典的な問題をいくつかまとめました。これらの大小さまざまな問題は、最終的には技術的な手段によって解決され、目標は達成されましたが、読者の皆さんには、より良い解決策があるはずです。一緒に学び、進歩できることを嬉しく思います。
注文システムには多数のアプリケーションとテーブルが含まれており、1 つのアプリケーションは 1 ～ n 個のテーブルに対応し、1 つのテーブルに対応します1 対 n のアプリケーションは、典型的な多対多の関係に対応します。図 4.1 に示すように、ある SQLServer データベースから別の MySQL データベースに切り替える上位層アプリケーションの場合、基本プロセスは、操作プロセスの章に従って少なくとも次のステップに分割されます。 ## 単一書き込み SQLServer から二重書き込み SQLServer と MySQL になる
単一読み取り SQLServer から単一読み取り MySQL へ
二重書き込み SQLServer から MySQL へMySQL を単独で書き込むための SQLServer と MySQL の書き込み
オフライン SQLServer
スイッチング処理では、二重書き込み、単一読み出し、単一書き込みの各処理が段階的に連動・依存しており、それを支援する設計モニタリング手法として、前回の動作が期待通りの効果を発揮していることを事前に確認する必要があります。次へ進みます。きれいに切り替えることなく、軽率に次のステップをスキップしたり次のステップに進んだりすると、たとえば、二重書き込みが完全に整合する前に MySQL データの読み取りを開始すると、データが見つからないか、ダーティなデータが見つかる可能性があります。次に、各 CRUD 操作の読み取りと書き込みを監視し、移行プロセス中に死角のない 360 度の視覚的なトラフィック セグメンテーション制御を実現する必要があります。具体的な方法は次のとおりです:
すべてのアプリケーションがミドルウェアに接続され、構成に従ってどの DB のどのテーブルを読み書きするかはミドルウェアによって CRUD が制御されます。
DB への書き込み後のキャッシュ削除の遅延により、信頼性の低いネットワークや GC などのダーティなキャッシュ データが読み取られ、キャッシュ削除の遅延が発生します。
DB への書き込み後にキャッシュを削除しないと読み取りが行われる Redis のマスター/スレーブ切り替え中など、ダーティ データのキャッシュは読み取りのみ可能ですが、書き込みはできません。
キャッシュの一貫性の問題を解決するために、図 4.2 に示すように、元のキャッシュと DB に基づいたオプティミスティック ロックと CUD 構築マーカーを追加して、同時実行時のデータの同時ロードを制限しました。キャッシュが互いに上書きし合う動作、および現在チェックされているデータに対して CUD 操作が実行されているという認識。楽観的ロックに基づく最終ライター勝利メカニズムを使用すると、クエリ トラフィックを実現して DB に直接接続し、これら 2 つのシナリオが終了しない場合の競合問題を解決できます。最終的に、キャッシュの不整合率は 100 万分の 2 から 1,000 万分の 3 に制御されました。
図 4.2 キャッシュ整合性ソリューション
図 4.2 クエリがキャッシュを欠落している場合、または現在データにオプティミスティック ロックまたは構築マークがある場合、直結DBに問い合わせを行い、該当トランザクションが完了するまでキャッシュデータの自動ロード機能を解除します。
プロジェクトの開始時に、MySQL 用に過去 N 年間のデータを一度だけ準備しました。二重書き込み段階では調整できない次の問題があります。 2 つのシナリオのデータ:
製造オーダー データベースは、ほぼ N 年間のデータを保持するように事前設定されているため、責任のあるジョブは、 MySQL がミドルウェアに接続される前にバックアップが N 年間存在していたので、このデータのバッチをポリシーで上書きしてクリアすることはできません。
すべてのアプリケーションをミドルウェアに接続するには時間がかかります。ミドルウェアを二重書きする前にデータが不整合になる可能性があります。すべてのミドルウェアを適用して二重書き込みする必要があります。以前のデータを書き換える前に、すべてのテーブルを一度に修復します。
最初の点に対応して、MySQL データ クリーニング ジョブを開発しました。注文データベースには複数のシャードがあるため、コア スレッドの総数はジョブ内で内部的に設定されます。実際のシャード数。各スレッドは、対応するシャード内の指定されたテーブルのクリーニングを個別に担当し、複数のサーバーを並行して実行してクリーニングのタスクを分散します。速度制御により、運用データベースの負荷に影響を与えることなく効率が確保されます。
2 番目の点に関しては、すべてのアプリケーション インターフェイス ミドルウェアとすべてのテーブルが二重に書き込まれた後、オンライン同期ジョブ スキャンの開始タイムスタンプを調整することで既存の注文データを修復できます。修復するときは、大量のデータがロードされて注文データベース サーバーの CPU が高くなりすぎることを防ぐために、スキャンされたデータを期間に応じてスライスで処理する必要があることに特別な注意を払う必要があります。
巨大なシステムでデータベースのライブ マイグレーションを実行したい場合、さまざまなデータベース間の類似点と相違点を深く理解する必要があります。効果的に問題を解決します。 MySQL と SQL Server はどちらも一般的なリレーショナル データベースであり、どちらも標準化された SQL クエリをサポートしていますが、詳細にはまだいくつかの違いがあります。移行中に直面する問題を詳しく見てみましょう。
1) 自動増分キーの問題
自動増分シリアル番号の不一致によるデータ修復のさらに大きなリスクを回避するには、次の 2 つの点を確認する必要があります。データベースは同じ自動増分シリアル番号を共有します。したがって、それぞれが自動インクリメント操作を実行できるようにすべきではありません。したがって、データが二重に書き込まれるときは、SQLServer によって生成された自動インクリメント ID を MySQL 自動インクリメント列に書き戻します。データが MySQL のみに書き込まれるときは、MySQL を使用して自動インクリメント ID 値が直接生成されます。
2) 日付の精度の問題
二重書き込み後のデータの一貫性を確保するには、両側のデータの一貫性をチェックする必要があります。タイプは Date、DateTime、タイムスタンプ フィールドの格納精度が一貫していないため、比較中に特別な処理が必要となり、データは比較のために数秒単位でインターセプトされます。
3) XML フィールドの問題
SQL Server は XML データ型をサポートしていますが、MySQL 5.7 は XML 型をサポートしていません。代わりに varchar(4000) を使用した後、MySQL データの書き込みが失敗するケースが発生しましたが、同期ジョブは SQLServer データを MySQL に正常に書き戻すことができました。分析後、プログラムは書き込み時に非圧縮の XML 文字列を書き込みます。SQLServer XML タイプはそれを自動的に圧縮して保存しますが、MySQL はそうではありません。その結果、4000 を超える長さの書き込み操作は失敗し、SQLServer 圧縮後の長さはは 4000 未満であり、MySQL に正常に書き戻すことができます。このため、書き込み前に圧縮して長さを検証する、重要でないフィールドを保存する前にインターセプトする、重要なフィールドの保存構造を最適化する、またはフィールドの種類を変更するなどの対策を提案します。
次に、移行プロセス中に注意すべき一般的な点をいくつか示します。
当社の早期警告の実践は、プロジェクトの進行中の要件の監視に限定されません。データ書き込みの異常、プロジェクト完了時の二重書き込みデータの一貫性率のレビュー、注文ライブラリの各シャードの注文書き込み量の通常の傾向をリアルタイムで監視して早期に警告する方法、および定期的に警告する方法システム全体の高可用性の受け入れ/検証については、次のページで説明します。
SQLServer から MySQL データベースへの注文データ移行の要件を満たすには、データ品質が移行の必須条件です。移行では、合理的な検証計画を設計することが移行の進行状況に関係します。データ検証については、オンラインとオフラインの 2 つのタイプに分けられます。
オンライン データ検証と早期警告
移行中、ジョブを同期し、一貫性のないデータを計算し、一貫性のないテーブルとフィールドを ElasticSearch に書き込み、次に Kibana を使用して一貫性のないデータの量と割合を監視するダッシュボードを作成しました。監視ダッシュボードを使用して、データの不整合が大きいテーブルをリアルタイムで監視し、DBA ツールを使用してテーブル名に基づいてテーブルに対して CUD 操作を実行したアプリケーションを特定し、アプリケーションをさらに特定できます。ミドルウェアが欠落しているコード。
実際の運用では、ミドルウェアに接続されていないアプリケーションを多数発見し、変更することができました。ミドルウェアに接続されるアプリケーションが増えるにつれて、データの整合性は徐々に向上していきます。監視ダッシュボードより見られる不一致の量も徐々に減少しています。しかし、一貫性がゼロになることはなく、その原因はアプリケーションと同期ジョブの同時実行によって引き起こされ、これが最も厄介な問題でもあります。
おそらく学生の中には、二重書き込みになるのだから同期ジョブをやめればよいのではないかと疑問に思う人もいるかもしれません。その理由は、SQL Server が主な書き込み方法であり、ミドルウェアがカバーする CUD 範囲がベンチマークとして使用されるためであり、MySQL へのデータ書き込みが 100% 成功することを保証しないことに加えて、データの量が2 つのデータベースは同等であるため、一貫したジョブが必要です。データを完全に一貫させることはできませんが、同時処理により不整合をさらに減らすことができます。
私たちのアプローチは、整合性ジョブを比較するときに 5 秒の安定ラインを設定することです (つまり、現在時刻から 5 秒以内のデータは不安定なデータとみなされます)。安定線の外側を比較する場合は、注文データが安定線内にあるかどうかを再計算し、全てのデータが安定線の外側にあることが確認できた場合に比較演算を行います。比較は中止され、次のスケジュールのテストで一貫性校正が実行されます。
初回の訓練では、Redis の接続が切断された際にアプリケーションエラーが急増したため、思い切って訓練を中止し、問題の原因を調査しながらロールバックしました。一部のアプリケーションの Redis 動作は統一的に管理されておらず、ミドルウェアによって制御されていないため、Redis が壊れると、アプリケーションはすぐに異常になります。この状況に対し、エラー報告アプリケーションのオーダーキャッシュアクセスポートを解析してミドルウェアに接続するとともに、ミドルウェアとRedis間の弱い依存関係を強化し、Redis操作のワンクリック切断をサポートし、さまざまなメトリクスの監視が改善されました。 2 回目の訓練では、Redis サーキット ブレーカーが成功し、すべてのビジネス システムが MySQL への完全なトラフィック アクセスで正常に実行されました。最新の Wandering Earth 演習では、コンピュータ ルームのネットワーク ブロッキングや非コア アプリケーションのブロッキングなどの一連のフォールト インジェクションの後、私たちのシステムは期待どおりの非常に良好な結果を達成しました。
このようにして、訓練に次ぐ訓練で問題を発見し、経験を要約し、システムを最適化し、緊急時計画を改善し、突然の障害に対処するシステムの能力を段階的に向上させ、ビジネスの継続性とデータの整合性を確保しました。 . セックス。ホテルの注文システム全体を保護するための基礎となるデータ サポートを提供します。
当社には、サーキット ブレーカー訓練、自動障害などの完全な監視ボードと早期警告システムがありますが、訓練、ハードウェアの障害とメンテナンス、および事前に予測できない問題が発生した場合、コア開発者が現場での操作に時間内に対応できなかった場合、システムは完全に自律的に機能を低下させることができず、応答時間の増加などのパフォーマンスの低下につながる可能性があります。 、など。将来的には、手動制御ダッシュボードを追加する予定です。認可後、NOC または TS に対象操作の実行を許可できます。たとえば、Redis クラスターの全体または一部がダウンした場合、障害のある Redis シャードをワンクリックで切断できます、または Redis の計画停止期間に基づいて、事前に切断時間を設定することで、システムの制御性を最大限に確保できます。
手動制御が可能なため、将来的には一部のコア指標の監視も検討します。第 2 レベルでは、ただし、一部の Redis が 10 秒以上書き込めないという状況も経験しました。このとき、キャッシュとデータベースの間で矛盾するダーティ データの量を監視できます。また、適用することもできます。 Redis に障害が発生した場合に異常な応答時間のしきい値を監視することで、ミドルウェアが自動的にこれらの障害のあるホストをダウングレードして切断し、サービスの基本的な安定性を確保し、クラスター インジケーターが安定していることを検出した後、徐々に回復を試みるいくつかの戦略があります。
現在の発注チームは、JAR 形式のミドルウェアを使用しています。このミドルウェアは、データベース内の根本的な違いを保護し、より複雑な機能を実現するために Redis を操作します。当然、サービス メッシュにアクセスする機能が備わっています。アクセス後は、基盤となるアップグレードが高速化され、煩わしさが軽減され、呼び出しが軽くなり、フレームワークとのグリッドの統合が向上し、クラウドがより便利になり、より適切なサポートが可能になります。 Ctrip の国際化戦略、目標。
以上がSQL Server センサーレス システムを MySQL に移行する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
