まず、なぜ難しいです
在庫一つだけ、誰もが設定時間内のデータを読み書きします：理由が困難なスパイクシステムです。
たとえば、毎週火曜日スパイクキビの電話は、携帯電話だけで1万かもしれないが、瞬間的な着信トラフィックは、数千万、数百のかもしれません。
別の例はまた、さらに多くのスパイク、瞬間的な流れに似12306グラブ票です。
第二に、共通のアーキテクチャ
億のレベル、一般的なサイトのアーキテクチャなどへのトラフィック：
1）ブラウザ側、トップは、いくつかのJSコードを実行します
バックエンドのデータにアクセスします2）サイトの階層、ブラウザに返さ戦いのhtmlページ
3）サービス層、上流シールドに基礎となるデータの詳細
4）データ層を、最終的な在庫は、ここに存在するMySQLが典型的です
第三に、最適化の方向
1）の可能上流限り、システム内の要求インターセプター：従来のスパイク吊りシステムは、要求は圧倒バックエンドのデータ層ある理由は、データを読み書きロック深刻な競合がほとんどすべての要求のタイムアウト、遅い応答を複雑、流量は、単一の、素晴らしいです成功の効果的な流れは非常に小さい[のみ2,000チケット実際に電車、200ワットの人は基本的に誰もが成功を購入することができ、購入しないように、実効レート要求0]
2）キャッシュをフルに活用：これは典型的な読み取りマルチアプリケーション・シナリオである[Xieshao実際には電車だけで2000のチケット、購入する200ワットの人々は、2000台のパーソナル成功の最大で、他の人がチェック、在庫、のみ0.1の書き込みの比率です％、使用キャッシュに非常に適し、] 99.9％の読み取り率を占め
第四に、最適化の詳細
4.1）ブラウザの層をインターセプト要求
ボタン、カードああ、ああプログレスバーをスローを「検索」をクリックした後、ユーザーとして、無意識のうちに継続して「検索」との点に進み、ポイント、少しポイントをクリックして行くでしょう。。。便利な？システムの負荷が増加する理由（ユーザポイント5倍、要求の80％が非常に多く出ている）、どのように全体の？
a）は製品レベルの後に、ユーザーは「検索」または「チケット」ボタンがグレーアウトされ、禁止のユーザーが繰り返し提出者の要求をクリックします
B）JSレベルのみリクエストを送信x秒にユーザを制限します
だから、トラフィックの80％が停止した、制限
4.2）層リクエストインターセプタサイトやページキャッシュ
ブラウザ層の傍受を要求し、唯一の白いユーザーを停止した（が、これはユーザーのヨーヨーの99％である）、ハイエンドのプログラマーは、単にループの書き込み、それを食べていない、あなたが直接、バックエンドのHTTPリクエストを呼び出す方法全体？
a）に同じUID、ページのキャッシュを行い、アクセス頻度を制限し、要求がx秒の層の部位に到達する、両方とも同じページを返します
b）は、携帯電話旅行と同じ項目のクエリを、ページのキャッシュを行い、x秒でサイトレベルで到着要求、両方とも同じページを返します
だから、制限、トラフィックの別の99％は、サイトレベルでブロックされます
4.3）サービス層の要求が傍受され、データ・キャッシュ
切片へのお願いサイトレベル、唯一の彼は10ワットブロイラーを制御仮定（と実名認証を必要としないチケットと仮定）、uidの制約の下で死ぬために、普通のプログラマ、上級ハッカーを停止する、右？どのように全体の？
a）のビッグブラザーは、私はサービス層だった、私ははっきりとそれだけ万キビの電話を知って、私は明らかにそれが何であるか、データベースへのI徹底的に10ワットの要求、わずか2000列車の切符を知っていますか？書き込み要求の場合は、要求キューは、データ層に限定された書き込み要求の時間を通じて、実行するグループが正常に再び置いた場合は、キューを返すために十分な在庫の書き込み要求がない場合は、すべての「完売」
b）は、読み出し要求のために、それを言うまでもないですか？抵抗するキャッシュ memcachedのか、Redisの、毎秒のスタンドアローン抗10ワットは、すべての問題になりませんか、
だから、非常に少数の書き込み要求を制限し、かつ非常に少ないキャッシュミスを読む要求がデータ層に通過します、リクエストの99.9％が停止されているがあります
4.4）データ層散歩
この層へのデータ、ほとんどの要求するだけでなく、スタンドアローン外出先では、再度、株式が限られている、キビの生産能力は意味がありません、データベースへの要求が多すぎて、限定されています。
