Poppen.de是一個德國的 交友/ 聊天/ 視頻 的SNS網站, 部分內容NSFW，網站采用了很多我們熟悉的技術，像Nginx ，MySQL，CouchDB，Erlang，Memcached的，RabbitMQ(消息服務器)，采用了Graphite作為網站的系統監控，Red5作為視頻服務，Tsung作為壓力測試工具，選擇的技術種類較多，還采用PHP和Erlang?2種程序語言作為不同功能的開發。

關于 Poppen.de 的資料統計數據
??? *? 2 000 000 用戶數
??? *? 20.000并發用戶數
??? *? 300.000條私人訊息/每天
??? *? 250.000登錄/每天
功能概要
??? * 用戶在線搜索其他用戶；
??? * 站內對方寫私人消息；
??? * 用戶上傳圖片和視頻；
??? * 用戶與用戶之間的在線視頻聊天。
?Poppen.de整個網站的技術團隊有 11個人開發人員，2個界面設計師和兩個系統管理員。

H.E的口水1：
Poppen.de 是德國的交友網站，與Facebook這樣巨頭網站相比算是一個小型網站了，但是通過Poppen.de網站這次對外的技術信息分享，可以看出網站有個不錯的技術架構，讓我們可以從中得到很多值得學習與借鑒的內容。?
H.E的口水2：
NSFW這個英文縮寫常常出現在Blog中，表示某個站點含有露點或者極度暴力的內容，如果你在上班的時候打開這個網站你的同事經過你身邊的時候估計會讓你很尷尬，呵呵。所以在我朝廷的大局域網內是無法打開這個站點，如果一定要滿足自己的好奇心，你可以動動腦筋看看有什么辦法。

下面是最新的截圖，如圖所示：

系統架構描述：

* Web 層服務器
采用Nginx作為Web App 服務器，2臺機器在前端作為www的請求，在高峰的時候每分鐘能夠處理150.000個用戶的請求，并且結合Memcached一起使用，用來緩存一些用戶的資料信息。
另外3臺Ngixn 服務器作為圖片服務器的請求 例如:img.bilder.poppen.de (image servers),每分鐘處理用戶80.000請求,用戶通過這3臺服務器進行圖片的讀、寫操作，只使用每臺服務器的本地緩存，并不通過Memcached服務器，并且將用戶上傳的圖片信息存放在中央式的文件系統中，估計這樣目的是為了減輕主要儲存設備的負荷。網站已經這樣使用了4年，一共5臺Ngixn服務器，每臺配置普通32位CPU、3GB RAM 內存。

* 語言環境
使用 PHP的5.3 版本 為程序語言運行環境，整個網站使用28臺機器作為PHP Ap 服務器，每臺機器配置6G內存。每個機器運行運行100個worker processes， 將運行環境的可選PHP緩存(Alternative PHP Cache, APC)打開, 據說網站透露這樣可以提高性能，能夠減少 30％的CPU和內存使用率，使用了Symfony1.2版本作為PHP的Web開發框架，可以提高網站開發效率，可快速創建復雜的WEB程序。

* 緩存(Memcached)
網站使用memcached的節點據說有50個總大小超過45 GB，Memcached用來用戶會話、個人信息、功能執行中需要的緩存、數據中需要執行like的查詢結果的存儲，網站對于將來可能會漸漸的采用 MongoDB Hash 的解決方法來進行代替現在大量的使用Memcached的現象，Javabloger個人也認為以為大量的使用Memcached緩存服務器不是明智之舉，因為Memcached的原則就不是給你放什么重要信息和可以長期存放的地方，你見過有人拿超市的存包格當私人的保險柜嗎？但一味的使用數據庫存儲也不是可取的方法，大量數據庫連接/關閉 執行SQL的開銷帶來的負載是很多機器設備不能接受的，所以使用像 MongoDB 之類的東西 還是比較折中的選擇，我們相信將來會有更多的網站會向MongoDB靠攏的。

