はじめに(ペインポイント分析)
親愛なる電子商取引の設計者や開発者は、“ダブル11”、“618 ”とユーザーのトラフィックの津波に直面して、吹き荒れる戦いの角笛の他の大きなプロモーションは、これまで、次のような問題のためにされている?
- システムは即座にダウンした。スパイクが始まった瞬間、何百万人ものユーザーが同時にクリックし、瞬間的なトラフィックがデータベースを介して直接ピークに達し、システム全体がクラッシュし、ページを開くことができず、巨大なトランザクションの損失。
- 在庫過剰販売の難問同時リクエストの下では、従来のデータベースの読み取り/書き込みロッキング性能のボトルネックが浮き彫りになり、在庫控除エラーや「売り越し」現象につながりやすく、その結果、大きな資本損失や顧客からのクレームが発生する。
- 反応は極めて鈍い。システムが完全にダウンしたわけではなかったが、核となるトランザクション・リンクは遅く、ユーザーは注文リクエストに何十秒も待たなければならず、エクスペリエンスは極めて悪く、ショッピングカートの放棄率は急上昇した。
- 資源コストとレジリエンスの難問。ピークに対応するために購入した大量のマシンが、スパイクの直後にアイドルとなり、リソースの利用率が極端に低下し、高いコストとなる。手作業による増設・縮小は非効率的で、トラフィックの瞬間的な変動に対応できない。
数百万QPSの同時実行に対応し、データの一貫性を確保し、コストを最適化したスパイク・システムを設計する方法に悩んでいるのであれば、テンセント・クラウドが提供するこの大規模なビジネス実績のあるスパイク・アーキテクチャ・ソリューションは、明確で信頼できる答えを提供してくれるだろう。
解决方案架构图与概述
次の図は、Tencent Cloud Secondsソリューションのコア・アーキテクチャとデータ・フロー・プロセスを示している:

