看到 Smugmug 的 CEO Don MacAskill 写的一篇关于使用 Sun 软件栈的经验。Web 2.0 公司用 Sun 这套东西的真的不多见。
| Smugmug 解决方案前后对比 | |
| 旧方案 | 新方案 |
| Linux | OpenSolaris |
| MySQL 5.0 | MySQL 5.1 |
| LVM2 + EXT3 | ZFS |
| 硬 RAID | 软 RAID |
| 非压缩 | GZip9 卷压缩 |
其实从一个技术体系迁移到另一个技术体系，最合理的理由就是能得到哪些收益。整个项目看下来，ZFS 是其中最大的亮点。管理简单，功能丰富，足够稳定。此外，ZFS 的备份、压缩功能也是非常值得称赞之处。
至于 OpenSolaris 的启用，倒是有一些潜在的隐患，比如 GNU 工具的集成使用上，缺少经验可能会给用户带来不少麻烦。其实 Sun 也是的，干脆把 ZFS 和 Dtrace 移植到 Linux 上算了。何必抱残守缺呢? 说起 Dtrace ，这可是好东西，性能 Tuning ，那可是屠龙刀。值得一提的是，以 OpenSolaris 衍生的Nexenta 项目似乎很有趣。
--EOF--
老文。去年受泰稳之托做的采访。这是我整理的稿件。另请参见 InfoQ 中文站上关于 此文的更多信息。
可能 MySQL Proxy 很多数据库技术人员都比较熟悉了，在前不久，国内也有开发者发布了一个Amoeba(变形虫)项目（http://sourceforge.net/projects/amoeba），这个项目专注分布式数据库 Proxy 开发，引起了广泛的关注。 DBA notes( http://www.dbanotes.net ) 站长Fenng 有幸采访了阿米巴项目的开发者陈思儒，以下是采访全文。
Fenng：你好，思儒，很高兴能接受采访，简要介绍一下自己吧?
陈思儒: 我目前是盛大计算机(上海)有限公司的一位高级研究员。 在就业生涯中从事分布式消息系统、分布式应用、多层框架设计、规则引擎开发框架研究，以及 Java 2D MMORPG框架研究。
Fenng: 说一下当初开发 Amoeba 项目的缘由如何，估计其中也会有不少小故事吧? 我可是非常好奇。
陈思儒: 其实 Amoeba 的前身是网络数据包分析代理，之所以 Amoeba 能够快速稳定发展也是因为个人在前期使用这些技术分析过一些游戏的数据包(这儿不方便透露一些细节，这些都只是个人爱好而已，并没有破坏那些被我研究过的游戏 :D )。
为什么会有 Amoeba 这个产品，这个话题的确非常有意思，我关注 MySQL Proxy 也有一段时间了。MySQL Proxy 的这种想法做的非常棒，它能够根据自己的想法去构造目标的 MySQL Proxy 应用，比如监控 SQL 执行、数据流量、读写分离。但由于我们使用 MySQL Proxy 并不能非常轻易的解决一些问题（读写分离、数据切分、水平切分、负载均衡），而是需要写大量的Lua Script，这些 Lua 并不是现成的而是自己需要去写。这个工作对于并不熟悉 MySQL Proxy 内置变量、MySQL Protocol 来说是非常困难的。
因此带着这个想法我就设想做一个非常容易使用、可移植性非常强的软件。Amoeba就因此诞生了。为什么叫Amoeba? 其实这个想法我是突然想到的，Amoeba中文意思是"变形虫"，Amoeba被设想为数据库代理的开发框架，它可以为符合Amoeba框架的任何数据库开发代理层。因此也比较象"变形虫"一样能够变成目标数据库的代理层软件。
Fenng: 我观察到 Amoeba 与 Oracle 交互的时候似乎还是模拟 MySQL 的驱动器, 实际情况是否如此?
陈思儒：目前Amoeba有2个产品：Amoeba for MySQL，Amoeba for Aladdin 。这2个产品有不同的适用范围：
其实在我上一家公司的时候也正在研发 Amoeba for Oracle，这个产品目前还正在研发状态。这个产品性能也跟 Amoeba for MySQL 一样出色。
就 Amoeba for Aladdin 产品来说，后端的任何数据与 Aladdin 交互采用 JDBC Driver. 对于 Aladdin来说，数据库的协议是透明的，而应用跟 Aladdin 的交互则采用 MySQL 协议，这个做法很多人有不明白，其实做这个决定主要是想借助 MySQL 使用的广泛程度以及对各种 开发语言的支持。因此对前端的应用来说 Aladdin 就是一个虚拟的 MySQL 数据库。你这个问题应该是问使用 Aladdin 的时候。
Fenng: 是的，是在看了你的 Aladdin 架构图后产生的疑惑。你比我严谨多了(笑)。能否冒昧问一下 Amoeba 项目当前的局限?
陈思儒：虽然 Amoeba 能够很好的解决水平切分、垂直切分等，但还是会存在一些局限性，这些局限性是因为我们在设计目标的数据库架构的时候就必须考虑到我们未来的数据库框架（可以线性扩容的数据库架构）。因此也有些查询将不支持，比如跨数据库服务器进行Join，我们要尽量避免类似的业务出现，也可以通过多次查询来解决这类问题。
Fenng: 你在前面也说到了 MySQL Proxy，能否简单的说说 Amoeba 与 MySQL Proxy的区别?
陈思儒：其实说与MySQL Proxy的区别应该是Amoeba for MySQL与 MySQL Proxy 的区别，在上面表述的第二点应该都涉及到了:
Fenng: 据说你也分析过 Oracle 的 TNS 协议，你认为可靠性如何?
陈思儒：的确，我在上一家公司为做 Amoeba for Oracle 分析过 TNS协议，可靠性以及安全方面都是没什么问题，Oracle 还提供了一些网络层的性能参数，用来改变Oracle的网络吞吐量。但是 Oracle 的数据部封包做法让我和老同事在分析 Oracle 数据包的时候伤透脑筋， 我觉得 Oracle 如果想在协议上面升级版本将不是一件容易的事情。而MySQL 的协议封包的做法我比较赞同。
Fenng: 对于分析 TNS 的可行性，我的看法倒是和你类似。顺便问一下，现在 Amoeba 是否已经有了成功案例, 方便的话能否举几个?
陈思儒：Amoeba for MySQL 的成功案例，目前就网友直接跟我说的有几个，但我还没具体了解他们具体的公司名称，以后知道了我再透露。
Fenng: 到时候千万要通知我一下。对了，能否说一下 Amoeba 项目的愿景以及下一步的目标? 陈思儒：目前距离Amoeba发展目标还有一点距离，Amoeba 未来将是一个更加容易使用、可管理、可动态装载配置、Amoeba集群等。
如果未来可行的话，我将补充 MySQL 协议，做一个用于负载均衡的"重定向路由器"（类似F5功能，但它只是做连接跳转）。
Fenng: 现在开发者主要是你一个人? 是否还有其他维护者 ?
陈思儒：Amoeba 框架、Amoeba for MySQL、Amoeba for Aladdin 目前的开发就我一个人。
Fenng: 很高兴你接受我的采访。期待 Amoeba 项目取得更大的成就，也祝你工作愉快！
陈思儒：客气！也希望有更多的开源爱好者或是数据库技术爱好者加入到这个项目的开发中来。关于 Amoeba 项目的进展我会在 "Amoeba 开发者博客"上更新，欢迎订阅。
--EOF--
旧文重发，期待新的一年这个项目能有更大的发展，能有更多公司从该项目中受益。
接上一篇。这其实是一篇综述文章 :)
可能有些企业已经在战略中加上了云计算这个关键字，问题是，真的需要那么多云计算么? 如果在技术上、规模化不能有效的节约成本，那么跟风建设云存储服务是缘木求鱼。更多的企业是自身的存储建设都远远不到位，大谈云存储无疑是痴人说梦。至少在国内，我们的基础建设还和国外有一段距离，而内容审查与一些政策上的限制又会增加建设、运营成本。
回答这个问题之前，我建议先看看服务提供方是否真的是云存储服务，如果只是炒炒概念，用老的架构支撑，换汤不换药，那还是谨慎为妙。企业如果不能从技术上做些本质突破而节约成本，那么成本肯定要转嫁到消费者身上，如果消费者不买单，那该服务如何能长久? 和我们现实生活中很多山寨 IDC 类比一下就知道了，动辄听到某主机托管商一夜之间蒸发，用户欲哭无泪的事情。
如果使用云存储服务，不妨和竞争对手使用同一家服务商。出问题的时候大家都出问题，保证始终处于同一起跑线。
在国内，短期内还看不到有规模的云存储服务商。由于网络的问题，企业用户也不太可能去使用国外的服务（不排除将来 Amazon S3 这样的服务能在国内提供服务）。期待在未来的一段时间能看到一些变化，但这恐怕只是乐观的想法。
时值全球经济的寒冬，能够为用户省钱的服务相信也应该能够赚到钱。从用户的角度上看，云存储解放了自身的生产力，能够允许中小创业团队集中精力做发展业务，只要不形成恶性竞争，应该不用担心盈利的问题。
就以 Amazon的 S3 来说，基本上也很好的展示并实践了 Web 2.0 长尾理论：利用企业建设剩余的存储以及网络带宽能力而为广大中小网站提供服务，前途大好。相信 Google 推出类似服务也是指日可待的事情。但这个市场内应该不会出现过多的有力竞争者，有些存储厂商(比如 EMC) 也在进入这个领域，数据存储不是问题，但网络能力可不是那么好解决的事情。
从我们前面提到的云计算中的存储特点来看，SAN(存储区域网络)产品就暴露出一些不适合的应用场景，毕竟 SAN 是面向集中式计算的架构。另外，大家也都知道 SAN 产品一般不便宜(现在也有厂商在力推低端海量存储产品，后面会介绍)，而且，主机端如果用 HBA 卡，也会进一步提高成本；SAN 面向传统企业应用而设计的扩展能力难以满足云计算的需求。
目前尽管已经有一些企业在做集群存储然后打包出售，但相对还是在起步阶段。至少现在还看不到真正集群 SAN 产品的出现。当然，如果对云计算的存储部分不计成本的话，SAN 仍然可以在云计算中发挥一些作用，这倒是中了存储厂商的下怀。
不管怎么说，RAID 这个 SAN 中的概念在云存储中已经绝对不适合了。
有业界评论说集群 NAS 可能会演变成云存储的通用架构，我怀疑这是不是 Sun 公司的宣传手段，因为这事实上宣布了 ZFS 将是云存储中的一个关键点。
从现有的情形看，或许会有越来越多的在线存储服务拥抱集群 NAS 。但这不代表集群 NAS 前途光明能够在云存储大展拳脚。集群 NAS 最大的问题是海量数据的寻址是个麻烦事儿，然后是扩展性与容错性的问题，底层的容错性如果通过硬件来做，那么成本无疑会上升，这恐怕是企业不愿意接受的。
在开源领域，以 MogileFS 为代表的分布式文件系统能够用于一些相对规模较小的分布式存储场景，很多 Web 2.0 自己的分布式存储就是借鉴 MogileFS 搭建的，不过毕竟 MofileFS 的Meta 信息仍是集中存储、管理的，在更大规模恐怕有些吃力。
此外，Kosmosfs（http://kosmosfs.sourceforge.net/）、Lustre(http://www.lustre.org) 等也都在不断发展中，相信能够给有兴趣研究云存储的技术人员一些借鉴。也有一些软件厂商将其专有的分布式文件系统和存储打包在一起销售，而存储厂商也有的在结合自己的存储产品做一些尝试。目前还很少有相对成熟度的东西进入用户视野。
更多分布式文件系统列表参见维基百科的文件系统列表介绍。
尽管我们接触不到 Google 大名鼎鼎的 GFS （Google File System），但我们能免费获取 Hadoop 的 HDFS (Hadoop Distributed File System)。HDFS 相对上述的 ZFS 来说，属于专门针对廉价硬件设计的分布式文件系统，在软件层内置数据容错能力。Hadoop 目前的案例多数用在数据分析与并行计算上，倒是很少看到有支撑给互联网应用的数据服务，但相信随着其在开放环境中的快速成长， Hadoop 将不断壮大。
（HDFS 架构示意图. from: http://hadoop.apache.org/core/docs/current/hdfs_design.html 关于 Hadoop 也请参阅《程序员》杂志 2008年10月刊的文章。）
云计算中存储的起步容量，我们不妨按照 1PB 可用空间来准备。近年来，随着磁介质存储能力的提升，企业存储的价格也是一降再降，$2.00/GB 的底线早已突破，现在Sun 的Thumper 声称可以达到 $1.20/GB 的成本。(注：企业存储[不是个人消费品]的磁盘价格一降再降，而且有很重要的商业因素，具体的成本应该还要更低一些，只是不知道哪位朋友有更为准确的数字)
粗略估算一下，2PB 的原始容量成本大约是 250 万美元左右(List Price)。单位机柜空间密度最高的已经能够做到4U的机存储48TB的原始容量(目前能看到密度最高的了)，这样最小只需要大约 45 个 4U 的机柜空间。其他方面，加上本地的工业电力价格，大致的硬件总体开销还是可估量的。软件方面，这个存储本身是基于 Sun 的 ZFS，内置的操作系统，成本也是可以控制的。
在山寨精神盛行的今天，没准儿已经有人在搭建一套山寨版的云存储方案呢。比如目标定在 1PB 可用容量，预计至少需要如下的东西:
选择廉价的刀片服务器(自己"生产"就不必了)，内置足够多的大硬盘，硬盘速度无所谓，预计每台机器预装4T容量(1T*4，坏了就整台机器替换)，大约需要 500台服务器，总容量2PB，确保每一份数据都至少冗余在另外的物理机器上，冗余后，起码能得到1PB容量(如果备份的数据启用压缩，没准儿能提供更多空间呢)。机架物理空间怕是需要 1000 U多一些，每个标准机柜是42U，怎么也要准备 25 个机架吧，再加上网络交换机什么的... 然后是电力与空调散热问题。
再弄一套 Hadoop ，定制一下跑起来 ...当然，山寨与否，关键是拼技术团队，一味的拿来主义注定只能跟风。
其实，这篇文章也是一篇山寨文。
--EOF--
这是去年发在《程序员》杂志的一篇文章。当时写得比较急，现在看起来，有些观点有些武断。仅供参考。
引言, "The one that is without any tradeoff is to have the logical storage master up in the cloud" by Bill Gates.
2008 年的 IT 界，云计算是个热词。很多企业都在宣称自己提供云计算服务，很多人也都在讨论云计算(一些明显是凑热闹的，比如所谓的"云安全")，从业界公认的几种云计算的服务能力看，都绕不开存储这个基础支撑组件，dSaaS(data-Storage-as-a-Service) 更是把存储提到了首要的位置。而从我们目前能得到的信息来看，在存储层已经解决很好的，恐怕也只有 Google 和 Amazon 两家，至于其他公司可能都还在路上，即使是微软，尽管也有自己的 Dryad ，但是实际上，仍然处于理论阶段，产品化的路还有点距离。
上面表格中的举例仅仅是为了举例，如果某家已经 "云计算了" 的公司大名不在上面，并非该公司"云"的不够彻底，应该只是笔者眼光差的原因而已。
根据 EMC 公司赞助 IDC 进行的研究计划 "Digital Universe" 的分析报告，在整个 2007 年，我们这个世界生成、占用的数字信息及复制总量大约是 281 Exabytes (1 Exabytes=1024 Petabytes ，1 Petabytes = 1024 TB 这里换算都按照二进制的换算)，这个数据平摊到地球上的所有人，大约是每个人 45 GB的数据；截至到笔者写稿的时候，2008年到现在整个世界已经生成了大约 374 EB 的数据（可以到 "Digital Universe" 页面查看最新的数据，也可以下载一个评估工具，看看自己产生的数据是大约如何）；到 2011 年，每年产生的数字信息大约是 1800 EB，10倍于2006 年产生的信息量。做为对比，Google 每天处理的数据大约是 20 PB 的样子，Google 的目标是要组织所有的信息，看来并非易事。
其他可参考数据：据美国国家档案馆工作人员估计，布什政府电子档案存储量大约为1亿GB，这一数字约为前总统克林顿两届政府档案总量的50倍，是国会图书馆2000万册编目图书内容总量的5倍。
每年激增如此庞大的信息量，加上已有的历史数据信息，对整个业界的数据存储、处理带来了很大的机遇与挑战。通过该研究能看出，在可用存储之间与信息生成总量之间不是严格匹配的，一方面多媒体领域信息增长过快，一方面因为不合理的存储分配、占用情形比比皆是。例如研究表明一封大约 1M 的邮件发出后，经过不同服务器的存储、备份、归档等最后总体占用空间竟然达到惊人的 50M 之多。正如云计算的初衷是为了充分发挥计算机闲置资源，提高总体使用率以便达到经济效益，云计算中的存储方面也应该能有效提高存储利用率而进一步创造价值，盲目的复制、堆积数据是没有出路的。工业界提倡节能减排，其实 IT 界应该提倡一下节约存储了。
其实，什么是云计算都很难有一个权威的定义，笔者在这里更愿意把"云计算中涉及的存储"简称为云存储(Cloud Storage)。云存储本身离不开云计算，更多的时候云存储是做为云计算的一个支撑组件。
云存储不是简单的在线存储或是网络硬盘，在线存储服务只是云存储能够提供的众多服务中的一种而已。
云存储至少应该能够具备如下特点：
要建设成功的云存储系统，高扩展性、高可靠性的分布式文件系统是一个关键因素。而硬件问题反而是次要的。
云存储的服务形式见上表。
未完待续...
在互联网这个行业，"以用户为中心的设计"已经达成共识，但很少听到有人说"以用户为中心进行性能优化"之类的话，很多时候，网站性能优化是面向服务器来进行，或许，应该扭转一点思维，改到考虑如何面向用户进行网站性能优化的时候了。
为什么要做优化? 不外乎如下几种原因：
多数公司做优化都是从前两者出发，而"提升用户体验"虽然是从用户(网站访问者)角度出发，但却很少提升到非常重要的高度。
此外，或许也有炫技的因素在内，为了优化而优化，当然这是不可取的做法。
有效的优化方式前提是要能有有效的度量。一个用户访问网站，从 提交请求到得到响应，完整看到页面，中间的每个环节都应该确保优化得当。否则如果后端已经"完美"优化，单用户请求的页面有 N 多大图片，也是个糟糕的事情。在没有建立端到端的度量数据收集之前，很可能存在较大偏差。
(图Refer)
一些常见的问题是，您知道访问自己站点的用户在使用什么样的线路? 什么样的 ADSL 线路，有多少还在用拨号上网? 在网吧上网的用户有多少? 多少是移动设备用户? ... 如果此类数据收集有所欠缺，也很难做出有效的性能度量。
服务器压力降低 = 用户访问速度快 这是最常见的一种优化态度。技术人员对自己的网站用尽了各种优化手段，服务器压力终于降低了，单用户会真的满意么? 未必。但如果从没观察过终端用户的访问习惯和网络连接方式能客观因素，也是徒劳。
前端优化不如后端优化重要 前端优化仍然没有受到应有的重视，仍有多数设计者对性能问题熟视无睹，随手弄个 1M 大小的活动页面对他们来说，图片设计是否华丽可能才最重要。对于越来越需要多媒体、富媒体表现的页面来说，前端优化其实是重中之重。两手抓，两手都要硬。用户访问费劲的页面，再华丽也是垃圾。
节省 PV = 减少 PV 以 KPI 为导向的 Web 公司中，PageView 可能是很多人的饭碗，轻易不要太岁头上动土。不过对于 KPI 制定者来说，起码要具备如何识别虚假繁荣的 PV (除非也是作弊团伙成员)。不必要的 PV 能节省就节省，节余的带宽资源留给更有价值的应用。
把优化作为项目来做 有些网站会有"起个项目对某某块做个优化"之类的事儿。优化应该是个长期、持续的事情，如果单纯的作为项目来做，可能一波热乎劲儿过去就没人管了。
--未完待续--
在前不久结束的 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 的专访。
周末的时候看到这篇 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! )
Fenng: 原来大约是用什么? 框架用的什么？
高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。
Fenng: 单说现在用的框架，大约投入了多少个人/天 ?
高春辉: 从全年开始考虑写，一直不断的写 -- 具体时间不好说。反正是不少了 :)
Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?
高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。后面第二期准备拿 Java 来写 Server 端。
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。
Fenng: "原有的两台数据库平均总和超过 2000QPS 的查询次数，目前仅有 150+150+250= 550QPS 左右了" 这个 150+150+250 怎么来得？ 三台？
高春辉: 现在变成三台机器了 :)
Fenng: 哈
高春辉: 是原来的 1/4 吧 。
Fenng: 你 Blog 中提到 "由于新系统未经大规模流量实际验证，即使再有信心", 前面有没有做过压力测试?
高春辉: 做过，但是那个问题不是马上就暴露的。而是要运行一段时间才会出。所以我强调的是实际验证。
Fenng: 问个比较俗 的事儿,最近一段时间给你压力最大的事儿是啥？ 招聘？项目发布？
高春辉: 人!
Fenng: 人员协调？还是人力招聘？
高春辉: 人永远是问题，好的人不够用， 差一点的人不想用，呵呵。
Fenng: 国内 PHP 好手还是太少吧？
高春辉: 嗯。太多人缺乏对大规模的研究和实践了。而且这次有些思路的转变是对 Java 的引入。之前是考虑 99% PHP 实现。现在考虑 PHP 只做前端。JAVA 做服务器后端。 这样混合编程才算是比较发挥各自的优势。
Fenng: 你们有很多事务的东西？
高春辉: 不是事务多，而是 PHP 本身就不适合做服务器端的内容。包括性能也很慢。比如开始发给你的链接(Fenng 注：之前发给我一个 Session 信息统计的地址)，那个 Session Server 就是拿 Java 做的。之前 PHP 的版本，一次请求要两位数(ms)以上，现在一次只要1.5ms，差距很大。
Fenng:提供给我一份网站架构拓扑图吧 ?
高春辉:这是实际的，包括 IP 了,供参考吧:
Fenng: 你们网站规模都这么大了!
高春辉: (笑)
Fenng: 考虑到安全问题，我只把缩略图放到网站上吧。估计没人能看清楚 :)
高春辉: 好。我们目前还是做了一些感觉比较不错的小东西的。比如 Data accessor、Session server、YUI compress server 等等吧。
Fenng: YUI compress server 应该是借鉴了 Yahoo YUI, 然后针对静态文件进行压缩的吧？
高春辉: 就是用 YUI Compressor 做的，只是做成了一个 Daemon 服务，而不是命令行的方式来处理。
Fenng: Data accessor 或者其他组件是否准备开源?
高春辉: 关键是只有到规模才需要它。恐怕大部分网站还是觉得麻烦得多吧。
Fenng: 统计分析和监控也是自己写程序？
高春辉: 那倒还没来得及下大功夫，只是做了一些简单的脚本。
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: 这一点很有趣。 突破传统思维 :)
高春辉: 也是基于之前的教训而琢磨的方法，呵。
Fenng: 这次架构升级还有什么补充一下?
高春辉: 刚才还忘了说，我们这次以后坚决拒绝 NFS ...
Fenng: 为何?
高春辉: 主要是太容易单点了。 IO对一个机器压力大。这本来就不是个分布式的解决方法。
最后帮老高做个广告，他那边还在招人，需要 PHP/Java 方面的好手，如果有兴趣请访问他的 Blog 并发邮件给他：[email protected] 。
--EOF--
