歡迎您光臨本站 註冊首頁

Yupoo(又拍網)的系統架構

←手機掃碼閱讀     火星人 @ 2014-03-12 , reply:0
  

Yupoo!(又拍網) 是目前國內最大的圖片服務提供商,整個網站構建於大量的開源軟體之上。以下為其使用到的開源軟體信息:

  • 操作系統:CentOS、MacOSX、Ubuntu
  • 伺服器:Apache、Nginx、Squid
  • 資料庫:MySQLmochiweb、MySQLdb
  • 伺服器監控:Cacti、Nagios、
  • 開發語言:PHP、Python、Erlang、Java、Lua
  • 分散式計算:Hadoop、Mogilefs、
  • 日誌分析:AWStats
  • 任務管理:Redmine
  • 消息系統:RabbitMQ、php-amqp
  • 前端框架:Mootools
  • 緩存系統:Memcached、php-memcached、libmemcached、pylibmc、XCache、RedisRiak、Predis
  • 圖片處理:GraphicsMagick、gmagick
  • FTP工具:vsftpd
  • 開發工具:VIM、Readline
  • 調試工具:Firebug、Xdebug
  • 版本控制:Mercurial
  • 搜索服務:Solr
  • 郵件服務:Postfix
  • 網路編程:Twisted、cURL、libevent、Net-SNMP、NTP
  • 可用性測試:ibrowse
  • 集群系統:Heartbeat
  • 并行開發:gevent
  • 負載均衡:IPVS
  • Python框架:bottle
  • 虛擬通道:OpenVPN

