大型网站架构技术方案集锦-具体内容讲解
大型网站架构技术方案集锦-具体内容
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，因为数据变化过快，很快就过期。我不知道这是因为https://www.wendangku.net/doc/be4117794.html, 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了30% 的CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。
负载均衡
微软Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对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--
YouTube 的架构扩展
在西雅图扩展性的技术研讨会上，YouTube 的Cuong Do 做了关于YouTube Scalability的报告。视频内容在Google Video 上有(地址)，可惜国内用户看不到。
Kyle Cordes对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)
简单的说YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日PV 超过1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有https://www.wendangku.net/doc/be4117794.html, 有这个规模. 但技术上和YouTube 就没法子比了.
Web 服务器
YouTube 出于开发速度的考虑，大部分代码都是Python 开发的。Web 服务器有部分是Apache，用FastCGI 模式。对于视频内容则用Lighttpd。据我所知，MySpace 也有部分服务器用Lighttpd ，但量不大。YouTube 是Lighttpd 最成功的案例。(国内用Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)
视频
视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个Web 页面上更是有多个，每秒钟因为这个带来的磁盘IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对Cache 和OS 做了部分优化。另一方面，缩略图请求的压力导致Lighttpd 性能下降。通过Hack Lighttpd 增加更多的worker 线程很大程度解决了问题。而最新的解决方案是起用了Google 的BigTable，这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。
出于冗余的考虑，每个视频文件放在一组迷你Cluster 上，所谓"迷你Cluster" 就是一组具有相同内容的服务器。最火的视频放在CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和Google 风格倒是一致。至于维护手段，也都是常见的工具，如rsync, SSH 等，只不过人家更手熟罢了。
数据库
YouTube 用MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到SWAP 颠簸的问题，解决办法是删掉了SWAP 分区! 管用。
最初的DB 只有10 块硬盘，RAID 10 ，后来追加了一组RAID 1。够省的。这一波Web 2.0 公司很少有用Oracle 的(我知道的只有Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者ID 上做文章,应用程序控制查找机制)
YouTube 也用Memcached.
很想了解一下国内Web 2.0 网站的数据信息,有谁可以提供一点?
--EOF--
WikiPedia 技术架构学习分享
维基百科(https://www.wendangku.net/doc/be4117794.html,)位列世界十大网站，目前排名第八位。这是开放的力量。
来点直接的数据：
?峰值每秒钟3万个HTTP 请求
?每秒钟3G bit 流量, 近乎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 的内容性质决定的--面向各个国家，各个地域。
负载均衡：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--
Tailrank 网站架构
每天数以千万计的Blog 内容中，实时的热点是什么? Tailrank这个Web 2.0 Startup 致力于回答这个问题。
专门爆料网站架构的Todd Hoff对Kevin Burton进行了采访。于是我们能了解一下Tailrank 架构的一些信息。每小时索引2400 万的Blog 与Feed，内容处理能力为160-200Mbps，IO 写入大约在10-15MBps。每个月要处理52T 之多的原始数据。Tailrank 所用的爬虫现在已经成为一个独立产品：spinn3r。
服务器硬件
目前大约15 台服务器，CPU 是64 位的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 所用的大部分工具都是开放的。
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的后边还有计算服务器来计算用户间的关系图的。
问题出来了，如何保证数据在各个RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。
第一个方式是用Timestamp . 对记录设置一个字段，标记最新更新时间。这个解决方法还是不错的---除了有个难以容忍的缺陷。什么问题？就是Timestamp 是SQL调用发起的时间，而不是Commit 的确切时间。步调就不一致喽。
第二个办法，用Oracle 的ORA_ROWSCN (还好是Oracle 10g). 这个伪列包含Commit 时候的SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个SCN 列，默认值"无限大"。然后用选择比某个SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。
ORA_ROWSCN 是Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的Wealink、联络家等站点是如何解决这个关系图的计算的呢?
--EOF--
一点题外话：我的LinkedIn Profile (Mail : dbanotes@https://www.wendangku.net/doc/be4117794.html,). Keep in Touch!。另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~
Yahoo！社区架构
旧金山举行的QCon会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站"晒架构"也是个比较过瘾的事情。请参观并收藏这个页面：Architectures you've always wondered about。
eBay 的架构和去年相比基本是换汤不换药，倒是Yahoo! 的Ian Flint(这位老兄是Bix 的运营总监. Bix 已被雅虎收购) 这个PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思，披露了一些鲜为人知的信息。
Yahoo! 社区包括我们比较熟悉的https://www.wendangku.net/doc/be4117794.html,、Flickr、Yahoo!群组、Yahoo! Mail、Bix 等。相当于Yahoo！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。
架构特点
有两点值得注意：1）层次化2）模块化。这也是大规模作业下的比较经济的途径。
软件架构
首先是操作系统已经从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 架构：
这里面居然部署了Oracle RAC，用来存储Mail 服务相关的Meta 数据。非常有趣。
运营维护
监控工具主要用的是Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过Ymon 来做到。网管上针对SNMP 的解决方案是用Yahoo！自己Y 字头的Ywatch。这些Y 字头的东西基本上外
面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用Drraw 展现。Drraw 是基于RRDtool 的Web 展现工具。
应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到Ywatch 中心控制台。
Note: 上面所有截图版权都属于Ian (Image COPYRIGHT@IAN) 。如果去看那个PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。
--EOF--
Craigslist 的数据库架构
(插播一则新闻：竞拍这本《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 的能力，数据库都使用64 位Linux 服务器, 14 块本地磁盘(72*14=1T ?), 16G 内存。
不同的服务使用不同方式的数据库集群。
论坛
1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到17G。最大的表接近4200 万行。
分类信息
1 主1
2 从。Slave 各有个的用途. 当前数据包括索引有114 G , 最大表有5600 万行(该表数据会定期归档)。使用myIsam。分类信息量有多大? "Craigslist每月新增的帖子近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--
https://www.wendangku.net/doc/be4117794.html, 的技术信息拾零
尽管是世界上最大的图片服务网站, https://www.wendangku.net/doc/be4117794.html, 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起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_64 来做到。详细信息可以参考Sun 站点上的这篇MySQL 优化文章，很有参考价值。
存储也是值得一说的，Fotolog 用的是SAN，还是比较贵的SAN: 3Par. 这个产品可能绝大多数DBA 是比较陌生的，该产品原来主打金融市场，现在也有很多Web 公司使用，一个比较典型的客户代表是MySpace。3Par 的最大的特点就是Thin Provisioning。Thin Provisioning 这个词有的人翻译为"自动精简配置"，在维基百科的定义：
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 PHP accelerator / MCache 做缓存后的效果。在IO 上似乎压力并不大。
数据库分割用Sharding (分片)的机制。从透露出来的信息看，Digg 数据量并不大，仅仅刚超30g . 看起来是只存储了一些元数据。至于这个Sharding 或者Shard, 其出发点
有些类似于数据库的分区，差别可能就是不再一个库上吧，其实都是结合业务和应用来对一些数据对象进行分割。
搜索服务器用的是Lucene。
进一步阅读：
?Digg Architecture
?How https://www.wendangku.net/doc/be4117794.html, uses the LAMP stack to scale upward
?Digg PHP's Scalability and Performance
--EOF--
Amazon 的Dynamo 架构
我在https://www.wendangku.net/doc/be4117794.html,上记录过不少比较大的网站架构分析(eg: eBay [1], eBay [2]) ，Amazon 一直找不到太多的资料。国庆期间读到了一篇关于Amazon Dynamo 的论文，非常精彩。Amazon Dynamo 这个高可用、可扩展存储体系支撑了Amazon 不少核心服务.
先看一个示意图:
从上图可以看出，Amazon 的架构是完全的分布式，去中心化。存储层也做到了分布式。Dynamo 概述
Dynamo 的可扩展性和可用性采用的都比较成熟的技术，数据分区并用改进的一致性哈希(consistent hashing)方式进行复制，利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似quorum 的机制以及去中心化的复制同步协议。Dynamo 是完全去中心化的系统，人工管理工作很小。
强调一下Dynamo 的"额外"特点：
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 系统的一致性协议实现。这个协议有两个关键值：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 内完成。
--待续--
财帮子（https://www.wendangku.net/doc/be4117794.html,）网站架构
财帮子(https://www.wendangku.net/doc/be4117794.html,)定位在”基金理财社区"。是国内访问量最大的基于Ruby on rails 的startup 项目。“理财”这个词据说是光大银行发明的，且不去管，不可否认的是，目前国内"理财"是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。
1.创建人员
创建者有三人。Robin Lu(石锅拌饭)、Meng Yan ( 孟岩)，还有一位"不写Blog的家伙"。前两位都是技术人员。很早就看过孟岩的Blog，那时候他还在Sun。Robin Lu 的Blog 也一直在我的订阅列表中的，所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师，叫赵路，曾经是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 的太多Meng Yan: ...Web 2.0网站的cache 非常重要。我们从Mem的cache，到disk的cache，
再到数据库的cache，架构还不错，否则当前机器撑不住:)
Fenng: 很多站点扩展作不好，也是Cache没用好
Meng Yan: 是啊，Cache非常重要，非常非常
Fenng: 豆瓣的阿北说他们Memcached 用的非常爽，命中率非常之高
Meng Yan: 确实，我们的内存cache就是用的memcached，真的很棒
5.挑战
这是就这次采访的最后一个问题。
Fenng:还要采访你一个问题：https://www.wendangku.net/doc/be4117794.html, 现在运营、开发面临的最大的一个问题是什么?
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。
6.后记
这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线，到现在已经积累了一定数量的用户，当然不是十全十美的(我个人就感觉应该提供更多的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 应用.
Tag 是Technorati 最为重要的数据元素. 爆炸性的Tag 增长给Technorati 带来了不小的挑战.
2005 年1 月的时候, 只有两台数据库服务器, 一主一从. 到了06 年一月份, 已经是一主一从, 6 台MyISAM 从数据库用来对付查询, 3 台MyISAM 用作异步计算.
一些核心的处理方法:
1) 根据实体(tags/posttags))进行分区
衡量数据访问方法，读和写的平衡.然后通过不同的维度进行分区．( Technorati 数据更新不会很多, 否则会成为数据库灾难)
2) 合理利用InnoDB 与MyISAM
InnoDB 用于数据完整性/写性能要求比较高的应用. MyISAM 适合进行OLAP 运算. 物尽其用.
3) MySQL 复制
复制数据到从主数据库到辅数据库上,平衡分布查询与异步计算, 另外一个功能是提供冗余．如图:
后记
拜读了一个藏袍的两篇大做(mixi.jp：使用开源软件搭建的可扩展SNS网站/ FeedBurner:基于MySQL和JAVA的可扩展Web应用) 心痒难当, 顺藤摸瓜, 发现也有文档提及Technorati , 赶紧照样学习一下. 几篇文档读罢, MySQL 的可扩展性让我刮目相看.
或许,应该把注意力留一点给MySQL 了 .
--End.