腾讯雲無認証アカウント: 腾讯雲同城双活とオフサイト多活(MySQL Redis) アーキテクチャ構築ガイド
インターネットの高合併、大流量の背景で、システムの安定性は企業の生命線である。多くの技術チームはプロジェクトの初期に、サーバーとデータベースはテンセント雲の同じ空きエリア (機械室) に積まれています。普段は風が穏やかで、機械室の電源が切れたり、光ケーブルが切られたり、大面積のネットワークが故障したりすると、業務全体が瞬時に麻痺してしまう。
「高可用性」を実現するために、設計者たちは通常、二級の大きなトリックを祭る
同城双活(Multi-AZ)
そして
異郷多活(Multi-Region)
。
多くの人は「多くの仕事」を聞くと、それは大工場で遊べる基礎的な黒技術だと思っている。実は、テンセント・クラウドの成熟したクラウド製品 (TDSQL、CDB、TcaplusDB、DTSデータ転送サービスなど) を利用して、中小チームも数日以内に高可用性のマルチアーキテクチャを構築することができる。
今日のこのチュートリアルは直接核心に入って、空虚な理論を引っ張らずに、あなたを口語で分解します
同城双活
と
よその土地で多く働く
のアーキテクチャロジックを手にして、どのように配置するかを教えます
MySQL + Redis
のダブルフロア。
核心復習: 同城双活vs異郷多活、どのような違いがありますか?
手を出す前に、この2つの案の境界を明らかにしなければならない。そうでなければ、間違ったタイプを選んで、お金を焼くだけでなく、問題も解決できない。
1. 同城双活(同城多可区)
どのように構築するか: アプリケーションとデータベースを同じ都市 (例えば上海) の2つの異なる機械室 (例えば上海利用可能区2、上海利用可能区3) に配置する。
ネットワーク遅延: 非常に低い (通常 <2ms)。2つの機械室の間には専用線が引かれているからです。
データ同期: 強い一貫性。MySQLとRedisは、ほぼゼロ遅延の同期が可能です。
リスク防止: シングルルームの停電、シングルルームの火災などの物理的な故障を完全に防御する。
2.異郷多活 (地域間多活)
どのように建設するか: 二つの離れた都市 (例えば北京と広州) にそれぞれ完全なシステムを構築する。
ネットワーク遅延: 高い (北京から広州までの光速伝送にも約30msの物理遅延がある)。
データ同期: 最終的な整合性。遅延の存在により、リアルタイムでの強い同期は絶対にできず、非同期でしかコピーできない。
リスク防止: 都市レベルの災害 (地震、幹線ネットワークの断裂など) を防御する。
大口語提案: 95% の企業は、同城の仕事を実現すれば、ほとんどのダウンタイム災害に十分対応できる。あなたのDAUが千万人を超えたり、コンプライアンスに極端な要求がある場合にのみ、オフサイトでの生活を考える必要があります。
第一段階: 同城双活(MySQL + Redis) 実戦構築
同城双活の核心思想は
アプリケーション層二重活 (トラフィックは自由に切る) 、データ層一主一備 (自動秒レベル切替)
。
1.インフラ: Vpcとサブネットを画定する
腾讯クラウドでサーバーを購入するときは、それらを別の利用可能な地域に落ち着かなければなりません。
上海地域にVPCを作る。
2つのサブネットを作成します。サブネットAは上海の利用可能エリア2に属し、サブネットBは上海の利用可能エリア3に属します。
2.アプリケーション層 (clbcvm) 構成
軽量サーバまたはCVMを2台購入し、1台はサブネットAに、1台はサブネットBに投げます。
腾讯クラウド負荷分散 (CLB) を購入し、バックエンドサーバのリストに、この2台のサーバを同時にマウントし、重みを50:50に設定します。
このようにして、どの機械室がハングアップしても、CLBは一秒以内に流量をすべて別の機械室の生存の応用に導くことができる。
3.データ層: MySQL(CDB高可用性版) 構成
自分でサーバーに行ってクラスターを装着しないで、直接腾讯雲を買う
クラウドデータベースCDB(高可用性バージョン)
。
購入選択: 購入ページで、使用可能なゾーン間の導入を選択します。
ノード分配: 主ノードは上海の利用可能区2を選び、予備ノードは上海の利用可能区3を選ぶ。
基礎原理: 腾讯雲の基礎は強い同期メカニズム (Semi-Sync) を利用して、主な予備データが絶対的に一致していることを保証する。利用可能エリア2が停電すると、CDBは30秒以内に自動的に利用可能エリア3の予備ノードをメインノードにアップグレードし、アプリケーションのデータベース接続アドレス (VIP) は変更されず、コードを手動で修正する必要はない。
4.キャッシュ層: Redis (ローカルダブルライブ)
Redisは通常、キャッシュとして使用されます。同城双活の下で、腾讯雲を使うことを提案した
Redisプレミアム (空き領域間で高可用性)
、その主な準備アーキテクチャはMySQLと類似している: 使用可能なゾーン2は読み書きし、使用可能なゾーン3は非同期的に同期している。同城の遅延が極めて低いため、キャッシュが貫通する確率はごくわずかである。
第二段階: オフサイト多活(MySQL Redis) 実戦構築
異郷の多活の難易度は指数的に上昇している。北京と広州の間の遅延は30msあるので、北京の応用が地域を越えて広州のデータベースを読むと、ネットワークのオーバーヘッドはあなたのシステムをPPTのようにカードします。
異郷の多活の鉄則:
ユニット化配置、各読み取り、データ非同期混算。
1.コアの大きなトリック: 流量染色とユニット化(GSLB)
ユーザーIDで分けて、IDが奇数の北京室、IDが偶数の広州室に行くとします。
腾讯雲のグローバル負荷均衡(GSLB) または制御DNS解析を利用して、北京ユーザーが要求したとき、北京機械室のCLBに直接解析する。
地域間の呼び出しは絶対に禁止されています。北京のアプリケーションは北京のローカルのMySQLとRedisしか読み書きできません。広州のアプリケーションは広州のローカルしか読み書きできません。
2.データ層: MySQLオフサイト二重活 (DTS双方向同期を利用)
北京にはMySQLがあり、広州にはMySQLがあり、両方とも同時にデータを書き込んで、どのように同期を保つのか?
腾讯クラウドコンソールに入り、データ転送サービスDTSを検索します。
双方向データ同期タスクを新規作成します。
ソースデータベースは北京のCDBを選び
目標データベースは広州のCDBを選ぶ。
競合解決策の設定: ポイント! 「主キーをずらす」か「タイムスタンプを優先する」を選択する必要があります。例えば、北京で生成されたIDはすべて奇数で、広州で生成されたIDはすべて偶数で、双方が同時にデータベースにデータを挿入するときに主キーの衝突が発生するのを防ぐ。
🚨よその土地で多く生きている「見えない穴」 ― データ回環: 北京のデータが広州に同期していれば、広州は地元で新たに生まれたと勘違いして、北京に同期して戻ってくると、システムは死んでしまう。腾讯雲のDTSバックグラウンドには「ループバック防止」の仕組みがあり、同期したデータに特別なラベルをつけて、データが一度だけコピーされるようにします。
3.キャッシュ層: Redisオフサイト多活
Redisのデータは通常有効期限があり、変化が非常に速い。オフサイトの多活シーンでは、通常のRedisコピーはまったく耐えられない。
公式神器: 腾讯雲はRedisグローバル・レプリケーション製品を提供した。
配置方法: 北京と広州でそれぞれRedisインスタンスを購入して、コンソールで「グローバル多活グループ」に結びつけることができます。
ビジネスロジック: 両方のRedisがローカルで読み取ることができます。共有が必要なキャッシュ (ユーザーがログインしたToken状態など) については、北京で書き込まれた後、腾讯雲の基礎は専用線を通って、数十ミリ秒以内に広州に非同期的にプッシュされる。短い時間差はありますが、ビジネスニーズを完全に満たすことができます。
第三段階: 災害を許す演習と切流 (肝心な時は盲目ではない)
枠組みができたので、どうやってそれが本当に助けられることを検証しますか?定期的な演習が必要です。
シーン1: 同城双活単室がハングアップした (例えば、利用可能エリア2が故障した)。
自動部分: 腾讯雲CLBは自動的に利用可能エリア2の異常CVMを取り除く。MySQLは自動的にプライマリ・バックアップの切り替えをトリガーし、利用可能なゾーン3のバックアップ・ライブラリが読み書きを引き継ぎます。
手動確認: 運送次元登録コンソール、業務ログをチェックし、汚れたデータがないことを確認し、演習を終了する。
シーン2: 異郷多活都市級ハングアウト (例えば北京機械室全体が連絡を失った場合)
この場合、手動でルーティング・ストリームに介入する必要があります
腾讯クラウドDNS解析/トラフィックスケジューリングコンソールにログインします。
もともと北京に分流していた50% 奇数ユーザーのトラフィックを、ワンクリックで広州機械室のCLBに切り替えた。
広州の応用はこの時点で100% のユーザー要求を同時に載せ始めた。DTSはバックグラウンドで同期しているため、広州のMySQLにはすでに北京の機械室が死んだ99.9% のデータがある。
コストの受け入れ: 切り替えの過程で、最後の数ミリ秒以内に登録された北京ユーザーが「ログイン失敗」または「データ遅れ」を提示する可能性があるこれはオフサイトで多く生きている「最終的な一貫性」の理論では完全に許されている。
総括と高利用の四つの口訣
高利用可能な枠組みは一苦労永逸の銀弾ではなく、物理法則 (光速とネットワーク遅延) に妥協する芸術である。まとめてみると、4つの言葉があります
同城双活が最もお得: 利用可能な地域を越えてサービスを購入し、代わりに
1行は改めなくても、防災は9割半になる。
オフサイトの多活先区分: 業務はユニット化しなければならず、北京人は北京庫を見て、都市を越えて読み書きするのは災難である。
主キーの衝突は避けなければならない: オフサイトの二重書込み用DTS、パリティ主キーがずれて、データが混乱しないようにする。
定期的に練習して初めて安心した: 本当のことが起きてから、書類をめくって流れを見て、普段は多くの訓練をして、戦時に神威を発揮する。