DBA notes 五年

到今天，DBA notes 五年了! 从当年记录的日志看，2003 年 12 月17 日，这个站点”对外正式提供访问”。

前几天浏览 Flickr 上的历史照片，过去的很多场景似乎一下子又跑了出来，今天翻看站点的历史信息，也有这种感觉，那些记忆并没完全消失在时间里，它们还在…

看看还存在旧首页，还有从最开始的那些尽量”符合 Web 标准”的 HTML 页面，站点成立之初完全是用刀耕火种似的手工方式进行更新，直到后来换到了 Movable Type 内容平台。这个过程也是摸索、学习、实践互联网相关技术与文化的过程。从今年开始，Twitter(有 1000 多个 Follower 了) 似乎成了发布微格式内容的一个更直接渠道，不过只需通过简单的集成即可把消息显示在 DBA notes 首页，独立站点仍然是主体，将来可能也不会变化。

一直觉得自己是个不善于坚持的人，从没想过会持续 5 年的时间做一件事情，并且还在不断尝试做一些改进。5 年，1800 多天，在这个站点上发布了 1200 多篇所谓的文章，从开始的 Oracle 数据库的一些小品文，到一些鸡毛蒜皮的个人事情，再到网络评论以及网站架构介绍…..有的时候自己会考虑迎合一下读者的口味，有的时候则完全由着性子写。自己其实不太清楚为什么会一路坚持写下去，可能仅仅像吃饭喝水那样，没有更深层的原因。

上次在广州参加网志年会的时候，居然遇到了一位 4 年前就是我的读者的朋友，多少有点惊讶。5 年，通过在站点上表达的这些东西，认识了很多新朋友，也收到过很多来自他们的反馈以及建议与意见 … 5 年，已经无法计算究竟为此花费了多少业余时间，不过有一点：我相信付出的那些时间都是有价值的。我付出，也得到了应有的回报。分享知识的过程是最让人快乐的，即使分享的那些东西或许微不足道。

回想当初申请域名时，最头疼的就是关于域名购买的网上支付问题，这也使我在考虑加入支付宝的时候无形中投了一票。从北京到杭州，如今也已经将近 4 年，互联网的支付问题已不再是问题，这其中有自己的一份力。或许，人在做某些决定的时候也只是其他某个地方的蝴蝶扇动了一下翅膀。阿里巴巴五年以上的老员工叫做 “5 年陈“，会有一枚戒指作为纪念。Blog 五年有什么纪念?

感谢互联网，没有这个神奇的事物可能我不会学到如此多的知识，更不会成为一个技术人! 感谢车东，我在看他的网站的过程中萌生了自己建个站点的想法；感谢 SixApart 提供的 MT ! 当然也要感谢 Larry Wall，因为 MT 是用 Perl 实现的；感谢 Dreamhost 提供的物美价廉的空间! 感谢鲜果，让我今年 Blog 订阅量暴增。感谢通过 DBA notes 我所认识的朋友们!

我会继续的…

–EOF–

尤其要感谢从前我的女友–当然，现在已经是我的老婆–感谢她容忍我不陪她逛街或是摄影。

MySpace 系统架构

在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。

架构概况

超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。

之前曾有一篇揭秘 MySpace 架构的文章，也有中文版本《亿万用户网站MySpace的成功秘密》，请 Google 之！

运维数据收集

其实这个演讲我感觉主要讲的是这个数据收集模块 :) MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。

每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、硬件数据等等。收集器服务(Agent) 用 C#实现的，完全的异步 I/O，用了微软的 Concurrency and Coordination Runtime 库。每台主机上一个 Agent。其实国内也有超大规模的 Windows 环境 — 比如盛大，数据采集和监控的机制倒是类似的。

数据协议用的 Google 的 Protocol buffers。这倒是看到 Google 的这玩意儿公开后第一家大站点在用。也是因为用 Protocol buffers 从而不用 XMPP+ejabberd 的消息处理方案。

