大型网站架构技术方案集锦

大型网站架构技术方案集锦-具体内容

PlentyOfFish 网站架构学习

采取 Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 \"Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值 10 亿，估计要让很多人眼热，更何况 Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。

之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西，会啥用啥。就这样，也能支撑 超过 3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。

带宽与CPU

PlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache，因为数据变化过快，很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了 30% 的 CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。

负载均衡

微软 Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均

1

衡对 Windows 架构的站点又是必须--IIS 的总连接数是有的。PlentyOfFish 用的是 ServerIron

(Conf Refer)，ServerIron 使用简单，而且功能比 NLB 更丰富。

数据库

一共三台 SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器\"。因为 Cache没啥用，所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好，越简单越好，这是常识，不过不是每个人都体会那么深而已。

微软好不容易找到了一个宣传案例，所以在 Channel 9 上有一个 PlentyOfFish 的访谈。

PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。

--EOF--

的架构扩展

在西雅图扩展性的技术研讨会上， 的 Cuong Do 做了关于 Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一

2

下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 的数据流量, \"一天的流量相当于发送750亿封电子邮件.\2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,\"每天有10亿次下载以及6,5000次上传\真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 就没法子比了.

Web 服务器

出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。

出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 \"迷你 Cluster\" 就

3

是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些\"漏网\"的随即访问即可。 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。

数据库

用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是\"分区\这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

--EOF--

WikiPedia 技术架构学习分享

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

来点直接的数据：

4

• 峰值每秒钟3万个 HTTP 请求

• 每秒钟 3Gbit 流量, 近乎375MB

• 350 台 PC 服务器(数据来源)

架构示意图如下：

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

5

的内容性质决定的--面向各个国家，各个地域。

负载均衡：LVS

WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.

图片服务器:Lighttpd

Lighttpd 现在成了准标准图片服务器配置了。不多说。

Wiki 软件: MediaWiki

对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。

Cache! Cache! Cache!

维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。

6

数据库: MySQL

MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。 复制、读写分离......应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。

运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。

参考文档：

Wikimedia architecture （PDF)

Todd Hoff 的文章

--EOF--

Tailrank 网站架构

每天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。

专门爆料网站架构的 Todd Hoff 对 Kevin Burton 进行了采访。于是我们能了解一

7

下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与 Feed，内容处理能力为 160-200Mbps，IO 写入大约在10-15MBps。每个月要处理 52T 之多的原始数据。Tailrank 所用的爬虫现在已经成为一个产品：spinn3r。

服务器硬件

目前大约 15 台服务器，CPU 是 位的 Opteron。每台主机上挂两个 SATA 盘，做 RAID 0。据我所知，国内很多 Web 2.0 公司也用的是类似的方式，SATA 盘容量达，低廉价格，堪称不二之选。操作系统用的是 Debian Linux 。Web 服务器用 Apache 2.0，Squid 做反向代理服务器。

数据库

Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB， 数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些 多核模式下互斥锁的问题(This Bug?)。到数据库的JDBC 驱动连接池用 lbpool 做负载均衡。MySQL Slave 或者 Master的复制用 MySQLSlaveSync 来轻松完成。不过即使这样，还要花费 20％ 的时间来折腾 DB。

其他开放的软件

任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针对 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。

8

Tailrank 的一个比较大的竞争对手是 Techmeme，虽然二者暂时看面向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank 离预期目标还差的很远。期待罗马早日建成。

--EOF--

LinkedIn 架构笔记

现在是 SNS 的春天，最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal 黑帮 成员创建的。在最近一个季度，有两个 Web 2.0 应用我用的比较频繁。一个是Twitter，另一个就是 LinkedIn。

LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过，写一则 Blog 记录之。

LinkedIn 雇员有 180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600 万，现在每月新增 100 万，50％ 会员来自海外(中国用户不少，也包括我).

开篇明义，直接说这个议题不讲\"监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候，关系数据库有些不合时宜，而把数据放到内存里进行计算就是必经之路。具体一点说，LinkedIn 的基本模式是这样的：前台应用服务器面向用户，中间是DB，而DB的后边还有计算服务器来计算用户间的关系

9

图的。

问题出来了，如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。

第一个方式是用 Timestamp . 对记录设置一个字段，标记最新更新时间。这个解决方法还是不错的---除了有个难以容忍的缺陷。什么问题？就是 Timestamp 是 SQL调用发起的时间，而不是 Commit 的确切时间。步调就不一致喽。

第二个办法，用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个 SCN 列，默认值\"无限大\"。然后用选择比某个 SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。

10

ORA_ROWSCN 是 Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢?

--EOF--

一点题外话：我的 LinkedIn Profile (Mail : ******************).Keep in Touch!。另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~

