002
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com
杂志订阅 : http://os.51cto.com/art/201011/233915.htm
51CTO Linux 频道 ：http://os.51cto.com/linux/
目录
Index
002
目录
人物·People
003 天涯首席工程师王建科：技术人要有产品观
交流·Interact
005 网站扩展实例:1亿用户的Tagged架构进化史
八卦·News
007 Linux 20周年庆，2011最佳开源软件
专题·Special
009 strace命令使用实例
010 Unix调试的瑞士军刀：lsof
012 使用top命令的一些小技巧
013 网站排障分析常用的命令
014 MySQL生产环境突发故障处理手册
016 oracle审计导致的系统性能故障
017 数据库故障分析与排查
技巧·工具·脚本
021 Linux管理员常用网络资源收集
022 五款救急的Linux文件恢复软件
024 运维自动化之Cobbler系统安装详解
027 用SHELL脚本来防止SSH和vsftpd暴力破解
出版方 ：51CTO 系统频道（北京无忧创想信息技术有限公司）
本期责编 ：李晶 杂志主编 ：杨赛
联系方法 ：yangsai@51cto.com 010-68476606（分机 8035）
出版日期 ：2011 年 9 月 16 日
每月第 2 个星期五出版
订阅 ：http://os.51cto.com/art/201011/233915.htm
003
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com
杂志订阅 : http://os.51cto.com/art/201011/233915.htm
51CTO Linux 频道 ：http://os.51cto.com/linux/
人物
People
003
天涯首席工程师王建科：技术人要有产品观
国内的网民们大多听说过天涯社区，只是也许很
多人并不知道，这个有 12 年历史的、现在同时在线已
经超过 50 万人的巨大社区，在最开始几年的产品设
计、开发和运维，都是由一个人来完成的。他就是现
在天涯的首席工程师、天涯论坛产品总监王建科。本
次访谈内容大致分为天涯的技术发展历程、天涯界面
的设计、对技术债务的观点、对技术选型的观点、对技
术人员成长的建议、以及开源相关的一些话题。对于
互联网行业的开发、运维和产品运营人员而言，相信
王建科的分享会给你带来一些启发。
51CTO ：首先，简单的介绍一下天涯的技术发展历
程吧。
王建科 ：天涯最初只有一个开发者，就是我。产品
的设计和技术实现都是我。当时是用 ASP 来做，有
很多困难，因为那时 ASP 这个技术没有文档，全靠摸
索，不像现在，网上资料非常多。那是在 98 年底的时
候。
天涯最开始上线运营的话是 99 年 3 月 1 号。我
的 ID 是 2 月 28 号注册的，是天涯第一个 ID。回想当
时，其实对技术的要求并不很高，只要把这个东西实
现出来，快速的实现
出来。当时整个互联网的网民也
比较少，所以用户比较少，所以对整个性能的压力也
比较小。当然服务器硬件也比较差，大概是 586 这样
的吧。
51CTO ：当时服务器是托管在机房？
王建科 ：当时我们还没在机房，只有一条链路，好
像也就是几十 K 吧，马上感觉不够，就搬到电信的机
房去了。当时电信还没有 IDC 这个概念，也就是一张
桌子，有个网线，连上去就行了（笑）。当时门槛是比
较低的。
我们把天涯分为几个阶段，第一个就是 2003 年之
前，刚起步的一个阶段。网民比较少，当时网友还是
一个比较异类的人群，ID 千奇百怪的，谈的话题别人
都听不懂。所以那个时候，同时在线也就是 90 人左
右。2002 年同时在线是 1000 人，到 2003 年的时候，
同时在线就差不多快要 10000 人了。不过 2003 年那
时候还是只有一台服务器，又当 web 又当 db，内存只
有 512MB，这个压力可想而知。
当时天涯还有一个特点，就是帖子是不分页的。
一千回复也好，一万回复也好，一个页面都要全部加
载进来。长帖
对天涯的系统压力非常大。
2003 年之后到 2006 年之间，是天涯发展的一个
中期阶段。这个阶段天涯快速发展，从 2003 年的同
时在线 8000 人，到 2006 年达到 20 万。快速发展我
觉得有几个原因吧，第一个是大概在 2005 年左右，中
国互联网快速增长，网民大爆发，天涯用户也跟着往
上增长。还有一个就是当时天涯的媒体性凸显出来，
因为天涯当时很多网络事件和话题，很多媒体就把天
涯作为一个新闻源去报导，这样相当于传播天涯的品
牌。
这样就导致了天涯的快速增长，而天涯的服务器
这时候增长的也比较快……
51CTO ：不再是一台服务器了。
王建科 ：嗯，不再是一台了。2004 年的时候，已经
是 4 台 web，2 台 db 了。之前已经是扛不住了，负载
全都满了这么一个状况。后来我们就拆分嘛，把 db
拆分。天涯不是论坛分很多版块吗，所以就是把不同
版块拆分到不同的服务器上。如果是所有版块在一
个表里的话就很难拆分，所以我们就是一个版块对应
一套表。所以如果这个服务器压力比较大的话，
我们
就可以把一整个版块，就是一个表，迁移到别的服务
器上去。
所以 db 方 面就是 按版块 拆分表 这个模 式。web
方面就是增加。现在 web 方面扩展比较容易点，最
采访/杨赛
人物简介：
王建科（天涯ID：卓锐），1996年毕业于吉林大学计算机科学
系，现任海南天涯在线网络科技有限公司首席工程师、天涯论坛
产品总监，天涯早期建设者及参与者，主导开发了天涯论坛、天
涯博客等产品。
004
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com
杂志订阅 : http://os.51cto.com/art/201011/233915.htm
51CTO Linux 频道 ：http://os.51cto.com/linux/
人物
People
004
早做的时候就是通过 session 会话把 web 进行拆分。
db 另一个方面就是不使用连合查询。天涯最早为
了优化性能有几个特点，一个就是不使用连合查询。
比如有的时候你要呈现用户的名字啊，标题等信息的
时候，就要去读，那么我们的做法是在产生的时候就
把信息写到同一个地方去了，读的时候就只要把它一
起呈现出来。这样表之间就没有太多关联，因为表关
联也是十分影响性能的。而且表关联还会造成难以
拆分的问题。
还有就是一帖到底这个，我们的做法就是把所有
回复写到一个字段里面去。有新的回复时，就把这个
内容插到字段最下面，这样呈现的时候，只要读一个
字段就全出去了。这样就极大的降低了 db 的 I/O，
因为多一次读写就多一次 I/O 嘛，你只有一个字段，
就只有一个 I/O ；如果 100 个回复分为 100 个字段，
那就 是 100 倍的 I/O，1000 个 就是 1000 个 I/O。所
以天涯把所有回复合并，就极大的减少了 I/O。所以
天涯才能大体做到“一帖到底
”，不分页。
另一个有关这个分页。很多论坛数据量很大的时
候，你越往后翻页，处理的速度就越慢，效果很差了。
所以天涯这边我们用 where 子句来分页。Where 子
句就是判断，你点下一页的时候，用 where 子句定位
到这个下一页的数据。所以这样的话，你每次点下一
页，每次请求在性能上的消耗都是一样的，一致的。
51CTO ：就不用做 n 次计算了。
王建科 ：对，就不用再去计算我下一页这个数据到
底在什么位置，尤其数据量大的时候，这就很快。当
然天涯只提供了下一页的功能，而没有提供直接到某
一页的功能，就只能一页一页翻这样。
另一个就是锁。很多网站采用了死锁这种机制，
但是天涯呢，因为网友看内容对一致性的要求并不
高，我们就都全部允许脏读。就是说你不用忽略这个
更新，不用在读的时候把它锁上这样。
51CTO ：因为没这个需要。
王建科 ：对，没必要。因为我们的数据不像银行数
据，对一致性要求并不特别高，就避免了死锁这样的
方式。
另外一方面就是我们也用了 DNS 轮询，但是 DNS
轮询这个效果并不是特别
好，没有我们想象的那么均
匀，所以后来我们就自己写了应用来控制负载均衡。
另一个就是在 2003 年后来压力大的时候，我们开
始用 Squid 做页面缓存。当时因为天涯很多动态的
内容，变化比较大，而用了页面缓存之后，命中率在
70 左右吧，还不错，减少了后端的很多压力。
这样就是 2003 年到 06 年这个阶段。
那么 07 年到现在呢，就是比较强调架构化这个方
面。07 年之前我们不是只有电信这么一个链路吗，
网通用户就抱怨很多，所以就购买了网通链路，然后
用 F5 做链路负载均衡。
然后就是做更多的页面缓存。Squid 之后我们开
始用 Varnish，这个感觉效果更好一些。然后就是对
页面进行压缩。因为天涯都是文本内容嘛，所以压
缩率能达到 70%，效果挺好。然后就是 memcached
内 存 缓 存，就 是 你 要 往 db 读 写 的 内 容 都 先 放 在
memcached 里面，这个命中率比较高，有 90%。
所以就是一步一步做过来，先解决网通用户的抱
怨，再整个做优化。
51CTO ：您对技术人员在中国的发展有何看法？
王
建科 ：在中国的话，技术人员在大企业成长的空
间会更大一点，在中小企业的成长空间就会小一点，
这是中国技术人员面临的一个问题。
51CTO ：意思是中国的技术人员还是尽量在大企业
寻求发展是吗（笑）？
王建科 ：这个嘛（笑），比如像我的话，其实从一开
始就是同时做技术和产品两条线。很多技术人员要
往产品的方向转，觉得有很大困难，但是我这边就要
求，技术人员也必须关注一些产品，因为接触过产品
的技术人员思考交流的方式跟没接触过产品的技术
人员是不一样的。他能够考虑到一个产品使用会不
会有问题，技术特点方面能不能作出更漂亮的功能。
像是国外很多互联网产品都是技术人员驱动的，好比
Google 这样的。那么我也会鼓励我们的技术人员，多
关注产品，参与一些决策。否则的话，现在很多公司
一个常态就是，运营人员埋怨产品，然后技术就成了
推脱责任的借口，我们叫做“炮灰”（笑），很辛苦，又
没有成就感。这是不利的，所以就想怎么把这部分和
运营团队糅合在一起，共同做一件事情，共同关注用
户。
这是知识面方面。另一方面
技术人员也要扩展一
下深度，还是要走专业化的路线。所以我们也鼓励技
术人员进行交流，好比刘天斯，就很喜欢写博客分享
一些东西，这个过程也学到很多东西。
本文有删节，完整内容见原文 ：
http://os.51cto.com/art/201104/254678.htm
005
《Linux 运维趋势》投稿信箱 : yangsai@51cto.com
杂志订阅 : http://os.51cto.com/art/201011/233915.htm
51CTO Linux 频道 ：http://os.51cto.com/linux/
交流
Interact
005
网站扩展实例:1亿用户的Tagged架构进化史
一家2004年创建的试水社交网站，经过7年的成长和扩展，现在已经拥有了1亿用户。平均50亿次的pv，承
担在1000多台服务器的网站架构上。Tagged网站，现在承载了1亿个用户、1千台服务器和50亿次页面浏览量。
这个过程是如何实现的？
本文将要介绍的就是这个叫 Tagged 的网站——
Tagged 架构实例 ：1 亿个用户、1 千台服务器和 50 亿
次页面浏览量。下面，Tagged 的 CTO 兼联合创始人
Johann Schleier-Smith 将 为我 们介 绍 Tagged 网站
架构的成长历程。
自 2004 年以来，Tagged 从一家试水社交领域的
小不点网站，逐渐变成全球最大的社交网络之一，数
百万的成员访问该网站以结交新成员，每个月的页面
浏览量达到 50 亿次。这个逐步发展的历程迫使我们
Tagged 不断完善网站架构，最终获得了功能异常强
大的平台。
第一个阶段：2004年，PHP Web应用程序、10万个
用户和15台服务器
孵化器有着一种快速成型文化 ：每年通常推出两
个新概念，寻觅其中的大赢家。正是在这样的文化中，
Tagged 应运而生。LAMP 是适合这种类型的工作的
自然选择 ；这种工作注重灵活性和快速开发周期。当
时，Java 开发主要面向大企业的开发工作，Python 吸
引的编程员寥寥无几，Perl 方面的编程员又不是我们
所要
的那一种。我们还知道，雅虎是 PHP 的大力支持
者 ；所以一旦有需要，完全有可能扩展业务规模。
我在以前的项目上运行 MySQL 方面有着丰富的
经历，这让我对这项技术爱恨交加。本着尝试的精神，
我们为 Tagged 购买了几份入门级 Oracle 许可证，看
看甲骨文的技术是不是用起来更好。
值得注意的是，许多构建的小型网站仍然就像早
期的 Tagged。具有一种简单的美 ；无状态的 PHP 与
有状态的 Oracle 之间的双向分离正是一台服务器中
最棘手的部分，而额外的 Web 显示计算能力很容易
添加。
第二个阶段：2005年，缓存PHP Web应用程序、100
万个用户和20台服务器
即使只有在 8 台服务器的时候，Tagged 的网站流
量也要比大多数人所知道的来得多。幸运的是，分布
式内存缓存系统 memcached 带来了两个优势 ：既消
除了 90% 以上的数据库读操作，又确保含有大量不
同信息的社交网络面面可以迅速显示。
自一开始，我们的对象缓存注重显式缓存更新，支
持更简单的技术，比如删除无效的键 ；或者根据计时
器，使失效数据无
效。这种方法的缺点是代码比较复
杂，但大幅减轻了数据库负载，而且使网站保持快速
运行，涉及经常更新的对象时更是如此。
我们的网站继续越来越复杂，在标准的社交网络
功能的基础上，添加了搜索和社交发现等功能。我的
团队说服我使用 Java 来建立搜索功能，那样我们就
能得益于 Lucene 库。当我们学会了让 Java 顺畅运行
后，我有一种如释重负的感觉。
第三个阶段：2006年，数据库扩展、1000万个用户
和100台服务器
文/Todd Hoff
编译/布加迪
