PHP搭建百万级网站架构技术揭秘

 

在了解过世界最大的PHP站点,Facebook的后台技术后,今天我们来了解一个百万级PHP站点的网站架构:Poppen.de。Poppen.de是德国的一个社交网站,相对Facebook、Flickr来说是一个很小的网站,但它有一个很好的架构,融合了很多技术,如 Nigix、MySql、CouchDB、Erlang、Memcached、RabbitMQ、PHP、Graphite、Red5以及Tsung。

统计信息

◆200万注册用户数;

◆2万并发用户数;

◆每天20万条私有消息;

◆每天25万登录次数;

◆项目团队有11个开发人员,两个设计,两个系统管理员;

商业模式

该网站采用免费增值模式,用户可以免费使用下面任何服务:

◆搜索其他用户;

◆给好友发送消息;

◆上载图片和视频;

◆寻找好友;

◆视频聊天;

◆更多…

但如果用户想享受不受限制发送消息和上载图片,那么就得根据需要支付不同类型的会员服务,视频聊天及网站其他服务也采用同样的策略。

工具箱

Nginx

Poppen.de 所有的服务都是基于Nginx服务上的。前端有两台Nginx服务器在高峰期提供每分钟15万次请求的负载,每个机器已经有四年寿命,并且只有一个CPU 和3GB RAM。Poppen.de拥有三台独立的图像服务器,由三台Nginx服务器为*.bilder.poppen.de提供每分钟8万次请求服务。

Nginx 架构中一个很酷的设计就是有很多请求是由Memcached处理的,因此请求从缓存中获取内容而不需要直接访问PHP机器。比如,用户信息页(user profile)是网站需要密集处理的内容,如果把用户信息页全部缓存到Memcached上,那么请求直接从Memcached上获取内容。 Poppen.de的Memcached每分钟可以处理8000次请求。

架 构中有三个Nginx图像服务器提供本地图像缓存,用户上载图 像到一个中央文件服务器。当向这三个Nginx之一中请求图像时,如果服务器本地中没有存在该图像,则从中央文件服务器下载到该服务器上作缓存并提供服 务。这种负载均衡的分布式图像服务器架构设计可以减轻主要存储设备的负载。

PHP-FPM

该网站运行在PHP- FPM上。共有28台双CPU、6GB内存的PHP机器,每个机器上运行100个PHP-FPM的工作线程。使用启用了APC的PHP5.3.x。 PHP5.3可以降低CPU和内存使用率的30%以上。

程 序代码是基于Symfony1.2框架之上开发的。一是可以使用外部资源,二是 能够提高项目开发进度,同时在一个著名的框架上可以让新开发人员更容易加入到团队中来。虽然没有任何事情都是十全十美的,但可以从Symfony框架中得 到很多好处,让团队可以更多的精力放在Poppen.de的业务开发上去。

网站性能优化使用XHProf,这是Facebook开源出来的一个类库。这个框架非常容易个性化和配置,能够可以缓存大部分高代价的服务器计算。

MySQL

MySQL 是网站 主要的RDBMS。网站又几个MySql服务器:一台4CPU、32GB的服务器存储用户相关信息,如基本信息、照片描述信息等。这台机器已经使用了4 年,下一步计划会使用共享集群来替换它。目前仍基于这个系统上进行设计,以简化数据访问代码。根据用户ID进行数据分区,因为网站中大部分信息都是以用户 为中心的,如照片、视频、消息等。

有三台服务器按主-从-从配置架构提供用户论坛服务。一台从服务器负责网站自定义消息存储,到现在有 2.5亿条消息。另外四台机器为主-从配置关系。另外由4台机器配置成NDB族群专门服务于密集型写操作数据,如用户访问统计信息。

数 据表设计尽量避免关联操作,尽可能缓存最多的数据。当然,数据库的结构化规范已经完全被破坏掉了。因此,为了更容易搜索,数据库设计创建了数据挖掘表。大 部分表是MyISAM型表,可以提供快速查找。现在的问题是越来越多的表已经全表锁住了。Poppen.de正考虑往XtraDB存储引擎上迁移。