QCon 是我非常心仪的技术会议。可惜今年因为客观原因没能组织同事去参加。期待 2009 年在伦敦的会议。

–EOF–

延伸阅读：InfoQ 对 DanFarino 的专访。

Facebook 的 Memcached 扩展经验

周末的时候看到这篇 Scaling memcached at Facebook，感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。

相比之前介绍过的数据( 5TB数据/400台服务器).，现在 Facebook 在 Memcached 上的内容已经超过 28TB，总服务器数量超过 800 台。可见硬件降价真是够快的，内存的确便宜得很。

Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器，总体节省的内存资源是惊人的。

第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响，这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句，网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。

最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。

四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力，延迟只有 173 微秒。

Facebook 的技术还是挺开放的。这一点上比 Google 强多了。

–EOF–

手机之家网站架构–对话高春辉

这次去北京参加 CSDN SD 2.0 ，没发现高春辉的身影，原来是忙着做手机之家的架构升级呢。

从老高的近期工作总结中看到：

目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。

对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )

1) 历史情况

Fenng: 原来大约是用什么? 框架用的什么？
高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。
Fenng: 单说现在用的框架，大约投入了多少个人/天 ?
高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 :)
Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?
高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。后面第二期准备拿 Java 来写 Server 端。

2) 遭遇 PHP Bug

Fenng: 你提到的 502 错误不会是 PHP Fastcgi 内存爆了的原因吧？
高春辉: 不是，是 PHP 和 APC Bug 的问题。换新版就好了，你可以看 PHP 5.2.7 的 Buglist。里面列了一个在 Fastcgi 下父进程不能执行 shutdown module 方法的问题。主要是这个原因。APC 也有问题，它的Lock在大并发下非常容易挂掉。换上还没发布的测试版就好了。现在挺稳定的。一台机器跑了700万次请求了。
Fenng: 你遇到的是这个问题吧? Bug 45423
高春辉: Yes Here is the APC bug link : http://pecl.php.net/bugs/bug.php?id=5280 还附带这个问题。当时发现原因之后，非常郁闷，呵呵。
Fenng: 现在用 5.2.8 了?
高春辉: 嗯。5.2.7/5.2.8 反正没啥区别，就修正了一个bug。

3) DB 压力

Fenng: “原有的两台数据库平均总和超过 2000QPS 的查询次数，目前仅有 150+150+250= 550QPS 左右了” 这个 150+150+250 怎么来得？三台？
高春辉: 现在变成三台机器了 :)
Fenng: 哈
高春辉: 是原来的 1/4 吧。
Fenng: 你 Blog 中提到 “由于新系统未经大规模流量实际验证，即使再有信心”, 前面有没有做过压力测试?
高春辉: 做过，但是那个问题不是马上就暴露的。而是要运行一段时间才会出。所以我强调的是实际验证。

4) 过程挑战

Fenng: 问个比较俗的事儿,最近一段时间给你压力最大的事儿是啥？招聘？项目发布？
高春辉: 人!
Fenng: 人员协调？还是人力招聘？
高春辉: 人永远是问题，好的人不够用，差一点的人不想用，呵呵。
Fenng: 国内 PHP 好手还是太少吧？
高春辉: 嗯。太多人缺乏对大规模的研究和实践了。而且这次有些思路的转变是对 Java 的引入。之前是考虑 99% PHP 实现。现在考虑 PHP 只做前端。JAVA 做服务器后端。这样混合编程才算是比较发挥各自的优势。
Fenng: 你们有很多事务的东西？
高春辉: 不是事务多，而是 PHP 本身就不适合做服务器端的内容。包括性能也很慢。比如开始发给你的链接(Fenng 注：之前发给我一个 Session 信息统计的地址)，那个 Session Server 就是拿 Java 做的。之前 PHP 的版本，一次请求要两位数(ms)以上，现在一次只要1.5ms，差距很大。

5) 再说网站架构

Fenng:提供给我一份网站架构拓扑图吧 ?
高春辉:这是实际的，包括 IP 了,供参考吧:

