序文
システムにメッセージミドルウェアを導入すると、どのようなメリットがありますか？
MQの導入後、解決できる3つの主な問題があることを知っておく必要があります。非同期、デカップリング、ピーククリッピングです。
この記事では、eコマースシステムのスパイクシステムの技術的な問題と解決策を目指して、ピークシェービングの特定のシナリオについて説明します。
システムが直面しているボトルネックは何ですか
最初に、スパイクシステムで解決する必要がある特定の問題を理解しましょう。写真を見てください：
私たちのシステムが急上昇している場合、多数のユーザーが注文システムのクラスターにアクセスします。実際、これは技術的なボトルネックではありません。注文システムのクラスターを拡張し、注文システム内のマシンの数を増やす限り、これ以上に抵抗できます。同時実行性が高い状況。
では、技術的なボトルネックは何でしょうか？
データベースの部分をもう一度見てみましょう。注文システムのクラスターに何台のマシンが追加されても、それらはまだデータベースにアクセスしていることがわかります。そうすると、スパイクシステムのようなアクティビティに直面するたびに、データベースへの圧力が非常に大きくなり、データベースがクラッシュしてシステム全体が崩壊する可能性が非常に高くなります。
このことから、データベースはスパイクシステムが直面する主要なボトルネックであると分析しました。
スパイクシステムのボトルネックを解決する方法
先ほど、スパイクシステムが直面している技術的なボトルネックがデータベースであることを述べましたが、どうすれば解決できますか？より多くのデータベースサーバー、サブデータベース、およびサブテーブルを展開し、より多くのデータベースサーバーが高い同時実行性の状況に共同で抵抗できるようにする必要がありますか？
このサブデータベースサブテーブルの戦略は次のとおりです。現在、1つのライブラリで注文テーブルを操作していると仮定すると、サブライブラリの後は複数のライブラリになり、各ライブラリには注文データの一部のみが格納されます。 、サブデータベース戦略は、タイムスタンプまたはハッシュアルゴリズムに従って計算できます（これはこの記事の焦点ではありません。後でデータベースについて個別に説明します）。サブテーブルは、注文テーブルをライブラリで複数に分割できることを意味しますテーブル、データは再びフラグメントに格納されます。
このモデルの利点は何ですか？
メリットは実際に明らかです。同時実行性の高いリクエストを複数のデータベースに均等に分散できます。データベースクラスタ全体が高い同時実行性のプレッシャーに共同で耐えることができ、データベースクラスタを拡張することで、より高い同時実行性に対応する機能も実現できます。
そうは言っても、この問題はこのように解決されたと友達は思っていますか？
はっきりと言うと、このソリューションは非常にトリッキーです。会社の技術力が弱すぎない限り、より信頼性の高いインフラストラクチャを構築できず、この最後の手段を選択することはできません。圧力下。
私たちのシステムが顧客に非常に人気があり、ユーザー数が日々増加し、膨大な数のユーザーに到達している場合、サーバーの数を増やし続ける必要がありますか？
サーバーのコストは少し高いですか？
したがって、この問題を解決するには、開始点が正しい必要があります。つまり、常にマシンを追加してこの問題を解決することはできませんが、限られたリソースでそれを解決するよりエレガントなアーキテクチャを設計します。この方法が最善のポリシーです。
フロントページの最適化
限られたリソースでアーキテクチャを最適化する必要があることを知ってから、まず問題について考えます。
ユーザーがスパイクアクティビティに参加する場合、システムをどのように操作しますか？
たとえば、ダブルイレブンラッシュを例にとると、00：00がスパイクの時間なので、多くのユーザーは数分前に対応するページに電話を開いてから、スパイクが始まるのを待たずにページを更新します。その瞬間がやってきた。
では、これらの更新されるページはどこから来るのでしょうか？
実際、このページには専用の注文ページサーバーが必要で、主にフロントエンドアクセスページを提供するために使用されます。基本的な構造は次のとおりです。
したがって、高い同時要求を受け入れる最初のシステムは、フロントエンドページシステムです。
質問について考えてみましょう。それがスパイクではない場合、ユーザーに表示される製品は異なる可能性がありますが、スパイクアクティビティが発生すると、同じ製品の同じページを更新する多数のユーザーがシステムに圧力をかける可能性があります。 。
では、この問題をどのように解決すればよいでしょうか？
今日導入されたソリューションは、静的ページデータ+マルチレベルキャッシングの戦略です。
静的ページデータ
まず、動的ページデータとは何かについて説明します。
フロントエンドページが動的であると仮定すると、ユーザーがページにアクセスするたびに、ユーザーはページシステムにデータを取得するリクエストを送信し、フロントエンドページは取得したデータに従ってページをレンダリングします。一般的に、システムの進化はこの動的なものから始まります、jspページなど。
つまり、静的ページを実現する方法は、実際には、ページがデータを取得する方法を変更することです。データを取得するたびに、ページシステムを介してデータベースにクエリを実行するのではなく、他の場所からデータを取得し、毎回バックエンドデータベースにアクセスすることを回避します。システムはストレスを引き起こします。
マルチレベルキャッシュ
静的な考え方を理解してから、マルチレベルキャッシュとは何かを見てみましょう。これから説明するマルチレベルキャッシュは、CDN + Nginx + Redisのマルチレベルキャッシュアーキテクチャを指します。
どういう意味ですか？つまり、ページのデータは最初にユーザーに最も近いCDNに配置されます。
一部の友人はCDNを理解していない可能性があるため、簡単なリテラシーを提供します。
たとえば、システムサーバーは北京に展開されており、システムにアクセスするユーザーは海南にいるため、システムにアクセスするたびに、北京のサーバーにアクセスしてデータを取得する必要がありますか？
いいえ、私たちは海南のCDNに静的ページデータをデプロイできます。海南ユーザーは、CDNを介してシステムのページデータを取得できます。
このCDNは、さまざまなクラウドベンダーによって提供されるサービスであり、私たちのアーキテクチャの最初のレベルのキャッシュです。
CDN内のキャッシュの期限切れなどが原因でページデータがCDNから取得されない場合、ユーザーは現時点でこのリクエストを北京のサーバーに送信しますが、現時点ではシステムはデータベースに直接クエリを送信してデータを返しませんが、最初にNginxサーバーのキャッシュにアクセスします。
NginxはLuaスクリプトに基づくローカルキャッシングを実装でき、ページデータをNginxキャッシュに事前に2次キャッシュとして配置できます。
Nginxに必要なデータがない場合はどうなりますか？
この時点で、Nginxのluaスクリプトを介してデータをロードするリクエストをRedisクラスターに送信できます。Redisクラスターは、マルチレベルキャッシュアーキテクチャの3次キャッシュとして機能します。
それでもRedisクラスターでデータが見つからない場合は、データベースからロードしてキャッシュに更新します。
このようなマルチレベルキャッシュアーキテクチャにより、ページの静的データ（データはjson文字列である場合があります）のストレージを実現できるため、ページサーバー自体への圧力は非常に小さくなります。
アーキテクチャ図は次のとおりです。
総括する
今日は、高同時実行システムでのスタッキングマシンソリューションの欠点について説明し、スパイクシナリオでいくつかの技術的な課題を紹介しました。
また、マルチレベルキャッシュアーキテクチャを使用して静的ページを構築する方法についても説明しました。
ただし、スパイクシステムは複雑なシステムであり、多くの詳細な調査の詳細があります。主な目的は、スパイクシステムの全体的なシーンとスパイクシステムのアーキテクチャの最適化のアイデアを紹介し、RocketMQをスパイクシステムに実装する方法を導くことです、トラフィックのピークシェービング効果を達成するため。
この記事があなたに役立つと思われる場合は、フォローしてサポートすることができます
この記事があなたに役立つと思うなら、あなたはそれを好きでそれをサポートするためにそれをフォローすることができます、またはあなたは私のパブリックアカウントをフォローすることができます。
