大型网站架构技术方案集锦具体内容讲解.docx

1、大型网站架构技术方案集锦具体内容讲解大型网站架构技术方案集锦-具体内容PlentyOfFish 网站架构学习采取 Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值 10 亿，估计要让很多人眼热，更何况 Markus Frind 每天只用两个小时打理网站-可操作性很强嘛。之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西，会啥用啥

2、。就这样，也能支撑 超过 3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。带宽与CPUPlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache，因为数据变化过快，很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了 30% 的 CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。负载均衡微软 Windows 网

3、络负载均衡(Network Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对 Windows 架构的站点又是必须-IIS 的总连接数是有限制的。PlentyOfFish 用的是 ServerIron (Conf Refer)，ServerIron 使用简单，而且功能比 NLB 更丰富。 数据库一共三台 SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器。因为 Cache没啥用，所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好

4、，越简单越好，这是常识，不过不是每个人都体会那么深而已。微软好不容易找到了一个宣传案例，所以在 Channel 9 上有一个 PlentyOfFish 的访谈。PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。-EOF-YouTube 的架构扩展在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。Kyle Cordes 对这个视频中的内容

5、做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)简单的说 YouTube 的数据流量, 一天的YouTube流量相当于发送750亿封电子邮件., 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,每天有10亿次下载以及6,5000次上传, 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 有这个规模. 但技术上和 YouTube 就没法子比了.Web 服务器YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式

6、。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)视频视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Ligh

7、ttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 迷你 Cluster 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些漏网的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。数据库YouTube 用 MySQL

8、存储元数据-用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是分区,这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)YouTube 也用 Memcached.很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点

9、 ?-EOF-WikiPedia 技术架构学习分享维基百科(WikiPedia.org)位列世界十大网站，目前排名第八位。这是开放的力量。来点直接的数据： 峰值每秒钟3万个 HTTP 请求 每秒钟 3Gbit 流量, 近乎375MB 350 台 PC 服务器(数据来源)架构示意图如下：Copy Mark BergsmaGeoDNS在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? A 40-line patch for BIND to add geographical filters support to the existent views in BIND, 把用户

10、带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的-面向各个国家，各个地域。负载均衡：LVSWikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.图片服务器:LighttpdLighttpd 现在成了准标准图片服务器配置了。不多说。Wiki 软件: MediaWiki对 MediaWiki 的应用层优化细化得快到极致了。用开销相对比较小的方法定位代码热点，参见实时性能报告，瓶颈在哪里，看这样的图树展示

11、一目了然。另外一个十分值得重视的经验是，尽可能抛弃复杂的算法、代价昂贵的查询，以及可能带来过度开销的 MediaWiki 特性。 Cache! Cache! Cache!维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。 数据库: MySQLMediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术

12、上的常见的一些扩展方案他们也在使用。 复制、读写分离.应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。参考文档：Wikimedia architecture （PDF)Todd Hoff 的文章-EOF-Tailrank 网站架构每天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。专门爆料网站架构的 Todd Hoff 对 Kevin Burton 进行了采访。于

13、是我们能了解一下 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

14、，Squid 做反向代理服务器。数据库Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB， 数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些 多核模式下互斥锁的问题(This Bug?)。到数据库的JDBC 驱动连接池用 lbpool 做负载均衡。MySQL Slave 或者 Master的复制用 MySQLSlaveSync 来轻松完成。不过即使这样，还要花费 20 的时间来折腾 DB。其他开放的软件任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针对 Java 程序的 Benchmark 用

15、 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。Tailrank 的一个比较大的竞争对手是 Techmeme，虽然二者暂时看面向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank 离预期目标还差的很远。期待罗马早日建成。-EOF-LinkedIn 架构笔记现在是 SNS 的春天，最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal 黑帮 成员创建的。在最近一个季度，有两个 We

16、b 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 会员来自海外(中国用户不少，也包括我).开篇明义，直接说这个

17、议题不讲监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候，关系数据库有些不合时宜，而把数据放到内存里进行计算就是必经之路。具体一点说，LinkedIn 的基本模式是这样的：前台应用服务器面向用户，中间是DB，而DB的后边还有计算服务器来计算用户间的关系图的。问题出来了，如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。第一个方式是用 Timestamp . 对记

18、录设置一个字段，标记最新更新时间。这个解决方法还是不错的-除了有个难以容忍的缺陷。什么问题？就是 Timestamp 是 SQL调用发起的时间，而不是 Commit 的确切时间。步调就不一致喽。第二个办法，用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个 SCN 列，默认值无限大。然后用选择比某个 S

19、CN 大的值就可以界定需要的数据扔到计算服务器的内存里。ORA_ROWSCN 是 Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢? -EOF-一点题外话：我的 LinkedIn Profile (Mail : dbanotes). Keep in Touch!。另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他 Yahoo！社区架构旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站晒架构也是个比较过瘾的事情。请参观并收藏

20、这个页面：Architectures youve 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！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游

