高负载网站架构

《高负载网站架构》由会员分享，可在线阅读，更多相关《高负载网站架构（43页珍藏版）》请在金锄头文库上搜索。

1、大型网站的架构设计问题大型网站的架构设计问题 在 CSDN 上看到一篇文章（http:/ HTML 静态化，这可以通过 CMS 自动实现；2. 图片服务器分离（类似的，在视频网站中，视频文件也应独立出来）；3. 数据库集群和库表散列，Oracle、MySQL 等 DBMS 都有完美的支持；4. 缓存，比如使用 Apache 的 Squid 模块，或者是开发语言的缓存模块，；5. 网站镜像；6. 负载均衡。作者将负载均衡称为“是大型网站解决高负荷访问和大量并发请求采用的终极解决办法”，并提出“一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建 squid 集群”。在实践时可以考

2、虑建立应用服务器集群和 Web 服务器集群，应用服务器集群可以采用 Apache+Tomcat 集群和 WebLogic 集群等，Web 服务器集群可以用反向代理，也可以用 NAT 的方式，或者多域名解析均可。从提升网站性能的角度出发，静态资源不应和应用服务器放在一起，数据库服务器也应尽量独立开来。在典型的 MVC 模式中，由谁来完成数据逻辑处理的，对系统性能有着至关重要的影响。以 Java EE 为例，在 OO 的设计思想中，我们强调系统的抽象、重用、可维护性，强调下层的更改不会扩散到上层逻辑，强调系统移植的便捷性，因而往往存在一种过分抽象的问题，比如在 Hibernate 的基础上再加入一

3、层 DAO 的设计。另外一方面，却会忽视利用 DBMS 本身的优秀特性（存储过程、触发器）来完成高效的数据处理。诚然，如果客户要求将数据从 Oracle移植到 MySQL，那么 DBMS 特性的东西越少，移植便越容易。但事实上，在实践中，提出类似移植要求的情况非常少见，因此在做架构设计时，不一定为了这种潜在的需求而大幅牺牲系统的性能与稳定性。此外，我不建议采用分布式数据库管理结构，这样带来的开销太大，数据维护也是个头痛的问题，尽可能采用集中式的数据管理。在商业系统中，算法逻辑本身并不复杂，在这种情况下，程序设计本身的好坏不会对系统的性能造成致命的影响。重要的影响因素反而变为软件系统架构本身。在

4、传统的 CORBA、J2EE、DCOM 等对象模型中，我们看到专家们对分布式对象计算的理论偏好，但实践证明，对象的分布带来的恶劣影响远远胜过其积极意义。这也是现在轻量级的开发框架受推崇的一个重要原因。如果能用简单的，就不要用复杂的，例如能够用 Python、RoR 完成的任务，是否一定要用 Java 来做？我看未必。对于用户来说，他们关心的不是采用什么先进的技术，而是我们提供的产品能否满足他的需求。而且，Python、RoR 这些开发工具已经强大到足以应对大部分网站应用，在各种缓存系统的帮助下，在其他技术的协调配合下，完全能够胜任高负载高并发的网站访问任务。在 HTML 静态化方面，如果是对于

5、更新相对较少的页面，可以这样处理，例如新闻、社区通告、或者类似与淘宝网的产品分类信息。但若数据更新频繁，这样做的意义便不大。网站镜像是个传统的技术，更高级的应用来自流媒体领域的 CDN(Content Delivery Network)，CDN 的概念可以由流媒体数据扩展到图片、视频文件等静态资源的传输。不过，在电子商务领域，很少有这样的应用。开源平台的高并发集群思考开源平台的高并发集群思考 目前碰到的高并发应用，需要高性能需求的主要是两个方面1。网络 2。数据库这两个方面的解决方式其实还是一致的1。充分接近单机的性能瓶颈，自我优化2。单机搞不定的时候(数据传输瓶颈:单位时间内磁盘读写/网络数

6、据包的收发cpu 计算瓶颈)，把负荷分担给多台机器，就是所谓的负载均衡网络方面单机的处理1。底层包收发处理的模式变化(从 select 模式到 epoll / kevent)2。应用模式的变化2.1 应用层包的构造方式2.2 应用协议的实现2.3 包的缓冲模式2.4 单线程到多线程网络负载均衡的几个办法1。代理模式：代理服务器只管收发包，收到包以后转给后面的应用服务器群（服务器群后可能还会有一堆堆的数据库服务器等等），并且把返回的结果再返回给请求端2。虚拟代理 ip：代理服务器收发包还负载太高，那就增加多台代理服务器，都来管包的转发。这些代理服务器可以用统一的虚拟 ip，也可以单独的 ip3。

