百万级PHP网站Poppen.de的架构分享心得

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

  Poppen.de目前有200万注册用户数,而项目团队有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%以上。

  程序代码是基于Symfony 1.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产生数以千计的并发用户访问实验 室的服务器。这样就可以在实验环境中与真实场景非常接近。

时间: 2024-08-29 23:09:29

百万级PHP网站Poppen.de的架构分享心得的相关文章

百万级PHP网站架构工具箱

在了解过世界最大的PHP站点,Facebook的后台技术后,今天我们来了解一个百万级PHP站点的网站架构:Poppen.de. Poppen.de是德国的一个社交网站,相对Facebook.Flickr来说是一个很小的网站,但它有一个很好的架构,融合了很多技术,如 Nigix.MySql.CouchDB.Erlang.Memcached.RabbitMQ.PHP.Graphite.Red5以及Tsung. Poppen.de目前有200万注册用户数.2万并发用户数.每天20万条私有消息.每天25

百万级访问网站前期的技术准备

开了自己域名的博客,第一篇就得来个重磅一点的才对得起这4美金的域名.作为一个技术从业者十年,逛了十年发现有些知识东一榔头西一棒槌的得满世界看个遍才整理出个头绪,那咱就系统点的从头一步一步的说,一个从日几千访问的小小网站,到日访问一两百万的小网站,怎么才能让它平滑的度过这个阶段,别在技术上出现先天不足,写给一些技术人员,也写给不懂技术的创业者. 转载请注明出自 http://zhiyi.us ,假如您还想从这转到好文章的话. 对互联网有了解的人都有自己的想法,有人就把想法付诸实现,做个网站然后开始

【转】一份发表于2010年左右的百万级访问量网站的技术准备工作

注:本篇从InfoQ上转载而来,作者 刘志一,如有侵权请联系本博主,会立马删除. 本文是5年前发布在InfoQ网站的一篇文章,现在看起来,虽然部分工具已经过时,但作者的思路以及部分方案还是有很多可以参考的地方. 5年,IT领域已经发生了翻天覆地的变化,不妨看看这篇文章,想想5年时间,哪些工具或者框架已经被淘汰,哪些当初不确定的概念,到现在已经落地. 如果你有你的感悟,欢迎私信我(微信greenguolei),我们一起聊聊,这5年,IT领域发生了哪些有意思的事情. 当今从纯网站技术上来说,因为开源

设计千万级用户量网站的高并发架构!!!

(1)单块架构 网站开始建立时,用户少 , 网站架构都是用单体架构设计,共部署3台服务器,1台应用,1台数据库,1台图片. 1.应用服务器上发布,可能是把应用服务器上的Tomcat给关掉,替换系统的代码war包,重新启动Tomcat. 2.数据库服务器,存全部核心数据. 3.网络文件系统(NFS)作图片服务器,存网站全部图片.应用服务器上代码会连接以及操作数据库以及图片服务器. 如下图所示: 但是这种纯单块系统架构下,有高可用问题存在,最大的问题就是应用服务器可能会故障,或者是数据库可能会故障

从100PV到1亿级PV网站架构演变

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 一个网站就像一个人,存在一个从小到大的过程.养一个网站和养一个人一样,不同时期需要不同的方法,不同的方法下有共同的原则.本文结合我自已14年网站人的经历记录一些架构演变中的体会. 1:积累是必不可少的 架构师不是一天练成的. 1999年,我作了一个个人主页,在学校内的虚拟空间,参加了一次主页大赛,几个DREAMWEAVER的页面,几个TABLE作布局,一个DB连接,几行PHP的代码嵌入在HT

从100PV到1亿级PV网站架构演变(转)

http://www.linuxde.net/2013/05/13581.html 一个网站就像一个人,存在一个从小到大的过程.养一个网站和养一个人一样,不同时期需要不同的方法,不同的方法下有共同的原则.本文结合我自已14年网站人的经历记录一些架构演变中的体会. 积累是必不可少的 架构师不是一天练成的. 1999年,我作了一个个人主页,在学校内的虚拟空间,参加了一次主页大赛,几个DREAMWEAVER的页面,几个TABLE作布局,一个DB连接,几行PHP的代码嵌入在HTML中,再用ftp传到服务

关于亿级流量网站架构一书缓存机制的探讨

在京东的亿级流量网站架构一书,175页介绍缓存有这样一段话 仅就这段代码来看,在高并发情况下,实际上并不能阻止大量线程调用loadSync函数 当然这个书里的代码是作者的简写,这里探讨只是针对书中这段代码,实际生成代码应该有考虑这个问题,另外loadSync函数的逻辑看不到,也可能有考虑到到这个问题. 这中情况应该使用双锁,另外firstCreateNewEntry也应该是定义为volatile类型.还有如果是分布式缓存,针对远程客户端的回源请求应该要设置一个时限,比如30秒内只受理一个回源请求

从0到千万级访问量网站架构演变史

从0到千万级访问量网站架构演变史 read it later. 架构演变第一步:物理分离webserver和数据库最 开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候已 经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这 个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问

谈谈运行稳定性好效率高的千万级大型网站系统架构性分析

千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题. 数据库海量数据处理:负载量不大的情况下select.delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题.另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的.索引和更新是一对天生的冤家. 高并发死锁:平时我们感觉不到,但数据库死锁在高并发的