Yahoo！社区架构

旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站\"晒架构\"也是个比较过瘾的事情。请参观并收藏这个页面：Architectures you've always wondered about。

eBay 的架构和去年相比基本是换汤不换药，倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思，披露了一些鲜为人知的信息。

Yahoo! 社区包括我们比较熟悉的 del.icio.us、Flickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。

架构特点

有两点值得注意：1）层次化 2）模块化。这也是大规模作业下的比较经济的途径。

11

软件架构

首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux，这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle，构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon（监控），还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache，请参考我以前写的 Yapache-Yahoo! Apache 的秘密

这是 Bix 与 DB 有关的部署架构:

数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了)，通过快照复制到其他数据中心。

Yahoo! Mail 架构：

12

这里面居然部署了 Oracle RAC，用来存储 Mail 服务相关的 Meta 数据。非常有趣。

运营维护

监控工具主要用的是 Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo！自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不

13

到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。

应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。

Note: 上面所有截图版权都属于 Ian (Image COPYRIGHT@IAN) 。如果去看那个 PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。

--EOF--

Craigslist 的数据库架构

14

(插播一则新闻：竞拍这本《Don’t Make Me Think》，我出价 RMB 85，留言的不算--不会有恶意竞拍的吧? 要 Ping 过去才可以，失败一次，再来)

Craigslist 绝对是互联网的一个传奇公司。根据以前的一则报道：

每月超过 1000 万人使用该站服务，月浏览量超过 30 亿次，(Craigslist每月新增的帖子近 10 亿条??)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18 名员工(现在可能会多一些了)。

Tim O'reilly 采访了 Craigslist 的 Eric Scheide ，于是通过这篇 Database War Stories #5: craigslist 我们能了解一下 Craigslist 的数据库架构以及数据量信息。

数据库软件使用 MySQL 。为充分发挥 MySQL 的能力，数据库都使用 位 Linux 服务器, 14 块 本地磁盘(72*14=1T ?), 16G 内存。

不同的服务使用不同方式的数据库集群。

论坛

1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到 17G。最大的表接近 4200 万行。

分类信息

1 主 12 从。 Slave 各有个的用途. 当前数据包括索引有 114 G , 最大表有 5600 万行(该表数据会定期归档)。 使用 myIsam。分类信息量有多大? \"Craigslist每月新增的

15

帖子近 10 亿条\"，这句话似乎似乎有些夸张，Eric Scheide 说昨日就超过 330000 条数据，如果这样估计的话，每个月的新帖子信息大约在 1 亿多一些。

归档数据库

1 主 1 从. 放置所有超过 3 个月的帖子。与分类信息库结构相似但是更大， 数据有 238G， 最大表有 9600 万行。大量使用 Merge 表，便于管理。

搜索数据库

4 个 集群用了 16 台服务器。活动的帖子根据 地区/种类划分，并使用 myIsam 全文索引，每个只包含一个子集数据。该索引方案目前还能撑住，未来几年恐怕就不成了。

Authdb

1 主 1 从，很小。

目前 Craigslist 在 Alexa 上的排名是 30，上面的数据只是反映采访当时(April 28, 2006)的情况，毕竟，Craigslist 数据量还在每年 200% 的速度增长。

Craigslist 采用的数据解决方案从软硬件上来看还是低成本的。优秀的 MySQL 数据库管理员对于 Web 2.0 项目是一个关键因素。

--EOF--

Fotolog.com 的技术信息拾零

16

尽管是世界上最大的图片服务网站, Fotolog.com 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起 Flickr. 但实际上 Fotolog 也的确是很猛的, Alexa 上的排名一直在 Flickr 前面, 目前注册用户超过 1100 万. 而前不久也卖了一个好价钱, 9000 万美金. 算下来的话, 1 个注册用户大约 9 美金. Yupoo 的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.

在前不久的 MySQL Con 2007 上, Fotolog 的 DBA Farhan Mashraqi 披露了一些技术信息.（PPT下载)

与其他大多数 Web 2.0 公司普遍用 Linux 不同的是, Fotolog 的操作系统用的是 Solaris . Solaris X86 也是免费的, 估计是维护人员更熟悉 Solaris 的操作系统而作出的选择吧.

数据库当然是使用 MySQL. 有32 台之多, 最开始的存储引擎是 MyISAM ,后来转向 InnoDB. 对于 DB HA , 使用 DRBD (介绍)，在 Solaris 上用 MySQL ,有个优化技巧是关于 time(2) 系统调用的，通过调用比 gethrestime() 更快的 gethrtime(3C) 来提高性能。可以通过设置 LD_PRELOAD (32位的平台) 或 LD_PRELOAD_ 来做到。详细信息可以参考Sun 站点上的这篇 MySQL 优化文章，很有参考价值。

