12306.cnウェブサイトがダウンしています，全国の人に叱られる。私はこの2日間これについて考えていました，私はあなたとウェブサイトのパフォーマンスの問題を大まかに議論するためにこの問題を使用したいと思います。急いで，そして、私の限られた経験と理解に完全に基づいています，など，ご不明な点がございましたら、一緒に話し合い、修正してください。（これは別の長い記事です，パフォーマンスの問題についてのみ話し合う，それらのUIについて話し合わないでください，ユーザー体験，それとも、支払いとチケットの購入と注文を分離する機能的なものですか？）ビジネスどのテクノロジーもビジネスニーズと切り離せません，など，パフォーマンスの問題を説明するため，まずはビジネスの問題についてお話したいと思います。 1，誰かがこれをQQやオンラインゲームと比較するかもしれません。しかし、私は2つが異なると思います，オンラインゲームとQQオンライン、またはログイン時に、ユーザー自身のデータにアクセスします，チケット予約システムは、センターのチケットボリュームデータにアクセスします，それは同じではありません。オンラインゲームやQQが機能するとは思わないでください。同じだと思います。。eコマースシステムと比較して、オンラインゲームとQQのバックエンドロードは依然として単純です。 2番目，春節の間に電車を予約するのは、ウェブサイトでの急上昇のようなものだと言う人もいます。。確かに非常に似ています，しかし、あなたの考えが表面にない場合，これも少し違うことがわかります。列車のチケット，一方では、多数のクエリ操作が伴います，さらにBTは、注文時にデータベースに対して一貫した操作が多数行われることです。，一方では、開始点から終了点までの各セグメントチケットの一貫性，一方，バイヤールート、列車番号、多くの時間オプションがあります，注文の仕方を常に変えていきます。そしてスパイク，直接殺すだけ，クエリや一貫性の問題はそれほど多くありません。加えて，スパイクについて，最初のN人のユーザーの要求のみを受け入れるようにすることができます（バックエンドでデータをまったく操作しないでください）， ユーザーの注文操作をログに記録するだけです），この種のビジネス，スパイクの数をメモリキャッシュに入れるだけで済みます，データを配布することもできます，100商品，10各サーバーは10を置きます，一度にデータベースを操作する必要はありません。あなたは十分に注文することができます，スパイクを停止します，次に、データベースへのバッチ書き込み。そして、スパイクには多くの製品がありません。列車の切符はスパイクほど単純ではありません，春節の時間，ほとんどすべてのチケットはホットチケットです，そして、全国のほぼすべての人々がここにいます，そして、転送ビジネスもあります，複数行の在庫はトランザクション操作である必要があります，考えてみてください，これはどれくらい難しいですか。（淘宝網のダブルイレブンには300万人のユーザーがいます，そして、列車の切符は即座に数千万、さらには数億になります）（更新：20141月11日：淘宝網に来てから，淘宝網のシステムを理解している，淘宝網のスパイク活動，基本的に、検証コードを使用して、CDNで直接ユーザーを除外します，といった：1数千万人のユーザーがフィルタリングされ、20,000人のユーザーだけが残ります，このようにしてデータベースは耐えることができます），誰かがこのシステムをオリンピックのチケットシステムと比較します。まだ違うと思います。オリンピックのチケットシステムは発売と同時に廃止されましたが。しかし、オリンピックは宝くじ抽選を使用します，言い換えれば、先着順の方法はありません，そして，後付けです，事前に情報を受け取るだけです，事前にデータの一貫性を確保する必要はありません，ロックなし，水平方向のスケーリングが簡単。 第4，予約システムは、eコマース注文システムと非常によく似ている必要があります，すべてがインベントリを実行する必要があります：1）在庫を占有する，2）支払い（オプション），3）在庫を差し引く操作。これは一貫性をチェックする必要があります，つまり、同時実行中にデータをロックする必要があります。B2Ceコマースは基本的にこれを非同期で行います，言い換えると，ご注文はすぐには処理されません，しかし、処理が遅れる，正常に処理されただけ，注文が成功したことを知らせる確認メールが送信されます。多くの友人が失敗した電子メールを受け取ったと思います。この意味は，データの一貫性は同時実行性のボトルネックです。 5番，鉄道切符事業が異常，突然のチケットリリースを使用しています，そして、いくつかの投票は誰にとっても十分ではありません，など，誰もが中国の特徴を持つビジネスのチケットを手に入れる練習をします。だからチケットがリリースされたとき，数百万または数千万人が殺されます，お問い合わせ，注文する。数十分以内，ウェブサイトは数千万の訪問を受けることができます，これはひどいことです。12306のピーク訪問は10億PVと言われています，午前8時から午前10時に焦点を当てる，ピーク時に毎秒数千万のPV。 もう少し言葉を言ってください： 在庫はB2Cの悪夢です，在庫管理は非常に複雑です。不信，あなたはすべての伝統的な電気小売会社に尋ねることができます，彼らが在庫を管理するのがどれほど難しいかを見てください。さもないと，Vanclの在庫について質問する人はそれほど多くありません。（「ジョブズバイオグラフィー」もご覧いただけます，ティムがアップルのCEOに就任した理由をご存知でしょう，主な理由は、彼がAppleの在庫サイクルの問題を解決したことです）Webサイトの場合，Webを閲覧する負荷が高いため、処理が簡単です。，クエリの負荷には、対処するのにある程度の難易度があります，ただし、クエリ結果をキャッシュすることで実行できます。，最も難しい部分は注文の負荷です。在庫にアクセスする必要があるため，ご注文の際，基本的には非同期で行われます。昨年はダブル11，淘宝網の1時間あたりの注文数は約60万件です，Jingdongは1日で400,000しかサポートできません（12306より悪いです），Amazonは5年前に1時間で700,000件の注文をサポートできました。見える，発注操作は私たちほど高くはありません。 淘宝網はB2Cウェブサイトよりもはるかにシンプルです，倉庫がないので，など，同じ製品在庫を更新および照会するためのN個の倉庫を持つB2Cのような操作はありません。。ご注文時，B2Cのウェブサイトは倉庫を見つけようとしています，再びユーザーに近づく，再度インベントリ，これには多くの計算が必要です。ただ想像します，あなたは北京で本を買いました，北京の倉庫は在庫切れです，周辺の倉庫から移動する必要があります，次に、瀋陽または西安の倉庫に在庫があるかどうかを確認します，ない場合，私は江蘇省の倉庫を見なければなりません，などなど。淘宝網にはそれほど多くのものはありません，各マーチャントには独自の在庫があります，在庫は数です，そして、在庫は商人に割り当てられます，パフォーマンスの向上につながります。 データの一貫性が実際のパフォーマンスのボトルネックです。nginxは1秒あたり100,000の静的リクエストを処理できると言う人もいます，間違いない。しかし、これは単なる静的な要求です，理論値，帯域幅がある限り、I / Oは十分に強力です，サーバーの計算能力は十分です，また、サポートされる同時接続の数は、100,000のTCPリンクの確立に耐えることができます，それは問題ありません。しかし、データの一貫性に直面して，この100,000は完全に達成不可能な理論値になっています。 たくさん言った，私はただビジネスからみんなに伝えたいです，春節鉄道の切符予約事業の異常を事業から真に理解する必要があります。。 パフォーマンスの問題を解決するためのフロントエンドパフォーマンス最適化テクノロジー，一般的に使用される方法はたくさんあります，以下にリストします，以下の技術を使用した12306のウェブサイトは、そのパフォーマンスを質的に飛躍させると信じています。。 1、フロントエンドの負荷分散DNSロードバランサー（通常、ルートの負荷リダイレクトに応じてルーター上にあります）は、ユーザーのアクセスを複数のWebサーバーに均等に分散できます。。これにより、Webサーバーのリクエスト負荷を減らすことができます。httpリクエストは短い仕事なので，など，この機能は、非常にシンプルなロードバランサーを介して実行できます。ユーザーが最寄りのサーバーに接続できるように、CDNネットワークを用意することをお勧めします（CDNには通常分散ストレージが付属しています）。（負荷分散の詳細については、「バックエンド負荷分散」を参照してください）2つ、フロントエンドリンクの数を減らす…