タオバオ商品のフラッシュセールアーキテクチャの設計プロセス中にどのような問題を考慮する必要があるか、またどのようなテクノロジーを適用する必要があるか?

返信内容:

1. フラッシュ セール イベントの技術的課題
Web サイトのフラッシュ セール イベントで 1 つの製品がリリースされ、イベントに参加する人が 10,000 人集まると予想されます。これは、技術的な同時リクエストの最大数が 10,000 であることを意味します。フラッシュ セール システムが直面する必要がある課題は次のとおりです。
既存の Web サイト ビジネスに影響を与える
フラッシュ セール活動は Web サイト マーケティングの単なる追加活動です。この活動には次のような特徴があります。短時間かつ大量の同時アクセスが発生するため、Web サイト本来のアプリケーションで導入すると、既存のビジネスへの影響が避けられず、ちょっとした不注意で Web サイト全体が麻痺してしまう可能性があります。
高同時実行下でのアプリケーションとデータベースの読み込み
これらのリクエストが一般的な Web サイト アプリケーションに続く場合、フラッシュ セールが開始される前に、ユーザーはブラウザ ページを常に更新してフラッシュ セールを見逃さないようにします。このアーキテクチャでは、アプリケーション サーバーにアクセスしてデータベースに接続すると、アプリケーション サーバーとデータベース サーバーに大きな負荷がかかります。
ネットワークとサーバーの帯域幅の突然の増加
商品ページのサイズが 200K (主に商品画像のサイズ) であると仮定すると、必要なネットワークとサーバーの帯域幅は 2G (200K×10,000) になります。これらのネットワーク帯域幅 これは、フラッシュ セール活動により、Web サイトが通常使用する帯域幅よりも多くの帯域幅が追加されたためです。
直接注文する
フラッシュ セール ゲームのルールでは、フラッシュ セール時間までにのみ商品の注文を開始できます。この時間までは、商品情報の閲覧のみが可能です。注文することはできません。注文ページも通常のURLですので、このURLを取得すればフラッシュセールの開始を待たずに注文することができます。
2. フラッシュセールシステムの対応戦略
上記の課題に対処するため、フラッシュセールシステムの戦略は以下のとおりです。
フラッシュセールシステムの独自展開
フラッシュ セール活動 Web サイトへの同時アクセスが多いためにシステム全体がダウンするのを避けるため、Web サイト全体がユーザーの集中アクセスに直面する必要がないようにします。必要に応じて、独立したドメインが展開されます。名前を使用すると、フラッシュセールシステムがクラッシュした場合でも、ウェブサイトに影響を与えることはありません。
フラッシュ セールの商品ページは静的になります
フラッシュ セールの商品ページは再設計され、Web サイトの元の商品詳細ページは使用されません。ページのコンテンツは静的です: 商品説明、商品。パラメータ、トランザクション レコード、およびユーザー レビューはすべて書き込まれます。静的ページに入るとき、ユーザー リクエストはアプリケーション サーバーのビジネス ロジックによって処理される必要も、データベースにアクセスする必要もありません。したがって、フラッシュ セール製品サービスには、動的な Web サーバーやデータベース サーバーの展開は必要ありません。
フラッシュ セール イベント用にネットワーク帯域幅をリースする
フラッシュ セールによる新しいネットワーク帯域幅については、再購入するか、オペレーターからレンタルする必要があります。 Web サイト サーバーへの負荷を軽減するには、フラッシュ セールの商品ページを CDN にキャッシュする必要があり、新しく追加されたエクスポート帯域幅も CDN サービス プロバイダーから一時的に借りる必要があります。
ランダムな注文ページを動的に生成するURL
ユーザーが注文ページの URL に直接アクセスできないようにするには、URL を動的にする必要があります。フラッシュ セール システムでは、フラッシュ セールが開始される前に注文ページの URL にアクセスすることはできません。その方法は、フラッシュセール開始時にのみ取得できる注文ページURLに、サーバーが生成した乱数をパラメータとして追加するというもの。
3. Flash Kill システム アーキテクチャ設計