Memcached

网 站架构中Memcached应用相当多,超过45GB的高速缓存和51个节点。缓存了Session会话、视图缓存以及函数执行缓存等。架构中有一个系统 当记录被修改时可以自动地把数据更新到缓存中去。未来改善缓存更新的可能方案是使用新的Redis Hash API或者MongoDB。

RabbitMQ

在 2009年中开始在架构中使用RabbitMQ。这是一个很好的消息解决方案,便于部署和集中到这个架构中去,在LVS后运行了两台RabbitMQ服务 器。在上个月,已经把更多的东西集成到该队列中,意味着同一时刻有28台PHP服务器每天要处理50万次请求。发送日志、邮件通知、系统消息、图像上载等 更多的东西到这个队列中。

应用PHP-FPM中的fastcgi_finish_request()函数集成队列消息,可以把消息异步发 送到队列中。当系统需要给用户发送HTML或JSON格式响应时,就调用这个函数,这样用户就没有必要等到PHP脚本清理。

这 个系统可以改善架构资源管理。例如,在高峰期服务每分钟可以处理1000次登录请求。这表示有1000并发更新用户表保存用户的登录时间。由于使用了队列 机制,可以 按相反的顺序来运行这些查询。如果需要提高处理速度,只需要增加更多的队列处理者即可,甚至可以增加更多的服务器到这集群中去,而不需要修改任何配置和部 署新节点。

CouchDB

日 志存储CouchDB运行在一台机器上。在这台机器上可以根据模块/行为进行日志查询 /分组,或者根据错误类型等等。这对定位问题非常有用。在使用日志聚合服务CouchDB之前,不得不逐台登录到PHP服务器上设法日志分析定位问题,这 是非常麻烦的。而现在把所有的日志集中到队列中保存到CouchDB中,可以集中进行问题检查和分析。

Graphite

网 站使用Graphite采集网站实时信息并统计。从请求每个模块/行为到Memcached的命中和未命中、RabbitMQ状态监控以及Unix负载等 等。Graphite服务平均每分钟有4800次更新操作。实践已经证实要监测网站发发生什么是非常有用的,它的简单文本协议和绘图功能可以方便地即插即 用的方式用于任何需要监控的系统上。

一件很酷的事情是使用Graphite同时监控了网站的两个版本。一月份部署了Symfony框架新 版本,以前代码作为一个备份部署。这就意味着网站可能会面临性能问题。因此可以使用Graphite来对两个版本在线进行对比。

发现新版本上的Unix负载表较高,于是使用XHProf对两个版本进行性能分析,找出问题所在。

Red5

网站为用户也提供了两种类型的视频服务,一种是用户自己上载的视频,另外一种是视频聊天,用户视频互动和分享。到2009年年中,每月为用户提供17TB的流量服务。

Tsung

Tsung 是一个Erlang编写的分布式基准分析工具。在Poppen.de网站中主要用于HTTP基准分析、MySQL与其他存储系统(XtraDB)的对比分 析。用一个系统记录了主要的MySQL服务器的流量,再转换成Tsung的基准会话。然后对该流量进行回放,由Tsung产生数以千计的并发用户访问实验 室的服务器。这样就可以在实验环境中与真实场景非常接近。

淘宝网架构师岳旭强的谈网站架构

摘要: “一场危机赢得高度关注的时候,它已经不是危机,人们是要处理这个危机。”——马云 2009年是挑战和机遇并存的一年,对大部分人来说,已经习惯了金融危机,并努力解决危机。在技术圈子也一样,被裁员的肯定也找到了工作,所以都在踏实做技术。言归正传,先念叨念叨2009年…

一场危机赢得高度关注的时候,它已经不是危机,人们是要处理这个危机。”——马云