7、p2p：一些广播的数据可以 p2p 的模式来减轻服务器的网络压力数据库(指 mysql)单机的处理1。数据库本身结构的设计优化（分表，分记录，目的在于保证每个表的记录数在可定的范围内）2。sql 语句的优化3。master + slave 模式数据库集群的处理1。master + slave 模式 （可有效地处理并发查询）2。mysql cluster 模式 （可有效地处理并发数据变化）相关资料：http:/ 时间：30-45 分钟开题：163,sina,sohu 等网站他们有很多应用程序都是 PHP 写的，为什么他们 究竟是如何能做出同时跑几千人甚至上万同时在线应用程序呢? 挑选性能更好 w

8、eb 服务器 o单台 Apache web server 性能的极限 o选用性能更好的 web server TUX,lighttpd,thttpd o动，静文件分开，混合使用 应用程序优化,Cache 的使用和共享 o常见的缓存技术 生成静态文件 对象持久化 serialize TRUNCATE TABLE ad_stats0;这样的操作对 Master 数据库是成功的，但对 Slave 会失败，正确的截断子表方法是： ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2); TRUNCATE TABLE ad_stats0;

9、ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2);解决方案的另外一部分就是我们最常用的水平分割数据库。把最常用的表分出去，单独做集群，例如广告啊，订阅计算啊，第七个问题，问题还真多，主数据库服务器的单点问题。虽然采用了 Master-Slave 模式，但主数据库 Master 和 Slave 都只有一台，当 Master 出问题的时候需要太长的时间进行Myisam 的修复，而 Slave 又无法很快的切换成为 Master。FB 试了好多办法，最终的解决方案好像也不是非常完美。从他们的实验过程来看，并没有

10、试验 Master-Master 的结构，我想 Live Journal 的 Master-Master 方案对他们来说应该有用，当然要实现 Master-Master需要改应用，还有有些麻烦的。第八个问题，停电!芝加哥地区的供电状况看来不是很好，不过不管好不好，做好备份是最重要的，大家各显神通吧。这个 Presentation 好像比较偏重数据库，当然了，谁让这是在 Mysql Con 上的发言，不过总给人一种不过瘾的感觉。另外一个感觉，FB 的 NO 们一直在救火，没有做系统的分析和设计。最后 FB 的运维总监 Joe Kottke 给了四点建议：1、 监控网站数据库负载。2、 “expl

11、ain”所有的 SQL 语句。3、 缓存所有能缓存的东西。4、 归档好代码。最后，FB 用到的软件都不是最新的，够用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。YouTube 的架构扩展的架构扩展flyincat 发布于：2007-07-25 09:23作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】网址：http:/ 在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在

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

13、服务器YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有 部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知， MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成 功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)视频视频视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有 4 个缩略 图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。 YouTube 技术人员启用了

14、单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案 是起用了 Google 的 BigTable，这下子从性能、容错、缓存上都有更好表现。看人 家这收购的，好钢用在了刀刃上。出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 “迷你 Cluster“ 就 是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要 承担一些“漏网“的随即访问即可。YouTube 使用简单、廉

15、价、通用的硬件，这一点和 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-回复(0) |引用(0)|收藏(0)|推荐给朋友|推荐到群组|22次阅读|标签： 系统架构 引用地址：引用地址： http:/ 了解一下了解一下 Technorati 的后台数据库架构的后台数据库架构作者：Fenng | English Version 【可以转载, 转