很多人问我雅虎有没有可能在搜索领域赶上谷歌，我明确地回答–没有，因为雅虎不可能专注在这个领域。有时，一个好的公司不能完全按华尔街的意愿办事
–Google 吴军
支持方言编程!
–在 Twitter 上有人讨论到”汉语编程”这个笑话一般的话题. Yining 干脆来个荒谬到底.
大唐今天倒闭，我们明天就能用上3G
–网友 xlight 针对明白了大唐 3G 为啥不行的留言.
辞职完全属于员工自愿，没有公司强迫行为。绝大部分员工会通过竞岗回到原来的岗位
–华为回应媒体报道的”华为让万人辞职、重新签订合同”事件
抄一段独白：
该死的
整整一代人都在当加油工、招待员或者白领奴隶
广告诱惑我们追逐汽车和时尚
于是我们拼命工作
买那些没用的狗屎
我们是被历史遗忘的一代
没有目的、没有地位
没有世界大战、也没有经济大萧条
我们的战争就是心灵的战争
我们的生活就是经济大萧条
我们看着电视
相信有一天我们会成为百万富翁、影帝或是摇滚明星
但是
我们不会
这就是我们渐渐面对的现实
所以
我们真他妈的被激怒了
Twitter 是我最近一段时间用的最多的网络服务之一.还记得刚开始有段时间发消息速度那叫一个慢. 难得的是 Twitter 的开发者在用户激增的情况下性能提升的不错, 据说,相比当初有 100 倍的性能提升, 那我们就来看看他们都做了什么.(发现我这个 Blog 快成了 High Scalability 的中文镜像站了.)
是否真的是 100 倍性能提升, 大可不必较真, 但 Twitter 的一些经验是足以借鉴的.
似乎 Twitter 是用 RoR 开发的流量最大的站点(有待于求证). 开始使用DRb (“Distributed Ruby”.), 该库可以通过 TCP/IP 从远程 Ruby 对象发送接收消息, 其缺点是不那么好用,并且没有冗余, 于是转向 Rinda , Rinda 基于 DRb 开发, 使用简单. Twitter 也证明了 Ror 应用同样可以支撑比较繁忙的站点, 工具没有对于错,关键是否能运用好.
图片来源. (这里面我非常疑惑的一点是据说只有两台DB(Master/Slave),可要支撑这么大的并发更新似乎有些难度.)
Twitter 对于Etag 的态度让不少人疑惑. 这恰恰是因技术制宜的一个体现, 因为 Etag 不是万能药. 另外一点比较重要的原因是 Twitter 有超过 90% 的流量来自 API, 而 多数 API 客户端不支持 Etag.
尽可能的索引(Fenng补充:不要过度索引). 因为 RoR 应用的特殊性, 索引是在代码中向 DB 提交的. 另外一个值得议题的是, 反范式. 严格遵守范式是要吃苦头的.建立可行的测试方法,明确的知道你的SQL都在用什么方式运行.(另外,我有个疑问是 rails 不支持 2 阶段提交的吧?)
哪个站点都不避免的有“水葫芦用户”,对于这样的 Spam 类型用户, 肯定会影响原有的应用处理资源. 该处理就要处理掉. 另一个方面,对于间歇性占用系统资源过多的进程用 Monit 处理.
另外一个很重要的环节是 Cache, 不废话了,没有好的Cache机制怕这样的站点不会成功的. (建议阅读车东辛苦翻译的这篇面向站长和网站管理员的Web缓存加速指南[翻译]). Twitter 运营的一个可取之处是能够积极听取社区的意见并改进, 同时社区上也有很多用户给他们提供了不少技术支持. 这也是开放而带来的好处吧.
–EOF–
维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。
来点直接的数据：
(数据来源)
架构示意图如下：
Copy @Mark Bergsma
在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? “A 40-line patch for BIND to add geographical filters support to the existent views in BIND”, 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的–面向各个国家，各个地域。
WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.
Lighttpd 现在成了准标准图片服务器配置了。不多说。
对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。
维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。
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: 有人说其实是临时工的错，很有道理