2009年是挑战和机遇并存的一年,对大部分人来说,已经习惯了金融危机,并努力解决危机。在技术圈子也一样,被裁员的肯定也找到了工作,所以都在踏实做技术。言归正传,先念叨念叨2009年的一些故事,寻个回忆,找个乐子。

数据扩展性探讨和总结

金融危机是电子商务的机遇,所以09年是淘宝高速发展的一年。当一个网站从百万、千万记录的数据规模,增长到亿、十亿、几十亿记录的数据规模时,是 一个量变到质变的过程,单纯的硬件升级已经达到了瓶颈,而需要在整体结构上做文章。09年一年,大部分时间都在数据的扩展性上努力。

对于一个电子商务网站来讲,订单是最核心的数据,也是增长最快的数据。对于数据的扩展性来讲,最传统也是最简单有效的模式是数据库的分库分表。当订 单和分库分表相遇,会有什么火花迸发出来?09年初碰撞了很久,结果产生的火花很小。最大的问题在于数据分割的规则,无规则的水平分割肯定会带来数据合并 的开销,而按照业务规则拆分,会因为买家和卖家的查询需求不同而导致数据不能分割,唯一可行的火花是把订单双份保存,买家卖家各自一份,只是成本比较高, 而且对数据同步的要求非常高。

于是我们初步决定按照双份保存的方式拆分订单,而有一天,仔细查看了订单访问的情况,发现订单数据库90%以上的压力来自于查询,而查询中90%以上的压力来自于非核心业务,仅仅是订单数据的展现,对一致性和实时性的要求很低。

因为数据量大,造成数据库压力大,天然想到的是分散压力,其办法就是分库分表。有些时候我们想问题不妨直接一点,既然压力大,能不能减小压力呢?通 过对订单访问情况的了解,发现昂贵的主数据库,有80%以上的压力给了不重要的需求,这个就是我们优化的关键,所以订单最后采用了读写分离的方案,高成本 的主数据库解决事务和重要的查询业务,80%以上不重要的读,交给了低成本的数据库服务器来解决,同时对数据复制的要求也很低,实现无太大难度。

另外一个有意思的案例是商品的数据扩容,商品的水平分割非常容易,按照卖家进行拆分即可。有了订单的先例,首先想到了读写分离,因为成本可以做低。 开始实施后一段时间,又仔细回想了一下商品的整体需求,突然发现商品其实不需要和订单同等的要求,一定要采用高成本的主数据库吗? 全部采用低成本的普通服务器来做数据库是否可行?经过仔细的评估,发现是可以接受的,而这样就导致之前已经启动的商品读写分离项目的一部分工作白做了!

故事讲完了总是要有点总结,来点虚的先:对于原始需求的清晰了解是系统决策的前提,否则弯路肯定要走,而对原始需求的了解并不容易,中间会有很多干 扰和阻力,前面的实例看起来很简单,但是在一个运行了5年的系统上来了解本质,来进行变更,并没那么容易。另外,经验有些时候会成为系统决策的障碍,这个 很矛盾,所以需要有归零的心态来思考问题。说到底,回归本源。

再来点稍微实际一点的,对于大型分布式系统的数据访问,一个统一的数据层是非常必要的,封装水平、垂直的数据分割,封装读写分离,封装数据访问的路 由、复制、合并、搬迁、热点处理等功能,并且要对应用透明,应用针对性的,可以在JDBC层面包装,数据库针对性的,可以在数据库协议层包装,比如 Amoeba。

关注系统和人的交互

还有一个故事,在数据层的前期版本,为了做到透明的路由,曾经采用无SQL的方式,所有的数据库访问都是写代码来做。上线后发现一个非常痛苦的问 题,无法和SQL对应,排错非常难。曾经一次DBA发现数据库上一个查询耗费太多资源,把优化后的SQL给开发人员改进,开发人员好几天没找到具体是哪个 查询。