21、戏的运营有些相近。架构特点有两点值得注意：1）层次化 2）模块化。这也是大规模作业下的比较经济的途径。软件架构首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux，这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle，构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon（监控），还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于

22、Yapache，请参考我以前写的 Yapache-Yahoo! Apache 的秘密这是 Bix 与 DB 有关的部署架构: 数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了)，通过快照复制到其他数据中心。Yahoo! Mail 架构：这里面居然部署了 Oracle RAC，用来存储 Mail 服务相关的 Meta 数据。非常有趣。运营维护监控工具主要用的是 Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo！自己 Y 字头的 Ywa

23、tch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。Note: 上面所有截图版权都属于 Ian (Image COPYRIGHTIAN) 。如果去看那个 PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。-EOF-Craigslist 的数据库架构(插播一则新闻：竞拍这本Dont Make Me Think，我

24、出价 RMB 85，留言的不算-不会有恶意竞拍的吧? 要 Ping 过去才可以，失败一次，再来)Craigslist 绝对是互联网的一个传奇公司。根据以前的一则报道：每月超过 1000 万人使用该站服务，月浏览量超过 30 亿次，(Craigslist每月新增的帖子近 10 亿条?)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18 名员工(现在可能会多一些了)。Tim Oreilly 采访了 Craigslist 的 Eric Scheide ，于是通过这篇 Database War Stories #5: craigslist 我们能了解一下 Craigslis

25、t 的数据库架构以及数据量信息。数据库软件使用 MySQL 。为充分发挥 MySQL 的能力，数据库都使用 64 位 Linux 服务器, 14 块 本地磁盘(72*14=1T ?), 16G 内存。不同的服务使用不同方式的数据库集群。论坛1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到 17G。最大的表接近 4200 万行。 分类信息1 主 12 从。 Slave 各有个的用途. 当前数据包括索引有 114 G , 最大表有 5600 万行(该表数据会定期归档)。 使用 myIsam。分类信息量有多大? Craigslist每月新增的帖子

26、近 10 亿条，这句话似乎似乎有些夸张，Eric Scheide 说昨日就超过 330000 条数据，如果这样估计的话，每个月的新帖子信息大约在 1 亿多一些。 归档数据库1 主 1 从. 放置所有超过 3 个月的帖子。与分类信息库结构相似但是更大， 数据有 238G， 最大表有 9600 万行。大量使用 Merge 表，便于管理。 搜索数据库4 个 集群用了 16 台服务器。活动的帖子根据 地区/种类划分，并使用 myIsam 全文索引，每个只包含一个子集数据。该索引方案目前还能撑住，未来几年恐怕就不成了。 Authdb1 主 1 从，很小。 目前 Craigslist 在 Alexa 上的

27、排名是 30，上面的数据只是反映采访当时(April 28, 2006)的情况，毕竟，Craigslist 数据量还在每年 200% 的速度增长。Craigslist 采用的数据解决方案从软硬件上来看还是低成本的。优秀的 MySQL 数据库管理员对于 Web 2.0 项目是一个关键因素。-EOF-F 的技术信息拾零尽管是世界上最大的图片服务网站, F 在国内的名气并不是很响亮, 每当提到图片服务, 很多人第一个会想起 Flickr. 但实际上 Fotolog 也的确是很猛的, Alexa 上的排名一直在 Flickr 前面, 目前注册用户超过 1100 万. 而前不久也卖了一个好价钱, 900

28、0 万美金. 算下来的话, 1 个注册用户大约 9 美金. Yupoo 的刘平阳可以偷着算算自己的网站如果卖给老外是怎样一个价格了.在前不久的 MySQL Con 2007 上, Fotolog 的 DBA Farhan Mashraqi 披露了一些技术信息.（PPT下载) 与其他大多数 Web 2.0 公司普遍用 Linux 不同的是, Fotolog 的操作系统用的是 Solaris . Solaris X86 也是免费的, 估计是维护人员更熟悉 Solaris 的操作系统而作出的选择吧.数据库当然是使用 MySQL. 有32 台之多, 最开始的存储引擎是 MyISAM ,后来转向 Inn

29、oDB. 对于 DB HA , 使用 DRBD (介绍)，在 Solaris 上用 MySQL ,有个优化技巧是关于 time(2) 系统调用的，通过调用比 gethrestime() 更快的 gethrtime(3C) 来提高性能。可以通过设置 LD_PRELOAD (32位的平台) 或 LD_PRELOAD_64 来做到。详细信息可以参考Sun 站点上的这篇 MySQL 优化文章，很有参考价值。存储也是值得一说的，Fotolog 用的是 SAN，还是比较贵的 SAN: 3Par. 这个产品可能绝大多数 DBA 是比较陌生的，该产品原来主打金融市场，现在也有很多 Web 公司使用，一个比较典

30、型的客户代表是 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

31、, on a just-enough and just-in-time basis.说白了就是对空间分配能够做到按需分配。有些扯远了。-EOF-Digg 网站架构本篇描述一下 Digg 的网站架构.国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。-by FenngDigg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服

32、务器，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 . 看起来是