はじめに（ペインポイント分析）
Eコマース・プラットフォームのアーキテクトやデベロッパーとして、「618」や「ダブル11」のような大型プロモーションを準備する際、秒殺シナリオに不安を感じたことはないだろうか。大勢のユーザーが同時にやってきて、必死に「今すぐ購入」をクリックするとき、システムは厳しい試練に直面しています：
- 在庫は売られすぎている。データベースの読み書きの競合が同時に発生し、実際の在庫が完売しているにもかかわらず注文が正常に生成されたため、資本損失と顧客からのクレームが発生した。
- データベースのボトルネック。スパイク・リクエストは津波のように中央データベースに押し寄せ、CPUとコネクション数を爆発的に増加させ、レスポンス・レイテンシを急増させ、さらには雪崩を起こしてシステム全体を停止させる。
- 貧弱なユーザーエクスペリエンス。ページの読み込みは遅く、ボタンは反応せず、ユーザーは「システムが混雑しています」というメッセージを見るだけで、結局は失望して去ってしまう。
一文で要約する。在庫の過剰販売、データベースのボトルネック、高同時実行スパイク・シナリオにおけるシステムの安定性に悩んでいるなら、この記事はTencent Cloud TDSQL-Cに基づく完全で高性能なソリューションを提供します。
解决方案架构图与概述
下図はTencent Cloud TDSQL-Cベースのスパイク・ソリューションのアーキテクチャを明確に示している。
アーキテクチャ図の説明：ユーザーリクエストはTencent Cloud CDNを経由してアクセラレートされた静的リソースにロードされ、ロードバランシングCLBを経由して分散される。ビジネス・アプリケーション・レイヤーはCVM上に配置され、ホットスポット・データ・キャッシュとしてTencent Cloud Redisにアクセスする。最も重要なのは、在庫控除の中核となるトランザクション操作が、高性能で互換性の高いTDSQL-C（PostgreSQLバージョン）データベースによって直接完結され、絶対的なデータの一貫性と高性能が保証されることだ。
ワークフローの概要。
- 交通アクセスと流通。ユーザーのリクエストは、まずTencent CloudのCDNによって静的ページのロードが高速化され、次にロードバランシング（CLB）によってバックエンドのビジネス・サーバー・クラスタに均等に分散される。
- 読み書き分離。ビジネスサーバーが商品情報などの非中核データを読み込む際には、Tencent Cloud Redisキャッシュへのアクセスが優先されるため、データベースへの負荷が大幅に軽減される。在庫控除のコア・トランザクションでは、アプリケーションはTDSQL-Cのメイン・インスタンスに直接接続する。
- コア控除。TDSQL-Cは、PostgreSQLの強力なトランザクション処理機能と行レベルのロックを利用し、データベースレベルで「在庫照会→0より大きいか判定→在庫控除」の処理をアトミック操作で実行することで、売れ残りを根本的に解消することができます。
- 結果が返ってきた。推論が成功すると、キャッシュが更新され、成功した結果がユーザーに返される。読み取り専用のインスタンスは、注文クエリのような読み取り要求を引き受ける役割を担い、メインデータベースへの負担をさらに軽減します。
価値提案。ソリューションは、“Redisキャッシュホットデータ+ TDSQL - Cは、コアトランザクションを保護するために ”アーキテクチャを介してだけでなく、キャッシュの高いパフォーマンスを活用するだけでなく、データの一貫性の能力の非常に高い並行性のデータベースは、2番目の殺害のコアの痛みのポイントに完璧なソリューションを確保する。
核心产品与组件详解
| コア・コンポーネント | 役を演じる | 关键配置/选型建议 | なぜそれを選んだのですか？ |
|---|---|---|---|
| テンセントクラウドTDSQL-C（PostgreSQL版） | 在庫控除のための強力な一貫性トランザクションのためのコアデータレイヤー。が売れすぎ問題を解決する鍵である。 | サーバーレスバージョンを選択することをお勧めします。このバージョンは、実際のコンピューティングリソースの使用量に応じて容量を自動的に拡大・縮小し、急増に容易に対応することができます。 | 極限のパフォーマンス。コンピュートとストレージの分離アーキテクチャにより、I/O性能はローカルSSDの2～3倍で、ミリ秒単位のレスポンスを保証。 100%はPostgreSQLと互換性があります。ビジネスコードを変更することなく、スムーズな移行が可能。 エクストリーム・ハイ・アベイラビリティ。マルチコピーデータ冗長性、自動フェイルオーバー、最大99.99%のサービス可用性。 |
| テンセント・クラウド・レディス | 商品詳細ページやスパイク状況などをキャッシュするキャッシュレイヤー。読み取りリクエストの大部分を引き受け、バックエンドのデータベースを保護する。 | 読み書きの速度を確保するためにメモリタイプの仕様を選択し、妥当な有効期限を設定する。キャッシュのウォームアップ。 | 超高スループット。数十万QPSをサポートし、データベースの負荷を大幅に軽減。 データ構造の充実。サポートリスト、セットなどの複雑なロジックを数秒のキューで実現することができます。 データの永続性。キャッシュの再スタートによるデータ損失を回避。 |
| テンセント・クラウド・ロードバランシング（CLB） | 膨大なユーザーリクエストを複数のバックエンド・ビジネス・サーバーに均等に分配するトラフィック・ポータル。 | レイヤー4（TCP）またはレイヤー7（HTTP/HTTPS）リスニング用に設定し、異常なバックエンドサーバーを自動的に拒否するヘルスチェックをオンにする。 | 超高同時性。1つのクラスタが数億の接続をサポートし、トラフィックのピークに容易に対処できる。 利用価値が高い。クラスタ化された配備は、単一障害点を排除します。 伸縮自在。流量に応じて自動的に調整できる。 |
| クラウドサーバー（CVM）／エラスティック・スケーリング（AS） | ビジネスロジックを実行するアプリケーションサーバー。 | エラスティック・スケーリング・グループを使用し、CPU使用率や同時接続数などの指標に基づいて、スパイク中はサーバー数を自動的に増やし、スパイク後はサーバー数を減らすことで、コストを節約します。 | 柔軟な構成。幅広い計算仕様があり、必要に応じて選択できる。 CLBとのシームレスな統合。スケーリング・グループ内のCVMは、CLBへの登録と解除を自動的に行う。 |
この計画のメリットをまとめたものです。
- ⛓️ 売り過ぎに終止符を打つ。TDSQL-Cの強力なトランザクション特性に基づいて、正確な在庫控除を実現し、根本から過剰販売による資本損失と顧客クレームを回避することができます。
- ⚡ 極限のパフォーマンス。TDSQL-Cの極端なI/O性能とRedisキャッシュは、スパイク中の安定したスムーズなシステムを保証し、注文するユーザーには絹のようなスムーズな体験を提供する。
- 📈 弾力的な高可用性。フルリンクの高可用性設計（CLB、CVMスケーリンググループ、TDSQL-Cマルチコピー）、システムに単一障害点はなく、制御可能なコストでトラフィックフローに応じて自動的に拡張することができます。
- 🛡️ スムーズな移行。TDSQL-C 100%はPostgreSQLと互換性があり、既存のサービスにほとんど手を加えることなくアクセスできるため、技術的な敷居と移行リスクを大幅に軽減することができます。
应用场景与适用客户
- 核となるシーンeコマース・プラットフォームにおける、秒単位、ラッシュ、期間限定スペシャル、懸賞などの瞬間的な高集中シナリオ。
- 适用客户特征：
- ビジネスには定期的あるいは突発的なトラフィックのピークがあり、キャパシティを拡大したり縮小したりするためのシステムの弾力性が強く求められている。
- データの一貫性要件が非常に高いため、在庫の売り越しなどのビジネス上の脆弱性は容認できない。
- 現在PostgreSQLデータベースを使用しているが、より堅牢で手間のかからないクラウドデータベースソリューションを探している。
日本語