-- 「大規模 Web サイトの技術アーキテクチャ」からの抜粋 http://t.cn/z8N27YQ 私が設計するとしたら、時間が来たらキューに項目を入れ始めると思います。キューには長さの制限が設定されています。消費者スレッドが商品が売り切れたことを検出すると、フロントエンドに新しいリクエストの受信を停止するように通知します。 私はタオバオのフラッシュセールシステムの設計には参加していません。以下の内容はすべて私が考えたものであり、概念についてのみ説明します。具体的な実装にはさまざまな種類があります。

フラッシュ セールスの中心的な問題は、グローバルかつアトミックな操作ですが、これは基本的にトレンドに反しています。現在のトレンドは、データベース システムであっても、Greenplum や Kafka などのメッセージング システムであっても、Redis であっても分散されています。

これらのシステムの大きな問題は、分散シナリオでタイミングを達成することが非常に困難であるか、コストがかかるか、不必要であることです。

しかし、フラッシュセールシステムの場合はそうではありません。このシナリオにはタイミングが必要です。アラカルトのデザインは必須かもしれません。

このため、まず知っておくべきことは、大規模な Web サイトに関するものではなく、超高 PV の Web サイトが知っておく必要があるトピックです。このシナリオでの欠点は、この 1 つの点にある可能性があります。

まず、自分の限界が何なのかを知る必要があります。

1. 極限ピーク値
   
2. 完全な持続性とは何ですか。バックアップに必要なコスト

最初の質問は、ネットワーク送信を前提としてハッシュにレコードを継続的に追加し、並列化が耐えられる最大 TPS を拒否するプログラムを設計できるかどうかです。相当する値は数万以内である必要があります。
これには、ディスクの書き込みやバックアップの転送は含まれていません。これらは後で行うことができ、フラッシュ セール時に行う必要はないためです。ここには矛盾があります。単一のポイントが継続的に高負荷にさらされており、永続化を継続的に完了できない場合は、1 つだけを取得して 1 つを書き込むことができます。このためには、多額の費用を支払うことになります。同時に、ディスクが非常にビジーな間は CPU がアイドル状態になる可能性があるため、リソースが無駄になります。これはダンプの意味でもあります。
2 番目の質問は上で説明しましたが、永続性に満足できない場合は、ログ システムの送信、Hadoop ストレージの送信、データベースの書き込みなどが必要な場合があるため、追加料金が発生する可能性があります。非常に遅い

上記を理解した後、負荷が要件を満たすかどうかを確認してください。たとえば、在庫が数百ある場合、これですでに満足できる可能性があり、そのうちに準備が整います。 1 秒。同時実行数が非常に少ない場合は数秒で完了します。その後は拒否します。

数万件の場合は 1 秒で完了するため、この理由でこの 1 つのポイントを入力してもよいでしょう。拒否率は事前に設定する必要があります。つまり、この時間より前に到着した人もいるかもしれませんが、その人を拒否する必要があります。しかし、非常に多くのシステムが関係しており、数百ミリ秒の遅延が発生するのが普通であるため、ユーザーがそれを見つけるのは困難です。

何百万もの株式がある場合 (そのようなシナリオが存在するかどうかはわかりません)、それを分散方式で解決し、ハッシュ形式で分散するための多数の単一点を見つける必要があります。このため、1 つのポイントが数秒以内に完了せず、別のポイントがずっと前に終了するという不均一なハッシュ状況が発生する可能性があります。これは、ユーザーを予測できず、ハッシュ方法が事前に決定されているため、このシナリオは非常に一般的です。

これは経験に基づいたもので、何度も実行すると、フラッシュ セールのニーズを比較的均等に分散する方法を見つけることができるはずです。 私はタオバオのフラッシュキリングシステムの開発に接したことがないので、参考のためにのみ、さまざまな角度からこの質問に答えます。
この種の問題では、まず大きさを決定する必要があります。大きさが異なるとシステム設計はまったく異なります。
タオバオのフラッシュ セール システムは間違いなく世界でも類を見ないもので、ダブル イレブンの午前 0 時に数億人のユーザーが Web サービスや API サービスにかかるプレッシャーを想像できるでしょう。 。
フラッシュ セールに対する期待を、これまでに遭遇したことのあるレベルまで下げました。たとえば、100 万人のユーザーが 1 分以内にフラッシュ セールを開始した場合、システムはそれをどのように処理するでしょうか。