另外一个在2009年的感触是业界服务化的实施情况,很多组织都在实施服务化,系统层面都很成功,通信、负载均衡、消息系统、服务容器等都有很多成 果,但是实施一段时间以后的效果并不是非常好,依赖复杂,变更混乱,效率低下。究其根本,是对人的关注不够,缺少的产品化的服务运维,缺少服务治理。

上面的两个例子都是对人的关注缺失,技术人员做系统,大部分都更关注技术,而忽视技术的创造者和使用者——人。软件或服务的可测试性是对测试人员的 关注、可维护性和可管理性是对运维人员的关注,而一个框架的易用性是对所有使用人员的关注。除非能做出自己进化的Skynet(注:Skynet(天网)出现在《终结者》系列电影中,是一个人类于20世纪后期创造的以计算机为基础的人工智能防御系统,最初是研究用于军事的发展。),否则还是要多关注系统和人的交互。

关注可用性

还有一个感触是业界对可用性这个基本指标的关注度不够。几乎所有的框架都会说自己的扩展性多高,性能多好,而很少会提到监控有多强、排错有多容易, 很少提到在故障时怎么做隔离,怎么做降级;从这个角度看,商用的产品确实做得好很多;关于性能相关的文章搜索一下,很多,各种优化策略,各种优化方法,而 可用性方面,找到的系统性的知识真的很少;希望是我了解的不多。

回顾过去,展望未来。2010年,很多可以做的事情,面向服务系统的隔离和降级、系统可维护性的提高、协程和异步模式在web应用的全面使用……

免责声明:我很现实,为解决问题和完成工作不择手段,并且不懂架构是什么意思,以上观点如有雷同,纯属巧合!如有异议,欢迎拍砖!


个人简介:岳旭强,淘宝网技术专家。2004年加入淘宝,见证了淘宝网业务以及技术上完整的发展过程;在过去 5年的时间中,参与了淘宝几乎所有核心系统改造,并主导了用来支撑淘宝网未来高速发展的核心业务中心的建设。岳旭强现在负责网站整体业务架构的设计和规 划,在大型交易网站的设计和调优方面有丰富的经验。

本文来自:http://www.infoq.com/cn/articles/yuexuqiang-share-outlook

 

架构师谈高性能大型网站架构设计

本文作者根据自己多年系统架构师的工作经验,讨论了高性能大型网站架构设计的几个关键技术。

笔者在Cernet做过拨号接入平台的搭建,而后在Yahoo3721负载搜索引擎前端平台开发,又在猫扑处理过大型社区猫扑大杂烩的架构升级等工 作,同时自己接触和开发过不少大中型网站的模块,因此在大型网站应对高负载和并发的解决方案上有一些积累和经验,可以和大家一起探讨一下。

一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站 对系统架构设计、性能的要求都很简单,随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所 采用的技术更是涉及面非常广,从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态 网站所能比拟的。

大型网站,比如门户网站。在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几个环节:使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面,还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入,并且这样的解决思路具备瓶颈,没有很好的扩展性,下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

1、HTML静态化
其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最 有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的 新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管 理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。

同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如 论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑 将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。

2、图片服务器分离
大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网 站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的网站架构设计可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不 会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可 能少的LoadModule,保证更高的系统消耗和执行效率。

3、数据库集群和库表散列
大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常 用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面 或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这 样的网站架构设计,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的 配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存
缓存一词搞技术的都接触过,很多地方用到缓存。大型网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大 型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多 了,.net不是很熟悉,相信也肯定有。

5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异,比如ChinaNet和 EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新。在镜像的细节技术方面,这里不阐述太深,有很多专业的现 成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如Linux上的rsync等工具。

6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,我个人接触过一些解决方法,其中有两个架构可以给大家做参考。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是 虚 IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上,需要复杂的 载量平衡算法。在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决 定。
在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换
大家知道了硬件四层交换机的原理后,基于OSI模型来实现的软件四层交换也就应运而生,这样的解决方案实现的原理一致,不过性能稍差。但是满足一定量的压力还是游刃有余的,有人说软件实现方式其实更灵活,处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决,LVS就是Linux Virtual Server,他提供了基于心跳线heartbeat的实时灾难应对解决方案,提高系统的鲁棒性,同时可供了灵活的虚拟VIP配置和管理功能,可以同时满 足多种应用需求,这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。