(信息來源:http://www.yupoo.com/info/about/)。

一、Yupoo的整體架構

二、程序語言的選擇

Yupoo的伺服器端開發語言主要是PHP和Python,其中PHP用於編寫Web邏輯(通過HTTP和用戶直接打交道), 而Python則主要用於開發內部服務和後台任務。在客戶端則使用了大量基於MooTools框架的Javascript。 另外,Yupoo把圖片處理過程從PHP進程里獨立出來變成一個服務。這個服務基於nginx,作為nginx的一個模塊開放REST API。

三、伺服器的選用

選用Squid的原因是「目前暫時還沒找到效率比 Squid 高的緩存系統,原來命中率的確很差,後來在 Squid 前又裝了層 Lighttpd, 基於 url 做 hash, 同一個圖片始終會到同一台 squid 去,所以命中率徹底提高了。」

同時Yupoo也使用Python開發了YPWS/YPFS:

  • YPWS?Yupoo Web Server 是用 Python開發的一個小型 Web 伺服器,提供基本的 Web 服務外,可以增加針對用戶、圖片、外鏈網站顯示的邏輯判斷,可以安裝於任何有空閑資源的伺服器中,遇到性能瓶頸時方便橫向擴展。
  • YPFS?Yupoo File System 與 YPWS 類似,也是基於這個 Web 伺服器上開發的圖片上傳伺服器。

有網友留言質疑 Python 的效率,Yupoo 老大劉平陽在 del.icio.us 上寫到 「YPWS用Python自己寫的,每台機器每秒可以處理294個請求, 現在壓力幾乎都在10%以下」

四、Yupoo的消息系統

由於PHP的單線程模型,Yupoo把耗時較久的運算和I/O操作從HTTP請求周期中分離出來, 交給由Python實現的任務進程來完成,以保證請求響應速度。這些任務主要包括:郵件發送、數據索引、數據聚合和好友動態推送等等。PHP通過消息隊列 (Yupoo用的是RabbitMQ)來觸發任務執行。這些任務的主要特點為:

  • 由用戶或者定時觸發的
  • 耗時比較長的
  • 需要非同步執行的

整個任務系統主要分為以消息分發、進程管理和工作進程組成。

五、資料庫的設計

資料庫一向是網站架構中最具挑戰性的,瓶頸通常出現在這裡。又拍網的照片數據量很大,資料庫也幾度出現嚴重的壓力問題。和很多使用MySQL的 2.0站點一樣,又拍網的MySQL集群經歷了從最初的一個主庫一個從庫、到一個主庫多個從庫、 然後到多個主庫多個從庫的一個發展過程。

最初是由一台主庫和一台從庫組成,當時從庫只用作備份和容災,當主庫出現故障時,從庫就手動變成主庫,一般情況下,從庫 不作讀寫操作(同步除外)。隨著壓力的增加,加上了memcached,當時只用其緩存單行數據。 但是,單行數據的緩存並不能很好地解決壓力問題,因為單行數據的查詢通常很快。所以把一些實時性要求不高的Query放到從庫去執行。後面又通過添加多個 從庫來分流查詢壓力,不過隨著數據量的增加,主庫的寫壓力也越來越大。在參考了一些相關產品和其它網站的做法后,進了行資料庫拆分。也就是將數據存放到不 同的資料庫伺服器中。

如何進行資料庫拆分?

  • 垂直拆分:是指按功能模塊拆分,比如可以將群組相關表和照片相關表存放在不同的資料庫中,這種方式多個資料庫之間的表結構不同。
  • 水平拆分:而水平拆分是將同一個表的數據進行分塊保存到不同的資料庫中,這些資料庫中的表結構完全相同。

一般都會先進行垂直拆分,因為這種方式拆分方式實現起來比較簡單,根據表名訪問不同的資料庫就可以了。但是垂直拆分方式並不能徹底解決所有壓力問 題,另外,也要看應用類型是否合適這種拆分方式。如果合適的話,也能很好的起到分散資料庫壓力的作用。比如對於豆瓣我比較適合採用垂直拆分, 因為豆瓣的各核心業務/模塊(書籍、電影、音樂)相對獨立,數據的增加速度也比較平穩。不同的是,又拍網的核心業務對象是用戶上傳的照片,而照片數據的增 加速度隨著用戶量的增加越來越快。壓力基本上都在照片表上,顯然垂直拆分並不能從根本上解決我們的問題,所以,Yupoo採用水平拆分的方式。

水平拆分實現起來相對複雜,我們要先確定一個拆分規則,也就是按什麼條件將數據進行切分。 一般2.0網站都以用戶為中心,數據基本都跟隨用戶,比如用戶的照片、朋友和評論等等。因此一個比較自然的選擇是根據用戶來切分。每個用戶都對應一個數據 庫,訪問某個用戶的數據時, 要先確定他/她所對應的資料庫,然後連接到該資料庫進行實際的數據讀寫。那麼,怎麼樣對應用戶和資料庫呢?Yupoo有這些選擇:

1、按演算法對應

最簡單的演算法是按用戶ID的奇偶性來對應,將奇數ID的用戶對應到資料庫A,而偶數ID的用戶則對應到資料庫B。這個方法的最大問題是,只能分成兩 個庫。另一個演算法是按用戶ID所在區間對應,比如ID在0-10000之間的用戶對應到資料庫A, ID在10000-20000這個範圍的對應到資料庫B,以此類推。按演算法分實現起來比較方便,也比較高效,但是不能滿足後續的伸縮性要求,如果需要增加 資料庫節點,必需調整演算法或移動很大的數據集, 比較難做到在不停止服務的前提下進行擴充資料庫節點。

2、按索引/映射表對應

這種方法是指建立一個索引表,保存每個用戶的ID和資料庫ID的對應關係,每次讀寫用戶數據時先從這個表獲取對應資料庫。新用戶註冊后,在所有可用 的資料庫中隨機挑選一個為其建立索引。這種方法比較靈活,有很好的伸縮性。一個缺點是增加了一次資料庫訪問,所以性能上沒有按演算法對應好。

比較之後,Yupoo採用的是索引表的方式,我們願意為其靈活性損失一些性能,更何況我們還有memcached, 因為索引數據基本不會改變的緣故,緩存命中率非常高。所以能很大程度上減少了性能損失。

索引表的方式能夠比較方便地添加資料庫節點,在增加節點時,只要將其添加到可用資料庫列表裡即可。 當然如果需要平衡各個節點的壓力的話,還是需要進行數據的遷移,但是這個時候的遷移是少量的,可以逐步進行。要遷移用戶A的數據,首先要將其狀態置為遷移 數據中,這個狀態的用戶不能進行寫操作,並在頁面上進行提示。 然後將用戶A的數據全部複製到新增加的節點上后,更新映射表,然後將用戶A的狀態置為正常,最後將原來對應的資料庫上的數據刪除。這個過程通常會在臨晨進 行,所以,所以很少會有用戶碰到遷移數據中的情況。當然,有些數據是不屬於某個用戶的,比如系統消息、配置等等,把這些數據保存在一個全局庫中。

分庫帶來的問題如何解決?

分庫會給在應用的開發和部署上都帶來很多麻煩。

1、不能執行跨庫的關聯查詢

如果我們需要查詢的數據分佈於不同的資料庫,沒辦法通過JOIN的方式查詢獲得。比如要獲得好友的最新照片,不能保證所 有好友的數據都在同一個資料庫里。一個解決辦法是通過多次查詢,再進行聚合的方式。所以需要盡量避免類似的需求。有些需求可以通過保存多份數據來解決,比 如User-A和User-B的資料庫分別是DB-1和DB-2, 當User-A評論了User-B的照片時,我們會同時在DB-1和DB-2中保存這條評論信息,我們首先在DB-2中的photo_comments表 中插入一條新的記錄,然後在DB-1中的user_comments表中插入一條新的記錄。這兩個表的結構如下圖所示。這樣我們可以通過查詢 photo_comments表得到User-B的某張照片的所有評論, 也可以通過查詢user_comments表獲得User-A的所有評論。另外可以考慮使用全文檢索工具來解決某些需求, 使用Solr來提供全站標籤檢索和照片搜索服務。

2、不能保證數據的一致/完整性

跨庫的數據沒有外鍵約束,也沒有事務保證。比如上面的評論照片的例子, 很可能出現成功插入photo_comments表,但是插入user_comments表時卻出錯了。一個辦法是在兩個庫上都開啟事務,然後先插入 photo_comments,再插入user_comments, 然後提交兩個事務。這個辦法也不能完全保證這個操作的原子性。

3、所有查詢必須提供資料庫線索

比如要查看一張照片,僅憑一個照片ID是不夠的,還必須提供上傳這張照片的用戶的ID(也就是資料庫線索),才能找到它 實際的存放位置。因此,必須重新設計很多URL地址,而有些老的地址我們又必須保證其仍然有效。Yupoo把照片地址改成/photos /{username}/{photo_id}/的形式,然後對於系統升級前上傳的照片ID, 又增加一張映射表,保存photo_id和user_id的對應關係。當訪問老的照片地址時,通過查詢這張表獲得用戶信息, 然後再重定向到新的地址。

4、自增ID重複的問題

如果要在節點資料庫上使用自增欄位,那麼我們就不能保證全局唯一。這倒不是很嚴重的問題,但是當節點之間的數據發生關係 時,就會使得問題變得比較麻煩。再來看看上面提到的評論的例子。如果photo_comments表中的comment_id的自增欄位,當我們在DB- 2.photo_comments表插入新的評論時, 得到一個新的comment_id,假如值為101,而User-A的ID為1,那麼我們還需要在DB-1.user_comments表中插入(1, 101 …)。 User-A是個很活躍的用戶,他又評論了User-C的照片,而User-C的資料庫是DB-3。 很巧的是這條新評論的ID也是101,這種情況很用可能發生。那麼我們又在DB-1.user_comments表中插入一行像這樣(1, 101 …)的數據。 那麼我們要怎麼設置user_comments表的主鍵呢(標識一行數據)?可以不設啊,不幸的是有的時候(框架、緩存等原因)必需設置。那麼可以以 user_id、 comment_id和photo_id為組合主鍵,但是photo_id也有可能一樣(的確很巧)。看來只能再加上photo_owner_id了, 但是這個結果又讓我們實在有點無法接受,太複雜的組合鍵在寫入時會帶來一定的性能影響,這樣的自然鍵看起來也很不自然。所以,Yupoo放棄了在節點上使 用自增欄位,想辦法讓這些ID變成全局唯一。為此增加了一個專門用來生成ID的資料庫,這個庫中的表結構都很簡單,只有一個自增欄位id。 當我們要插入新的評論時,我們先在ID庫的photo_comments表裡插入一條空的記錄,以獲得一個唯一的評論ID。 當然這些邏輯都已經封裝在我們的框架里了,對於開發人員是透明的。 為什麼不用其它方案呢,比如一些支持incr操作的Key-Value資料庫。Yupoo還是比較放心把數據放在MySQL里。 另外,Yupoo會定期清理ID庫的數據,以保證獲取新ID的效率。

資料庫優化的實現

前面提到的一個資料庫節點為Shard,一個Shard由兩個台物理伺服器組成, 可以理解為Node-A和Node-B,Node-A和Node-B之間是配置成Master-Master相互複製的。 雖然是Master-Master的部署方式,但是同一時間還是只使用其中一個,原因是複製的延遲問題, 當然在Web應用里,可以在用戶會話里放置一個A或B來保證同一用戶一次會話里只訪問一個資料庫, 這樣可以避免一些延遲問題。但是Python任務是沒有任何狀態的,不能保證和PHP應用讀寫相同的資料庫。那麼為什麼不配置成Master-Slave 呢?Yupoo覺得只用一台太浪費了,所以在每台伺服器上都創建多個邏輯資料庫。 如下圖所示,在Node-A和Node-B上我們都建立了shard_001和shard_002兩個邏輯資料庫, Node-A上的shard_001和Node-B上的shard_001組成一個Shard,而同一時間只有一個邏輯資料庫處於Active狀態。 這個時候如果需要訪問Shard-001的數據時,我們連接的是Node-A上的shard_001, 而訪問Shard-002的數據則是連接Node-B上的shard_002。以這種交叉的方式將壓力分散到每台物理伺服器上。 以Master-Master方式部署的另一個好處是,可以不停止服務的情況下進行表結構升級, 升級前先停止複製,升級Inactive的庫,然後升級應用,再將已經升級好的資料庫切換成Active狀態, 原來的Active資料庫切換成Inactive狀態,然後升級它的表結構,最後恢複復制。 當然這個步驟不一定適合所有升級過程,如果表結構的更改會導致數據複製失敗,那麼還是需要停止服務再升級的。

前面提到過添加伺服器時,為了保證負載的平衡,需要遷移一部分數據到新的伺服器上。為了避免短期內遷移的必要,在實際部 署的時候,每台機器上部署了8個邏輯資料庫, 添加伺服器后,只要將這些邏輯資料庫遷移到新伺服器就可以了。最好是每次添加一倍的伺服器, 然後將每台的1/2邏輯數據遷移到一台新伺服器上,這樣能很好的平衡負載。當然,最後到了每台上只有一個邏輯庫時,遷移就無法避免了,不過那應該是比較久 遠的事情了。

Yupoo把分庫邏輯都封裝在我們的PHP框架里了,開發人員基本上不需要被這些繁瑣的事情困擾。下面是使用框架進行照片數據的讀寫的一些例子:

 array('type' => 'long', 'primary' => true, 'global_auto_increment' => true),                     'user_id'     => array('type' => 'long'),                     'title'       => array('type' => 'string'),                     'posted_date' => array('type' => 'date'),                 ));         $photo = $Photos->new_object(array('user_id' => 1, 'title' => 'Workforme'));         $photo->insert();         // 載入ID為10001的照片,注意第一個參數為用戶ID         $photo = $Photos->load(1, 10001);         // 更改照片屬性         $photo->title = 'Database Sharding';         $photo->update();         // 刪除照片         $photo->delete();         // 獲取ID為1的用戶在2010-06-01之後上傳的照片         $photos = $Photos->fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));     ?>

