# 维基媒体架构 > 原文： [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>