このプログラムの核となる設計思想は以下の通りである。“レイヤード・インターセプション、非同期処理、究極の一貫性”ワークフローは以下の通り:
- 1.交通アクセスとスケジューリング。ユーザーリクエストはまずグローバル・アプリケーション・アクセラレーション(GAAP)もしかしたらシーディーエヌ高速アクセスの入り口ロードバランシング(CLB)均等に分配する。
- 2.読み取り要求の最適化とチェックサム。大半のクエリーリクエスト(商品詳細や在庫確認など)は、高性能のレディスキャッシュ。同時に、新しいキャッシュを作成するにはクラウド機能(SCF)軽量の権限検証(CAPTCHAなど)と悪意のあるリクエストの遮断を実装する。
- 3.書き込み要求のクリッピングと非同期化。コアスパイクリクエストは、チェックサムを渡した後、データベースを直接操作せず、直ちにメッセージキュー CKafkaキューの途中で、すぐにユーザーの「キューイング」ステータスに戻る。これにより、瞬間的なピークが平準化され、バックエンドへの負担が大幅に軽減される。
- 4.注文処理とデータの永続性。バックエンドの注文処理サービスは、データベースを完成させるために、CKafkaから均等な割合でメッセージを消費する(MySQL用TencentDB)トランザクションの在庫控除と注文作成、キャッシュの更新。
- 5.結果の通知処理が完了すると、最終的な注文結果がWebSocketまたはロングポーリングによってユーザーに通知される。
建築の価値提案はこうだ。メッセージ・キューイング(CKafka)により絶対的なトラフィック削減を達成し、キャッシュ(Redis)により読み取り圧力の大部分を引き受け、エラスティック・スケーリング(AS)により計算需要に柔軟に対応する。このようにして、壊れやすいリレーショナル・データベースを保護し、高い並行性のもとでもシステム全体が安定性と効率性を維持できるようにしている。
核心产品与组件详解
| コンポーネントの名称 | 役を演じる | 关键配置/选型建议 | なぜそれを選んだのですか? |
|---|---|---|---|
| クラウドデータベース Redis | キャッシュとカウンター・コア.スパイク前の在庫情報の読み取り、スパイク中の在庫の事前削減とカウンターの機能を引き受け、データベースへの圧力を大幅に削減します。 | -バージョン選択。最高のパフォーマンスを発揮するために、RAMバージョンを選択してください。 -キャパシティ・プランニング。スパイク用に30%以上のバッファスペースを確保する。 -配備モデル。高可用性を確保するには、マスター・スレーブまたはクラスタ化されたバージョンを使用します。 | 1秒間に数十万回の読み取りと書き込みをサポートする非常に高いパフォーマンス。アトミック演算(DECRなど)を提供することで、インベントリ推計の精度を保証し、高度な同時読み取りとカウンターのシナリオを解決するための第一選択肢です。 |
| メッセージキュー CKafka | トラフィック・ピーキングとデカップリング・コア.すべての2番目の書き込み要求を引き継ぎ、突然の瞬間的なトラフィックを非同期で均等な速度のメッセージフローに変換し、下流の注文処理システムが圧倒されないように保護する。 | -容量の見積もり。スパイクアイテム数とピークQPSに基づいて、トピックパーティション数とディスク容量を見積もる。 -リテンション戦略。ディスクへの書き込みを避けるため、妥当なメッセージ保持時間を設定する。 | 高スループット、低レイテンシ、Apache Kafkaプロトコルと互換性があり、簡単に数百万TPSを扱うことができます。メッセージのスタッキング機能は、トラフィックがはるかに予想以上であることを確認するには、リクエストを失うことはありません。 |
| エラスティック・ストレッチAS | 計算資源弾力性スケジューリングコア.CKafkaにスタックされているメッセージ数やCPU負荷などの指標に基づいて、注文処理サーバーの数を自動的に増減します。 | -拡大戦略。メッセージのスタッキング量に基づくアラート・スケーリング・ポリシーを設定し、迅速な容量拡張を実現。 -クールダウン。頻繁なストレッチを避けるため、適度な冷却時間を設定する。 | コンピューティング・リソースの「オンデマンド利用」を実現し、スパイクの初期にはピークに対応するために容量を自動的に拡大し、スパイクの終了後にはリソースを解放するために容量を自動的に縮小することで、コストを大幅に最適化する。 |
| クラウドサーバー CVM | ビジネス・ロジック・コンピューティング・コア.注文処理サービス、ビジネス検証サービスなどを実行するために使用される。 | -ミラーの製造。スケーリングチームによる迅速なデプロイメントを可能にする、ビジネスコードを含む既製のイメージ。 -インスタンスタイプ。注文処理速度を確保するために、計算が最適化されたインスタンスを選択する。 | AS、CLB、その他の製品とシームレスに統合し、ビジネスコードを実行するための基盤となる、安定性、信頼性、回復力のあるコンピューティングパワーを提供します。 |
| ロードバランシング CLB | トラフィック分配コア.膨大なユーザーリクエストをバックエンドの複数のビジネスサーバーに均等に分散し、一点集中型のオーバーヒートを避ける。 | -スケジューリングアルゴリズム。加重ポーリング(WRR)などのアルゴリズムが使われる。 -健康診断。ヘルスチェックを有効にして、異常なバックエンドを自動的に除外する。 | サービスの可用性とスケーラビリティを向上させることは、水平スケーリングを可能にする重要な要素である。 |
| クラウド機能 SCF | 軽量ロジック処理コア.回数制限、ユーザーの参加資格チェック(すでに参加しているかどうかなど)、CAPTCHAチェックなどの軽量ロジックを実行するために使用されます。 | -タイムアウト。関数実行の妥当なタイムアウトを設定する。 -メモリ構成。ロジックの複雑さに応じて適切なメモリを構成する。 | サーバーレスアーキテクチャ、マシンを管理する必要がない、実際の実行数に応じて課金される、瞬間的なピークに最適、非常に低コスト。 |
この計画のメリットをまとめたものです。
- 26A1 ⚡ 数百万の同時実行による極めて高いパフォーマンス。RedisキャッシュとCKafkaの非同期処理により、数百万QPSレベルの読み書きのリクエストを簡単にサポートし、スムーズで安定したシステムを実現します。
- ? 柔軟なスケーリングによるコスト最適化。メッセージの蓄積量に基づくオートスケーリング戦略により、コンピューティングリソースの正確なプロビジョニングとピーク後の自動解放を実現し、50%以上のコスト削減を実現。
- ?データは一貫性があり、売れすぎを排除している。Redisのアトミックオペレーションとデータベーストランザクションを活用することで、並行性の高いシナリオでも在庫控除の絶対的な精度を確保し、売れすぎの問題を完全に解決。
- ? 高い可用性で安心のビジネス。コア・コンポーネント(Redis、CKafka、CLB)はすべて高可用性アーキテクチャ、自動フェイルオーバーを提供し、プロモーション期間中も中断することなく継続的なビジネスを保証します。
- ? 迅速な展開、シンプルなO&M。テンセントクラウドの成熟した製品上に構築されているため、複雑なミドルウェアを構築する必要がなく、すぐに利用できるため、開発・運用保守の複雑さが大幅に軽減される。
应用场景与适用客户
このソリューションは、次のようなビジネス・シナリオや顧客に最適です:
- アプリケーションのシナリオ。
- Eコマース秒読み。例えば、期間限定スペシャル、数量限定セール、ポップアップデビューなど。
- タイミングを合わせたスナップ。例えば、クーポン、電車のチケット、コンサートのチケットなど。
- 大規模なプロモーション。ダブル11や618など、平日の何十倍もの交通量があるイベント。
- 該当するお客様
- すべてのeコマース・プラットフォーム、オンライン取引システムは、高い同時実行性の課題に直面している。
- 大規模なプロモーションを計画しており、システムがトラフィックの殺到に対応できないのではないかと心配している加盟店。
- 複雑なアーキテクチャーを自社で構築することから、クラウド上のホスティングサービスに移行し、O&Mコストを削減したいと考えている技術チーム。
関連リンク
- 製品公式サイトへのリンク。
- 無料体験リンク
- 技術チュートリアルへのリンク。
- ソリューション・リンク