PHP 電子商取引 Web サイトでの製品フラッシュ セールに推奨されるビデオ リソース

ご存知のとおり、大量のトラフィックと非常に高い安定性要件を伴う商品フラッシュセール機能の場合、従来の PHP テクノロジーでは要件を満たすことが難しいため、Web サイトのアーキテクチャ設計、サーバー構成、負荷分散、CDN アクセラレーション、クラウド分析、redis などこの方法でしか実現できないこのコースは、関数の実装の考え方を主に紹介するものであり、初心者は注意してください。

コース再生アドレス: http://www.php.cn/course/279.html

先生の教え方:

講義はフレンドリーで自然で、気取らず、気取らないものです。意図的に誇張するのではなく、雄弁かつ詳細に話し、教師と生徒は平等、協力、調和の雰囲気の中で静かに感情的な交流を行い、知識の渇望と探求をシンプルさと信頼性の中に統合します。 教育現場では、生徒は知識を獲得します。静かな思考と沈黙の承認を通じて

このビデオのより難しい点は、フラッシュ キル プロジェクト アーキテクチャ - データ処理層です:

1 フラッシュ キル ビジネス分析

通常のエレクトロニクス ビジネス プロセス (1) 製品のクエリ ( 2) 注文を作成する; (3) 在庫を差し引く; (5) 支払いを行う;

フラッシュセールビジネスの特徴 (1) 大幅なプロモーション; (4) 通常は時間制限付きの出品です。イベントに参加することは、同時リクエストの最大数が 10,000 であることを意味します。フラッシュ セール システムが直面する必要がある技術的課題は次のとおりです。

既存の Web サイト ビジネスへの影響 フラッシュ セール活動は、Web サイト マーケティングの追加アクティビティにすぎません。このイベントは短期間であり、同時アクセス数が多いため、Web サイトの本来のアプリケーションと併用すると、必然的に既存のビジネスに影響を及ぼし、全体の麻痺につながる可能性があります。 Webサイト。解決策: フラッシュ セール システムを独立して展開するか、独立したドメイン名を使用して Web サイトから完全に分離します。

高い同時実行性でのアプリケーションとデータベースの負荷。フラッシュ セールが開始される前に、ユーザーはフラッシュ セールを見逃さないようにブラウザ ページを更新し続けます。これらのリクエストが一般的な Web サイトのアプリケーション アーキテクチャに従っている場合は、アプリケーション サーバーにアクセスして接続します。データベースに影響を与えると、サーバーとデータベース サーバーに負荷がかかります。解決策: フラッシュ セールの商品ページを再設計し、Web サイトの元の商品詳細ページを使用しないでください。ページのコンテンツは静的であり、ユーザーのリクエストはアプリケーション サービスを経由する必要はありません。

ネットワークとサーバーの帯域幅の突然の増加 商品ページのサイズが 200K (主に商品画像のサイズ) であると仮定すると、必要なネットワークとサーバーの帯域幅は 2G (200K×10000) になります。これらのネットワーク帯域幅はフラッシュにより新たに追加されます。営業活動やWebサイトの通常使用帯域を超えます。解決策: フラッシュ セールによって新しいネットワーク帯域幅が追加されるため、再購入するか、オペレータからリースする必要があります。 Web サイト サーバーへの負荷を軽減するには、フラッシュ セールの商品ページを CDN にキャッシュする必要があり、新しく追加されたエクスポート帯域幅も CDN サービス プロバイダーから一時的に借りる必要があります。

直接注文とフラッシュ セールのゲームのルールは、フラッシュ セール後にのみ商品の注文を開始できることです。この時点までは、商品情報の閲覧のみが可能であり、注文することはできません。注文ページも通常のURLですので、このURLを取得すればフラッシュセールの開始を待たずに注文することができます。解決策: ユーザーが注文ページ URL に直接アクセスできないようにするには、フラッシュ セール システムの開発者であっても、フラッシュ セールが開始される前に注文ページ URL にアクセスできないようにする必要があります。その方法は、フラッシュセール開始時にのみ取得できる注文ページURLに、サーバーが生成した乱数をパラメータとして追加するというもの。

