分类： 系统运维
2008-12-06 16:23:28
Wikimedia作为一个平台，用于构建Wikipedia、Wiktionary和其它的七种wiki(维基)。这篇文章对于那些想将大型站点的伸缩性提升到一定高度的研究者来说，是非常好的。文章详细介绍了许多的细节和创新的想法，并且这些想法都已经能够在一些非常成熟的网站上得到过证明。
参考资料
Wikimedia体系结构
关于wikimedia服务器的文章
平台
Apache
Linux
MySQL
PHP
Squid
LVS
Lucene搜索
分布式对象高速缓存Memcached
Lighttpd图像服务器
统计信息
8 百万文章，覆盖了超过100中语言
世界前10最繁忙的站点
指数增长：访问者/流量/服务器数量在每4-6个月翻倍
高峰期30000HTTP请求量
3 Gbit/s 数据流量
3个数据中心：坦帕[美国佛罗里达州西部港市]、阿姆斯特丹、汉城
350个服务器，从1x P4到2x Xeon Quad-Core排列，0.5 - 16 GB内存
大约6个人员管理
3个不同的州设有3个群集器
体系结构
地理负载平衡，基于用户源IP分析器，将用户的请求集中在最近的服务器群。静态映射IP地址到该国家的服务器群集上。
依据wiki正文，图像媒体，大型静态文件，使用Squid ，来实施HTTP反向代理
目前使用了55 Squid服务器，另外20个等待安装。
每个服务器1000HTTP请求，应力测试环境下达到2500
每个服务器大约100 - 250 Mbit/s
每个服务器大约~ 14 000 - 32 000连接
每个Squid服务器磁盘高速缓存达到40 GB
每个服务器达到4个磁盘
8GB的内存，一半被Squid用掉
命中率：使用CARP以来，Text 85%，Media 98%
PowerDNS提供地域分配功能
在他们主要的区域数据中心，建立了text和media群集，构建于LVS、CARP Squid、 Cache Squid之上。在主要的数据中心，他们还有media存储器。
为上百个wiki安装了一个管理&同步的软件 ;
使用 多CPU进行MediaWiki 伸缩性扩展效果不错，因此我们买了双4核服务器(每盒8个CPU芯);
硬件被分派用来进行外部存储和Memcached任务;
Memcached用来高速缓存图像元数据，分析数据，差别，用户和sessions、修正文本等。元数据，如文章修改历史，文章间的关系(链接，分类等)，用户帐户，设置等都存储在核心数据库中。
实际的修改文本作为blob存储在外存储器上。
静态(上传)文件，比如图像，单独存在图像服务器上。元数据(大小，类型等)高速缓存在核心数据库和对象caches上。
每个wiki站点使用单独数据库(而非单独的服务器);一个主数据库，多个从属数据库 ;
读操作在从属的上面应该负载均衡，写操作应该让主数据库进行。
使用主数据库来进行一些读操作，以备从数据库没有更新(延迟)。
外存储器
文章文本存储在单独的数据存储器上，仅仅简单追加blob存储器。处理主要没有的数据，给昂贵和繁忙的核心数据库节约空间
应用程序服务器上允许使用备用资源(每个服务器2x 250-500 GB )
使用3个MySQL主机 ，在将来会得到更好的易管理性。
可借鉴的经验
集中于体系结构，不要过于专注操作或者非技术性的东西;
有些时候，比起重计算或者是查找数据源，比高速缓冲器的成本还要高;
避免消耗大的算法，数据查询等;
高速缓存结果消耗很大的结果，有一个时间访问局部性;
注意代码中的过热点;
各自进行伸缩性扩展;
读写操作(主/从)
提升高速缓存的技术：时间和空间访问局部性，减少每个服务器的数据集大小
文本进行压缩，只有文章修订版进行存储
简化程序调用，像使用stat来检查一个需要加载很久的文件是否存在
限制磁盘I/O查找，磁盘主轴越多越好
Wikipedia的数据库服务器目前是16GB的双数或者四芯盒，有6 15,000 RPM SCSI驱动。这是一个最好的工作设置和负载均衡设置。他们使用更小的，更廉价的系统，16GB对于工作组的大小还不错。类似的现在的web服务器目前是8芯盒，因为对于负载平衡的效果不错，对于PHP来说，有很好的吞吐量。
如果你开始没有设计好，有许多的伸缩性工作需要做。Wikipedia的MediaWiki 最初是为单个主数据库服务器写的。后来增加了从服务器。接着加入了语言/项目的划分。那个时候的设计试验合格，虽然需要做许多提炼工作来解决瓶颈问题。
任何想要设计他们的数据库体系结构，那么就要能够让他们花费很低的成本，从一个站点很容易扩展到前十，或者上百的站点。这就需要一开始设计处理从数据库中的过时数据，对于所有的读操作查询知道如何进行负荷均衡，尽量让数据块(成批用户，帐户等等)访问不同的服务器。
