今天

昨天已经约好了今天集团几个 DBA 到上海与盛大的同行进行技术交流。今天还算起的早，到创业大厦楼下等同事。大门口已经热闹非凡，红彤彤一片。很多同事在那里摆 Pose “敲上市钟”，还有很多排队买纪念品(接下来还有抽奖活动，没我的份儿了)。差 5 分钟 9:30 ，我们出发了 — 没看到宣布上市那一刹那的沸腾场面。

一下午都在盛大参加讨论，盛大作为游戏厂商的领头羊，运维技术自有独到之处，讨论气氛也比较热烈，当然这一天下来也比较累。在盛大的园区用手机拍了几张照片(出大门的时候看到陈天桥领着一群人进来参观)。晚上住的地方……别说了，堪称今年出差最差的一次。一个有趣的插曲是，吃完晚饭出来，我们几个看到路边有卖DVD的，Biti 买了一张《色戒》，小贩告诉他是香港影院录下来的枪版…..路上 Biti 说”如不是，肯定打车回去找那个小贩”。结果，经过仔细检验，结论是100%的国内影院录的枪版。

晚上回来，看看新闻，市场反应出乎大多数人的预料。好多人对财富榜开始津津乐道，好多旧故事、旧的细节又被翻了出来，有些我都快能背下来了。这一天就过去了。

嗯，2007 年 11 月 6 日，阿里巴巴 B2B 业务香港成功上市!

–EOF–

世说新语: 汉语编程

很多人问我雅虎有没有可能在搜索领域赶上谷歌，我明确地回答–没有，因为雅虎不可能专注在这个领域。有时，一个好的公司不能完全按华尔街的意愿办事
–Google 吴军

支持方言编程!
–在 Twitter 上有人讨论到”汉语编程”这个笑话一般的话题. Yining 干脆来个荒谬到底.

大唐今天倒闭，我们明天就能用上3G
–网友 xlight 针对明白了大唐 3G 为啥不行的留言.

辞职完全属于员工自愿，没有公司强迫行为。绝大部分员工会通过竞岗回到原来的岗位
–华为回应媒体报道的”华为让万人辞职、重新签订合同”事件

抄一段独白：

该死的
整整一代人都在当加油工、招待员或者白领奴隶
广告诱惑我们追逐汽车和时尚
于是我们拼命工作
买那些没用的狗屎
我们是被历史遗忘的一代
没有目的、没有地位
没有世界大战、也没有经济大萧条
我们的战争就是心灵的战争
我们的生活就是经济大萧条
我们看着电视
相信有一天我们会成为百万富翁、影帝或是摇滚明星
但是
我们不会
这就是我们渐渐面对的现实
所以
我们真他妈的被激怒了

继续阅读 →

Twitter 的架构扩展: 100 倍性能提升

Twitter 是我最近一段时间用的最多的网络服务之一.还记得刚开始有段时间发消息速度那叫一个慢. 难得的是 Twitter 的开发者在用户激增的情况下性能提升的不错, 据说,相比当初有 100 倍的性能提升, 那我们就来看看他们都做了什么.(发现我这个 Blog 快成了 High Scalability 的中文镜像站了.)

是否真的是 100 倍性能提升, 大可不必较真, 但 Twitter 的一些经验是足以借鉴的.

Ruby on rails

似乎 Twitter 是用 RoR 开发的流量最大的站点(有待于求证). 开始使用DRb (“Distributed Ruby”.), 该库可以通过 TCP/IP 从远程 Ruby 对象发送接收消息, 其缺点是不那么好用,并且没有冗余, 于是转向 Rinda , Rinda 基于 DRb 开发, 使用简单. Twitter 也证明了 Ror 应用同样可以支撑比较繁忙的站点, 工具没有对于错,关键是否能运用好.

twitter_drb.png

图片来源. (这里面我非常疑惑的一点是据说只有两台DB(Master/Slave),可要支撑这么大的并发更新似乎有些难度.)

ETag

Twitter 对于Etag 的态度让不少人疑惑. 这恰恰是因技术制宜的一个体现, 因为 Etag 不是万能药. 另外一点比较重要的原因是 Twitter 有超过 90% 的流量来自 API, 而 多数 API 客户端不支持 Etag.

数据库方面的经验

尽可能的索引(Fenng补充:不要过度索引). 因为 RoR 应用的特殊性, 索引是在代码中向 DB 提交的. 另外一个值得议题的是, 反范式. 严格遵守范式是要吃苦头的.建立可行的测试方法,明确的知道你的SQL都在用什么方式运行.(另外,我有个疑问是 rails 不支持 2 阶段提交的吧?)

避免资源过度被占用

哪个站点都不避免的有“水葫芦用户”,对于这样的 Spam 类型用户, 肯定会影响原有的应用处理资源. 该处理就要处理掉. 另一个方面,对于间歇性占用系统资源过多的进程用 Monit 处理.

另外一个很重要的环节是 Cache, 不废话了,没有好的Cache机制怕这样的站点不会成功的. (建议阅读车东辛苦翻译的这篇面向站长和网站管理员的Web缓存加速指南[翻译]). Twitter 运营的一个可取之处是能够积极听取社区的意见并改进, 同时社区上也有很多用户给他们提供了不少技术支持. 这也是开放而带来的好处吧.

–EOF–

WikiPedia 技术架构学习分享

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

来点直接的数据：

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

    • (数据来源)

架构示意图如下：
WikiPedia_arch.png 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–