* 消息服務器
整個網站采用的算是一種分布式的異步架構體系，中間采用RabbitMQ作為異步通訊服務器，通過上層28臺PHP Ap Server做成的LVS集群對下層2臺集群的 RabbitMQ 消息系統進行調用，這里消息系統主要用來發送運行日志，電子郵件通知，系統消息，用戶圖片上傳，每天大約需要處理 500.000條消息，這樣的架構體系可以對系統的運行性能有所改善，在Javabloger看一般有3個原因：????
????第一是加強了系統的可擴展性，
????第二是提高系統資源的使用率，
????第三是降低系統運行中瞬間的瓶頸。
比如在系統繁忙的時間里，每分鐘有1000個用戶進行登錄,這意味著我們將有1000個并發的用戶請求需要對緩存/數據庫表的更新，但是現在有了消息隊列的架構，我們可以運行他們每個順序相反。如果我們需要更多的處理速度，我們可以添加更多的消費者到消息隊列，還可以加入更多的機器到MQ消息群集中，不需要修改以前任何的配置或部署任何新的代碼。網站表示系統將來會向異步式架構發展，將更多的業務放入RabbitMQ 系統隊列中進行處理。

H.E的口水1：
? 在2010年4月份中旬，VMware旗下的SpringSource 將RabbitMQ給收購了，不過這次收購應該是一件好事，因為SpringSource計劃對RabbitMQ開發者社區提供全方位的支持，另外，SpringSource還針對此次收購發布了一個FAQ。詳見：http://www.springsource.com/rabbit-technologies-acquisition-faq

H.E.的口水2:
來自2位國內/外網友的經驗分享 (Ref1) (Ref2) (Ref3)
1.RabbitMQ支持AMQP協議，而ZeroMQ的極為簡單。
2.RabbitMQ較慢，幾十個并發以內，延時為幾十毫秒，但當客戶端達到1000個并發的時候，速度就無法容忍了（參考）；ZeroMQ上則據稱可以達到13毫米延時和高達每秒4.1兆次傳遞（參考, 國內需要翻墻才能訪問）。
3.如果隊列較多的話，RabbitMQ很容易把內存耗盡，而ZeroMQ則把隊列內容保存在發送端。
4.JMS僅僅是Java領域內的API規范，只能說AMQP比JMS更先進，它有自己的wire-level protocol 可編程的協議，并且RabbitMQ服務器充分利用了Erlang的分布式、高可靠性、并發等特性，而并不能一概而論的說JMS沒有RabbitMQ服務器好與壞。
??
* 分布式文檔數據庫(CouchDB)
系統中運行CouchDB的服務器只有一臺，主要是用來存日志的，因為在過去我們需要查看某臺機器的日志需要登錄某臺機器進行tail -f 的查看，如果機器一多肯定混亂，采用CouchDB 中一些查詢方法 query/group 就會讓工作簡化很多，而且采用分布式文檔數據庫存放系統日志似乎真的很合理，而且管理，使用也不算很復雜。Javabloger前端時間一個人看管了15臺機器，需要查看日志的時候還真的有點不方便，所以日后會在項目中嘗試一下將日志系統進行集中化處理的方案。

* 數據庫服務器
采用MySQL數據庫作為網站主要的數據信息存儲，有4臺MySQL服務器使用基于集群方式NDB表引擎用來存放用戶資料和用戶相關數據，這組集群每臺機器配置32GB內存 、4個CPU，但是他們打算在將來采用 Sharing的方式根據用戶的id來進行水平劃分，這樣當然有好處，可是這樣做了以后需要面對事物和跨庫查詢的問題，網站還有另外3臺MySQL服務器使用的是 master-slave-slave 架構存放用戶在論壇里面的信息，目前數據庫表引擎采用的是MyISAM，這樣讀寫會很快，但是會遇到全表鎖的問題，所以將來打算使用?XtraDB?引擎進行存儲，網站對于查詢SQL和建立數據庫表結構也進行了多次考慮，為了避免like和join帶來的開銷，因此創建數據庫匯總表，以紓緩用戶查詢帶來壓力。

* 系統監控(Graphite)
Graphite是這個網站一個重要的部分，用來進行收集服務器所有的及時狀態，用戶請求信息，Memcached命中率，RabbitMQ消息服務器的狀態，Unix操作系統的負載狀態，Graphite服務器大約每分鐘需要有4800次更新操作，Graphite采用簡單的文本協議和繪圖功能可以方便地使用在任何操作系統上。Graphite 是一個Python寫的web應用，采用django框架，如果你想嘗試一下的話，具體的安裝步驟參見：http://graphite.wikidot.com/installation
安裝好以后的效果如圖所示：

