Twitterのシステムアーキテクチャの分析
（A）コアビジネスのさえずり
コア事業さえずり、および従うべき以下のこと：
（1）following-注意を
個人用のホーム・ページには、次のされますが、公開人（なし140以上の単語）に従うメッセージを、表示されます工程;
（2）followed-注意
あなたはそれがプロセスに従うことで、このメッセージが表示されますあなたの人々に従って、メッセージを投稿。
（B）のビジネスロジックのさえずり
ビジネスロジックをツイッター複雑ではありません
操作を次のように、メッセージに従ってください、と誰が公表誰チェックし、
続いビジネス、フロントエンド、バックエンドのjsのポーリング、人々は新しいメッセージはありません従う参照してください。更新は、（時間に更新されたポーリング時間に依存）があります。
（C）三層アーキテクチャ（3層アーキテクチャ）
ウェブサイトのアーキテクチャ、伝統的なアプローチは、3層構造であり、いわゆる「伝統的な」は、トレンディな未成熟な技術を「時代遅れ」を意味するものではありません、伝統的な方法は、より堅牢です。
（1）プレゼンテーション層（プレゼンテーション層）はApacheウェブサーバ 、 主なタスクは、httpプロトコルを解析する論理層への要求である;
（2）論理層（論理層）：雑種サーバレール 、 動作を低減するために、レールを準備モジュールを使用して量;
（3）データ層（データ層）のMySQL。
データ層来て：
コアさえずり（1）ユーザ、（2）メッセージ、（3）ユーザ関係;
コアのこれらコア、スキーマ設計データ囲む：
（1）ユーザテーブルユーザー
IDを、名前、パス、ステータス、...
MSG（2）表メッセージ
MSGID、AUTHOR_ID、MSG、タイム、...
（3）ユーザ関係テーブルのリレーション
ID、following_ids、followed_ids
論理層：
ユーザがメッセージを発行すると、順次行う：
（1）記憶されたメッセージmsg表に、
（2）ユーザが、関係テーブルをチェックfollowed_idsを見つける、
ユーザ状態followed_idsで取得し;（3）
（4）ラインIDS 、キューキューにメッセージをプッシュする;
（5）キューMSGでは、IDSは、ホームページを更新し、
使用するキューが存在し、自分のチームがチョウゲンボウを達成さえずりなどのapacheミナなど、それを達成するための多くの方法が存在します。
プレゼンテーション層は：
メイン層は2つの機能を有している：
（1）処理HTTPプロトコル（HTTPプロセッサ）;
（2）分配器（ディスパッチャー）;
もちろん、より多くのアクセスTwitterに単にブラウザよりも、原因可能に、携帯電話があってもよいです他のプロトコルがありますので、他のプロセッサがあるかもしれません。
次のようにいずれの場合も、アーキテクチャフレームワークをクリアします：
図1：スキーマのバージョン1
キャッシュに等しい（D）キャッシュ=現金収入
キャッシュ・アーキテクチャを使用しては、大規模なサイトのために不可欠であり、サイトには、応答速度は、ディスクIOの最大の敵である影響を与える最も重要な要因を、体験するユーザーの応答時間です。
Twitterのエンジニアがサイトの平均応答時間のための良い経験が500msの周りにする必要があり、理想的な時間は200-300msであると信じています。
キャッシュを使用するには、以下のように明確なキャッシュ・アーキテクチャとTwitterのアーキテクチャの主要部分であります：
図2：バージョン2キャッシュ・アーキテクチャでは
どこに必要なキャッシュ？IOは、より多くの場所、キャッシュへのより多くの必要性を頻繁に。
IOは、メモリに置くことが必要である3つのコアテーブル場合、最も頻繁にアクセスされるデータベースのですか？
Twitterのアプローチは、最も頻繁にアクセスされるフィールドは、キャッシュが読み込まれ、テーブルを分割することです。
（1）は、キャッシュの配列であり、キャッシュのベクトルキャッシュおよび行キャッシュライン
のベクトルキャッシュ ;：、新しく発行されたメッセージのmsgids、著者のIDに関連した、IDの訪問のこれらの高周波をキャッシュキャッシュに保存するには、ベクトルと呼ばれる
行キャッシュをメッセージ本文：キャッシュライン、
限られたメモリ、優先順位ベクトルキャッシュ、実際の結果のベクトル・キャッシュ・ヒット率が99％で、行キャッシュは95％です。
（2）フラグメントキャッシュとページキャッシュの
さえずりページ（ウェブ・チャネル）、ならびに携帯電話（APIチャネル）に加えて、ユーザアクセス、後者の総トラフィックの割合は80％-90％つつ。
また、mysqlのキャッシュ、キャッシュAPI比重は、チャネルになります。
メイン電話画面は、画面は、メッセージの画面では、ページ全体がそれぞれその断片であるローカル/メッセージの数に対応する、いくつかのローカルに分割されてもよいです。
そのページのキャッシュフラグメントの高い人気、あなたは効率を改善するために、そのニュースリリースを読むことができ、これは、フラグメントキャッシュの使命です。
著者の人気は、人々は、ページキャッシュの使命であるそのホーム・ページを訪問します。
実際の結果、95％のフラグメントキャッシュヒット率は、ページキャッシュは40％です。
ページキャッシュヒット率が、それはホーム・ページにアクセスしているので、それが占有するスペースは素晴らしいですが、キャッシュの2種類を防止するために、お互いに影響を与える、両方のキャッシュは、異なる物理マシン上に展開する必要があります。
フラグメント・キャッシュとページキャッシュがmemcachedを使用しているさえずり。
HTTPアクセラレータ（3）
ウェブチャネルが必要なキャッシュの問題は、Webチャネルの検索から、主に、分析した後、圧力に対処します。
予期せぬ出来事に直面したとき、読者は、関連する情報を検索することができ、これらの情報の著者気にしない、自分のフォローでない人々です。
検索の圧力を低下させるためには、キーワード検索と検索内容はここまでキャッシュすることができ、Twitterのエンジニアはニスを使用しています。
興味深いことに、通常はWebサーバ層、コンテンツに関連していない最初の訪問ワニス、ちょうど訪問のWebサーバに配備ワニス、
彼らはニスの操作を信じているので、Twitterのエンジニアプットは、内側のApache Webサーバ上のワニスワニスシステムの崩壊によって引き起こされる麻痺の複合体、恐怖は、この保守的な配置を採用しました。
無公共ワニスヒット率TWITTER、彼らはニスの使用後、負荷の全体のポイントが50％減少した、と主張しました。
（E）は、分離洪水必要と
ユーザの操作、ピーク流量の平滑化を隔離する：Twitterのアーキテクチャは、そのメッセージ・キューの別の主要な部分です。
サーブではないが、シャットアウトしていないが、今彼らラウンジで待機するようにしましょうが、レストランでは、新規顧客のために、いっぱいになると。
ユーザーは、Twitterにアクセスする場合は、Apacheウェブサーバですが、Apacheは、ユーザーの数に制限を受けることができなかった彼を受け取りました。
2009年1月20日には、オバマ氏は、Twitterのトラフィックが何をすべきか、その後、急騰し、就任演説を行いました。
洪水のピークに直面し、サイトは崩壊を急いでいないことを確認するために、どのように？迅速に受け入れたが、サービスを延期しました。
雑種、実際の処理を担当するMongrelのに転送された要求のapacheの領収書は、次の利用者を迎えるためにフリーハンドをのapache。
Apacheを受け取ることができるユーザの数は常に限られているが、それは同時のapacheの数の対象となる業務プロセスの数を収容することができ、次のようにApacheの原則内部詳しく見てはありません。
図3：Apacheの内部アーキテクチャ
（VI）のデータの流れと制御が流れ
、ユーザーは503（サービス利用不能）を受信しませんようにする急速な普及、遅延サービスだけ遅延戦術を。
：洪水実能力が洪水洪水二つの側面に反映されている
（1）が大容量フラッディングができる巨大ツイッターmemcachedのクラスターである
（2）ツイッターケストレル自身のメッセージキューは、余水路排水手段として、制御コマンドが送信される（排水及びチャネル）
システムの麻痺、その結果、応力集中を避けるために、避難する複数のマシンに、データのさえずり制御データフローをピークに達します。
以下は、読者が、ブラウザを介してそのメッセージを読んで、ブラウザ・メッセージを介して、2人の著者が存在すると仮定すると、内部プロセスさえずり例です。
図4：Twitterのストリーム
（1）ログapacheのウェブサーバー、Apacheのアサインそのサービスのためのワーカープロセスにログインし、ID、書き込みクッキーを確認し、等;
（2）は、Mongrelのになど、Apacheの待機Mongrelの返信を、書かれた新しいメッセージをアップロード前方著者IDを入れて、メッセージ、更新するために、ホームページで、新しい更新メッセージがアップ書かれた;
（3）雑種は、メッセージを受信した後、MSGIDを割り当て、それが上がるし、IDや他のベクターmemcachedのキャッシュを保持する上で保持;
同時に、雑種犬がベクトルの著者を見つけるためにmemcachedをしましょうフォロー、何のキャッシュヒットがキャッシュを内蔵し、バックエンドのMySQLを見に行きませんがある場合は、
読者のIDがMongrelのに戻って、雑種犬はmemcachedの行にテキストキャッシュでMSGID SMSを置く;
（4）Mongrelの通知チョウゲンボウメッセージキューサーバー、各著者と読者キューは、（作成しない）がある;
;雑種犬は、キューの著者としてだけでなく、キューに読者をMSGIDます
（5）Mongrelのは、それはおそらく、特定のキューIDを扱うテーブルは、それがユーザーIDに戻りますホームページ上の情報の提供に追加します。
（6）Mongrelのは、Apacheのホーム待機の前に更新された後、Apacheは戻っています ブラウザ。
（VII）のピークとクラウドコンピューティング
手の込んだない、洪水のピークが運ぶことができなかったとき、唯一のマシンを追加することができます。
彼らはマシンをどこから来ましたか？同社の機器のレンタルプラットフォームのクラウドコンピューティング。
もちろん、あなただけがお金ああ（？：Twitterのピークがあるときに知ってどのように質問）を保存、ピーク時に機器を借りる必要があります。
プッシュと妥協のプル（VIII）
見ることができ、雑種のワークフロー：
（1）memcachedのとmysqlデータベースを投稿するための行memecachedも、ニュースリリースの成功、責任を負いませんベクターに関連するIDS;
（2）関連MSGIDメッセージキューチョウゲンボウプッシュ成功へのメッセージがあっても、
Mongrelのは、著者、読者に知らせるためにあらゆる手段を使用してできません彼らは再プルメッセージを。
「スピンオフ」のさえずり建築設計コンセプトを反映上記作業：
完全なプロセスは、各サービスによって作業が責任（3層アーキテクチャ自体であってもよいし、独立したサブプロセスの作業に分割されます（1）をスピン・オフであります）;
コラボレーション（2）
独立したビジネスプロセスのTwitter、主に二つの側面では、イベント駆動型設計である：
（1）分離雑種とMySQL、前者が直接責任を負う委託memcachedのは、MySQLの操作に介入しない、
（2）アップロード、論理的な分離をダウンロード：命令キューを通過するだけケストレル。
