出典：W3CSCHOOLの建築家の道
まず、なぜ難しいのビジネススパイク
1）は、QQやマイクロブログなどのIMシステムを、誰もが自分自身のデータ（バディリスト、グループリスト、個人情報）を読み取る;
2）マイクロブログシステム、それぞれの人が人のデータへのあなたの注意を読んで、人は一人以上を読んでデータ;
3）スパイク・システム、在庫一つだけ、誰もが、設定された時間内にデータを読み取るために、複数の人がデータを読み書きします。
たとえば：火曜日のスパイクキビの電話、電話が唯一万かもしれないが、瞬時の着信トラフィックは、数千万、数百のかもしれません。
別の例：12306枚のラッシュチケット、チケットが限られている、株式は、瞬間的な流れは、すべて同じインベントリを読んで、非常に大きいです。書き込みの競合ロックは、事業所をスパイクすることは困難である、非常に深刻です。次に、どのように我々はスパイク事業構造を最適化していますか？
第二に、最適化の方向
2つの方向の最適化は、（今日のこの二点について話をする）があります。
（1）システムの上流での要求を傍受しようとします（競合がデータベースをロックするために落ちてはいけません）。伝統的なスパイクシステムハングは、要求がバックエンドのデータ層を圧倒した理由は、データが読み書きロックを深刻な葛藤、遅い高応答によって複雑に、ほとんどすべての要求時間を、フローは素晴らしいが、成功の一つの効果的な流れは非常に小さいです。12306には、例えば、実際に列車は、200ワットの人が購入する唯一の2000のチケットは、基本的に誰もが成功、0要求の有効率を購入することはできません。
（2）キャッシュをフルに活用する、典型的な少しの読み取りと書き込みのシナリオでチケットを購入スパイク、リクエストのほとんどが旅行のお問い合わせ、チケットのお問い合わせ、注文があり、支払いは、書き込み要求です。実際には、電車、唯一の2000のチケット、200ワットの個人は、単一の成功の下で2000人まで購入する、他の人がチェック、在庫、わずか0.1％に書き込み率、99.9％の読み取り率を占め、最適化するために、キャッシュの使用に最適です。さて、どのようにフォローアップする方法、およびどのように「キャッシュ」方法、詳細についての話「インターセプトにシステムの上流で要求をしてみてください」との話。
第三に、共通のアーキテクチャスパイク
共通の基本的なサイトのアーキテクチャは、（確かアーキテクチャ図フリッカクラスを描画しない）ようなものです
（1）ブラウザ側、上部、実行いくつかのJSコード
（2）サイトレベル、この層は、ブラウザに返されたHTMLページスペル、バックエンドデータにアクセスする
（3）サービス層上流のシールドに、基礎となるデータの詳細をデータ・アクセスを提供するために、
（4）データ層は、最終的な在庫は、MySQLが（もちろん、キャッシュがあるの）典型的なもので、ここに存在します
この図は簡単ですが、画像が高同時スパイク事業構造の大きな流れを説明することができ、私たちは絵を覚えておく必要があります。決意の背後にどのように慎重にすべてのレベルの最適化。
4.各レベルの最適化の詳細
クライアント（ブラウザレベル、APP層）を最適化するためにどのように第一層、
あなたの質問を、我々はすべての赤い封筒は、右、毎回振るマイクロ文字のシェイクシェイクグラブを果たし、それが要求バックエンドが送信されますか？私たちの次のシングルグラブ票のシーンを確認した後、「検索」ボタンをクリックし、カードは、ああ、ああプログレスバーを遅く、ユーザーとして、私は意識的に右に、「検索」をクリックして行きませんか？、少しポイントを継続するために、ポイントにポイントを続行します。。。便利な？システムの負荷が増加する理由はなく、ユーザーポイント5倍、要求の80％が非常に多く出ている、どのように全体の？
（A）製品レベルでは、ユーザーは、「検索」または「チケット」ボタンがグレーアウトされ、繰り返し要求を提出禁止ユーザーをクリックします。
（B）JSレベルのみリクエストを送信X秒にユーザを制限します。
APPレベル、あなたが同様のことを行うことができ、マイクロ手紙であなたクレイジー揺れが、実際にはバックエンドに要求を開始する秒xは。これは、より良い、より上流の、ブラウザのレベルは、APP層は、我々が+ 80％に要求をブロックすることができるように、停止して与えた「システムの上流での要求を傍受してみてください」と呼ばれ、このアプローチは、唯一の普通のユーザによって停止（ただし、99することができますユーザの％は、ハイエンド・プログラマ内のグループのための一般ユーザ）が防止することができるされています。放火犯パケットキャプチャは、jsは全く要求のこの部分に対処する方法は、http長期鋸すべて知っている、forループを書くために、プログラマを停止していないHTTPインターフェースを呼び出していますか？
第二層、サイトレベルの要求インターセプタ
どのようにインターセプトか？どのように、サイクル呼び出しのために書くためにプログラマーを防ぐために、それは再ごとに持っていますか？IP？クッキー-ID？...複雑たい、ビジネスのこのタイプは、あなたはuidを使用することができ、ログインする必要があります。サイトレベルでは、要求のuid重いまで数えるとする、でもサイトに直接統合ストレージ、メモリストレージ層をカウントせずに（この数は許可されますが、最も簡単なことだろう）。UID、リクエストによって5秒しか許可されますが、これは、サイクル要求の99％のために停止します。
リクエストによる5S、要求の残りの部分はどのようにしますか？キャッシュ、ページキャッシュ、同じUID、アクセス頻度を制限し、ページのキャッシュを行い、x秒でサイトレベルで到着要求、両方とも同じページを返します。こうした旅行、ページのキャッシュを行い、x秒でサイトレベルに到達した要求と同じ項目クエリ、両方とも同じページを返します。制限だから、（要求はサイトレベルでインターセプトされるページのキャッシュを使用して、）システムの堅牢性を保証することができ、ユーザーは優れたユーザーエクスペリエンス（ノーリターン404）を持っていることを確認するために、両方の。
ページ・キャッシュは、すべてのサイトがサイトごとにメモリに直接一貫したページを返すことも可能であることを保証する必要はありません。利点は欠点がHTTPリクエストが別のサイトに落ちている、シンプルで、データが異なる場合があります返さチケットは、これはリクエストインターセプタサイトレベルの最適化とキャッシングです。
まあ、HTTP、UIDの10ワット手をブロイラー10ワットを制御するために、プログラマのためのライトへの要求、一部のハイエンド・プログラマ（ハッカー）髪のサイクルを停止する方法、同時に要求を送信する（実名システムの問題、グラブキビの電話を考慮しないようにそれは、次のこれを行う方法を、）本当の名前を必要としない、サイトのレベルに応じて電流制限を防ぐことができるUIDです。
第3層は（とにかく、データベース要求までに秋聞かせすることはありません）切片にサービス層であり、
サービス層どのようにインターセプトか？ブラザーは、私はサービス層です、私は明らかにそれが何であるデータベースにのみ万キビの電話、私ははっきりと列車の切符にのみ2000を知って、私は徹底的に10ワットの要求ということを知っていますか？はい、リクエストキュー！
書き込み要求の場合は、要求キューは、データ層に限定された書き込み要求の時間を通じて、実行する（注文、支払いなどの書き込み操作）
唯一の1ワットDBへの単一の要求による1ワット電話
3Kデシベルにのみ単一の要求による3K列車のチケット
それはグループの下、その後成功した場合は、キューが返すのに十分な在庫書き込み要求でない場合は、すべての「完売」。
読み取り要求のために、どのように最適化するには？アンチキャッシュ、memcachedのいずれか、またはRedisのは、毎秒のスタンドアローン抗10ワットは、すべての問題になりません。だから、非常に少数の書き込み要求、および非常に少ないデータ層に通過しますキャッシュミスを読む要求を制限し、要求の99.9％が停止されているがあります。
もちろん、ビジネスルールのいくつかの最適化があります。リコール12306は、時間セグメントのチケット、オリジナルのチケット団結午前10時00分、今8時00分、午前8時30分、9時00分に行われ、...すべての半分のグループを解放する時間：均等に流れ広がりました。
第二に、データの粒度の最適化：あなたはチケットが58、または26を残し、この事業に関するお問い合わせは、チケット、I票を買いに行くには、あなたは本当に、実際には、我々は唯一のチケットを気にして何のチケットを持っていないかについて懸念していますか？大流量時には、粗粒「は票を持っている」作る「投票権」キャッシュになることはできません。
第三に、いくつかのビジネスロジックの非同期：例えば、単一のビジネス決済サービスの分離。これらの最適化がビジネスに組み合わされて、私は「前の視点を共有しなければならなかったすべてのビジネス・アーキテクチャのいじめのうち」最適化されたアーキテクチャだけでなく、ビジネスのために。
最後に、第4の層はデータベース層であります
ブラウザ・ブロックの80％は、99.9％のサイトレベルをブロックし、ページキャッシュを作った、サービス層と書かれたリクエスト・キューとデータ・キャッシュを作った、データベース層に至るまで、各要求が制御可能です。DBは基本的には、圧力、および散歩するだけでなく、スタンドアローン外出先では、再度、株式が制限されていないキビの生産能力が制限され、データベースを通じて非常に多くの要求が意味をなしません。
すべてのデータベースを介して、単一の、成功0、0％要求効率100W。データ3K、すべて成功し、要求100％の効率化による。
V.の概要
非常に明確にする必要があり、上記の、何も、再び次の二つの繰り返しのためのスパイクシステムアーキテクチャの最適化のアイデアの私の個人的な経験にまとめません：
（1）切片に、システムの上流での要求をしてみてください（より良い上流の）;
（2）複数の使用を読み書き少ない従来のキャッシュ（キャッシュ抗圧力を読み取ります）。
ブラウザとAPP：速度制限を行います
サイトレベル：、速度制限を行うには、UIDに従ってページキャッシングを行います
サービス層：データキャッシュを行い、書込み要求キュー制御トラフィックに基づいてビジネスを行います
データ層：散歩
そして、企業結合の最適化を行います
六、Q＆A
あなたのアーキテクチャに応じて質問1、しかし、可能性が低いこと、そしてどのように圧力プロセスのこの部分の接続要求の数を制限するために、現実と効果的な要求千万があると仮定して、実際にはほとんどストレスの多いサイトレベルですか？
A：同時かもしれないではない1キロワット、と仮定すると1キロワットあたり、解決方法2：
（1）サイトの膨張層は聖歌に機械、最も無能な1K機によって適用されます。
マシンは（後で再び50％の直接リターン）が50％を放棄するための要求を放棄するのに十分でない場合には（2）は、原則として、すべてのユーザーが失敗することはできませんのでという、システムを保護することです。
質問2、ハァッ、この問題を解決する方法「ブロイラーの10ワット、10ワットUIDの手を制御要求しながら、」？
A：上記は、サービス層書込み要求キュー制御を言いました
質問3：キャッシュアクセス頻度を制限し、また、検索のために使用することができるかどうか？検索のキャッシュページの後に生成された優先順位を使用して、このような「携帯電話」のための「モバイル」、Bのユーザー検索などのユーザーを検索すると、？
：これは、この方法は、多くの場合、例えば、短押し4キロワットユーザアプリプッシュ営業活動は、ページのキャッシュを行い、「ダイナミック」営業活動のページで使用され、可能です。
質問4：キュー処理が失敗した場合、どのように対処しますか？キューが行う方法ブロイラーChengbaoのですか？
A：プロセスは、ユーザーが再試行することができ、単一故障の下に戻すことに失敗しました。キューのコストは、それがバーストすることは困難である、非常に低いです。最悪の場合は、キャッシュがいくつかの要求の後、後続の要求は、直接「投票権」を返されない（キューが100ワット要求されているため、すべての待機、その後、意味がありません要求を受け入れます）
質問5：サイトレベルのフィルタリング、それはそれで、各サイトのメモリに別々に保存リクエストのUID数がありますか？このような場合は、別のサーバーに配布し、同じユーザー応答にロードバランサを介して複数のサーバークラスタの例をどのように扱いますか？または跡地のロードバランシングにフィルタ層の？
A：はい、メモリに、その一つのサーバが（10台のマシンがあると仮定して）グローバルの要求を5S制限する表示された場合、それは実際には、5秒に解決策を10個の要求を制限しています。
1）推奨ソリューション、最も簡単な）である（制限を増やす
nginxの層7層バランスを行うには2）、のは、uidが同じマシン上に落ちる依頼してみましょう
質問6：サービスレベルのフィルタリング、キューが統一され、サービス層のキューがありますか？または、各サーバは、各キューのサービスを提供するには？それは統一キューである場合は、キューに、各サーバーから提出されたロック要求の前に制御する必要がないのですか？
A：あなたは、統一されたキューを持つことができない、各サービスので、リクエストの数が少ない（投票/サービス数の合計数）によって、シンプルなので。キューを統一し、複雑。
質問7：支払い完了後のスパイクだけでなく、未払いキャンセルフットプリント、残りの在庫管理にタイムリーな更新を行うためにどのように？
A：データベースの状態、支払われていません。時間をかけて、45分例えば、再入荷は（お馴染みの「バック倉庫」）を再開します場合は、私たちに明らかにしたグラブ票にある、開始後のスパイクした後、45分後にしようと、多分チケットヨーヨーがあります〜
質問8：別のユーザーが同じ商品陳列在庫の秋異なるキャッシュ・インスタンスが同じか、キャッシュされたデータを行う方法を先生に聞いて完全に異なっている見て汚れが許可されている読み込みますか？
A：現在のアーキテクチャは、要求が異なるサイトに落ち、データは（ページキャッシュが同じではありません）一致しないことが、このビジネスシナリオを受け入れることができます。しかし、データベースレベル実際のデータには問題ありません。
質問9：でも、ビジネス上の考慮事項の最適化で、これはまだ渋滞が起こるのではないだろうと3K注文「3K列車の切符、唯一の3K DBへの単一の要求スルー」？
A：（1）データベース書き込み要求または抗3K OK;及び（2）データを分割することができ、（3）3Kを搬送しない場合、サービス層は3K、圧力が来て測定する場合によると、に同時の数によって制御することができます例のみ;
質問10、つまり背景レイヤーまたはサービス層での処理サイトを失敗した場合、その後、バッチまたはこのリクエストのリプレイを検討する必要が行うことができませんでしたか？直接、または破棄しますか？
A：DOは、それが失敗したユーザーのクエリ失敗したか、オーダーへの復帰を再生ない、アーキテクチャ設計の原則の一つは、「フェイルファスト」です。
12306、同時に多くのスパイク活動などの大規模システムのスパイクの問題については11、どのように分割するには？
A：垂直分割
質問12余分な問題を考えました。このプロセスは、同期または非同期作られるのですか？それが同期されている場合、それはまた、遅い応答のフィードバックの存在を持っている必要があります。それは非同期そうであるなら、どのように正しい結果を返すように要求する当事者の応答を制御することができますか？
A：ユーザレベルが同期させる必要があります（ユーザーのhttpリクエストがライブ追突された）、サービスのレベルは、同期または非同期にすることができます。
質問13、質問スパイクグループ：マイナス在庫は、それがその段階で減少していますか？それは、単一のロックストック、それを処理する方法を支払うことなく、単一のロック株式の下で、悪意のあるユーザーが多数ある場合は？
A：データベースレベルの書き込み要求が非常に低いが、幸い、受注は賃金をせず、その時間の前提に終わっていたし、その後、過去の「裏倉庫」。