スパイクは何ですか
スパイクのシーンは、通常12306ウェブサイト上で投票をつかむ電気事業のウェブサイトや休日の出会いに活動の数を開催しました。時間内にいくつかの希少な電気の供給業者のウェブサイトやスペシャルでは、ゼネラル・エレクトリック社のWebサイトが原因でこれらの商品の特殊な性質のため、指定された時間での限定販売となり、多くの顧客を引き付ける買いに来て、意志同時に同意した時点で、ページスパイクラッシュ
スパイク・システムは、シーンの特徴
- 多数のユーザーが購入されます際にスパイクと同時に、サイト瞬間トラフィック急増
- スパイクは、通常のアクセス数よりもはるかに大きい、在庫数、スパイク成功への唯一の少数のユーザーを要求
- スパイクビジネスプロセスは、一般的には受注マイナス在庫の下で、比較的簡単です
スパイク事業を、短いバーストアクセスの多くの典型的なもので、他のビジネスシナリオとスパイクのビジネスシナリオは同時実行が非常に大きい、メインインスタントスパイクと同じではありません、このような大規模な同時実行をどのように扱うか、我々が解決する必要があるということです
スパイクアーキテクチャ設計
- ので、ほとんどの交通規制の、スパイク成功に少数のユーザのみということを考えると、バックエンドサービスへの流れのほんの一部を許可：制限
- 多数のユーザーの瞬間流入のためのスパイクシステムが持っているので、高い瞬時ピークを購入するラッシュが存在します開始：クリッピング。ピークフローシステムは、高流量は瞬時にも非常に重要なデザインのアイデアスパイクシステムで時間をかけてスムーズな流れになりますので、どのように、非常に重要な理由を圧倒しています。従来のバッファーを用いて実施される方法は、クリッピングとミドルウェア技術メッセージングれます
- 非同期処理：スパイク・システムは高度に並行システム、大幅にシステムの同時実行を向上させることができ、非同期処理モードの使用で、非同期処理は、実際には、クリッピングの実装であります
- メモリキャッシュ：データベースのディスクの読み取りおよび書き込みは、我々はキャッシュメモリにいくつかのデータやビジネスロジックを置くことができれば、効率が大幅に改善され、IO、低パフォーマンスに属しているため、システム内の最大のボトルネックは、一般的にスパイクデータベースの読み取りと書き込みされています
- 拡大する可能性があります。私たちはより多くのユーザーとより高い同時実行をサポートしたい場合はもちろん、それは最高のシステムは、トラフィックが来れば、うまくマシンを展開する、弾性的に展開するように設計されていることでしょう。そのような淘宝網、Jingdongはよう際、ダブル11回の活動これは、高い取引に対処するために多数のマシンが増加します
スパイクシステムアーキテクチャ設計のアイデア
- 上流、下流の圧力低下のリクエストインターセプタシステム：スパイクシステムは、並行処理の偉大な量によって特徴づけられるが、傍受可能性が高いロックの競合を読み書きするためにフロントエンドデータベース、最終要求タイムアウトを引き起こすことがないので、場合リクエストの数が実際のスパイクは、めったに成功しています
- キャッシュを使用：キャッシュの使用が大幅に読み取りおよび書き込みシステムの速度を向上させることができます
- メッセージキューは：メッセージキューは、ピーククリッピングすることができ、同時多数の要求をインターセプトし、これは、アクティブプルサービス処理要求メッセージのメッセージ・キューからのバックグラウンドトラフィック処理能力に応じて、非同期プロセスであります
フロントエンドソリューション
静的ページは：すべては最小限に抑えるために、すべての静的および動的要素のイベントページの静的な要素となることができる。CDNによるピークに抵抗します
提出再しないでください：ユーザーがボタンがグレー表示されている提出した後に、重複送信を禁止します
制限ユーザー：特定の期間にのみ、ユーザーがリクエストを送信することができ、例えば、IPを制限取ることができます
バックエンドプログラム
ユーザーのアクセス頻度を制限し、ブラウザにアクセスするための要求をインターセプトしながら、いくつかの悪意のある攻撃や他のプラグインのためのサービス・エンドで同じ周波数アクセス制御層のユーザーのアクセスを制限する必要があります。
アクセス要求、ユーザースパイクの大規模な量の一部のみ上記インターセプトし、各ユーザーには、サービス層に一つだけの要求はまだ要求の非常に大きな数でいたとしても、例えば、我々は同じ時間グラブで10万人のユーザー10件の携帯電話、サービス層の同時実行性を持っています少なくとも100 000の要求圧力
メッセージキューの使用が要求をキャッシュ：サービス層は、インベントリにのみ10携帯電話を知っているので、それ100,000リクエストがデータベースに渡されると、あなたはこれらの要求は、メッセージキューのキャッシュそこに書かれて置くことができ、データベース層は、在庫削減をサブスクライブ・メッセージングは全く不要ですスパイク終了を返すために、在庫成功した要求リターンスパイク成功を減らし、失敗
応答への要求を読んでキャッシュを使用してクエリ要求のほとんどが要求され、それが共有データベースキャッシュの圧力に使用することができ、同様のチケットや他のサービスや商品のスパイクシーンのために12306の典型的な読書で、小規模ビジネスを書きます：
使用キャッシングは、書き込み要求に対処する：キャッシュはまた、我々はすべてのRedisのユーザーにバックグラウンド・プロセスによって、その後インベントリ操作がRedisの中で行われている削減、および、Redisのキャッシュへのデータベースのインベントリデータを転送することができますように書き込み要求を処理することができますデータベースに同期するためのスパイク要求
データベース層
上流の傍受をオフに依頼する必要がある場合に、データベース層には、「能力の範囲内」のみのアクセス要求、データベース層のクマ最も脆弱な層、一般的なアプリケーションの設計です。したがって、データベースの底部が座ってリラックスすることができるように、サービス層における上記キュー及びバッファを導入することによって
モールスパイク技術は、プロジェクトで使用されます
- フロントエンド：Thymeleaf、ブートストラップ、jQueryの
- バックエンド：SpringBoot、MyBatisの
- ミドルウェア：RabbitMQの、Redisの、ドルイド
注：Thymeleafは、実際にサーバー側のテンプレートであり、RabbitMQのは、非同期の注文を実装するために使用される、使用Redisのは（Memcachedのに比べRedisの永続性を行うことができますより、いくつかのメリットがあります）キャッシュを行い、ドルイドアリババは、接続プールを開発利点は、あなたが監視を行うことができるということですサーベイランス接続が内部接続プーリング、最大接続数、同時最長時間の最大数およびその他の特性
プロジェクトの技術説明
- 、分散Seesionを使用するので、複数のサーバーことも応答すること
- Redisのは、データベースのストレスを軽減、同時アクセスの速度と量を向上させるために使用キャッシュを行います
- 擬似静的なページを使用するには、ブラウザのキャッシュにページが、サーバー側は、前と分離後の圧力を減らすために
- ユーザーエクスペリエンスを強化するために、完全な非同期メッセージキューの順序を使用し、ダウンフロークリッピング
- セキュリティの最適化：ダブルチェックMD5パスワード、隠されたスパイクインターフェイスアドレス、抗ブラシ、数式の確認コードを制限するインタフェース
プロジェクトでは、スクリーンショットを結果
ログインページ：
スパイク商品表示ページ：
スパイク・進捗ページ：
スパイクカウントダウンページ：
スパイク成功ページ：
成功した店舗リストページスパイク：
一定時間内に回数を制限SPIKE：
スパイクを繰り返すことはできません。
