# 標記式架構-擴展到 1 億用戶，1000 臺服務器和 50 億個頁面視圖 > 原文： [http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html](http://highscalability.com/blog/2011/8/8/tagged-architecture-scaling-to-100-million-users-1000-server.html)  *這是 [Johann Schleier-Smith](http://www.crunchbase.com/person/johann-schleier-smith) 和 CTO &聯合創始人 Tagged 的嘉賓帖子。* ## 關于 Tagged 如何擴展到 1,000 臺服務器的五個快照 自 2004 年以來，[標記為](http://www.tagged.com/)已從微小的社交實驗發展成為最大的社交網絡之一，每月向訪問與新朋友見面和社交的數百萬成員提供 50 億頁。 一次一步，這一演變迫使我們發展自己的體系結構，最終形成了功能強大的平臺 [](http://www.stigdb.org) 。 ## V1：PHP Webapp，100k 用戶，15 臺服務器，2004 年  Tagged 誕生于一個孵化器的快速原型文化中，該孵化器通常每年都會推出兩個新概念來尋找大贏家。 LAMP 是這種工作方式的自然選擇，當 Java 開發主要面向大型企業的開發，Python 吸引了很少的程序員并且 Perl 帶來了錯誤的排序時，LAMP 強調了靈活性和快速的周轉時間。 另外，我們知道 Yahoo 是 PHP 的大力支持者，因此有可能在需要時擴展業務。 在以前的項目中運行 MySQL 的豐富經驗使我對這項技術產生了深惡痛絕的關系。 本著實驗的精神，我們為 Tagged 購買了一些入門級 Oracle 許可證，以了解這樣做是否更好。 值得注意的是，仍然建立了許多較小的網站，就像原始的“已標記”一樣。 簡單有其美，無狀態 PHP 和有狀態 Oracle 之間的雙向劃分將最棘手的部分集中在單個服務器中，同時易于添加額外的頁面呈現計算能力。 ## V2：緩存的 PHP **w** **ebapp，1 百萬用戶，20 臺服務器，2005**  即使在 8 臺服務器上，Tagged 的 Web 流量也比我們大多數人所知道的要多。 幸運的是，memcached 具有雙重優勢，可以刪除 90％以上的數據庫讀取，并確保包含各種信息的社交網站頁面可以快速呈現。 從一開始，我們的對象緩存就著重于顯式緩存更新，而采用了更簡單的技術，例如刪除無效密鑰或基于計時器使過期數據過期。 以更復雜的代碼為代價，這大大減少了數據庫負載并保持了站點的快速運行，尤其是在涉及到頻繁更新的對象時。 除了標準的社交網絡功能（朋友，個人資料，消息）外，我們的網站還不斷增加復雜性，并增加了搜索和社交發現功能。 我的團隊說服我使用 Java 來構建搜索，以便我們可以從 Lucene 庫中受益。 當我們學會很好地運行它時，我感到寬慰，而我對 JDK 1.0 的早期經驗所產生的不情愿也轉化為對該平臺的熱情。 ## V3：數據庫可擴展，1000 萬用戶，100 臺服務器，2006 年  隨時都有 1000 萬注冊用戶和數千在線用戶，我們迎接了我一直在恐懼的挑戰。 我們剛剛籌集了資金，并且正在為增長而努力，但是數據庫的容量正在爆炸。 我們爭先恐后地發布了一個緩存或 SQL 調優優化，但是我們服務器的 CPU 會一次又一次地趨向 100％。 擴大規模的想法提供了一個快速解決方案，但是多路服務器硬件可能要花費數百萬美元，因此我們選擇了 Oracle RAC，這使我們可以使用標準網絡連接許多商用 Linux 主機來構建一個大數據庫。 結合最新 CPU 的優勢，Oracle RAC 的容量比我們的第一臺數據庫服務器增加了 20 倍，這是至關重要的，并使應用程序開發人員可以專注于構建新功能。 當 Tagged 開始通過將來自大型內存數據集的統計數據縫合在一起來提供個性化的人員匹配建議時，Java 進一步進入了環境，這與 PHP 完全不切實際。 ## V4：數據庫分片，5000 萬用戶，500 臺服務器，2007 年  毫無疑問，對數據庫進行分片是擴展 Tagged 中最具挑戰性，也是最有意義的一集。 通過將用戶分散在多個數據庫中，我們最終獲得了一種設計，該設計可以在所有地方僅通過添加硬件即可進行擴展。 我們在 Tagged 的規則是將每個表劃分為 64 個分區，并且除非有非常有說服力的例外理由，否則我們堅持默認設置。 僅將受益于玩家之間高性能保護交易的某些游戲垂直劃分在單獨的數據庫中。 對現有數據進行分片表示跨數 TB 的復雜轉換。 最初，我們一次依靠應用程序代碼來替換功能來攻擊功能，以替換聯接，但最終我們在應用程序的核心遇到了一系列表，這些表對于這種方法過于緊密地聯系在一起。 編寫遷移軟件以生成 SQL，我們使用觸發器跟蹤源系統上的更改并逐步更新目標，從而導出，轉換和重新加載了億萬行，以便最終的同步少于 30 分鐘。 具有許多數據庫意味著具有許多數據庫連接。 尤其是當我們添加了更多的“社交發現”功能（例如我們的第一個約會功能“遇見我”）時，分片將淹沒 PHP，后者缺少 Oracle 連接池。 為了解決這個問題，我們構建了一個 Java 應用程序，該應用程序公開了一個用于運行查詢的 Web 服務，該應用程序還將繼續提供非常方便的監視點并允許正常處理數據庫故障。 ## V5：完善和擴展功能，8000 萬用戶，1,000 臺服務器，2010 年  我們在這里前進了幾年。 解決了關鍵數據庫可伸縮性問題后，我們發現通過添加硬件來支持擴展很簡單。 PHP 和 memcached 繼續為我們服務，并支持快速的功能開發。 在這段時間里，可伸縮性的考慮轉向了減少故障，從而解決了越來越多的易碎部件的威脅。 通過負載平衡器運行狀況檢查和無響應服務的自動關閉，可以保護 Web 層免于依賴項的問題。 我們還設計了核心組件以提高彈性，例如，如果 memcached 的連接過載，則必須在減輕負擔后立即恢復。 Java 發揮了更加重要的作用，部分原因是接受度和專業知識的提高，但挑戰也日益增加。 為了與垃圾郵件和其他濫用作斗爭，我們的算法利用了大容量共享內存空間以及計算密集型技術。 社交游戲也得益于 Java 的性能和并發控制，但是代價是復雜性高。 我們現在需要比以前管理更多不同的應用程序池。 ## 未來 如今，Tagged 每月向其數百萬成員提供 50 億頁面瀏覽量。 由于我們已經實現了可擴展的設計，因此我們可以將大部分精力花在創建更好地為用戶服務的功能上。 我們擁有創建可擴展軟件的有效工具，但是可以想象會有更好的工具，因此當前的投資重點是軟件庫，以提高程序員的效率和生產率，而我們即將開發的開源，基于圖形的數據庫項目 [Stig](http://www.stigdb.org) 適用于大型社交網絡，實時服務和云應用程序。 ## 相關文章 * [Johann Schleier-Smith 對 theCube 的采訪](http://siliconangle.tv/video/johann-schleier-smith-cto-cofounder-tagged) PHP 和 Oracle 數據庫用戶（如 Tagged）的經驗導致 Oracle Database 11g 的“數據庫常駐連接池”功能。 PHP 現在具有可與 Oracle 數據庫一起使用的本機連接池，從而使其具有高度可伸縮性，而無需早期先驅者必須實施的中間解決方案。 關于 PHP 和 Oracle DRCP 的白皮書為： [PHP 可伸縮性和高可用性：數據庫常駐連接池和快速應用程序通知](http://www.oracle.com/technetwork/topics/php/whatsnew/php-scalability-ha-twp-128842.pdf)。 享受了這種架構的失敗，對非 OSS 堆棧可伸縮系統進行了有趣的研究。 以我的經驗，如果您使用 Oracle 的任何東西來嘗試“省錢”，您可能犯了一些更深層次的錯誤。 其中很大一部分可能是出于非操作性原因而不選擇 MySQL。 從長遠來看，Oracle 的主要問題是對其平臺的大量鎖定。 您將無法輕松地從 Oracle 遷移過來，尤其是當您使用 Java 存儲過程之類的更獨特（且公平，有用的）功能時。 加上他們對自己的企業級 Linux 的熱愛，當您吸引 2 億或 3 億用戶時，確實會使您的財務困難。 另一方面，如果它能正確完成工作，并且您的長期擴展和性能不受影響，那么如果您擁有知道如何使用它的人，那么任何工具都將是不錯的選擇。 這很有趣。 節目的王者是 Java，而那個家伙堅持在每張圖中都貼上“ PHP”。 那就是您的“架構”。 您可能會認為 Oracle 現在已經為您完成了擴展。 考慮到吹牛他們可以在兩個 Exadata 系統上運行 Facebook，那么為什么對于帶標簽的它開箱即用呢？ 還是僅當您立即購買 Exa 東西時才起作用，還是根本不起作用？ 有任何信息/見解嗎？ PHP 在 Apache 前叉模式下運行，即作為獨立進程運行，這在高度可擴展的世界中是相對異常的。 該過程模型意味著 Oracle 的傳統基于線程的中間層池解決方案不適用于 PHP。 在 Oracle DB 11g 中引入 Oracle DRCP 連接池之前，被標記為先驅者并實現了其池解決方法，有關鏈接，請參見我先前的評論。 DRCP 之所以有效，是因為連接池是在數據庫服務器上處理的，因此可以在中間層進程和應用程序服務器之間共享該池。 白皮書顯示了一個基準，該基準具有由商品服務器上的數據庫處理的數以萬計的 PHP 連接。 JDK 1.0，太慢了。 但是 JDK 1.6 更好。 并且您不應該在 1.0 版中想象...看一下 JDK 5 或 6。