存储也是值得一说的，Fotolog 用的是 SAN，还是比较贵的 SAN: 3Par. 这个产品可能绝大多数 DBA 是比较陌生的，该产品原来主打金融市场，现在也有很多 Web 公司使用，一个比较典型的客户代表是 MySpace。3Par 的最大的特点就是 Thin Provisioning。Thin Provisioning 这个词有的人翻译为\"自动精简配置\"，在维基百科的定

17

义：

Thin provisioningis a mechanism that applies to large-scale centralized computer disk storage systems, SANs, and storage virtualization systems. Thin provisioning allows space to be easily allocated to servers, on a just-enough and just-in-time basis.

说白了就是对空间分配能够做到\"按需分配\"。有些扯远了。

--EOF--

Digg 网站架构

本篇描述一下 Digg 的网站架构.

国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。--by Fenng

Digg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。

数据库方面，和其他成功的 Web 2.0 站点一样，也是 MySQL，不过 Digg 稍微\"激进\"一点，用 MySQL 5，而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%，写只有 2%，实际的读写比例应该高于这个数字，这应该是 Digg 在前端用 Memcached 以及 APC

18

PHP accelerator / MCache 做缓存后的效果。在 IO 上似乎压力并不大。

数据库分割用 Sharding (分片)的机制。从透露出来的信息看，Digg 数据量并不大，仅仅刚超 30g . 看起来是只存储了一些元数据。至于这个 Sharding 或者 Shard, 其出发点有些类似于数据库的分区，差别可能就是不再一个库上吧，其实都是结合业务和应用来对一些数据对象进行分割。

搜索服务器用的是 Lucene。

进一步阅读：

• Digg Architecture

• How Digg.com uses the LAMP stack to scale upward

• Digg PHP's Scalability and Performance

--EOF--

Amazon 的 Dynamo 架构

我在 DBAnotes.net 上记录过不少比较大的网站架构分析(eg: eBay [1], eBay [2]) ，Amazon 一直找不到太多的资料。国庆期间读到了一篇关于 Amazon Dynamo 的论文，非常精彩。Amazon Dynamo 这个高可用、可扩展存储体系支撑了Amazon 不少核心服务.

19

先看一个示意图:

从上图可以看出，Amazon 的架构是完全的分布式，去中心化。存储层也做到了分布式。

Dynamo 概述

Dynamo 的可扩展性和可用性采用的都比较成熟的技术，数据分区并用改进的一致性哈希(consistent hashing)方式进行复制，利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似 quorum 的机制以及去中心化的复制同步协议。 Dynamo 是完全去中心化的系统，人工管理工作很小。

强调一下 Dynamo 的\"额外\"特点：

20

1) 总是可写

2) 可以根据应用类型优化

关键词

Key: Key 唯一代表一个数据对象，对该数据对象的读写操通过 Key 来完成.

节点(node)：通常是一台自带硬盘的主机。每个节点有三个 Java 写的组件：请求协调器(request coordination)、成员与失败检测、本地持久引擎(local persistence engine)

实例(instance)；每个实例由一组节点组成，从应用的角度看，实例提供 IO 能力。一个实例上的节点可能位于不同的数据中心内, 这样一个数据中心出问题也不会导致数据丢失。