對于具體的PHP程序性能運行的監控是采用Facebook開源出來的一個php性能測試工具，XHProf是一個分層PHP性能分析工具。它報告函數級別的請求次數和各種指標，包括阻塞時間，CPU時間和內存使用情況。一個函數的開銷，可細分成調用者和被調用者的開銷。原始數據收集部分是用純C實現的，是一個名叫xhprof的 Zend擴展 。XHProf有一個簡單的HTML的用戶界面（ PHP寫成的）。基于瀏覽器的性能分析用戶界面能更容易查看，或是與同行們分享成果。也能繪制調用關系圖。如果他們通過 Graphite發現那臺Unix負荷高了，將會進一步的使用 XHProf 分析器進行測試。并且有一個單獨的服務器發送 XHProf測試的概況，并從那里進行分析，找到性能問題的所在。

* 視頻服務器 (Red5)
網站還為用戶提供視頻服務，一種是用戶上傳的一段視頻，還可以彼此進行分享與評價，此外，網站還有一個在線的視頻聊天，在2009年中期每月視頻說產生的網絡流量達到17TB。網站將會尋找更換Red5 視頻服務的方案，可能會選擇Oneteam媒體服務器。

* 壓力測試 (Tsung)
Tsung是采用Erlang編寫一個分布式測試工具。在Tsung控制機器上寫tsung.xml，在這個文件中指定所有的client機器地址、每臺機器的權重、模擬的用戶數量 配置完成就可以進行測試了，網站用它做HTTP的 benchmarks? 測試，測試 MySQL存儲引擎的處理能力，例如是否需要使用新的MySQL引擎 XtraDB，并且還需要知道XtraDB的處理能力是多大，都是通過Tsung得出的結果，因為Tsung可以輸出不同的格式的報告和圖表信息，如圖所示：

查看大圖請點擊這里，如果你有興趣的話，可以查看Tsung詳細的用戶手冊：http://tsung.erlang-projects.org/user_manual.html

通過Poppen.de這次的對外技術分享，整個網站在我腦海中的架構如圖所示，這只是我的猜想，與實際的架構有出入，請多多見諒：

查看大圖請點擊這里

總結：

1.越來越多的網站由于業務的壯大，在尋求通過消息傳遞的，異步式架構的方案，在poppen.de中使用的RabbitMQ是Erlang編寫的消息服務器，支持Java、C/C++、.Net 、PHP 等語言。

2.MySQL 的第三方引擎 XtraDB 受到越來越多人的認知，MyISAM依然有用武之地，只是老大難鎖表問題一直沒有很好的解決辦法。

3.Graphite是一款不錯的系統監控軟件，對與一個網站來說監控其運行狀態，觀測硬盤、CPU的使用率，Memcached的命中率，客戶的訪問動向、來源，是一件比較重要的事情， 采用Python語言寫的，個人感覺Python如果能得到更好的商業支持，將來的前景會比Java好。

4.CouchDB是Apache組織又一款經典產品，作為非關鍵性的數據進行存儲是一個絕佳的方案，例如：系統中的日志。

5.Memcached 和 數據庫之間會逐漸的多出一個產物，比如?MongoDB ，不會像現在這樣緩存和數據庫2者之間有這么大的跨度。

6.凡是接觸過 Erlang 的人，都會對其產生喜好，可見Erlang的勢頭。

7.MySQL 的 官方集群方案仍然不會被人看好，但是 MySQL 的 MMM 和 MSS 依然是經典。

8.Ngixn的性能強大和配置簡單讓他成為web服務器的新寵兒， 對一些圖片的訪問/讀寫還可以使用Ngixn的本地緩存 。
??
–end–

原文地址： http://www.javabloger.com/article/couchdb-erlang-rabbitmq-red5-linux-poppen-architecture.html

總結

以上是生活随笔為你收集整理的德国SNS交友/视频网站Poppen.de的技术架构分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。