著者| Wukongチャットフレームワーク
ソース| Wukongチャットアーキテクチャ（ID：PassJava666）
プラネット入門
場所：β-410銀河、A-731電子商取引惑星。
時間：新時代2036。
惑星について：
中国名：A-731Eコマースプラネット
外国名：A-731モール
カテゴリ：惑星
革命期間：1年
常駐ユーザー：ミドルウェアワーカー、さまざまなリクエスト。
地球の総歴史：20万年。
惑星危機
私はスパイクリクエストです。私の毎日の仕事は、スパイクリクエストデータをバックエンドワーカーに送信することです。
この日、Nginx転送サーバーで「Xiaokong」というリクエストに応え、Xiaokongに都合の悪い重要なニュースがあると伝えたので、仕事帰りに予約をとるように言って、急いで出かけました。
Xiaokongと私は夕方10時に仕事を終えてバーに行き、モヒートを2杯注文し、隅に座った。
Xiao Kong：最近心配しているようです。
私：私たちの地球上の注文数が最近急激に増加しており、毎日生成される1,000万件の注文のデータは1日か2日ではないことに気づきましたか。
Xiao Kong：要求されたデータを配信するために、毎日夕方10時まで残業しているのも不思議ではありません。
私：宇宙機関で働いている叔父がいて、私たちの惑星はそれほど多くの要求と注文データを運ぶことができず、まもなく「惑星爆発」が起こるだろうと私に言いました。他人に明かさないでください。
Xiao Kong：どうすればいいですか？
私： 100光年離れた惑星T-714に行くことができますが、スパイクチャネルを通るタイムシャトルを使用することによってのみその惑星に行くことができます。また、場所の数にも制限があります。シャトルに乗る機会があるかどうかはわかりません。
私：トンネルは明日午前10時と午後2時に2回開かれます。あなたは明日私と一緒に行きます！
Xiao Kong：わかりました。
「関係する知識のポイント：」
ここでの惑星爆発とはどういう意味ですか？
-
注文データが大量にあるため、データベースはそれをサポートできませんでした。データベースがダウンしている可能性があります。
毎日大量のリクエストがサーバーに送信されるため、サーバーはそれを処理できません。サーバーがダウンしている可能性があります。
スパイクチャネルが1日に2回開くとはどういう意味ですか？
-
トラフィックを2つのスパイクに分割する「トラフィックピークシフト」。
もちろん、「トラフィックのピークシフト」方法には、入力の確認、ショッピングカートへの追加など、トラフィックを共有する方法が含まれます。
スパイクチャンネル
場所：A-731プラネット空港
時間：09：45
通路
「惑星T-714に行き、乗客にプラットフォームY1で並んで待って特別な通路に入り、15分でシャトルホールに入るように要求してください。」ロビーでの放送は3回連続で放送されました。
私は特別なチャンネルに歩いて行き、チャンネルの隣に立っている看板を見ました：スパイクチャンネル、スパイクリクエストのみ。
「知識ポイントの関与：」
スパイクシーンが別のチャネルを作成したのはなぜですか？
-
システムの他のサービスに影響を与えないために、スパイクビジネスはスパイクシステムのセットを個別に展開しました。
「サービスの単一責任+独立した展開」として要約
リアルタイムの大画面
見上げるとすぐに、通路の上に大画面があり、惑星T-714の写真とチケットの注文情報が絶えず再生されていました。
2人の制服を着た労働者が大画面でパトロールしています。1つのユニフォームはNginxで印刷され、もう1つのユニフォームはCDNで印刷されます。
Nginx + CDN
「知識ポイントの関与：」
Nginxユニフォーム：
-
Nginxユニフォームの労働者は、Nginxの静的および動的リソースを維持しています。
製品詳細ページは静的ページです。これらの静的ページはNginxサーバーに保存されます。静的リソースにアクセスする場合、要求は最初にNginxに送信され、次にNginxサーバーは要求されたURLリンクを介してアクセスされた静的リソースであるかどうかを照合します。
大画面の製品詳細ページは、リクエストを送信してもバックグラウンドサーバーから取得されません。実際、「動きと静的な分離」が実現されています。
写真はNginxの動的および静的分離を説明しています
Nginxフローチャート
-
HTMLファイルなどの静的リソースはめったに変更されません。バックエンドサーバー（Tomcatなど）と対話することなく、サーバーに配置して直接アクセスできます。
製品を購入した人の数をバックグラウンドで取得したり、データを保存するための注文リクエストを送信したりする必要があるなどの動的リソース。これらは動的リソースと呼ばれ、可視リソースとして狭義に理解することはできず、論理処理の結果を広く含めることができます。 、データの保存などの操作を実行します。
CDNユニフォーム
-
CDNとは：CDNの一般的な説明は、ユーザーが近くのリソースを取得し、ネットワークの送信時間を短縮し、アクセス速度を上げることです。
HTMLファイルはNginxに配置され、HTMLによってインポートされた画像ファイルとスクリプトファイルはCDNに配置されます。
CDNユニフォームの労働者はCDNリソースを維持しています。
フローチャートはCDNの動作原理を説明しています
CDNフローチャート
検証チャネル
時間：10：00
「確認チャンネルが開設されました。パスワードをご持参ください！」放送は3回放送されました。
「関係する知識のポイント：」
なぜパスワードが必要なのですか？
-
シミュレートされた多数のスパイク要求がビジネス処理フローに入るのを防ぐために、最初に検証が追加され、これらの偽の要求は破棄されます。
どうやってやったの？フロントエンドのWebページは、最初にパスワードの取得要求を送信します。クリックして購入すると、暗号化されたパスワードが要求の本文に含まれ、バックエンドはパスワードが一致するかどうかを確認します。MD5で暗号化できます。
「seckillリクエストの暗号化」として要約されます。
シャトルホール
検証チャネルによるスクリーニングの後、偽のリクエストの半分はドアの外でブロックされ、正しいパスワードを取得した私のような人はスムーズにシャトルホールに入りました。
ホールに来ると、ホールの中央にモニターが置かれているのを見つけ、そこに表示されている赤い数字の100が目に入った。
ディスプレイの左側には、Redisのユニフォームを着た美しい少女が立っています。彼女がシャトルの残り数を表示するようにモニターを制御しているのを聞いた。数が0になった場合は、すべてのシャトルが使用されていることを意味し、後続の人々は成功せずに戻る必要があります。
Redis
「関係する知識のポイント：」
スパイクシナリオでは、残りのインベントリのクエリはデータベースを直接チェックするのではなく、Redisキャッシュをチェックします。
なぜキャッシュをチェックするのですか？キャッシュのチェック速度はデータベースのチェックよりもはるかに高速であるため、応答時間が短縮され、データベースへの負荷が大幅に軽減されます。データベースに対して多くのインベントリチェック要求が行われると、データベースは崩壊し、データベースは他のタスクを実行できなくなります。
投票をつかむ
ディスプレイの右側には、まっすぐなスーツを着たハンサムな若い男が立っていて、Redissonの言葉が印刷された赤いアームバンドが彼の袖口にぶら下がっているのが見えました。彼は真剣な表情で、ホールの暗い要求を無視した。たぶん、あなたはこの種のシーンに慣れています。
このハンサムな男を見ていると、左手にチケットの山を持っているのがわかりました。そうです、チケットでシャトルにログインできます。私は100メートルの速さで彼の前に到着しました。彼の前に到着したとき、すでに十数件のリクエストがありました。彼は先着順で航空券を発行しました。私の時間までに、残りのチケットはわずかでした。幸い、100メートルのラッシュスピードでチケットを手に入れることができました。私はハンサムな男に別のチケットを送ってくれないかと尋ねましたが、彼は拒否しました。
チケットが発行されるたびに、Redisのユニフォームを着たかわいい女の子がディスプレイを操作してその数を1つ減らします。
10秒後、チケットが発行され、ディスプレイに番号0が表示されます。
「関係する知識のポイント：」
Redissonとは何ですか？Redisクライアントは、分散のいくつかの一般的な問題を解決します。
ここでは、Redissonセマフォ機能が実用的であり、合計100のチケット、つまり100のセマフォがあり、マルチスレッドの同時実行または分散システムのためにチケットの数が売られ過ぎになることはありません。たとえば、101枚のチケットが販売されました。
一人一人が取得できるチケットは1つだけです。これはスパイクシステムに関連する同一性チェックであり、繰り返しチケットを取得することはできません。
搭乗券
搭乗券
チケットを発行したハンサムな男は、チケットを受け取った後、登録カードを受け取る前に、支払いのためにウィンドウAに列を作る必要があると私に言いました。それで私は他の99のリクエストでウィンドウAにキューイングしました。
チケットが高すぎると言って、支払いをあきらめたいというリクエストを見て、ロビーを出ようとしたとき、チケットを発行したハンサムな男に止められました。彼はリクエストを検討するかどうか尋ねました。検討するのに15分かかりました。リクエストがまだ感じられる場合いいえ、チケットを彼に返却して、他の人に発行することができます。
キュークリッピング
「関係する知識のポイント：」
スパイクシステムで一般的に使用される「キューピーククリッピング」。スパイクが成功したリクエストはキューに入り、ゆっくりと注文を作成し、在庫を差し引きます。
スパイクが成功したら、注文が完了するのを待ってからユーザーに伝えるのではなく、スパイクが成功したことをユーザーにすばやく伝えます。その後、ユーザーはしばらく待つ必要があり、エクスペリエンスに影響します。
なぜキューピーククリッピングを実行したいのですか？成功したリクエストは、注文を一度に作成するためにデータベースにアクセスする必要がないため、データベースへの負荷が軽減されます。
スパイクシナリオでは、ユーザーがそれを取得しても支払いを行わないシナリオが存在する場合があります。この時点で、インベントリが追加され、他のユーザーに提供できます。
出航する
注文が正常に作成された後、搭乗パスを取得しました。搭乗パスの確認に合格した後、シャトルに正常に搭乗しました。
出発し、惑星T-714に行きます。その惑星のデータベースはデータベースとテーブルに分割されており、サービスもマイクロサービスに分割されていると聞きました。
総括する
上記は、サイエンスフィクションを通じてスパイクシステムの懸念事項を説明しました。以下は、スパイクシステムの8つの懸念事項の要約です。
スパイクシーンに焦点を当てる
サービス単一責任、独立した展開
在庫の予熱、迅速な控除
スパイクリンクの暗号化
動的および静的分離
悪意のあるリクエストの傍受
フローピーク
現在の制限と融合とダウングレード
キュークリッピング
原則を話しているだけではなく、本当の駅になるのでしょうか？
更多精彩推荐
☞多样性计算时代，怎样的技术生态才能满足发展需求
☞牛！发出中国第一封电子邮件，注册登记域名CN，中国互联网之父传奇
☞苹果回应iPhone12用5G耗电快；央行：微信支付宝和数字人民币不存在竞争关系；Win10X 将于年底签署 RTM|极客头条
☞算力至上？四大AI芯片大对决
☞大数据给教育带来怎样的可能？
☞干货 | 以太坊上的数字签名
点分享点点赞点在看