More Related Content
More from fulin tang (15)
毕业设计－Slide
- 2. 高并发高流量网站架构－概要
院系：信息科学学院
专业：计算机科学与技术
学号： 03281077
姓名：唐福林
指导教师：朱小明
- 6. 高并发高流量网站架构－目录
1 引言
2 网络层架构
3 交换层架构
4 服务器优化
5 应用程序层优化
6 扩容、容错处理
7 总结及展望
- 26. 高并发高流量网站架构－服务器程序
APACHE vs. LIGHTTPD
PHP vs. JSP
举例：
百度，新浪，搜狐，网易
−
Google ， Yahoo ， CNN ， AOL
−
- 34. 高并发高流量网站架构－
总结及展望
展望：
Web1.0 : LAMP （ Linux ＋ Apache ＋
−
MySQL ＋
PHP/PERL/PYTHON ）
Web2.0 : 新的解决方案
−
- 35. 高并发高流量网站架构－
总结及展望
Web2.0 : 新的解决方案
透明的第三方 CDN 网络加速服务
−
价格低廉的第四层甚至更高层网络交换设备
−
优化了网络性能的操作系统
−
优化了读写性能，分布式，高可靠的文件系统
−
揉合了内存，硬盘等各个级别缓存的 HTTP 服务器
−
更为高效的服务器端脚本解析器
−
封装了大部分细节的应用层设计框架。
−
- 36. 高并发高流量网站架构－致谢
朱小明老师
信息科学学院
北京师范大学
新浪网研发中心
新浪爱问 http://iask.com
−
新浪播客 http://v.blog.sina.com
−
家人及朋友们
- 37. 高并发高流量网站架构－提问
Please feel free to
question anything!
Papers, slides and more information linked to:
http://www.fulin.org/paper/
- 38. 高并 发高流 量网站 架构
唐福林 03281077
申请北京师范大学学士学位
各位老师，大家好！我的论文题目是《高并发高流量网站架构》
- 39. 高并发高流量网站架构－概要
院系：信息科学学院
专业：计算机科学与技术
学号： 03281077
姓名：唐福林
指导教师：朱小明
首先我向大家概要的介绍一下我自己及这篇论文的一些情况。我是北京师范大学
信息科学学院计算机科学与技术系 03 级学生唐福林，这篇《高并发高流量网站架
构》是我的毕业论文，是在信息学院朱小明老师的指导下完成的。
- 40. 高并发高流量网站架构－背景
Web2.0 给网站带来的新特点和要求
用户内容
高并发
高流量
新浪播客
经验教训
《高并发高流量网站架构》这个题目的提出，是我在新浪公司实习的过程中，参
与了真实的大型网站——爱问视频和新浪播客，的开发，在如何架构一个具有
Web2.0 特点的网站方面，积累了一定的经验，希望以毕业论文的形式，将自己的
一些经验和感悟进行系统的整理，总结及提高，抽象出普遍适用的一套架构及解
决方案，与大家分享。
网络技术的发展， Web2.0 的兴起，掀起了互联网新一轮的网络创业大潮，也给
网站建设提出了新的挑战。 Web2.0 的典型特点是，网站只是提供一个平台，所有
的内容由用户参与生成和传播。这类的网站包括博客（新浪博客，
LiveJournal ），播客（ YouTube ，新浪播客），相册（网易相册， flickr ），
社会化书签（ del.icio.us ，百度搜藏），以及 Feed 托管
（ feedburner ， feedsky ）等等。这些网站在建设过程中都遇到了一些相同的技
术问题，如高并发——不同于传统网站，如新浪新闻，用户只是在浏览一些静态
的网页，这些网站的用户在生成内容的时候，如上传照片，视频，写博客等，需
要长时间，多次的连接网站服务器，即使在同样数目的用户情况下， web2.0 网站
也会比传统网站承受多的多的并发量。还有高流量问题，随着网络的发展，上网
人数的急剧增加，一个成功的 web2.0 网站，或者说任何一个成功的网站，需要承
受的流量压力比十年前要大的多。以著名的 Feed 托管网站 FeedBurner 为例，到
2006 年 4 月份，它的流量已经到了 115Mbps ，每天点击量一亿次。我的论文中引
用的数据是 2000 年 5 月的 Yahoo 声称其日页浏览数达到 6 亿 2500 万。
这样的一些新的特点和要求都需要一个好的网站架构来支撑。网上可以找到一些
从某一个或几个方面来解决如何增加服务器或服务器集群的负载能力，处理能力
及对大规模数据的适应能力的文章，但很少见到从架构的高度来阐述和整合的。
因为 web2.0 兴起的时间并不长，而且大都是一些商业公司在运作，成熟的架构解
决方案很少公开，前赴后继的建设者们都只能依靠自己摸索和尝试来解决问题。
作者在此希望通过自己的一些不成熟的想法抛砖引玉，为以后的成熟方案的提出
，做一些奠基工作。
- 41. 高并发高流量网站架构－摘要
首先在整个网络的高度讨论了使用镜像网站， CDN 内容分发
网络等技术对负载均衡带来的便利及各自的优缺点比较。然
后在局域网层次对第四层交换技术，包括硬件解决方案 F5 和
软件解决方案 LVS ，进行了简单的讨论。接下来在单服务器
层次，本文着重讨论了单台服务器的 So cket 优化，硬盘级
缓存技术，内存级缓存技术， CPU 与 IO 平衡技术（即以运算
为主的程序与以数据读写为主的程序搭配部署），读写分离
技术等。在应用层，本文介绍了一些大型网站常用的技术，
以及选择使用该技术的理由。最后，在架构的高度讨论了网
站扩容，容错等问题。
文章。。。
- 43. 高并发高流量网站架构－目录
1 引言
2 网络层架构
3 交换层架构
4 服务器优化
5 应用程序层优化
6 扩容、容错处理
7 总结及展望
这是论文的目录，大致也是按照刚刚描述的数据的流动顺序来组织内容的。
- 45. 高并发高流量网站架构－网络层
镜像网站
CDN 内容分发网络
应用层分布式设计
网络层指的是在整个互联网络的层次，可以使用镜像网站，内容分发网络，及应
用层分布式设计等方法，来提升网站的访问速度
- 46. 高并发高流量网站架构－网络层
镜像网站
− 原理
− 不足
镜像网站是指将一个完全相同的站点放到几个服务器上，分别有自己的 URL ，这
些服务器上的网站互相称为镜像网站。镜像网站和主站并没有太大差别，或者可
以视为主站的拷贝。镜像网站的好处是：如果不能对主站作正常访问（如服务器
故障，网络故障或者网速太慢等），仍能通过镜像服务器获得服务。不便之处是
：更新网站内容的时候，需要同时更新多个服务器；需要用户记忆超过一个网址
，或需要用户选择访问多个镜像网站中的一个，而用户选择的，不一定是最优的
。在用户选择的过程中，缺乏必要的可控性。
当前一些大型的软件下载站，因为符合镜像网站的条件——下载的内容是静态的
，更新频率较低，对带宽，速度要求又比较高，所以还在使用这种技术。图为在
SourceForg 上下载软件的时候，弹出对话框让用户选择从哪个镜像上下载。
9
- 47. 高并发高流量网站架构－网络层
CDN 内容分发网络
− 原理
− 不足
CDN 的全称是 Content Delivery Network ，即内容分发网络，它是通过在现有的
互联网中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘
”，使用户可以就近取得所需的内容，分散服务器的压力，提高用户访问网站的
响应速度。 CDN 与镜像网站技术的不同之处在于网站代替用户去选择最优的内容
服务器，增强了可控制性。
CDN 其实是夹在网页浏览者和被访问的服务器中间的一层镜像或者说缓存，浏览
者访问时点击的还是服务器原来的 URL 地址，但是看到的内容其实是对浏览者来
说最优的一台镜像服务器上的页面缓存内容。这是通过调整服务器的域名解析来
实现的。使用 CDN 技术的域名解析服务器需要维护一个镜像服务器列表和一份来
访 IP 到镜像服务器的对应表。当一个用户的请求到来的时候，根据用户的 IP ，
查询对应表，得到最优的镜像服务器的 IP 地址，返回给用户。这里的最优，需要
综合考虑服务器的处理能力，带宽，离访问者的距离远近等因素。当某个地方的
镜像网站流量过大，带宽消耗过快，或者出现服务器，网络等故障的时候，可以
很方便的设置将用户的访问转到另外一个地方。这样就增强了可控制性。
CDN 网络加速技术也有它的局限性。首先，内容更新的时候，依然需要同步更新
多台镜像服务器；其次， DNS 解析有缓存，当某一个镜像网站的访问需要转移时
，主 DNS 服务器更改了 IP 解析结果，但各地的 DNS 服务器缓存更新会滞后一段
时间，这段时间内用户的访问仍然会指向该服务器，可控制性依然有不足。
目前，国内访问量较高的大型网站如新浪、网易等的资讯频道，均使用 CDN 网络
加速技术。但论坛，邮箱等更新频繁，实时性要求高的频道，则不适合使用这种
技术。
10
- 48. 高并发高流量网站架构－网络层
应用层分布式设计
− 原理
− 不足
应用层分布式设计是指为了增强可控性，同时保留 CDN 的速度优势，在应用层程
序上进行分布式设计的办法。
举例说明，新浪播客在应用层软件设计上，采取了这样一个办法。新浪播客提供
了一个供播放器查询视频文件地址的接口。当用户打开视频播放页面的时候，播
放器首先连接查询接口，通过接口获得视频文件所在的最优的镜像服务器地址，
然后再到该服务器去下载视频文件。这样，用一次额外的查询获得了全部的控制
性，而这次查询的通讯流量非常小，几乎可以忽略不计。 CDN 中由域名解析获得
的灵活性也保留了下来：由接口程序维护镜像网站列表及来访 IP 到镜像网站的对
应表即可。镜像网站中不需要镜像所有的内容，而是只镜像更新速度较慢的视频
文件。这是完全可以承受的。
应用层的这种设计只适合用在用户不需要记忆 URL 地址的场合，而且它给网站的
开发和维护增加了很大的工作量
11
- 50. 高并发高流量网站架构－交换层
第四层交换
− 原理
− 硬件实现： F5 ， Alteon
− 软件实现： LVS
第四层交换指的是传输不仅仅依据 MAC 地址 ( 第二层网桥 ) 或源 / 目标 IP 地址
( 第三层路由 ) ，而且依据 IP 地址与 TCP/UDP ( 第四层 ) 应用端口号的组合
（ Socket ）。第四层交换功能就像是虚拟 IP （ VIP ），指向一台或多台实际的
服务器。
当用户请求页面时，一个带有目标服务器组的 VIP 连接请求发送给第四层交换机
。第四层交换机使用某种选择策略，在组中选取最优的服务器，将数据包中的目
标 VIP 地址用实际服务器的 IP 地址取代，并将连接请求传给该服务器。第四层交
换一般都实现了会话保持功能，即同一会话的所有的包由第四层交换机进行映射
后，在用户和同一服务器间进行传输。
第四层交换按实现方法可以分为硬件实现和软件实现。
硬件实现一般都由专业的硬件厂商作为商业解决方案提供，它们都非常昂贵，但
是能够提供非常优秀的性能和很灵活的管理能力
软件实现性能比专业硬件稍差，但是满足一定量的压力还是可以达到的，而且软
件实现配置起来更灵活。 软件四层交换常用的有 Linux 上的 LVS （ Linux
Virtual Server ），它提供了基于心跳（ heart beat ）的实时灾难应对解决方案
，提高了系统的鲁棒性，同时提供了灵活的 VIP 配置和管理功能，可以同时满足
多种应用需求
- 52. 高并发高流量网站架构－服务器层
整体性能优化
SOCKET 优化
CPU 与 IO 均衡
读写分离
在服务器层，文章讨论了以下问题
- 53. 高并发高流量网站架构－服务器层
整体性能优化
− 影响性能的因素
− 瓶颈的定义
常见的影响服务器的处理速度的因素有：网络连接，硬盘读写，内存空间， CPU
速度等。
服务器的某一个部件如果满负荷运转仍然低于需要，而其他部件能力还有剩余，
我们将低于需要的部件称为性能瓶颈。
服务器想要发挥最大的功效，关键的是消除瓶颈，让所有的部件都被充分的利用
起来。
16
- 54. 高并发高流量网站架构－服务器层
SOCKET 优化
− 起因
− 优化方法
操作系统的默认设置是为了适应各种部署情况，对于某种特定的硬件环境，网络
环境很可能不是最优化的。
以 linux 为例， GNU/Linux 提供了很多可调节的内核参数，这些选项包含在
/proc 虚拟文件系统中。这个文件系统中的每个文件都表示一个或多个参数，它
们可以通过 cat 工具进行读取，或使用 echo 命令进行修改
论文中列举了几个我自己经历过的参数优化，在这里就不详细说明了。
17
- 55. 高并发高流量网站架构－服务器层
CPU 与 IO 均衡
− 举例
− 不足
在一个网站提供的所有功能中，有的功能可能需要消耗大量的服务器端 IO 资源，
像下载，视频播放等，而有的功能则可能需要消耗大量的服务器 CPU 资源，像视
频格式转换， LOG 统计等。在一个服务器集群中，当我们发现某些机器上 CPU 和
IO 的利用率相差很大的时候，例如 CPU 负载很高而 IO 负责很低，我们可以考虑
将该服务器上的某些耗 CPU 资源的进程换成耗 IO 的进程，以达到均衡的目的。均
衡每一台机器的 CPU 和 IO 消耗，不仅可以获得更充分的服务器资源利用，而且还
能够支持暂时的过载，遇到突发事件，访问流量剧增的时候，实现得体的性能下
降 (Graceful performance degradation) ［ 34 ］，而不是立即崩溃。
它的不足在于，程序部署如果不是按照逻辑模块进行划分的话，会给日后的维护
带来很大的麻烦。例如一台前台页面服务器遭受攻击死机了，如果上面还跑着一
个 log 分析程序，那么这个 log 分析程序也会受到影响。
18
- 56. 高并发高流量网站架构－服务器层
读写分离
− RAID
− 文件系统 EXT3 vs ReiserFS
为了分离读与写操作，在 Linux 下可以使用软件 RAID-0 （磁盘冗余阵列 0 级）
。 RAID-0 在获得硬盘 IO 提升的同时，也会增加整个文件系统的故障率——它等
于 RAID 中所有驱动器的故障率之和。如果需要保持或提高硬盘的容错能力，就
需要实现软件 RAID-1 ， 4 或 5 ，它们能在某一个（甚至几个）磁盘驱动器故障之
后仍然保持整个文件系统的正常运行，但文件读写效率不如 RAID-0 。而专门用
来读的硬盘，则不用如此麻烦，可以使用普通的服务器硬盘，以降低开销。
ReiserFS 是基于平衡树的文件系统结构，尤其对于大量文件的巨型文件系统，搜
索速度要比使用局部的二分查找法的 ext3 快。 ReiserFS 里的目录是完全动态分
配的，因此不存在 ext3 中常见的无法回收巨型目录占用的磁盘空间的情况。
ReiserFS 里小文件（ <4K ）可以直接存储进树，小文件读取和写入的速度更快，
树内节点是按字节对齐的，多个小文件可共享同一个硬盘块，节约大量空间。
ext3 使用固定大小的块分配策略，也就是说，不到 4K 的小文件也要占据 4K 的空
间，导致的空间浪费比较严重。
不足：但 ReiserFS 对很多 Linux 内核支持的不是很好，包括 2.4.3 、 2.4.9 甚至
相对较新的 2.4.16 ，如果网站想要使用它，就必须要安装与它配合的较好的 2.4.18
内核，还有 ReiserFS 每次升级都必须重新格式化整个硬盘。八卦： Hans Reiser
涉嫌谋杀入狱
如果我们需要写很多的小文件，可以选择 ReiserFS ，如果只读和存储，则选择
EXT3
19
- 58. 高并发高流量网站架构－硬盘缓存
SQUID
− 简介
− 算法
− 集群
− 不足
Squid 是一个高性能的代理缓存服务器。和一般的代理缓存软件不同， Squid 用
一个单独的、非模块化的、 I/O 驱动的进程来处理所有的客户端请求
Squid 默认通过检测 HTTP 协议头的 Expires 和 Cache-Control 字段来决定缓存
的时间， Squid 运行的时候，默认会在硬盘上建两层 hash 目录，用来存
储缓存的 Object 。它还会在内存中建立一个 Hash Table ，用来记录硬盘中
Object 分布的情况。如果 Squid 配置成为一个 Squid 集群中的一个的话，它还会
建立一个 Digest Table( 摘要表 ) ，用来存储其它 Squid 上的 Object 摘要。。
在硬盘空间快要达到配置限额的时候，可以配置使用某种策略（默认使用 LRU ：
Least Recently Used- 最近最少用）删除一些 Object ，从而腾出空间
Squid 处理 TCP 连接的能力要比 web 服务器强大的的多，它唯一的不足就是配置
非常的复杂，但默认配置的 Squid ，没有经过任何优化的时候，一般可以达到
50% 的命中率。如果需要，还可以通过参数优化，拆分业务，优化文件系统等办
法，使得 Squid 达到 90% 以上的缓存命中率
图为某服务器使用 MRTG 工具检测到的 Squid 命中率
蓝线表示 Squid 的流量，绿色部分表示 Apache 流量
- 60. 高并发高流量网站架构－内存缓存
MEMCACHED
− 简介
− 算法
− 集群
− 不足
Memcached 是 danga.com （运营 Live Journal ［ 32 ］的技术团队）开发的一套非
常优秀的分布式内存对象缓存系统，用于在动态系统中减少数据库负载，提升性
能。
Memcached 是以守护程序方式运行于一个或多个服务器中，随时接受客户端的连
接操作，客户端可以由各种语言编写，目前已知的客户端 API 包括
Perl/PHP/Python/Ruby/Java/C#/C 等等。客户端首先与 Memcached 服务建立
连接，然后存取对象。每个被存取的对象都有一个唯一的标识符 key ，存取操
作均通过这个 key 进行，保存的时候还可以设置有效期。保存在 Memcached
中的对象实际上是放置在内存中的，而不是在硬盘上。 Memcached 进程运行之后
，会预申请一块较大的内存空间，自己进行管理，用完之后再申请一块，而不是
每次需要的时候去向操作系统申请。 Memcached 将对象保存在一个巨大的 Hash 表
中，它还使用 NewHash 算法来管理 Hash 表，从而获得进一步的性能提升。所以
当分配给 Memcached 的内存足够大的时候， Memcached 的时间消耗基本上只是网
络 Socket 连接了。
Memcached 最吸引人的一个特性就是支持分布式部署；也就是说可以在一群机器
上建立一堆 Memcached 服务，每个服务可以根据具体服务器的硬件配置使用不
同大小的内存块，这样，理论上可以建立一个无限大的基于内存的缓存系统。
Memcached 也有它的不足。首先它的数据是保存在内存当中的，一旦服务进程重
启（进程意外被关掉，机器重启等），数据会全部丢失。其次 Memcached 以 root
权限运行，而且 Memcached 本身没有任何权限管理和认证功能，安全性不足。第
一条是 Memcached 作为内存缓存服务使用无法避免的，当然，如果内存中的数据
需要保存，可以采取更改 Memcached 的源代码，增加定期写入硬盘的功能（这里
补充说明一下，我在新浪实习的时候就做过这个，朱老师在审阅论文的时候，提
出附录一些代码，以突出自己做的工作。但这部分代码作为商业机密，公司不允
许对外发表，所以我只好附录了 Memcached 的 php 客户端包装，因为这部分也是
我做的，而且不算机密）。对于第二条，我们可以将 emcached 服务绑定在内网
IP 上，通过 Linux 防火墙进行防护。
- 61. 高并发高流量网站架构－
应用程序层
网站服务器端程序的选择
数据库选择
可配置性和封装思想
在讨论了服务器的优化和各个层次的缓存之后，论文接下来对服务器端运行的服
务程序的选择，数据库的选择及可配置性和封装思想进行了讨论
- 63. 高并发高流量网站架构－服务器程序
APACHE vs. LIGHTTPD
PHP vs. JSP
举例：
百度，新浪，搜狐，网易
−
Google ， Yahoo ， CNN ， AOL
−
Apache 是开源界的首选 Web 服务器，因为它的强大和可靠，而且适用于绝大部分
的应用场合。但是它的强大有时候却显得笨重，配置文件复杂得让人望而生畏，
高并发情况下效率不太高。而轻量级的 Web 服务器 Lighttpd 却是后起之秀，基于
单进程多路复用技术，其静态文件的响应能力远高于 Apache 。有论文提出的
Lighttpd->Squid->Apache 处理链，效率是很高，但配置起来太过复杂。一般的
建议是，将应用按模块拆分，然后根据各个模块的特点灵活的选择服务器。
脚本语言选择一般在 php 或 jsp 。它们之间的比较这里就不展开来说了。我们举
几个例子
Google ： python 之父
Yahoo ： php 之父
- 65. 高并发高流量网站架构－数据库
MySQL
− 简介
− 优势
− 集群
− 不足
MySQL 是一个快速的、多线程、多用户和健壮的 SQL 数据库服务器，支持关键任
务、重负载系统的使用，是最受欢迎的开源数据库管理系统，是 Linux 下网站开
发的首选
因为 MySQL 的高性能，开放和易用，几乎绝大部分的新兴网站都选择了 MySQL 作
为它们的存储数据库引擎。每年的 mysql 开发者大会，总是能给人耳目一新的感
觉，譬如 2006 年， Technorati 的架构师向大家介绍了他们使用 MySQL 处理分布
在大约 20 台机器上的 10Tb 核心数据，通过冗余复制，增加到了 200 台机器
上的 100Tb ，每天增长 1TB 的数据的经验。
MySQL 有一个用于记录数据改变的二进制日志。因为它是二进制的，这一日志能
够快速地将数据的更改从一台机器复制（ replication ）到另一台机器上。即使
服务器崩溃，这一二进制日志也能够保持完整。这一特性通常被用来搭建数据库
集群，以支持更大的流量访问要求
MySQL 还是一个开发中的数据库引擎，它还缺乏一些企业级的特性，如触发器，
参照完整性等。但随着开发者的不断努力，相信这些特性在不久的将来就能得到
实现
- 66. 高并发高流量网站架构－
应用程序层
可配置性和封装思想
方便管理
−
方便扩容
−
方便容错
−
在大型网站开发过程中，不管使用什么技术，网站的可配置性是必须的。在网站
的后期运营过程中，肯定会有很多的需求变更。如果每一次的需求变更都会导致
修改源代码，那么，这个网站的开发可以说是失败的。
29
- 67. 高并发高流量网站架构－
扩容与容错
扩容
− 存储
− 数据库
− 前台
− 应用程序
讨论完了用户请求数据的流动过程以后，文章还从架构的高度讨论了网站的扩容
和容错问题。
以新浪播客为例，扩容包括四个层次的扩容：
存储：新浪播客在主存储服务器上，采用配置文件形式指定每一个存储盘柜上存
储的视频文件的 ID 范围。当前台服务器需要读取一个视频的时候，首先通过询问
主存储服务器上的接口获得该视频所在的盘柜及目录地址，然后再去该盘柜读取
实际的视频文件。这样如果需要增加存储用的盘柜，只需要修改配置文件即可，
前台程序丝毫不受影响。
数据库：新浪播客采用 MySQL 数据库集群，在逻辑层封装了所有的数据库连接及
操作。当数据库存储架构发生改变的时候，如增加一台主库，将某些数据表独立
成库，增加读取数据用的从库等，都只需要修改封装了的数据库操作类，上层代
码不用修改。
前台：新浪播客的前台页面服务器使用 F5 公司的硬件第四层交换机，网通，电
信分别导向不同的虚拟 IP ，每一个虚拟 IP 后面又有多个服务器提供服务。当访
问流量增大的时候，可以很方便往虚拟 IP 后面增加服务器，分担压力。
应用程序：新浪播客的应用程序都根据配置文件与系统的其他部分交换数据，当
增加服务器的时候，只需要正确设置配置文件即可
- 68. 高并发高流量网站架构－
扩容与容错
容错
− 存储
− 数据库
− 前台
− 应用程序
容错包括同样的四个层次：
存储：存储容错主要是针对写入服务器，，可以使用 RAID （冗余磁盘阵列），
定期离线备份
数据库：数据库（主要是负责写入的主库），可以采用双主库设计，也要定期离
线备份
提供服务的前台，则可以使用第四层交换的集群，由多台服务器同时提供服务，
不仅分担了流量压力，同时还可以互相作为备份。
在应用层程序中，也要考虑“用户友好”的出错设计。典型例子如 HTTP 404 出
错页面，程序内部错误处理，错误返回提示等，尽可能的做到人性化。
- 71. 高并发高流量网站架构－
总结及展望
展望：
Web1.0 : LAMP （ Linux ＋ Apache ＋
−
MySQL ＋
PHP/PERL/PYTHON ）
Web2.0 : 新的解决方案
−
针对一般的中小网站，当前 Linux 环境下有著名的 LAMP （ Linux ＋ Apache ＋
MySQL ＋ PHP/PERL/PYTHON ）网站建设方案。
但对于高并发高流量的大型商业网站，还没有一个完整的，性价比高的解决方案
。除去服务器，硬盘，带宽等硬件投资外，网站建设者们还需要花费大量的预算
和时间精力在软件解决方案上。
- 72. 高并发高流量网站架构－
总结及展望
Web2.0 : 新的解决方案
透明的第三方 CDN 网络加速服务
−
价格低廉的第四层甚至更高层网络交换设备
−
优化了网络性能的操作系统
−
优化了读写性能，分布式，高可靠的文件系统
−
揉合了内存，硬盘等各个级别缓存的 HTTP 服务器
−
更为高效的服务器端脚本解析器
−
封装了大部分细节的应用层设计框架。
−
随着互联网的持续发展， Web2.0 的兴起，在可以预见的未来里，互联网的用户持
续增多，提供用户参与的网站不断增加，用户参与的内容日益增长，越来越多的
网站的并发量，访问量会达到一个新的高度，这就会促使越来越多的个人，公司
以及研究机构来关注高并发高流量的网站架构问题。就像 Web1.0 成就了无数中小
网站，成就了 LAMP 一样， Web2.0 注定也会成就一个新的，高效的，成本较低的
解决方案。
技术的进步永无止境。我们期待互联网更为美好的明天。
35
- 73. 高并发高流量网站架构－致谢
朱小明老师
信息科学学院
北京师范大学
新浪网研发中心
新浪爱问 http://iask.com
−
新浪播客 http://v.blog.sina.com
−
家人及朋友们
最后，我希望能非常诚挚的对在论文写作过程中给予我悉心指导的朱小明老师说
声谢谢，同时感谢信息科学学院的老师们在这四年来教会我的专业的知识和做人
的道理，感谢北京师范大学的所有的老师，同学们，我们一起在“学为人师，行
为世范”的校训下度过了这难忘的四年，完成了成长最后的蜕变。
本文在写作的过程中得到了新浪公司的大力支持，有来自新浪播客，新浪爱问搜
索的多位同事对文中的架构方案，技术细节等提供了非常有用的建议，在此一并
感谢！
最后，感谢在我生命的过程中一直毫无保留的支持我的家人和朋友！
谢谢！
- 74. 高并发高流量网站架构－提问
Please feel free to
question anything!
Papers, slides and more information linked to:
http://www.fulin.org/paper/
下面是提问时间。
