本文作者 Johann Schleier-Smith，他是Tagged的聯合創始人兼CTO。2004年 Tagged 還是一個微不足道的實驗性社交網站，如今它已經成為最大的社交網路之一。
如今每個月，登入Tagged 網站的會員有數百萬計，每月有50億網頁瀏覽量（PV）， 會員們在這裡參與各種社交活動並結交新朋友。這迫使我們逐步地提升我們的架構，使得平臺能夠勝任Tagged的飛速發展。根據Tagged網站首頁的資訊，可知其使用者已超過1億。
1. PHP web應用程式， 10萬使用者， 15臺伺服器， 2004年
Tagged誕生於一個孵化器的快速成型培養專案，該專案每年都會尋找兩個獲獎的創意並啟動創業。 LAMP是實現這種創意的自然選擇，它強調靈活性並能夠快速適應變化，與此同時，Java的定位是大型企業級應用開發，Python得到程式設計師 的關注寥寥，Perl針對的並非此類專案。我們也瞭解到Yahoo是PHP的堅定支持者，因此當我們業務擴張時 LAMP應該能提供相應的支援。
編注：LAMP：Linux+Apache+Mysql+Perl/PHP/Python一組常用來搭建動態網站或者伺服器的開源軟體，本身都是各自獨立的程式，但是因為常被放在一起使用，擁有了越來越高的相容度，共同組成了一個強大的Web應用程式平臺。參見LAMP詞條。
之前專案使用MySQL的深刻經歷讓我對它愛恨交加。本著實驗主義精神我們為Tagged購買一些基礎的Oracle授權，想看看Oracle 能否讓Tagged變得更好。很明顯，許多小的web站點仍然在採用這樣的結構。簡潔之美正在於此。無組織的PHP和組織化的Oracle這兩個方向的分 割在單個伺服器上將最具技巧的部分濃縮在了一起，在此基礎上新增額外的頁面顯示計算能力變得輕而易舉。
2. 帶快取記憶體支援的PHP web應用程式， 100萬使用者， 20臺伺服器， 2005年
即使在只有8臺伺服器的時候，Tagged遇到的網路擁堵也超出我們大多數人的想象。幸運的是記憶體快取記憶體帶來了雙重好處，它減少了90%的資料庫讀取並確保與其它資訊打包在一起的社交網路頁面可以快速呈現。
從一開始，我們的物件快取策略就強調顯式的快取更新，支援例如刪除無效的鍵值、定時器判定超時的過期資料等簡單技術。這些技術雖然增加了程式碼複雜度，但確實有效地減少了資料載入並讓站點保持快速訪問，在涉及到需要頻繁更新的物件時效果尤其明顯。
我們的站點複雜度逐漸超過了通常的社交網路網站功能（朋友，評價，訊息），我們還提供搜尋和社會關係發現功能。我的團隊勸我使用 Java來構建搜尋，這樣就可以利用Lucene庫並從中受益。當我們可以對此運用自如時我鬆了口氣，我對Java的態度從JDK1.0時的不 情願變成熱情地擁抱Java平臺。
編注：Lucene：是一個開源的資訊檢索軟體庫，由Java編寫，最初由Doug Cutting釋出。
3. 資料庫擴充套件， 1千萬使用者， 100臺伺服器， 2006年
當Tagged擁有1千萬註冊使用者同時線上人數達到上千人的時候，我一直擔心的問題出現了。那個時候我們剛剛籌集資金並致力於快速發展，但是資料庫容量達到了極限。雖然我們馬上陸續地增加資料快取或者對SQL進行優化，但是我們的伺服器CPU使用率還是常常逼近100%。
雖然增加伺服器能夠快速解決問題，但是帶有multi-socket支援的伺服器硬體需要上百萬的投入，所以我們選擇了Oracle RAC，這樣可以在標準的網路環境下連線多臺普通的Linux主機來構建一個大資料庫。再配合最新的CPU，Oracle RAC可以在原來的基礎上增加20倍資料儲存容量，這使得應用程式工程師可以專注於新功能的開發。
當我們需要將個性化的尋人匹配功能與記憶體中大量的資料結合時，Java再一次成為了系統的合適選擇，而這是PHP不可能完成的。
4. 資料庫分片，5千萬使用者， 500臺伺服器， 2007年
在Tagged擴充套件的過程中，資料分片毫無疑問是挑戰最大但也是回報最大的技術。通過對多個資料庫中的使用者資料進行分隔，我們最終找到一種設 計，它能保證在擴充套件系統時僅僅需要新增硬體裝置。在Tagged設計中，我們制定了每個資料表被分片在64個分割槽上，除非有令人信服的理由否則這個預設設 置不允許例外。只有對玩家之間互動有效能要求的遊戲才會採用在一個單獨的資料庫內進行垂直分割槽。
編注：資料分片：一種分散式計算，通過業務邏輯將不同的分類的資料儲存到不同的資料庫（具有相同的表結構）中。可以簡單看作是一種負載均衡技術，因為每個表中的 資料少了， 查詢速度就快了，系統能承受的負載也就大了。很多大公司都在用這種技術，比如Google, Facebook, Wikipedia等等。參考資料分片。
對現有的資料分片意味著在上TB的資料之間進行復雜的轉換。一開始我們針對產品功能逐個進行分片處理，通過應用程式程式碼來取代資料庫 JOIN。但是，我們逐漸發現有很多與核心應用程式相關的表之間關係過於緊密沒有辦法使用這種方法進行分片。最終，通過編寫資料庫移植程式來生成SQL， 我們實現了對數以億計的資料行匯出、轉換並重新載入，並採用觸發器對源系統進行變化跟蹤並增量地更新目標系統，所以最終的系統同步在30分鐘內得以完成。
編注：1TB = 1024GB
多個資料庫意味著有多個資料庫連線。尤其是當我們新增更多”社交發現“功能的時候，比如”Meet Me”－－我們第一個約會功能，由於缺乏Oracle的連線池支援，在進行資料分片時PHP完全不能勝任。為了應對這種情況，我們編寫一個Java程式提 供資料查詢的web service服務，同時該程式還可以非常方便地進行資料監控並能很好地處理資料庫異常。
5. 優化及擴充套件， 8千萬使用者，1000臺伺服器，2010年
這裡我們略過幾年。隨著資料庫擴充套件這一關鍵問題的解決，我們可以直接通過新增硬體來解決擴充套件的問題。在快速地功能開發過程中PHP和記憶體快取機制依舊發揮 著重要作用。這段時間裡隨著系統脆弱部分的不斷增加，我們關注的重點從對擴充套件性的考慮轉移到儘量減少系統錯誤。為保護web層我們採取了負載均衡檢查和自 動關閉不響應服務來減少錯誤。與此同時，我們也對核心元件進行適應性擴充套件，例如，如果記憶體快取因為連線過多而超載，它必須能夠在負載解除的時候馬上恢復。
隨著接受程度的增加並且語言本身越來越成熟，也因為我們面對的越來越多的挑戰，Java扮演的角色變得越來越重要。為了對付垃圾郵件和其他惡意訪問，我們 的演算法利用了大量的共享記憶體空間以及計算密集型技術。社交遊戲同時也受益於Java的效能以及併發控制機制，但這是以複雜性作為代價，現在我們需要管理比 以前更多不同的應用程式緩衝池。
未來的發展
時至今日，Tagged每個月為它的百萬使用者提供50億頁面瀏覽量PV。我們的設計可以方便地進行擴充套件，因此可以把更多的精力投入到開新功能以便更好地為使用者提供服務。現有的工具可以高效地開發具有可擴充套件性的軟體，但是我們希望可以做得更好，因此現在我們把投資的重點轉移到軟體庫的開發、程式設計師的效率和生產率的提高，以及即將釋出的針對大型社交網路、實時服務以及雲應用設計的開源圖形資料庫專案Stig。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