首先要定義一個ShardedDBTable對象,所有的API都是通過這個對象開放。第一個參數是對象類型名稱, 如果這個名稱已經存在,那麼將返回之前定義的對象。你也可以通過get_table(『Photos』)這個函數來獲取之前定義的Table對象。 第二個參數是對應的資料庫表名,而第三個參數是資料庫線索欄位,你會發現在後面的所有API中全部需要指定這個欄位的值。 第四個參數是欄位定義,其中photo_id欄位的global_auto_increment屬性被置為true,這就是前面所說的全局自增ID, 只要指定了這個屬性,框架會處理好ID的事情。

如果我們要訪問全局庫中的數據,我們需要定義一個DBTable對象。

 array('type' => 'long', 'primary' => true, 'auto_increment' => true),                     'username' => array('type' => 'string'),                 ));     ?>

DBTable是ShardedDBTable的父類,除了定義時參數有些不同(DBTable不需要指定資料庫線索欄位),它們提供一樣的API。

六、緩存方案的選擇

Yupoo使用的框架自帶緩存功能,對開發人員是透明的。

load(1, 10001);     ?>

比如上面的方法調用,框架先嘗試以Photos-1-10001為Key在緩存中查找,未找到的話再執行資料庫查詢並放入緩存。當更改照片屬性或刪除照片時,框架負責從緩存中刪除該照片。這種單個對象的緩存實現起來比較簡單。稍微麻煩的是像下面這樣的列表查詢結果的緩存。

fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01'));     ?>

Yupoo把這個查詢分成兩步,第一步先查出符合條件的照片ID,然後再根據照片ID分別查找具體的照片信息。 這麼做可以更好的利用緩存。第一個查詢的緩存Key為Photos-list-{shard_key}-{md5(查詢條件SQL語句)}, Value是照片ID列表(逗號間隔)。其中shard_key為user_id的值1。目前來看,列表緩存也不麻煩。 但是如果用戶修改了某張照片的上傳時間呢,這個時候緩存中的數據就不一定符合條件了。所以,需要一個機制來保證我們不會從緩存中得到過期的列表數據。我們 為每張表設置了一個revision,當該表的數據發生變化時(調用insert/update/delete方法), 我們就更新它的revision,所以我們把列表的緩存Key改為Photos-list-{shard_key}-{md5(查詢條件SQL語 句)}-{revision}, 這樣我們就不會再得到過期列表了。

revision信息也是存放在緩存里的,Key為Photos-revision。這樣做看起來不錯,但是好像列表緩 存的利用率不會太高。因為我們是以整個數據類型的revision為緩存Key的後綴,顯然這個revision更新的非常頻繁,任何一個用戶修改或上傳 了照片都會導致它的更新,哪怕那個用戶根本不在我們要查詢的Shard里。要隔離用戶的動作對其他用戶的影響,我們可以通過縮小revision的作用范 圍來達到這個目的。 所以revision的緩存Key變成Photos-{shard_key}-revision,這樣的話當ID為1的用戶修改了他的照片信息時, 只會更新Photos-1-revision這個Key所對應的revision。