上面提到的本地持久引擎支持不同的存储引擎。Dynamo 上最主要的引擎是 Berkeley Database Transactional Data Store(存储处理数百K的对象更为适合），其他还有 BDB Java Edition、MySQL 以及 一致性内存 Cache 等等。

三个关键参数 (N,R,W)

第一个关键参数是 N，这个 N 指的是数据对象将被复制到 N 台主机上，N 在 Dynamo 实例级别配置，协调器将负责把数据复制到 N-1 个节点上。N 的典型值设置为 3.

复制中的一致性，采用类似于 Quorum 系统的一致性协议实现。这个协议有两个关

21

键值：R 与 W。R 代表一次成功的读取操作中最小参与节点数量，W 代表一次成功的写操作中最小参与节点数量。R + W>N ，则会产生类似 quorum 的效果。该模型中的读(写)延迟由最慢的 R(W)复制决定，为得到比较小的延迟，R 和 W 有的时候的和又设置比 N 小。

(N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性。R 和 W 直接影响性能、扩展性、一致性，如果 W 设置 为 1，则一个实例中只要有一个节点可用，也不会影响写操作，如果 R 设置为 1 ，只要有一个节点可用，也不会影响读请求，R 和 W 值过小则影响一致性，过大也不好，这两个值要平衡。对于这套系统的典型的 SLA 要求 99.9% 的读写操作在 300ms 内完成。

--待续--

财帮子（caibangzi.com）网站架构

财帮子(caibangzi.com) 定位在”基金理财社区\"。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的，且不去管，不可否认的是，目前国内\"理财\"是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。

1.创建人员

创建者有三人。Robin Lu(石锅拌饭)、Meng Yan ( 孟岩 ) ，还有一位\"不写Blog的家伙\"。前两位都是技术人员。很早就看过孟岩 的 Blog，那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的，所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也

22

是工程师，叫赵路，曾经是 Mozilla 项目accessibility模块的module peer.\"

2.服务器信息

Web 服务器用的是 Lighttpd ，出于节省成本的目的，服务器是自行组装的。数据库采用的是 MySQL 5，目前还没有使用 Replication. 正准备扩充服务器，服务器数量...暂且保密一下。

3.统计分析及监控

统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit，\"以及自己写的一些分析 Proc 的脚本\"，再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。

4.优化之路

Robbin 在此前的一篇 财帮子性能优化简报披露：“财帮子两个星期以前，遇到严重的性能问题，最终我们采用了相当非主流的部署方案和打了自己补丁的web server，成功度过了难关”，我很好奇这具体是个什么问题。得到的答案是：“Apache的负载均衡是有问题的，算法太简单了，对Ror的应用来说，会造成某一个app instance的阻塞，从而阻塞了所有的request”。

谈及 Cache 的感慨:

Fenng: ... 我个人感觉你们需要Cache服务器， 这一类的站点内容需要 Cache 的太多

23

Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache，到disk的cache，

再到数据库的cache，架构还不错，否则当前机器撑不住 :)

Fenng: 很多站点扩展作不好，也是Cache没用好

Meng Yan: 是啊，Cache非常重要，非常非常

Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽，命中率非常之高

Meng Yan: 确实，我们的内存cache就是用的memcached，真的很棒

5.挑战

这是就这次采访的最后一个问题。

Fenng:还要采访你一个问题：caibangzi.com 现在运营、开发面临的最大的一个问题是什么?

Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。

6.后记

这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线，到现在已经积

24

累了一定数量的用户，当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是，不要太在乎站点流量，流量本身也是开销)，网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。

这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构，我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息，相对来说，国内站点还是比较保守，各自闷头折腾。为什么不换个角度，分享、借鉴、壮大，这个方式不也不错麽?

BTW: 如果你有 Web 2.0 站点技术信息要报料，联系我！(要写软文就免了)。

--EOF--

了解一下 Technorati 的后台数据库架构

Technorati (现在被阻尼了, 可能你访问不了)的 Dorion Carroll在 2006 MySQL 用户会议上介绍了一些关于 Technorati 后台数据库架构的情况.

基本情况

目前处理着大约 10Tb 核心数据, 分布在大约 20 台机器上.通过复制, 多增加了 100Tb 数据, 分布在 200 台机器上. 每天增长的数据 1TB. 通过 SOA 的运用, 物理与逻辑的访问相隔离, 似乎消除了数据库的瓶颈. 值得一提的是, 该扩展过程始终是利用普通的硬件与开源软件来完成的. 毕竟 , Web 2.0 站点都不是烧钱的主. 从数据量来看，这绝对是一个相对比较大的 Web 2.0 应用.

25

Tag 是 Technorati 最为重要的数据元素. 爆炸性的 Tag 增长给 Technorati 带来了不小的挑战.

2005 年 1 月的时候, 只有两台数据库服务器, 一主一从. 到了 06 年一月份, 已经是一主一从, 6 台 MyISAM 从数据库用来对付查询, 3 台 MyISAM 用作异步计算.

一些核心的处理方法:

1) 根据实体(tags/posttags))进行分区

衡量数据访问方法，读和写的平衡.然后通过不同的维度进行分区．( Technorati 数据更新不会很多, 否则会成为数据库灾难)

2) 合理利用 InnoDB 与 MyISAM

InnoDB 用于数据完整性/写性能要求比较高的应用. MyISAM 适合进行 OLAP 运算. 物尽其用.

3) MySQL 复制

复制数据到从主数据库到辅数据库上,平衡分布查询与异步计算, 另外一个功能是提供冗余． 如图:

26

后记

拜读了一个藏袍的两篇大做(mixi.jp：使用开源软件搭建的可扩展SNS网站 / FeedBurner:基于MySQL和JAVA的可扩展Web应用) 心痒难当, 顺藤摸瓜, 发现也有文档提及 Technorati , 赶紧照样学习一下. 几篇文档读罢, MySQL 的 可扩展性让我刮目相看.

或许,应该把注意力留一点给 MySQL 了 .

--End.

27