プロジェクトのハイライト:
1. 分散型 Seesion を使用すると、複数のサーバーが同時に応答できます。
2. Redis をキャッシュとして使用すると、アクセス速度と同時実行性が向上し、データベースの負荷が軽減され、メモリ タグを使用して Redis アクセスが軽減されます。
3. 静的ページを使用してユーザー アクセスを高速化し、QPS を向上させ、ページをブラウザーにキャッシュし、フロントエンドとバックエンドを分離してサーバーの負荷を軽減します。
4. メッセージ キューを使用して、非同期の注文を完了し、ユーザー エクスペリエンスを向上させ、ピーク レートとフロー レートを削減します。
5. セキュリティの最適化: ダブル md5 パスワード検証、フラッシュキルインターフェイスアドレスの隠蔽、インターフェイス電流制限とアンチブラッシング、数式検証コード。
主な知識ポイント:
分散型セッション
フラッシュ セール サービスの実際のアプリケーションは、1 台のサーバーに展開されるだけでなく、複数のサーバーに分散される場合があります。ユーザーが最初のサーバーにログインすると、最初のリクエストは最初のサーバーに送信されますが、2 番目のリクエストは 2 番目のサーバーに送信され、ユーザーのセッション情報は失われます。
解決策: セッションの同期では、どのサーバーにアクセスしても、redis キャッシュ メソッドを使用し、特にユーザーのセッション情報を保存するための redis サーバーを使用してセッションを取得できます。この方法では、ユーザー セッションが失われることはありません。 (セッションが必要になるたびに、キャッシュから取得するだけです)
redis はデータベースの負担を軽減します
このプロジェクトでは、ユーザー情報のキャッシュ (分散セッション)、製品などのキャッシュ テクノロジを広範囲に利用しています。情報 キャッシュ、商品在庫キャッシュ、注文キャッシュ、ページ キャッシュ、オブジェクト キャッシュにより、データベース サーバーへのアクセスが軽減されます。
ユニバーサル キャッシュ キーのカプセル化
問題の 1 つは、同じキー値が存在する可能性があるため、異なるモジュール内のキャッシュをどのように区別するかです。
解決策: 抽象クラスを使用して BaseKey を定義します。 ( プレフィックス)。キャッシュ キーをカプセル化するために、キャッシュ キーのプレフィックスとキャッシュの有効期限が定義されます。異なるモジュールにそれを継承させることで、モジュールがキャッシュに保存されるたびにキャッシュ固有のプレフィックスが追加され、異なる有効期限を均一に設定できます。
ページの静的化 (フロント エンドとバック エンドの分離)
ページの静的化の主な目的は、ページの読み込みを高速化し、商品詳細ページと注文詳細ページを静的 HTML にすることです。 (純粋な HTML )、データのロードには ajax を介してサーバーにリクエストするだけで済み、静的な HTML ページをクライアントのブラウザにキャッシュできます。
メッセージ キューを使用して非同期注文発注を完了する
メッセージ キューを使用して非同期注文発注を完了し、ユーザー エクスペリエンスを向上させ、ピークをカットし、フローを削減します
アイデア:
1 .システムが初期化され、製品在庫数量在庫が Redis にロードされます。
2. バックエンドはフラッシュ セール リクエストを受信し、Redis は在庫を事前に削減します。在庫が臨界値に達した場合、リクエストを続行する必要はなく、失敗が直接返されます。後続の多数のリクエストによってシステムに問題が発生する必要はありません。
3. フラッシュ セール注文が成立したかどうかを判断し、フラッシュ セールが到着したかどうかを判断し、1 つのアカウントから複数の製品を避けるようにし、フラッシュ セールが繰り返されるかどうかを判断します。
4. 在庫は十分であり、重複したフラッシュ セールはありません。フラッシュ セール リクエストはカプセル化され、メッセージがキューに入れられます。同時に、コード (0) がフロント エンドに返されます。キューに戻されることを意味します。 (返されるのは失敗か成功ではなく、現時点では判断できません)
5. フロントエンドはデータを受信後、キューを表示し、プロダクトID( 200 ミリ秒ごとにポーリングすることを検討してください)。
6. バックエンドの RabbitMQ はフラッシュ セールの MIAOSHA_QUEUE というチャネルを監視し、メッセージがあれば受信情報を取得します。実際のフラッシュ セールを実行する前に、在庫を判断する必要があります。データベースを参照し、フラッシュ セールが繰り返されるかどうかを判断し、フラッシュ セール トランザクションを実行します (フラッシュ セール トランザクションはアトミックな操作です。在庫を 1 つ減らし、注文し、フラッシュ セール注文を書き込みます)。
7. このとき、フロントエンドは製品 ID に基づいてリクエスト インターフェイス MiaoshaResult をポーリングし、製品注文が生成されたかどうかを確認します。リクエストが -1 を返した場合、フラッシュ セールが失敗したことを意味します。 0 はキューに登録されていることを意味し、>0 は製品 ID が返されたことを意味し、フラッシュ セールが成功したことを意味します。
セキュリティの最適化
ダブル md5 パスワード検証、フラッシュキルインターフェイスアドレスの隠蔽、インターフェイス電流制限とアンチスワイプ、数式検証コード。
エレガントなコードの書き方
インターフェースの出力結果はResultカプセル化されます
間違ったコードはCodeMsgカプセル化されます
アクセスキャッシュキーのカプセル化
プロジェクトと問題解決の難しさ:
1. JMeter を使用してストレス テストを実行すると、5000 のスレッドが開かれ、システムは実行できず、例外が発生します
理由: 構成ファイル内の Redis 構成項目 poolMaxTotal を変更し、1000 に設定します。
#redis 構成項目
redis.poolMaxTotal=1000
redis.poolMaxldle=500
redis.poolMaxWait=500
2 . 大量のキャッシュが使用されるため、キャッシュの故障、キャッシュなだれ、キャッシュの一貫性などの問題が発生しますか?
キャッシュ侵入とは、存在してはいけないデータに対するリクエストを行うことを指します。リクエストはキャッシュを通過してデータベースに到達します。
解決策: これらの存在しないデータについては空のデータをキャッシュし、そのようなリクエストをフィルターします。
キャッシュ雪崩とは、データがキャッシュにロードされていないか、キャッシュされたデータが広範囲で同時に失敗 (期限切れ) しているか、キャッシュ サーバーが停止しているために、データベースに到達する大量のリクエストを指します。下。 ＃＃＃＃＃＃解決：＃＃＃
広い領域で同時にキャッシュの期限切れによって引き起こされるキャッシュなだれを防ぐために、ユーザーの行動を観察し、キャッシュの有効期限を合理的に設定できます;
キャッシュ サーバーによって引き起こされるキャッシュなだれを防ぐためにダウンタイムの場合は、分散キャッシュを使用できます。分散キャッシュ内の各ノードは、データの一部のみをキャッシュします。ノードがダウンしても、他のノードのキャッシュが引き続き利用可能であることを確認できます。
システムの起動直後に大量のデータがキャッシュされないことによるキャッシュなだれを回避するために、キャッシュの予熱を実行することもできます。
例: まず、セッション キャッシュなどのキャッシュごとに異なる有効期限を設定します。userKey プレフィックスでは、設定は 30 分で期限切れになり、キャッシュ時間はユーザーが応答するたびに更新されます。各セッションの取得は 30 分延長されるため、キャッシュが期限切れになる可能性は比較的低くなります。
キャッシュの一貫性では、データの更新中にキャッシュされたデータをリアルタイムで更新できることが必要です。
解決策:
データが更新されたらすぐにキャッシュを更新します。まずキャッシュからの読み取りを試行し、データの読み取り後にすぐに戻ります。読み取れない場合は、データベースを読み取り、データを保存すると、キャッシュに書き込まれて返されます。
キャッシュを読み取る前に、キャッシュが最新かどうかを判断し、最新でない場合は更新を行い、データを更新する必要がある場合はデータベースを更新してから無効化(削除)します。キャッシュ内の対応するデータ。
3. キャッシュを大量に使用すると、キャッシュ サーバーに大きな負荷がかかります。Redis アクセスを減らす方法をお考えですか?
redis がインベントリを事前に削減する場合、isOvermap はメモリ マークとしてメモリに維持され、インベントリがない場合は true に設定されます。各フラッシュセール事業者がredisにアクセスする前にマップマークを確認し、trueの場合は在庫がないことを意味し、redisサーバーにリクエストせずに直接失敗を返します。
4. 同時リクエストが多いビジネス シナリオで、大量のリクエストの処理が遅すぎたり、リクエストが積み重なったりする場合はどうすればよいですか?
メッセージ キュー。リクエストを非同期に処理するために使用されます。リクエストが来るたびに、リクエストを処理するのではなくメッセージキューに入れ、バックグラウンドでリスナーを配置してさまざまなビジネスのメッセージキューをリッスンし、メッセージが来るとビジネスロジックが実行されます。 。これにより、複数のリクエストが同時に操作されるときに、過剰なデータベース接続の例外が発生するのを防ぎます。
5. ユーザーが繰り返し注文できないようにするにはどうすればよいですか?
解決策: フラッシュ セール注文テーブル (参照はユーザー ID と製品 GoodsId) に一意のインデックスを作成して、最初のレコードを挿入できるようにします。2 番目のレコードはエラーになり、その後ロールバックされます。トランザクションを通じて、ユーザーが同時に発行された複数のリクエストを処理し、複数の商品を即座に販売することを防ぎます。
ユニーク インデックスとは、一意であることを意味します。データベース テーブル構造内のフィールドに一意のインデックスを追加し、データベースでストレージ操作を実行した後、データベースは、データがデータベースにすでに存在するかどうかを判断します。データが存在しない場合に実行される挿入操作。
これは小さなスキルですが、実際にはビジネス開発において非常に実践的なスキルです。たとえば、同時実行性の高いビジネスにおいて、データが 2 つの同一の注文番号を同時に挿入することをデータベースはどのようにして防ぐことができるでしょうか?もちろん、一意のインデックスを追加するのが最も早い方法の 1 つです。もちろん、インデックスを追加するか、ビジネス コードで解決するかは、会社のビジネスによって異なります。
6. 売られすぎ現象を解決するにはどうすればよいですか?
売れすぎのシナリオ: さまざまなユーザーがリクエストを読んだときに、製品の在庫が十分であることがわかり、同時にリクエストを開始して在庫を減らすフラッシュセール操作を実行し、在庫が減少します。負の数に。
最も簡単な方法は、データベースを更新して在庫を減らし、在庫制限を実装することです。reduceStock(GoodsVo Goodsvo) メソッドで、SQL に Stock_count > 0 をもう 1 つ追加し、データベース機能を使用して売られすぎを確認します。つまり、stock_count が 0 より大きい場合にのみ、stock_count が読み取られて 1 減算されます。
@Update("update miaosha_goods setstock_count=stock_count-1 where Goods_id=#{goodsId} and Stock_count>0" )
public void reduceStock(MiaoshaGoods Goods);
7. ページの静的化のプロセスとブラウザのキャッシュとは何ですか?
HTML 静的ページをクライアント ブラウザにキャッシュします。データのみが Ajax 非同期呼び出しインターフェイスを通じて取得されます。データの一部のみが対話されるため、帯域幅が削減され、ユーザー アクセスが高速化されます。
ブラウザ キャッシュとは、要求された Web リソース (HTML ページ、画像、JS、データなど) のコピーをブラウザに保存することです。キャッシュは、受信リクエストに基づいて出力コンテンツのコピーを保持します。次のリクエストが来たとき、それが同じ URL であれば、キャッシュはキャッシュ メカニズムに従って、コピーを直接使用してアクセス リクエストに応答するか、リクエストをソース サーバーに再度送信するかを決定します。より一般的なのは、ブラウザが Web サイト上で訪問した Web ページをキャッシュすることです。URL アドレスに再度アクセスしたときに、Web ページが更新されていない場合、Web ページは再度ダウンロードされませんが、ローカルにダウンロードされます。キャッシュされた Web ページが直接使用されます。リソースが更新されたことが Web サイトで明確に識別された場合にのみ、ブラウザは Web ページを再度ダウンロードします。
8. フラッシュ セール アーキテクチャの設計コンセプトは?
現在の制限: インスタントキルに成功できるユーザーは少数であるため、ほとんどのトラフィックを制限する必要があり、トラフィックのごく一部のみがサービス バックエンドに入ることが許可されます。
フラッシュセール活動を行う場合、ラッシュセール開始と同時に大量のユーザーが殺到し、ピークタイムが発生します。したがって、ピークカット対策を講じる必要があります。ピーク時のトラフィックがシステムに負荷をかける重要な原因となるため、瞬間的なトラフィックの高さを一定期間安定したトラフィックに変える方法も、フラッシュ セール システムを設計する際の重要なアイデアです。ピーク クリッピングを実現するために一般的に使用される方法には、キャッシュやメッセージ ミドルウェアなどのテクノロジの使用が含まれます。
非同期処理: フラッシュ セール システムは同時実行性の高いシステムです。非同期処理モードを使用すると、システムの同時実行量が大幅に増加します。実際、非同期処理はピーク カットを実現する方法です。
メモリ キャッシュ: フラッシュ セール システムの最大のボトルネックは、一般にデータベースの読み取りと書き込みです。データベースの読み取りと書き込みはディスク IO に属するため、パフォーマンスが非常に低くなります。一部のデータまたはビジネス ロジックを転送できれば、メモリキャッシュの効率は非常に高くなります。
スケーラブル: もちろん、より多くのユーザーとより優れた同時実行性をサポートしたい場合は、システムを柔軟でスケーラブルに設計することが最善です。トラフィックが発生した場合は、マシンを拡張するだけです。タオバオや京東などのダブル イレブン イベント中は、取引のピークに対応するために多数のマシンが追加されます。
9. フラッシュ セール システム アーキテクチャの設計アイデアはありますか?
システムの上流でリクエストをインターセプトしてダウンストリームの圧力を軽減します: Flash Kill システムは大量の同時実行性を特徴としていますが、実際に成功した Flash Kill リクエストの数は非常に少ないため、そうでない場合はフロントエンドでインターセプトされると、データベースの読み取り/書き込みロックの競合が発生する可能性があり、最終的にはリクエストがタイムアウトになります。
キャッシュの使用: キャッシュを利用すると、システムの読み取りおよび書き込み速度が大幅に向上します。
メッセージ キュー: メッセージ キューは、ピークをカットし、多数の同時リクエストをインターセプトできます。これは非同期処理プロセスでもあります。バックグラウンド ビジネスは、メッセージ キューからリクエスト メッセージを積極的に取得し、そのメッセージ キューに基づいてビジネス処理を行います。独自の処理能力。
10. 在庫が減り、ユーザーが支払いをしない場合、どうすれば在庫を復元してラッシュ セールに参加し続けることができますか?
最大支払い時間を設定します (例: 30)バックグラウンドでスケジュールされたタスクがあり (タイマー タイマーを使用)、30 分を超える保留中の注文をローテーションして (注文のステータスはデータベースで決定されます)、注文をクローズして在庫を復元します。
以上がRedis プロジェクトのナレッジポイントは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
