![好友買賣[Facebook遊戲]](/img/9/ff1/nBnauM3X2EDMzkTM4MTN0ETN1UTM1QDN5MjM5ADMwAjMwUzLzUzL2gzLt92YucmbvRWdo5Cd0FmLxE2LvoDc0RHa.jpg "好友買賣[Facebook遊戲]")
遊戲起源
朋友買賣起源於Facebook(一個國際的SNS網站)
而非開心網
2.1 基本介紹
官方命名：Friends For Sale!
中文譯名：好友買賣、朋友買賣
在朋友買賣外掛程式出現的短短三個月時間內，朋友買賣成為facebook前十名的套用，它每秒鐘處理200個請求，每月產生300 000 000個page view。在技術上，選擇了Ruby on Rails框架，兩個兼職程式設計師，一打伺服器，和優秀的架構。
2.2 套用架構
l Ruby on Rails
l CentOS 5(64bit)
l Capistrano 升級和重啟套用伺服器
l Memcached
l Mysql
l Nginx
l Starling 分散式佇列服務
l Softlayer 堡壘主機
l Pingdom 站點監視器
l LVM 邏輯卷管理器
l Dr.Nics Magic Multi-Connections Gem 資料庫讀寫分離
2.3 當前情況
l Facebook十大熱門套用
l 將近600 000活躍用戶
l 每天500000獨立用戶訪問量並保持持續增長
l 300 000 000 page view 每月
l 每月300%的穩定增長率
l 上個月2100 000 000的獨立用戶
l 每秒處理200次請求
l 每月5TB的流量
l 兩個兼職開發者（目前一個全職），一個遠程DBA支持
l 4台資料庫伺服器，6台套用伺服器，a staging server, a front end server
六台 4核 8G記憶體 套用伺服器
每個套用伺服器建立16個mongrels一共是96個mongrels
2.4 F&Q答問
為什麼做這個系統：
做這個系統更多的是為了測試和了解facebook這個系統
設計系統的時候，在設計，架構和實現方面有什麼挑戰和創新？
因為作為facebook的套用，每個請求都不能使用快取頁面，因此，它是一個時實行，並且寫操作頻繁的系統，對資料庫最佳化要求比較高。
如何應付這些挑戰？
我們採用memcached作為中間層，每個請求都不直接訪問資料庫。使用Rail's fragment caching快取表現層。
系統目前是什麼規模？
昨日訪問量是500 000個獨立用戶並且訪問量一直在增長。根據統計反饋，本月有 300 000 000 的page view。
頻寬使用狀況
上月產生了3T的流量，這月最少5T，內容僅僅是一些圖示和xhtml/css。
檔案數目，圖片數目，和數據情況
沒有檔案，有10 000 000用戶信息。只有少量圖片。
增長率？
Page view由平均3M 每天增長到一個月前的10M每天，之前一個月1M，因此平均300%的月增長率，平均每秒處理200個訪問。
用戶需要付費么？
全部免費
用戶增長率
平均1%，並且以每天3%的速度增長。
上月有多少用戶活動了？
通過google的統計，上月有2 100 000 獨立用戶訪問。
系統架構如何做？
首先它構建於非常穩定的Rails集群，而且使用nginx軟體運行負載均衡和靜態內容的服務。6個套用伺服器使用4核CPU8G記憶體。每個套用伺服器運行16個mongrels，一共有96個mongrels。負載均衡直接轉向mongrels ports。還有，一個4G的memcache伺服器，獨立的一台對列伺服器。
使用god檢測進程。
數據層，使用兩台32G記憶體，4核CPU，4×15K SCSI RAID 10disk 做主從。使用Dr Nic's magic multi-connection's gem產品做讀寫分離。
現在添加了更多的從屬伺服器可以獲得更高的讀效率和冗餘。
託管商略。
如何規劃架構
在套用層沒有做什麼，因為功能非常瑣碎。在資料庫方面，我們只有一個主資料庫，儘可能去快速分發。垂直劃分資料庫提高可用性。
有什麼獨特的地方可以借鑑？
三個方面：
1、兩個開發者之前都沒有進行過大規模的Rails開發
2、我們的增長率在Rails開發史上比較少見。
3、幾乎沒有做快取，每個請求直接用Rails處理
你們中間學到了什麼？你們為什麼成功？你們是否希望以後做其他的東西，有什麼不想改變的？
我們知道了一個好的託管上，好的硬體，好的DBA都是非常重要的。我們曾經選擇Railsmachine，他們是一個非常不錯的空間提供商但給我們很大的支持。之後幾乎沒有碰到過硬體上的問題，而且之用兩個小時就平滑切換到了Softlayer上。選擇一個好的託管上尤其重要。
另一個重要的事情是可伸縮的架構一貫問題出現在資料庫上。首先檢查資料庫，一般情況下都可以通過資料庫伺服器，資料庫配置，查詢，索引來解決。
開始就建立在一個好的託管商。
我們鑑定用Rails，因為這是免費並且可快速開發的程式，實踐證明兩個小伙在沒有充足時間的前提下也順利開發完成了。
你們的小組如何組成的？
我們有兩個Rails程式設計師，包括我在內。而且招安了曾經兼職遠程辦公的DBA。
你們一共有多少錢人？
技術方面，兩個兼職的，一個全職的，一個遠程辦公的DBA。
你們現在在哪？
兩個全職人員依然在 SOMA area of San Francisco。
這些人的職責？
兩個開發者作為創始人，我最早做前端開發和程式開發。有一些經驗後我也做網管。創始人Alex非常專注於Rails開發，大部分的應用程式是他開發的。現在我主要做資料庫方面的工作。
有什麼獨特的管理方法？
首先，找到最聰明的人，給最好的待遇，盡其所長。最好的管理是盡其所長，我用這種方法管理公司。我想我經常在這裡出問題。
你如使一個分散的團隊工作？
有個好的交流工具。遠程辦公比較痛苦，核心開發還是要在本地，一些DBA之類的事情可以遠程。
2.6 開發情況
使用Rails，很多快取採用Chris Wanstrath的方案，資料庫連線使用Dr Nic。我們使用VIM作為編輯器。
開發語言
Ruby / Rails
伺服器數量
12台伺服器
伺服器套用情況
4台資料庫，6台套用，一台staging server，一台前端機
託管商
Softlayer
伺服器作業系統
Centos 5 64bit
Web server
Nginx
資料庫軟體
Mysql 5.1
反向代理
Nginx
如何部署
委託Softlayer
存儲
NAS備份，SCSI硬碟支撐。
存儲容量
5TB
存儲如何擴展
Ad-hoc。 我們不關注這塊，這是我們的軟肋。
存儲伺服器
Nope
如何處理session
資料庫，memcache也許更好
資料庫如何規劃
目前用的主從。一主多從，使用負載均衡提高讀性能。
如何做負載均衡
Nginx
使用何種框架和ajax類庫
Rails
是否使用了訊息服務
沒
使用了何種分散式任務管理系統
Starling(佇列管理)
如何處理廣告服務
使用eCPM
是否使用了標準的API
Nope
團隊有多少成員
兩個開發
團隊的技能情況
Me：前端開發，開發（Rails）。最近專注資料庫和高擴展性Rails的開發。
Alex：應用程式開發，前端開發，程式架構設計。
開發環境
Alex使用OSX，我在ubuntu上，我們使用svn進行同步，我用vim編輯器，alex用textmate。
開發進度
邏輯層，測試驅動開發，在套用層，使用疊代開發。
快取策略
使用memcache no TTL，手工設定過期
是否採用了客戶端快取機制
沒
2.6 系統管理
如何保證性能
使用Pingdom工具進行網頁性能監測。
伺服器和網路可用性檢測
現在我們用自己的檢測工具和Softlay提供的ping檢測工具。最近我們開發了 FiveRuns作為伺服器監控工具。
如何做網路和伺服器性能圖示
沒有做
如何測試系統
我們分模組測試，然後完善的部分，部署到套用伺服器上。
如何做性能分析
分析每條sql語句保證效率。沒有測試標準。
如何保證安全
小心
那些特性需要改進/保持
反思和批評。我們會非常謹慎得增加一些特性。
如何做web分析
使用一個成長中的檢測工作做病毒檢測，也使用了google analytics。
是否做A/B測試
一直在做
2.7 相關說明
系統設計目標
支撐facebook套用－買賣朋友。
它基於一個波動的金融市場。
目前它是facebook排名前十的熱門套用。
Tips：像買賣寵物一樣買賣好友！你可以玩弄他，送禮物，或者用來炫耀。精明的投資者會把他的朋友發展成人們的貨物，其實這只是滿足
數據中心是如何設定的
如何備份和回復系統
LVM，每周做增量備份，每日做基本備份
如何升級軟硬體
現在手工來做，除非有新的套用。使用capistrano升級和重啟套用伺服器。
如何處理主資料庫的升級
一般是先切換一個從資料庫為主，升級完後再切換回來。
你們的發展計畫
不是很好
你們有獨立的運營團隊么
希望有
是否使用內容分發系統
Nope
盈利模式
CPM，瀏覽多收入多。也通過虛擬貨幣盈利。
如何行銷你們的產品
口碑。病毒傳銷。
在算法上有什麼獨特的地方
Ruby已經非常優秀。我們只需要簡單套用。
是否在資料庫中存儲圖片
沒有，這樣不太好
在前端設計上你們都做了什麼
在事情發生之前你不知道會發生什麼事情。一旦做過，你會有完備的知識去解決下個問題。
有什麼值得關注的好事或者壞事
不可靠的硬體，託管商之間溝通的困難，最重要的事情是選擇一個能支持你套用的託管商。（sun補充：好像他們的運維都是idc來做）。另一個重要的事情是商用硬體做一個主從設定能支撐多久，你可以輕鬆支撐10億級訪問。
系統什麼時候增加新的擴展
沒這個計畫，事情來了才去計畫。
有什麼值得發揚的
Memcache，你可以隨意切分你的架構
未來是否要調整架構
我們馬上要給用戶資料庫分區，因為馬上就會達到資料庫的極限。
Facebook 行銷思想
l Facebook 成功的把社會關係網路數位化
l 未來社會關係很重要
l Facebook把飛速發展的社會關係放在了網際網路上
l 你的套用創意可以是：社會性的，誘人的，通用的。
l 社會化的病毒行銷
l 貨幣化
l 普遍具有潛力
l 朋友買賣是個社會，因為你可以買賣你的社會關係
l 因為它只是一個概念，沒有壓力並且有點調侃的玩，所以非常有趣
l 它是公平的因為每個人都是虛擬的，有價錢，而且都想變得有人緣。
l 每次套用都可能發展一些新的用戶
l 從增長指數上來計算，每個人都能影響1.4個人
l 每個用戶發出好多邀請，查看公告，閱讀feed，查看用戶資料，和其他的項目
l 每個頻道都能跟蹤用戶點擊，修改，和卸載
本節收穫
l 擴展性從開始就是facebook的一個方向，他們在一周內就做到每天1000000pv的訪問量
l Ruby on Rails可擴展
l 擴展性表現在架構上，關注架構和運營
l 你需要個好的DBA，好的託管商，合理的硬體
l 利用cache和高負載的硬體，你不用去做負載的資料庫最佳化
l 社會關係是真實的，它構建於facebook的用戶基礎上，而且有非常好的虛擬套用。
l 大部分問題都是資料庫的，資料庫伺服器，資料庫配置，查詢，和索引。
l 用戶依然試用VI
