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

大型网站架构技术方案集锦 -具体内容 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 状态 ( 我没有用过这玩意儿，不能确认 ) ，价格也不便宜，而且复杂；网络负载均 衡对 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 的架构扩展 1 在西雅图扩展性的技术研讨会 上， YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有 ( 地址 ) ，可惜国内用户看不到。 Kyle Cordes 对这个视频中的内容做了 介绍 。里面有不少技术性的内容。值得分享一下。 (Kyle Cordes 的介绍是本文的主要来源 ) 简单的说 YouTube 的数据流量 , 一天的 YouTube 流量相当于发送 750 亿封电子邮件 ., 2006 年中就有消息说每日 PV 超过 1 亿,现在 ? 更夸张了 , 每天有 10 亿次下载以及 6,5000 次上传 , 真假姑且不论 , 的确是超乎寻常的海量 . 国内的互联网应用 , 但从数据量 来看 , 怕是只有 51.com 有这个规模 . 但技术上和 YouTube 就没法子比了 . Web 服务器 YouTube 出于开发速度的考虑， 大部分代码都是 Python 开发的。 Web 服务器有部分是 Apache ， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知， MySpace 也 有部分服务器用 Lighttpd ，但量不大。 YouTube 是 Lighttpd 最成功的案例。 ( 国内用 Lighttpd 站点不多， 豆瓣 用的比较舒服。 by Fenng ) 视频 视频的缩略图 (Thumbnails) 给服务器带来了很大的挑战。 每个视频平均有 4 个缩略图， 而 每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。 YouTube 技 术人员启用了单独的服务器群组来承担这个压力， 并且针对 Cache 和 OS 做了部分优化。 另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Li