一、twitter的核心業務
twitter的核心業務，在于following和be followed
（1）following-關注進入個人主頁，會看到你follow的人發表的留言（不超過140個字），這是following的過程；
（2）followed-被關注你發布一條留言，follow你的人將看到這條信息，這是be followed的過程；

二、twitter的業務邏輯
twitter的業務邏輯也不復雜。
following業務，查follow了哪些人，以及這些人發表的留言；
followed業務，前端js輪詢后端，看follow了的人有沒有新留言，有則更新（更新及時性取決于輪詢時間）；

三、三層架構（three-tier architecture）
網站的架構設計，傳統的做法是三層架構，所謂“傳統”不意味著“過時”，新潮的技術不成熟，傳統的路子更穩健。
（1）表示層（presentation tier）：apache web server，主要任務是解析http協議，將請求分發給邏輯層；
（2）邏輯層（logic tier）：mongrel rails server，利用rails現成的模塊，降低工作量；
（3）數據層（data tier）：mysql；
表示層：表示層的主要職能有2個：（1）http協議處理（http processor）；（2）分發器（dispatcher）；當然，訪問twitter的不僅僅是瀏覽器，可能還有手機，由于可能存在其他協議，故可能存在其他processor。
邏輯層：當用戶發布消息時，依次執行：（1）存消息至msg表；（2）查用戶relation表，找出其followed_ids；（3）獲取followed_ids中用戶的狀態；（4）在線的ids，將消息push進一個隊列queue；（5）queue中的msg，更新ids的主頁；這里面要用到隊列，其實現方式有很多種，例如apache mina，twitter團隊自己實現了一個kestrel。
數據層：twitter的核心是用戶；消息；用戶關系。圍繞這幾個核心，其核心數據的schema設計：（1）用戶表userid, name, pass, status, …（2）消息表msgid, author_id, msg, time, …（3）用戶關系表relationid, following_ids, followed_ids。
無論如何，架構框架清晰如下：

四、cache=cash即緩存等于收入
cache的使用對大型網站架構至關重要，網站響應速度是影響用戶體驗最明顯的因素，而影響響應速度最大的敵人又是磁盤I/O。twitter工程師認為，良好體驗的網站平均響應時間應該在500ms左右，理想的時間是200-300ms。關于cache的使用，是twitter架構的一大看點，帶cache的架構清晰如下：

哪里需要cache？IO越頻繁的地方，越需要cache。數據庫是IO訪問最頻繁處，三大核心表是否有必要放入內存中？twitter的做法是，將表拆分，將其中訪問最頻繁的字段裝入cache。
（1）vector cache and row cache即數組cache與行cache
數組緩存：新發表消息的msgids，相關作者的ids，這些id的訪問頻率很高，存放它們的cache稱為vector cache；
行緩存：消息正文的行cache；內存有限的情況下，優先vector cache，實際結果vector cache的命中率是99%，row cache為95%；
（2）fragment cache and page cache
訪問twitter的用戶除了網頁（web通道），還有手機（API通道），而后者的比例占總流量的80%-90%。mysql cache之外，cache的重心會在API通道上。手機屏幕的主體，是一屏一屏的消息，不妨把整個頁面分割成若干局部，每個局部對應一些/一條消息，這些就是fragment。人氣高的作者，緩存其頁面的fragment，可以提高讀取其發布消息效率，這就是fragment cache的使命。人氣旺的作者，人們也會訪問其主頁，這就是page cache的使命。實際結果，fragment cache的命中率為95%，page cache為40%。雖然page cache的命中率低，但由于是訪問主頁，其占用的空間是很大的，為了防止兩種cache相互影響，這兩種cache需要部署在不同的物理機器上。twitter的fragment cache和page cache都是使用的memcached。
（3）http accelerator加速器
web通道的緩存問題也需要解決，分析之后，web通道的壓力主要來自搜索。面臨突發事件時，讀者們會搜索相關信息，而不會理會這些信息的作者是不是自己follow的那些人。為了降低搜索壓力，可以將搜索關鍵詞與搜索內容cache起來。這里，twitter的工程師使用了varnish。有趣的是，varnish通常部署在web server外層，先訪問varnish，其中沒有相關的內容，才訪問web server；twitter的工程師卻將varnish放在apache web server的內層，原因是他們認為varnish操作復雜，擔心varnish崩潰造成系統的癱瘓，故采用了這種保守型部署方式。twitter沒有公開varnish的命中率，他們聲稱，使用了varnish之后，整站的負載下降了50%。

