作者文章: Fenng

WikiPedia 技术架构学习分享

维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。

来点直接的数据：

峰值每秒钟3万个 HTTP 请求
每秒钟 3Gbit 流量, 近乎375MB
350 台 PC 服务器

架构示意图如下：
Copy @Mark Bergsma

GeoDNS

在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? “A 40-line patch for BIND to add geographical filters support to the existent views in BIND”, 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的–面向各个国家，各个地域。

负载均衡：LVS

WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.

图片服务器:Lighttpd

Lighttpd 现在成了准标准图片服务器配置了。不多说。

Wiki 软件: MediaWiki

对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。

Cache! Cache! Cache!

维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。

数据库: MySQL

MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。复制、读写分离……应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。

运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。

参考文档：

Wikimedia architecture （PDF)
Todd Hoff 的文章

–EOF–

说说北京奥运购票系统瘫痪这事儿

奥运购票网站据说刚上线就瘫痪了，听说而已，没有亲见。奥运会这种”钱多人傻”的项目，自是财大气粗，听说购票系统所用的存储都是花费人民币千万级别的，即使花了大钱还是没办好事，遭到批评也是活该。

开始说是因为网络负载导致瘫痪，后来又辟谣说，“主要还是系统后台的数据库的处理能力，在设计、规划方面，还有待于改进”

那我们实际看一下具体数据。“票务系统已经做了多次压力测试，票务系统每小时将能处理3万张门票的销售(另外又说：三个售票渠道共同能够处理的售票能力是每小时15万张），以及承担每小时100万次以上的网上浏览量。”，这算下来，也就是每秒钟处理不到 9 个交易请求，平均每秒钟 278 个点击(这也难怪百度李彦宏唏嘘一把: 不要说800万次，就是每小时8000万次，对百度来说，也只是a piece of cake)，这真是一个非常业务指标非常低的系统了。整个系统启动后，系统一个小时涌进来 20 万订单，其实平均每秒钟不过 56 个交易请求罢了。如果把问题推到数据库身上，还不如把问题推到开发人员数据库水平上。

抛开技术限制，门票的销售策略也让人觉得很傻，难道就不能一次只售一种项目的票麽? 先售那些比较冷门的项目分流一下访问压力，是很简单方便的真实压力测试。这只是奥运 IT 体系建设的第一次公共亮相，不由得让人担心其他方面的健壮性。

回头说李彦宏的自大。每小时 8000 万次，一天就是 19 亿的 PV，百度能有多少? 雅虎也不过是 40 亿PV而已。就别小菜一碟了，再说这只是 PV，如果加上事务量，那是更难搞的。

对比一下国内比较大的交易网站，中国彩票协会的数据：

营收35,000,000元/日(博彩业钱真好赚）, 目前系统每天交易笔数50,000,000笔,峰值处理4000笔/秒

这种压力估计还有的一搞。

–EOF–
Updated: 有人说其实是临时工的错，很有道理

不能参加本届网志年会, 遗憾

本届中文网志年会不能参加了。本来想让公司去做个赞助的，没有游说成功。阿里妈妈和中国雅虎应该会有不少人过去。有些遗憾错过这个几乎是全国最大的 Geek 集会。去年的年会我是全程参加的，认识了不少朋友，感觉很有收获。

这个时候北京挺冷，我怕冷，这是第一个理由；第二，很累，路上再一折腾，估计要散架；第三，没钱，路费比较贵，还是留点钱吃猪肉吧；第四，年会议题大多是空话废话，弄几个技术主题不行么?

去年的会议有个小插曲，会场在最后时刻才定下来。希望今年顺利！08 年年会见！

–EOF–

【有趣】10 种迹象表明 DBA 该退休了

看到一篇十分有趣的关于 DBA 的帖子。10 种迹象表明你的 DBA 该退休了. 作者是 Chris Muir. 这 10 条越看越好玩，翻译并注释一下。

1. Complains about these “new fangled stored procedures”.
对”存储过程这新玩意儿”抱怨不停。 (暗示这个人还停留在 Oracle 古老版本的使用经验中。)

2. Rants about the good old days of Oracle PE (Punchcard Edition).
嚷嚷着 Oracle 卡片机版本(暗指非常古老的版本)美好时光.

3. Thinks Thomas Kyte is a whipper-snapper (even with the beard).
认为 Thomas Kyte 是个傲慢自大的年轻人(即使他有胡子). Kyte 现在已经是几个孩子的父亲了。而且，近年来 Kyte 在 Oracle 领域已经成为无可争议的大师级别的人物。 (暗示有这样想法的人可能 N 年前见过 Thomas Kyte, 近年来没关心 Oracle 社区的发展)

4. Still demands all Oracle manuals in hardcopy.
仍旧靠着所有打印的 Oracle 手册过日子. (现在的手册足有几万页, 说明还是用的老手册, 而且守旧)

5. Has a service request with Oracle Support to forward port the RBO to 11g.
对 Oracle 支持人员提出一个把 RBO 移植到 10g 的服务请求。(RBO–基于规则的优化器, 局限性非常大，已经不适合现现在复杂的数据环境了，如果还死抱着RBO大腿不放…)

6. Knows about Edgar’s secret 13th rule.
知道 Edgar 的第十三条规则的秘密。(Edgar Codd，就是大名鼎鼎的关系数据库理论之父，他提出的基本准则只有 12 条。如果有 DBA 知道第十三条规则的秘密…)

7. Thinks Oracle Support went downhill when they moved the HQ to Redwood Shores in 1989.

认为 Oracle 支持自从1989年总部搬到 Redwood Shores 后每况愈下。(看看 Oracle 各个版本的 Bug 众多，以及 Oracle 服务费的昂贵，从哪个角度来看，Oracle 支持都是不差的，当然服务质量除外)

8. Has [email protected] in his address book.
邮件地址簿里有 [email protected] 。(RSI 是Oracle公司前身，[email protected] 是 Oracle CEO 拉里－艾里森的邮件地址。还有这个邮件地址，估计至少有 20 年没更新过地址簿了。这个人有些”火星”)

9. Still replaces blank lines in PL/SQL with single line comments.
仍旧在 PL/SQL 用单行注释替换空行.(这个需要解释一下，用手册上的话就不用绕了: You cannot use single-line comments in a PL/SQL block that will be processed by an Oracle Precompiler program because end-of-line characters are ignored. As a result, single-line comments extend to the end of the block, not just to the end of a line. In this case, use the /* */ notation instead)

10. Has an open 10 year old Oracle Support “TAR” to fix a bug in version 7 which he/she wont close because of the “principal of the thing.”
在 Oracle 支持上开了一个长达10年之久的 “TAR”，要修复某个 Oracle 7 的Bug，并且坚持认为此乃”首要之事”而不肯关闭该 Tar。(刻舟求剑)

等有时间再写写那些该下课的 IT 经理人
–EOF–