フラッシュセール商品ページの購入ボタンの点灯制御方法 フラッシュセール開始時のみ購入ボタンが点灯します。ページが動的に生成される場合は、もちろん、サーバー側で応答ページ出力を構築して、ボタンを灰色にするか点灯させるかを制御できます。これは、サーバー側の負荷圧力を軽減し、パフォーマンスの最適化を有効に活用するためです。 CDN やリバース プロキシなどの方法では、このページは静的ページとして設計され、CDN、リバース プロキシ サーバー、さらにはユーザーのブラウザ上にキャッシュされます。フラッシュ セールが開始されると、ユーザーはページを更新しますが、リクエストはアプリケーション サーバーに到達しません。解決策: JavaScript スクリプト コントロールを使用して、フラッシュ セール製品の静的ページに JavaScript ファイル参照を追加します。フラッシュ セールが開始されると、新しい JavaScript ファイルが生成されます。ただし内容は異なります）、フラッシュセール開始フラグを「はい」に更新し、注文ページのURLと乱数パラメータを追加します（この乱数は1つだけ生成します。つまり、全員が見るURLは同じです。）サーバー側では、分散キャッシュ サーバーを使用して乱数を保存し、ユーザーのブラウザによって読み込まれて、フラッシュ セールの商品ページの表示を制御できます。この JavaScript ファイルは、ブラウザー、CDN、およびリバース プロキシ サーバーによってキャッシュされないように、ランダムなバージョン番号 (xx.js?v=32353823 など) を付けてロードできます。この JavaScript ファイルは非常に小さいため、ブラウザが更新されるたびに JavaScript ファイル サーバーにアクセスしても、サーバー クラスターやネットワーク帯域幅に大きな負担をかけることはありません。

最初に送信された注文のみが注文サブシステムに送信されるようにする方法 製品を正常にフラッシュセールできるユーザーは 1 人だけであるため、ユーザーが注文を送信するときに注文が送信されたかどうかを確認する必要があります。注文が正常に送信された場合は、JavaScript ファイルを更新する必要があり、フラッシュ セール開始フラグが「いいえ」に更新され、購入ボタンが灰色になります。実際には、最終的に注文を送信できるのは 1 人のユーザーだけであるため、注文ページ サーバーの負荷を軽減するために、注文ページへのアクセスを少数のユーザーのみに制限することができます。他のユーザーはフラッシュ セール終了ページに直接アクセスします。解決策: 注文サーバー クラスターに 10 台のサーバーがあり、各サーバーが最大 10 個の注文リクエストのみを受け入れると仮定します。誰かが注文を正常に送信する前に、サーバーにすでに 10 件の注文があり、一部の注文が処理されていない場合、考えられるユーザー エクスペリエンス シナリオは、ユーザーが初めて購入ボタンをクリックし、ページを更新すると完了したページに入るというものです。繰り返しますが、注文を処理していないサーバーによって処理される可能性があります。注文を記入するページに入るときは、一貫性の原則に沿って、Cookie を使用して処理することを検討できます。もちろん、最小接続負荷分散アルゴリズムを使用することもでき、上記の状況が発生する可能性は大幅に減少します。

注文前検査の実行方法

商品数が10個を超える場合、完了したページがユーザーに直接返されます

商品数が10個以下の場合、ユーザーは注文の記入と確認を入力できます。ページ;

フラッシュ セール商品の総数を超えました。完了したページをユーザーに返します。

フラッシュ セール商品の総数を超えていないため、サブオーダー システムに送信されます。送信された注文の数:

注文サーバーは、マシンによって処理された注文リクエストの数をチェックします:

フラッシュ セール全般 このスケジュールされた出品機能を実装するには、さまざまな方法があります。ただし、現時点でより良い方法は、商品の賞味期限を事前に設定することです。ユーザーはフロントで商品を見ることはできますが、「今すぐ購入」ボタンをクリックすることはできません。ただし、考慮する必要があるのは、誰かがフロントエンドの制限を回避し、URL を通じて直接購入を開始できることです。これには、バグ ページやバックエンド データベースだけでなく、フロントエンドの製品ページでもクロックの同期が必要です。バックエンドでの制御が強化されるほど、セキュリティが強化されます。時限フラッシュセールでは、売り手がフラッシュセール前に商品を編集することによって引き起こされる予期せぬ影響を避ける必要があります。この特定の変更には複数の評価が必要です。編集は原則として禁止されており、変更が必要な場合はデータ修正の手続きを行うことができます。

在庫を減らすには 2 つのオプションがあります。1 つは在庫を減らすために写真を撮ること、もう 1 つはお金を払って在庫を減らすことです。現在採用されている「在庫を減らすために写真を撮る」方法は、ほんの一瞬しかかかりません。ユーザーエクスペリエンスが向上します。

在庫は「売れすぎ」の問題を引き起こします。同時在庫更新の問題により、実際の在庫が不足しているにもかかわらず在庫が減り続け、販売者が売れてしまいます。フラッシュセールの予想以上。

以上がPHP 電子商取引 Web サイトでの製品フラッシュ セールに推奨されるビデオ リソースの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。