五、抗洪需要隔離
twitter架構的另一大看點是其消息隊列：隔離用戶的操作，將流量高峰攤平。
餐廳客滿時，對于新來的顧客，雖然不能服務，但不是拒之門外，而是讓他們現在休息廳等待。
用戶訪問twitter時，接待他的是apache web server，而apache不能接待無限多的用戶。2009年1月20日，奧巴馬發表就職演說，twitter流量猛增，此時如何是好。
面對洪峰，如何保證網站不奔潰？迅速接納，但推遲服務。
apache收到請求，轉發給Mongrel，由Mongrel負責實際處理，apache則騰出手來，迎接下一位用戶。但apache能夠接待的用戶數總是有限的，它的并發數受apache能夠容納的工作進程數量，這里不細究apache內部原理，圖如下：

六、數據流與控制流
快速接納，推遲服務，只是緩兵之計，目的是讓用戶不至于收到503（service unavailable）。
真正的抗洪能力，體現在蓄洪與泄洪兩個方面：
（1）twitter有龐大的memcached集群，能大容量蓄洪；
（2）twitter自己的kestrel消息隊列，作為引流泄洪手段，傳遞控制指令（引流和渠道）；洪峰到達時，twitter控制數據流，將數據及時疏散到多個機器，避免壓力集中，造成系統癱瘓。
下面舉例說明twitter內部流程，假設有兩個作者，通過瀏覽器發消息，一個讀者也通過瀏覽器閱讀他們的消息。

（1）登陸apache web server，apache分配一個工作進程為其服務，登陸，查id，寫cookie等；
（2）上傳新寫的消息，把作者id，消息等轉發給Mongrel，apache等待Mongrel回復，以便更新作者主頁，將新寫的消息更新上去；
（3）Mongrel收到消息后，分配一個msgid，將msgid與作者id等緩存到vector memcached上去；同時，Mongrel讓vector memcached查找作者被哪些人follow，緩存如果沒有命中會去后端mysql查找，并入cache；讀者ids會返回給Mongrel，Mongrel把msgid與短信正文緩存至row memcached；
（4）Mongrel通知kestrel消息隊列服務器，每個作者及讀者都有一個隊列（沒有則創建）；Mongrel將msgid放入讀者的隊列，以及作者本人的隊列；
（5）某一臺Mongrel，它可能正在處理某一個id的隊列，就會往返回該id用戶的主頁上添加上此條信息；（6）Mongrel將更新后作者的主頁給前端等待著的apache，apache則返回瀏覽器。

七、洪峰與云計算
不細說了，洪峰扛不住時，只能加機器。機器哪里來？租云計算平臺公司的設備。當然，設備只需要在洪峰時租用，省錢呀。