もう一度フラッシュセールビジネスの特徴を見てみましょう。以下の点があると思います:
1. これはユーザーが購入/注文する必要があるものなので、資格があれば商品があり、代金を支払うことができるはずです。逆に、何かを見て写真を撮らなかったとしても、それは掴めないのが普通なので問題ありません。
2. ユーザーは特定の時点付近で猛烈にリフレッシュしている必要があります。
3. ピーク時のデータトラフィックは膨大で、これは人間による DDOS 攻撃です (マシンの DDOS 攻撃の要素もあるはずです)

これらのタイプのビジネスの特徴を 1 つずつ分析します。 1.1、100 万人のユーザーが数千万のアイテムを購入する可能性があります (数千万のトランザクションが生成されます)。ユーザーが資格を持っている場合、サーバーはトランザクションを処理する必要があります。ここでの行動時間ポイントの分布は、資格取得後、15分以内の支払いや即日支払いなど、一定期間内の支払いなどの行動が規定されるため、すでにほぼ正常になる可能性があります。この種のビジネス量は、分散メッセージ キュー、スプリット ホライズン、マルチレイヤー ロード バランシング、およびマルチレイヤー キャッシングが確実に存在する分散トランザクション システムによってサポートされる必要があります。テクノロジーの選択については、各企業が独自の方法を持っています。このレベルでは、取引の数と頻度は通常の製品の範囲内であるため、ここではあまり説明しません。
1.2. 100 万人のユーザーが同時に数千万の製品を入手したとしても、生成されるリクエストは数億のオーダーになる可能性があるため、購入資格を取得するユーザーのビジネスは個別に分離する必要があります。これらのリクエストが数秒以内に発生する可能性があることを考慮すると、これをサポートできる動的システムはほとんどありません。最初にレイヤー 3/4 のロード バランシングを実行し、次に DNS ローテーション トレーニングに進み、次に 1,000 台の nginx を使用してビジネス サーバーに分散したとしても、各ビジネス グループには 100 台のサーバーがあり、各サーバーが処理しなければならない同時トランザクションの数は1000トランザクション/秒以上です。これは私の yy の結果ですが、fb/google などの主要なビジネス サポート サーバーは 2k ～ 5k であると聞いています。このサーバーの大きさは、1000x100=10w です。サポートする平衡装置がないと推定されます。そこで、ここでは、動的データがビジネスに与える影響を軽減することを試みます。たとえば、製品ラッシュの結果からトークン キューを生成し、勝ち取ったトークンを取得したユーザーのみが購入できるようにします。これらのトークンはすべて静的データです。キューの形式で取得されます。地理的に異なる場所に異なるキューを配置し、事前にボリュームを割り当て、最終リクエストがトランザクション ビジネス システムに落ちないようにします。
2. ユーザーのクレイジーなリフレッシュ行動にとって、ここでのビジネスの規模は以前の資格ビジネスの少なくとも 10 倍であり、何十億ものリクエストが生成されることを意味します。 2 つの対策: 各 http リクエスト URL は同じではなく、トークン メカニズムでもあるため、接続を繰り返し使用することはできません。これにより、人身/機械による DDoS の可能性が防止されます。 2 つ目は静的リソース CDN で、本業の帯域幅を節約します。
3. トラフィックの問題に関しては、2 番目のポイントで述べた CDN に加えて、フロントエンドの JS スクリプトとアプリ側のロジックで可能な限りトラフィックを迂回できる必要があります。たとえば、携帯電話がスワイプを続けると、時間に達する前、または HTTP プロトコル キャッシュの有効期限が切れる前に、アプリはローカル キャッシュに戻り、CDN トラフィックは必要なくなります。

一般:
app/html->cdn/各層の負荷分散->ビジネス分割->データ分割 + 非同期処理/修復

特定のビジネスを解決するニーズ。フラッシュ セールスの場合、ビジネスの分割は非常に重要です。不可能な同時実行要件を静的にするのは単なる偶然です。私の意見では、これは何百万ものユーザーをサポートするソリューションです。タオバオよりも 3 ～ 4 桁高いビジネス ニーズには、各リンクのサービス機能の最適化に加えて、さまざまなビジネス ソリューションも必要です。