对于大型网站来说,前面提到的每个方法可能都会被同时使用到,我这里介绍得比较浅显,具体实现过程中很多细节还需要大家慢慢熟悉和体会,有时一个很小的squid参数或者apache参数设置,对于系统性能的影响就会很大,希望大家一起讨论,达到抛砖引玉之效。

讨论大型高并发负载网站的系统架构问题,作者提出了几点建议:
1. HTML静态化,这可以通过CMS自动实现;
2. 图片服务器分离(类似的,在视频网站中,视频文件也应独立出来);
3. 数据库集群和库表散列,Oracle、MySQL等DBMS都有完美的支持;
4. 缓存,比如使用Apache的Squid模块,或者是开发语言的缓存模块,;
5. 网站镜像;
6. 负载均衡。
作 者将负载均衡称为“是大型网站解决高负荷访问和大量并发请求采用的终极解决办法”,并提出“一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的 基础上搭建squid集群”。在实践时可以考虑建立应用服务器集群和Web服务器集群,应用服务器集群可以采用Apache+Tomcat集群和 WebLogic集群等,Web服务器集群可以用反向代理,也可以用NAT的方式,或者多域名解析均可。

从提升网站性能的角度出发, 静态资源不应和应用服务器放在一起,数据库服务器也应尽量独立开来。在典型的MVC模式中,由谁来完成数据逻辑处理的,对系统性能有着至关重要的影响。以 Java EE为例,在OO的设计思想中,我们强调系统的抽象、重用、可维护性,强调下层的更改不会扩散到上层逻辑,强调系统移植的便捷性,因而往往存在一种过分抽 象的问题,比如在Hibernate的基础上再加入一层DAO的设计。另外一方面,却会忽视利用DBMS本身的优秀特性(存储过程、触发器)来完成高效的 数据处理。诚然,如果客户要求将数据从Oracle移植到MySQL,那么DBMS特性的东西越少,移植便越容易。但事实上,在实践中,提出类似移植要求 的情况非常少见,因此在做网站架构设计时,不一定为了这种潜在的需求而大幅牺牲系统的性能与稳定性。此外,我不建议采用分布式数据库管理结构,这样带来的 开销 太大,数据维护也是个头痛的问题,尽可能采用集中式的数据管理。

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

在HTML静态化方面,如果是对于更新相对较少的页面,可以这样处理,例如新闻、社区通告、或者类似与淘宝网的产品分类信息。但若数据更新频繁,这样做的意义便不大。

网站镜像是个传统的技术,更高级的应用来自流媒体领域的CDN(Content Delivery Network),CDN的概念可以由流媒体数据扩展到图片、视频文件等静态资源的传输。不过,在电子商务领域,很少有这样的应用。

开源平台的高并发集群思考
目前碰到的高并发应用,需要高性能需求的主要是两个方面

网络负载均衡的几个办法
1。代理模式:代理服务器只管收发包,收到包以后转给后面的应用服务器群(服务器群后可能还会有一堆堆的数据库服务器等等),并且把返回的结果再返回给请求端
2。虚拟代理ip:代理服务器收发包还负载太高,那就增加多台代理服务器,都来管包的转发。这些代理服务器可以用统一的虚拟ip,也可以单独的ip
3。p2p:一些广播的数据可以p2p的模式来减轻服务器的网络压力
数据库(指mysql)单机的处理
1。数据库本身结构的设计优化(分表,分记录,目的在于保证每个表的记录数在可定的范围内)
2。sql语句的优化
3。master + slave模式
数据库集群的处理
1。master + slave模式 (可有效地处理并发查询)
2。mysql cluster 模式 (可有效地处理并发数据变化)

来源:http://blog.csdn.net/SmartTony