# 維基媒體架構 > 原文： [http://highscalability.com/blog/2007/8/22/wikimedia-architecture.html](http://highscalability.com/blog/2007/8/22/wikimedia-architecture.html) Wikimedia 是建立 Wikipedia，Wiktionary 和其他七個 Wiki 矮人的平臺。 對于試圖擴大巨型網站高度的學生而言，該文檔非常有用。 它充滿了詳細信息和創新思想，這些思想和創新思想已在互聯網上一些最常用的網站上得到證明。 網站：http：//wikimedia.org/ ## 信息來源 * [Wikimedia 架構](http://www.nedworks.org/~mark/presentations/san/Wikimedia%20architecture.pdf)* http://meta.wikimedia.org/wiki/Wikimedia_servers* 從 Oracle 到 MySQL 博客中*中的[橫向擴展與縱向擴展](http://oracle2mysql.wordpress.com/2007/08/22/12/)。 ## 平臺* * 阿帕奇* 的 Linux* 的 MySQL* 的 PHP* 烏賊* LVS* Lucene 搜索* Memcached 用于分布式對象緩存* Lighttpd Image Server ## 統計資料 * 800 萬篇文章遍布數百個語言項目（英語，荷蘭語，...）* 世界排名第十繁忙的網站（來源：Alexa）* 指數級增長：每 4-6 個月訪問者/流量/服務器增加一倍* 高峰時間 30000 個 HTTP 請求/秒* 3 Gbit / s 的數據流量* 3 個數據中心：坦帕，阿姆斯特丹，首爾* 350 臺服務器，范圍在 1x P4 至 2x Xeon 四核之間，內存為 0.5-16 GB* 由?6 人管理* 3 個大洲的 3 個群集 ## 架構 * 地理負載平衡基于客戶端解析器的源 IP，將客戶端定向到最近的服務器群集。 將 IP 地址靜態映射到國家/地區到群集* 使用 Squid 實現的 HTTP 反向代理緩存，按文本分組表示 Wiki 內容，對媒體分組表示圖像和大型靜態文件。* 當前有 55 個 Squid 服務器，外加 20 個等待設置。* 每個服務器 1,000 個 HTTP 請求/秒，在壓力下最多 2500 個* 每個服務器?100-250 Mbit / s* 每個服務器?14000-32000 個開放連接* 每個 Squid 服務器最多 40 GB 的磁盤緩存* 每臺服務器最多 4 個磁盤（1U 機架服務器）* 8 GB 的內存，Squid 使用的內存的一半* 自使用 CARP 以來，命中率：文本為 85％，媒體為 98％。* PowerDNS 提供地理分布。* 他們在其主要和區域數據中心中構建基于 LVS，CARP Squid，Cache Squid 構建的文本和媒體集群。 在主數據中心中，它們具有媒體存儲。* 為了確保提供所有頁面的最新版本，將無效請求發送到所有 Squid 緩存。* 一個集中管理的&同步了數百個 Wiki 的軟件安裝。* MediaWiki 可在多個 CPU 上很好地擴展，因此我們現在購買雙四核服務器（每個盒 8 個 CPU 內核）* 與外部存儲和 Memcached 任務共享的硬件* Memcached 用于緩存圖像元數據，解析器數據，差異，用戶和會話以及修訂文本。 元數據（例如文章修訂歷史記錄，文章關系（鏈接，類別等），用戶帳戶和設置）存儲在核心數據庫中* 實際修訂文本以 blob 形式存儲在外部存儲中* 靜態（上載）文件（例如圖像）分別存儲在圖像服務器上-元數據（大小，類型等）存儲在核心數據庫和對象緩存中* 每個 Wiki 都有獨立的數據庫（不是獨立的服務器！）* 一個主機，許多復制的從機* 讀取操作在從屬服務器上實現負載平衡，寫入操作轉到主服務器* 如果從站尚未更新（滯后），則將主站用于某些讀取操作* 外部存儲 -文章文本存儲在單獨的數據存儲群集中，即簡單的僅附加 blob 存儲。 為大量未使用的數據節省昂貴和繁忙的核心數據庫上的空間 -允許在應用程序服務器上使用備用資源（每個服務器 2x 250-500 GB） -當前使用了 3 個 MySQL 主機的復制集群； 為了更好的可管理性，將來可能會改變 ## 得到教訓 * 專注于體系結構，而不是操作或非技術性內容。 * 有時，緩存比重新計算或查找 數據源要花更多的錢……剖析！ * 避免使用昂貴的算法，數據庫查詢等。 * 緩存所有昂貴且具有時間參考性的結果。 * 關注代碼中的熱點（概要分析！）。 * 通過分開進行縮放： -讀寫操作（主/從） -廉價操作和更頻繁操作（查詢組）中的昂貴操作 -小型 Wiki 中的大型，流行 Wiki * 改善緩存：參考的時間和空間局部性，并減少每個服務器的數據集大小 * 文本被壓縮，并且僅存儲文章之間的修訂。 * 簡單的看似庫調用（例如使用 stat 來檢查文件的存在）在加載時可能會花費很長時間。 * 磁盤搜尋 I / O 受限，磁盤心軸越多越好！ * 使用商品硬件的橫向擴展不需要使用便宜的硬件。 如今，Wikipedia 的數據庫服務器是 16GB 的雙核或四核機箱，其中有 6 個 15,000 RPM SCSI 驅動器（采用 RAID 0 設置）。 這恰好是他們擁有的工作集和負載平衡設置的最佳選擇。 如果可以的話，他們會使用更小/更便宜的系統，但是 16GB 的空間適合工作集大小，這將驅動其余的規范以匹配具有那么多 RAM 的系統的需求。 類似地，Web 服務器目前是 8 個核心設備，因為它恰好可以很好地用于負載平衡，并通過相對容易的負載平衡提供了良好的 PHP 吞吐量。 * 擴大規模是一項艱巨的工作，如果您不是最初設計的，則需要做更多工作。 Wikipedia 的 MediaWiki 最初是為單個主數據庫服務器編寫的。 然后添加了從屬支持。 然后添加了按語言/項目劃分。 那時的設計經受住了考驗，盡管需要進行更多的改進以解決新的瓶頸。 * 任何想要設計數據庫體系結構，以便允許它們廉價地從一臺機器升級到網絡上排名前十或百位的站點的人，都應該從設計它來處理復制從屬設備的過時數據開始， 知道如何為所有讀取查詢負載均衡給從屬服務器，并盡可能設計它以便數據塊（用戶批次，帳戶等等）可以放在不同的服務器上。 從第一天開始，您就可以使用虛擬化來完成此工作，并在小巧的時候證明其架構。 當負載每幾個月增加一倍時，這比做起來容易得多！ 對于那些在有限的預算下處理大量可緩存內容（例如，能夠返回有效到期標頭的內容）的人來說，我的建議是采用反向代理，如本文所述。 在上周，我們有一個站點獲得了 AP，在不到 5 小時的時間內觸發了 10 萬唯一身份訪問者訪問單個 IIS 服務器。 它取出了 IIS 服務器。 在適中的 Intel IV 3Ghz 上，將服務器的單個魷魚放置在服務器的前端即可處理整個攻擊，最大服務器負載為 0.10。 對于任何有興趣的人來說，實現它都是微不足道的。 [http://wiki.squid-cache.org/SquidFaq/ReverseProxy](http://wiki.squid-cache.org/SquidFaq/ReverseProxy) 有很多服務器。 似乎他們比添加慢速的 php 腳本更好地添加新服務器 向我展示服務器數量較少的前十名網站。 只有一個。 如果您發現任何東西，我會感到驚訝。 我一直對 Wikimedia 架構感到驚訝，他們做得很好。 這是一個很好的理由，為什么您不想要選擇 squid 作為反向代理。 [http://varnish.projects.linpro.no/wiki/ArchitectNotes](http://varnish.projects.linpro.no/wiki/ArchitectNotes) 問候， 斯瑞吉斯 Sreejith： 我不確定在使用持續充滿（意味著驅逐不斷發生）緩存時，是否證明清漆與魷魚一樣穩定或快速。 直到最近，清漆才有了驅逐機制。 如果您知道這種用法，請分享。 :) 嗨，有人知道如何擴展 Lucene 嗎？ 他們是否使用在多個盒子之間共享數據的任何文件系統？ 我認為在這種情況下，成功的重點是地理分布，而不僅僅是緩存或其他。 Show me a top-10 website with less servers. Just one. I'd be amazed if you'd find any. @以上職位。 我認為這是不可能的。如果沒有至少 3 臺服務器，它總是必須經過。 ----- [http://underwaterseaplants.awardspace.com“](<a rel=) >海洋植物 [http://underwaterseaplants.awardspace.com/seagrapes。 htm“](<a rel=) >海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](<a rel=) >海藻 不可能 更新： * [http://www.networkworld.com/news/2009/011309-wikipedia-digital-media.html“](<a rel=) > Wikipedia 為數字媒體的爆炸式發展做好了準備 * [http://blogs.sun.com/WebScale/entry/scaling_wikipedia_with_lamp_7“](<a rel=) >使用 LAMP 擴展 WikiPedia：每月 70 億頁面瀏覽量 * [http://blogs.sun.com/jonathan/entry/open_storage_wins_at_wikipedia“](<a rel=) >開放存儲在 Wikipedia 上獲勝 <cite>視頻文件的大小正迅速達到數十兆和數百兆字節，而高百萬像素相機的普及意味著，即使是小照片也可能占用幾兆字節。 Vibber 說，直到 2008 年初，用戶生成的百科全書庫的主要媒體文件服務器只有 2TB 的總空間。</cite> <cite>“很長一段時間以來，我們只是沒有[處理非常大的媒體文件]的能力，”他說。</cite> <cite>此后，維基百科已將其主要的中間文件服務器的存儲容量從 2TB 擴展到 24TB，現在增加到 48TB，并且最近將文件上傳限制從 20MB 提高到了 100MB。 Vibber 說，實際使用的存儲量大約為 5TB，但是它將迅速增長。</cite>