作為140個字的締造者，twitter太簡單了，又太復雜了，簡單是因為僅僅用140個字居然使有幾次世界性事件的傳播速度超過任何媒體，復雜是因為要為2億用戶提供這看似簡單的140個字的服務，這真的是因為簡單，所以復雜。可是比較遺憾的是目前在中國大陸twitter是無法訪問的，但作為一個愛好架構的程序猿，這道墻是必須得翻的，墻外的世界更精彩。今天就結合網絡上的一些資料，來淺談一下我對twitter網站架構的學習體會，希望給路過的朋友一點啟示.......

一、twitter網站基本情況概覽

◆ 截至2011年4月，twitter的注冊用戶約為1.75億，并以每天300000的新用戶注冊數增長，但是其真正的活躍用戶遠遠小于這個數目，大部分注冊用戶都是沒有關注者或沒有關注別人的，這也是與facebook的6億活躍用戶不能相提并論的。

◆ twitter每月有180萬獨立訪問用戶數，并且75%的流量來自twitter.com以外的網站。每天通過API有30億次請求，每天平均產生5500次tweet，37%活躍用戶為手機用戶，約60%的tweet來自第三方的應用。

◆ 平臺：Ruby on Rails 、Erlang 、MySQL 、Mongrel 、Munin 、Nagios 、Google Analytics 、AWStats 、Memcached

下圖是twitter的整體架構設計圖：

二、twitter的平臺

twitter平臺大致由twitter.com、手機以及第三方應用構成，如下圖所示：

其中流量主要以手機和第三方為主要來源。

◆ Ruby on Rails：web應用程序的框架

◆ Erlang：通用的面向并發的編程語言，開源項目地址：http://www.erlang.org/

◆ AWStats：實時日志分析系統：開源項目地址：http://awstats.sourceforge.net/

◆ Memcached：分布式內存緩存組建

◆ Starling：Ruby開發的輕量級消息隊列

◆ Varnish：高性能開源HTTP加速器

◆ Kestrel：scala編寫的消息中間件，開源項目地址：http://github.com/robey/kestrel

◆ Comet Server：Comet是一種ajax長連接技術，利用Comet可以實現服務器主動向web瀏覽器推送數據，從而避免客戶端的輪詢帶來的性能損失。

◆ libmemcached：一個memcached客戶端

◆ 使用mysql數據庫服務器

◆ Mongrel：Ruby的http服務器，專門應用于rails，開源項目地址：http://rubyforge.org/projects/mongrel/

◆ Munin：服務端監控程序，項目地址：http://munin-monitoring.org/

◆ Nagios：網絡監控系統，項目地址：http://www.nagios.org/

三、緩存

講著講著就又說到緩存了，確實，緩存在大型web項目中起到了舉足輕重的作用，畢竟數據越靠近CPU存取速度越快。下圖是twitter的緩存架構圖：

大量使用memcached作緩存

◆ 例如，如果獲得一個count非常慢，你可以將count在1毫秒內扔入memcached

◆ 獲取朋友的狀態是很復雜的，這有安全等其他問題，所以朋友的狀態更新后扔在緩存里而不是做一個查詢。不會接觸到數據庫

◆ ActiveRecord對象很大所以沒有被緩存。Twitter將critical的屬性存儲在一個哈希里并且當訪問時遲加載

◆ 90%的請求為API請求。所以在前端不做任何page和fragment緩存。頁面非常時間敏感所以效率不高，但Twitter緩存了API請求

在memcached緩存策略中，又有所改進，如下所述：

1、創建一個直寫式向量緩存Vector Cache，包含了一個tweet ID的數組，tweet ID是序列化的64位整數，命中率是99%

2、加入一個直寫式行緩存Row Cache，它包含了數據庫記錄：用戶和tweets。這一緩存有著95%的命中率。

3、引入了一個直讀式的碎片緩存Fragmeng Cache，它包含了通過API客戶端訪問到的sweets序列化版本，這些sweets可以被打包成json、xml或者Atom格式，同樣也有著95%的命中率。

4、為頁面緩存創建一個單獨的緩存池Page Cache。該頁面緩存池使用了一個分代的鍵模式，而不是直接的實效。

四、消息隊列

◆ 大量使用消息。生產者生產消息并放入隊列，然后分發給消費者。Twitter主要的功能是作為不同形式(SMS，Web，IM等等)之間的消息橋

◆ 使用DRb，這意味著分布式Ruby。有一個庫允許你通過TCP/IP從遠程Ruby對象發送和接收消息，但是它有點脆弱

◆ 移到Rinda，它是使用tuplespace模型的一個分享隊列，但是隊列是持久的，當失敗時消息會丟失

◆ 嘗試了Erlang

◆ 移到Starling，用Ruby寫的一個分布式隊列

◆ 分布式隊列通過將它們寫入硬盤用來挽救系統崩潰。其他大型網站也使用這種簡單的方式

五、總結

1、數據庫一定要進行合理索引

2、要盡可能快的認知你的系統，這就要你能靈活地運用各種工具了

3、緩存，緩存，還是緩存，緩存一切可以緩存的，讓你的應用飛起來。

原文：http://www.cnblogs.com/lonelysharer/archive/2011/10/10/2205116.html

【編輯推薦】

1. 揭秘Google與Facebook開發之道
2. Google算法十年變遷史
3. Google為什么要執行嚴格的代碼編寫規范
4. 揭秘Google是如何做代碼審查的
5. 揭秘Google+技術架構