因為全局庫沒有shard_key,所以修改了全局庫中的表的一行數據,還是會導致整個表的緩存失效。 但是大部分情況下,數據都是有區域範圍的,比如幫助論壇的主題帖子, 帖子屬於主題。修改了其中一個主題的一個帖子,沒必要使所有主題的帖子緩存都失效。 所以在DBTable上增加了一個叫isolate_key的屬性。

 array('type' => 'long', 'primary' => true),             'post_id'     => array('type' => 'long', 'primary' => true, 'auto_increment' => true),             'author_id'   => array('type' => 'long'),             'content'     => array('type' => 'string'),             'posted_at'   => array('type' => 'datetime'),             'modified_at' => array('type' => 'datetime'),             'modified_by' => array('type' => 'long'),         ), 'topic_id');     ?>

注意構造函數的最後一個參數topic_id就是指以欄位topic_id作為isolate_key,它的作用和shard_key一樣用於隔離revision的作用範圍。

ShardedDBTable繼承自DBTable,所以也可以指定isolate_key。 ShardedDBTable指定了isolate_key的話,能夠更大幅度縮小revision的作用範圍。 比如相冊和照片的關聯表yp_album_photos,當用戶往他的其中一個相冊里添加了新的照片時, 會導致其它相冊的照片列表緩存也失效。如果指定這張表的isolate_key為album_id的話, 我們就把這種影響限制在了本相冊內。

緩存分為兩級,第一級只是一個PHP數組,有效範圍是Request。而第二級是memcached。這麼做的原因是, 很多數據在一個Request周期內需要載入多次,這樣可以減少memcached的網路請求。另外Yupoo的框架也會儘可能的發送memcached 的gets命令來獲取數據, 從而減少網路請求。

參考文章:http://www.infoq.com/cn/articles/yupoo-partition-database

來自:http://www.biaodianfu.com/yupoo-architecture.html



[火星人 ] Yupoo(又拍網)的系統架構已經有1117次圍觀

http://coctec.com/docs/enterprise/show-post-73097.html