Fenng: 你们网站规模都这么大了!
高春辉: (笑)

Fenng: 考虑到安全问题，我只把缩略图放到网站上吧。估计没人能看清楚 :)
高春辉: 好。我们目前还是做了一些感觉比较不错的小东西的。比如 Data accessor、Session server、YUI compress server 等等吧。
Fenng: YUI compress server 应该是借鉴了 Yahoo YUI, 然后针对静态文件进行压缩的吧？
高春辉: 就是用 YUI Compressor 做的，只是做成了一个 Daemon 服务，而不是命令行的方式来处理。
Fenng: Data accessor 或者其他组件是否准备开源?
高春辉: 关键是只有到规模才需要它。恐怕大部分网站还是觉得麻烦得多吧。
Fenng: 统计分析和监控也是自己写程序？
高春辉: 那倒还没来得及下大功夫，只是做了一些简单的脚本。

6) 图片处理问题

Fenng: 提一个小建议：我发现主题频道这里的图片仍然有拉伸，我个人觉得拉伸是网站必须要慎重对待的问题，用户体验非常不好。
高春辉: 应该是 Imagemagick 使用的问题。我还在继续修正，不过相信不是大问题。
Fenng: 这么说图片处理用了 Imagemagick ?
高春辉: 嗯。有图形处理后端 Server。

高春辉: 你可以看看手机之家论坛(http://bbs.imobile.com.cn/)的页面源代码…
Fenng: 现在(网站)的速度可真不是一般的快…YSlow 上的表现惊人, 差不多是国内网站我看到的最高分了。
高春辉: 其实全都都是动态请求，包括你看到的任何一个图片/JavaScript/CSS …
Fenng: 你们的图片都是如何处理的？我看到似乎是动态拿过来？在DB里？然后Cache到缓存里么？
高春辉: 全部放到数据库里。作为备份。你在前台看到的都是动态处理的，通过 ID 进行关联。前面有两级缓存。数据库的内容相当于备份。这么做的我认为的好处是不用备份上百万个小文件了。而只是备份几百个大文件就行了。速度会提高非常多；而且那种静态损坏的几率就没有了，因为数据库本身会做数据的校验，我们也都保留的验证数据。

Fenng: 这是个反潮流的做法啊,我的猜测是每天数据量变化不大？
高春辉: 目前一天顶多也就是几百兆的增加，应该是可以承受的。而且即使量大也没关系，我可以具体到一个表拆到一个机器上跑。
Fenng: 可这样的话 EXIF 信息就不用了？
高春辉: 所有的信息都可以有一个 Metainfo 表进行保存。而且可以从新生成，假设你的文件信息解析程序有更新的话。
Fenng: 这是我这几年来看到的第一例。不过合适就好。
高春辉: Metainfo表,当然也可以由各应用自己解析自己保存。目前 FileStorage 已经保存了 1.1TB 的文件数据了。当前拆成了 256 个小表，每个表4G左右大小。
Fenng: 文件层用什么文件系统？XFS?
高春辉: 数据库都是 CentOS 5.2 64 bit 的系统。文件系统用 Ext3。其实没你想像的那么大的 I/O 压力，只要两级缓存有了。根本到不了数据库这里。而且前端的两级缓存都是可以多台机器一起跑冗余的。
只要配置就行了。以后备份和故障恢复也很简单。
Fenng: 这一点很有趣。突破传统思维 :)
高春辉: 也是基于之前的教训而琢磨的方法，呵。

7) 对待 NFS 的态度

Fenng: 这次架构升级还有什么补充一下?
高春辉: 刚才还忘了说，我们这次以后坚决拒绝 NFS …
Fenng: 为何?
高春辉: 主要是太容易单点了。 IO对一个机器压力大。这本来就不是个分布式的解决方法。

最后帮老高做个广告，他那边还在招人，需要 PHP/Java 方面的好手，如果有兴趣请访问他的 Blog 并发邮件给他：[email protected] 。

–EOF–