百万级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万登录次数。而项目团队有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产生数以千计的并发用户访问实验 室的服务器。这样就可以在实验环境中与真实场景非常接近。

转自:http://blog.wangjunfeng.com.cn/index.php/archives/126

时间: 2024-10-08 05:01:54

百万级PHP网站架构工具箱的相关文章

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

观《亿级流量网站架构核心技术》一书有感

本文的架子参考张开套的<亿级流量网站架构核心技术>这本书分为四个部分:指导原则,高可用,高并发,实践案例.这篇文章说一说前三个部分,大部分内容都是我自己的思考,书只作为参考. 指导原则 高可用 事前 副本技术 隔离技术 配额技术 探知技术 预案 事发 监控和报警 事中 降级 回滚 failXXX系列 事后 高并发 提高处理速度 缓存 异步 增加处理人手 多线程 扩容 指导原则 书中所列举的,里有一些可能并不是原则,而是技巧.我理解的原则如下: 高并发原则: 无状态设计:因为有状态可能涉及锁操作

百万级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个开发人员,两个设计,两个系

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

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

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

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

千万级PV网站架构

1 架构背景 CleverCode了解了一下架构.现在的情况是:一共约有50台服务器,安装的服务nginx,mysql,memcached,squid,solor等. 现在日均纯PHP访问的PV是2500万,最高峰值可以抗住5000万访问. 以下只列出来一些常用域名,部分访问域名未列出来,其中的机器也只列出来部分. 2 架构原理图 3 架构原理说明 3.1 LVS部分 1)首先让所有的域名都通过DNS指向211.181.168.168.211.181.168.168是一个外网IP.对于LVS结构