八、push與pull的折衷
可以看到，Mongrel的工作流程：
（1）將相關ids放入vector memcached和row memecached就算消息發布成功，而不負責mysql數據庫的存入；
（2）將相關msgid放入kestrel消息隊列就算消息推送成功；Mongrel沒有使用任何方式去通知作者、讀者，讓他們重新拉取消息。
上述工作方式，反映了twitter架構設計分拆的理念：
（1）將一個完整的流程分拆成獨立工作的子流程，一個工作可以由各個服務負責（三層架構本身是一種分拆）；
（2）多機器之間協作，細化數據流與控制流，并強調其分離；
twitter業務流程的分隔，是一種事件驅動式的設計，主要體現在兩個方面：
（1）Mongrel與mysql的分離，前者不直接插手mysql的操作，而委托memcached全權負責；
（2）上傳、下載邏輯分離：只通過kestrel隊列來傳遞指令；
每時每刻都有用戶在Twitter上發表內容，Twitter工作是規劃如何組織內容并把它發送用戶的粉絲。
實時是真正的挑戰，5秒內將消息呈現給粉絲是現階段的目標。
投遞意味著內容、投入互聯網，然后盡可能快的發送接收。
投遞將歷時數據放入存儲棧，推送通知，觸發電子郵件，iOS、黑莓及Android手機都能被通知到，還有短信。
Twitter是世界上活躍中最大的信息發送機。
推薦是內容產生并快速傳播的巨大動力。
兩種主要的時間軸：用戶的及主頁的。
用戶的時間軸特定用戶發送的內容。
主頁時間表是一段時間內所有你關注用戶發布的內容。
線上規則是這樣的：@別人是若被@的人你未關注的話將被隔離出來，回復一個轉發可以被過濾掉。
這樣在Twitter對系統是個挑戰。
1.Pull模式
有針對性的時間軸。像twitter.com主頁和home_timeline的API。你請求它才會得到數據。拉請求的不少：通過REST API請求從Twitter獲取數據。
查詢時間軸，搜索的API。查詢并盡可能快的返回所有匹配的推特。
2.Push模式
Twitter運行著一個最大的實時事件系統，出口帶寬22MB/秒。
和Twitter建立一個連接，它將把150毫秒內的所有消息推送給你。
幾乎任何時候，Push服務簇上大約有一百萬個連接。
像搜索一樣往出口發送，所有公共消息都通過這種方式發送。
不，你搞不定。(實際上處理不了那么多)
用戶流連接。 TweetDeck 和Twitter的Mac版都經過這里。登錄的時，Twitter會查看你的社交圖，只會推送那些你關注的人的消息，重建主頁時間軸，而不是在持久的連接過程中使用同一個時間軸 。
查詢API，Twitter收到持續查詢時，如果有新的推特發布并且符合查詢條件，系統才會將這條推特發給相應的連接。
3.高觀點下的基于Pull（拉取方式）的時間軸：
短消息(Tweet)通過一個寫API傳遞進來。通過負載平衡以及一個TFE(短消息前段)，以及一些其它的沒有被提到的設施。
這是一條非常直接的路徑。完全預先計算主頁的時間軸。所有的業務邏輯在短消息進入的時候就已經被執行了。
緊接著扇出（向外發送短消息）過程開始處理。進來的短消息被放置到大量的Redis集群上面。每個短息下在三個不同的機器上被復制3份。在Twitter 每天有大量的機器故障發生。
扇出查詢基于Flock的社交圖服務。Flock 維護著關注和被關注列表。
Flock 返回一個社交圖給接受者，接著開始遍歷所有存儲在Redis 集群中的時間軸。
Redis 集群擁有若干T的內存。
同時連接4K的目的地。
在Redis 中使用原生的鏈表結構。
假設你發出一條短消息，并且你有20K個粉絲。扇出后臺進程要做的就是在Redis 集群中找出這20K用戶的位置。接著它開始將短消息的ID 注入到所有這些列表中。因此對于每次寫一個短消息，都有跨整個Redis集群的20K次的寫入操作。
存儲的是短消息的ID, 最初短消息的用戶ID, 以及4個字節，標識這條短消息是重發還是回復還是其它什么東東。
你的主頁的時間軸駐扎在Redis集群中，有800條記錄長。如果你向后翻很多頁，你將會達到上限。內存是限制資源決定你當前的短消息集合可以多長。
每個活躍用戶都存儲在內存中，用于降低延遲。
活躍用戶是在最近30天內登陸的twitter用戶，這個標準會根據twitter的緩存的使用情況而改變。
只有你主頁的時間軸會存儲到磁盤上。
如果你在Redis 集群上失敗了，你將會進入一個叫做重新構建的流程。
     查新社交圖服務。找出你關注的人。對每一個人查詢磁盤，將它們放入Redis中。
     MySQL通過Gizzard 處理磁盤存儲，Gizzard 將SQL事務抽象出來，提供了全局復制。
通過復制3次，當一臺機器遇到問題，不需要在每個數據中心重新構建那臺機器上的時間軸。
如果一條短消息是另外一條的轉發，那么一個指向原始短消息的指針將會存儲下來。
當你查詢你主頁的時間軸時候，時間軸服務將會被查詢。時間軸服務只會找到一臺你的時間軸所在的機器。
     高效的運行3個不同的哈希環，因為你的時間軸存儲在3個地方。
     它們找到最快的第一個，并且以最快速度返回。
     需要做的妥協就是，扇出將會花費更多的時間，但是讀取流程很快。大概從冷緩存到瀏覽器有2秒種時間。對于一個API調用，大概400ms。
因為時間軸只包含短消息ID, 它們必須”合成”這些短消息，找到這些短消息的文本。因為一組ID可以做一個多重獲取，可以并行地從T-bird 中獲取短消息。
Gizmoduck 是用戶服務，Tweetypie 是短消息對象服務。每個服務都有自己的緩存。用戶緩存是一個memcache集群 擁有所有用戶的基礎信息。Tweetypie將大概最近一個半月的短消息存儲在memcache集群中。這些暴露給內部的用戶。
在邊界將會有一些讀時過濾。例如，在法國過濾掉納粹內容，因此在發送之前，有讀時內容剝離工作。