关于 Poppen.de 的资料统计数据

• 2,000,000用户数
• 20,000并发用户数
• 300,000条私人讯息/每天
• 250,000登录/每天

功能概要

• 用户在线搜索其他用户；
• 站内对方写私人消息；
• 用户上传图片和视频；
• 用户与用户之间的在线视频聊天。

Poppen.de整个网站的技术团队有 11个人开发人员，2个界面设计师和两个系统管理员。

Poppen.de目前有200万注册用户数、2万并发用户数、每天20万条私有消息、每天25万登录次数。而项目团队有11个开发人员，两个设计，两个系统管理员。该站的商业模式采用免费增值模式，用户可以使用搜索用户、给好友发送消息、上载图片和视频等功能。

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

系统架构描述：

Web 层服务器

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之一中请求图像时，如果服务器本地中没有存在该图像，则从中央文件服务器下载到该服务器上作缓存并提供服 务。这种负载均衡的分布式图像服务器架构设计可以减轻主要存储设备的负载。

采用Nginx作为Web App 服务器，2台机器在前端作为www的请求，在高峰的时候每分钟能够处理150.000个用户的请求，并且结合Memcached一起使用，用来缓存一些用户的资料信息。
另外3台Nginx 服务器作为图片服务器的请求 例如:img.bilder.poppen.de (image servers),每分钟处理用户80.000请求,用户通过这3台服务器进行图片的读、写操作，只使用每台服务器的本地缓存，并不通过 Memcached服务器，并且将用户上传的图片信息存放在中央式的文件系统中，估计这样目的是为了减轻主要储存设备的负荷。网站已经这样使用了4年，一 共5台Nginx服务器，每台配置普通32位CPU、3GB RAM 内存。

语言环境

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

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

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

XHProf是一个分层PHP性能分析工具。它报告函数级别的请求次数和各种指标，包括阻塞时间，CPU时间和内存使用情况。一个函数的开销，可细分成调用者和被调用者的开销。原始数据收集部分是用纯C实现的，是一个名叫xhprof的 Zend扩展 。

使用 PHP的5.3 版本 为程序语言运行环境，整个网站使用28台机器作为PHP Ap 服务器，每台机器配置6G内 存。每个机器运行运行100个worker processes， 将运行环境的可选PHP缓存(Alternative PHP Cache, APC)打开, 据说网站透露这样可以提高性能，能够减少 30％的CPU和内存使用率，使用了Symfony1.2版本作为PHP的Web开发框架，可以提高网站开发效率，可快速创建复杂的WEB程序。

缓存(Memcached)

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

网站使用memcached的节点据说有50个总大小超过45 GB，Memcached用来用户会话、个人信息、功能执行中需要的缓存、数据中需要执行like的查询结果的存储，网站对于将来可能会渐渐的采用 MongoDB Hash 的解决方法来进行代替现在大量的使用Memcached的现象，Javabloger个人也认为以为大量的使用Memcached缓存服务器不是明智之 举，因为Memcached的原则就不是给你放什么重要信息和可以长期存放的地方，你见过有人拿超市的存包格当私人的保险柜吗？但一味的使用数据库存储也 不是可取的方法，大量数据库连接/关闭 执行SQL的开销带来的负载是很多机器设备不能接受的，所以使用像 MongoDB 之类的东西 还是比较折中的选择，我们相信将来会有更多的网站会向MongoDB靠拢的。

消息服务器

RabbitMQ 是一个实现了AMQP协议的消息服务器。该版本引入一个全新的插件体系结构，提供更强的扩展性；外提升了集群处理中跨节点消息路由的性能；更严格的 channel.flow 来确保 RabbitMQ 阻止生产者停止发送消息的流程。

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

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

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

整个网站采用的算是一种分布式的异步架构体系，中间采用RabbitMQ作为异步通讯服务器，通过上层28台PHP Ap Server做成的LVS集群对下层2台集群的 RabbitMQ 消息系统进行调用，这里消息系统主要用来发送运行日志，电子邮件通知，系统消息，用户图片上传，每天大约需要处理 500.000条消息，这样的架构体系可以对系统的运行性能有所改善，在Javabloger看一般有3个原因：

• 加强了系统的可扩展性。
• 提高系统资源的使用率。
• 降低系统运行中瞬间的瓶颈。

比如在系统繁忙的时间里，每分钟有1000个用户进行登录,这意味着我们将有1000个并发的用户请求需要对缓存/数据库表的更新，但是现在有了消息队列 的架构，我们可以运行他们每个顺序相反。如果我们需要更多的处理速度，我们可以添加更多的消费者到消息队列，还可以加入更多的机器到MQ消息群集中，不需 要修改以前任何的配置或部署任何新的代码。网站表示系统将来会向异步式架构发展，将更多的业务放入RabbitMQ 系统队列中进行处理。

• RabbitMQ支持AMQP协议，而ZeroMQ的极为简单。
• RabbitMQ较慢，几十个并发以内，延时为几十毫秒，但当客户端达到1000个并发的时候，速度就无法容忍了（参考）；ZeroMQ上则据称可以达到13毫米延时和高达每秒4.1兆次传递（参考, 国内需要翻墙才能访问）。
• 如果队列较多的话，RabbitMQ很容易把内存耗尽，而ZeroMQ则把队列内容保存在发送端。
• JMS仅仅是Java领域内的API规范，只能说AMQP比JMS更先进，它有自己的wire-level protocol 可编程的协议，并且RabbitMQ服务器充分利用了Erlang的分布式、高可靠性、并发等特性，而并不能一概而论的说JMS没有RabbitMQ服务 器好与坏。

分布式文档数据库(CouchDB)

CouchDB 是一个面向文档的数据库管理系统。它提供以 JSON 作为数据格式的 REST 接口来对其进行操作，并可以通过视图来操纵文档的组织和呈现。 CouchDB 也是 Apache 基金会的顶级开源项目。

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

系统中运行CouchDB的服务器只有一台，主要是用来存日志的，因为在过去我们需要查看某台机器的日志需要登录某台机器进行tail -f 的查看，如果机器一多肯定混乱，采用CouchDB 中一些查询方法 query/group 就会让工作简化很多，而且采用分布式文档数据库存放系统日志似乎真的很合理，而且管理，使用也不算很复杂。Javabloger前端时间一个人看管了15 台机器，需要查看日志的时候还真的有点不方便，所以日后会在项目中尝试一下将日志系统进行集中化处理的方案。

数据库服务器

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

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

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

采用MySQL数据库作为网站主要的数据信息存储，有4台MySQL服务器使用基于集群方式NDB表引擎用来存放用户资料和用户相关数据，这组集群每台机 器配置32GB内存 、4个CPU，但是他们打算在将来采用 Sharing的方式根据用户的id来进行水平划分，这样当然有好处，可是这样做了以后需要面对事物和跨库查询的问题，网站还有另外3台MySQL服务器 使用的是 master-slave-slave 架构存放用户在论坛里面的信息，目前数据库表引擎采用的是MyISAM，这样读写会很快，但是会遇到全表锁的问题，所以将来打算使用 XtraDB 引擎进行存储，网站对于查询SQL和建立数据库表结构也进行了多次考虑，为了避免like和join带来的开销，因此创建数据库汇总表，以纾缓用户查询带来压力。

系统监控(Graphite)

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

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

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

Graphite是这个网站一个重要的部分，用来进行收集服务器所有的及时状态，用户请求信息，Memcached命中率，RabbitMQ消息服务器的 状态，Unix操作系统的负载状态，Graphite服务器大约每分钟需要有4800次更新操作，Graphite采用简单的文本协议和绘图功能可以方便 地使用在任何操作系统上。Graphite 是一个Python写的web应用，采用django框架，如果你想尝试一下的话，具体的安装步骤参见：http://graphite.wikidot.com/installation，安装好以后的效果如图所示：

对于具体的PHP程序性能运行的监控是采用Facebook开源出来的一个php性能测试工具，XHProf是一个 分层PHP性能分析工具。它报告函数级别的请求次数和各种指标，包括阻塞时间，CPU时间和内存使用情况。一个函数的开销，可细分成调用者和被调用者的开 销。原始数据收集部分是用纯C实现的，是一个名叫xhprof的 Zend扩展 。XHProf有一个简单的HTML的用户界面（ PHP写成的）。基于浏览器的性能分析用户界面能更容易查看，或是与同行们分享成果。也能绘制调用关系图。如果他们通过 Graphite发现那台Unix负荷高了，将会进一步的使用 XHProf 分析器进行测试。并且有一个单独的服务器发送 XHProf测试的概况，并从那里进行分析，找到性能问题的所在。

视频服务器 (Red5)

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

网站还为用户提供视频服务，一种是用户上传的一段视频，还可以彼此进行分享与评价，此外，网站还有一个在线的视频聊天，在2009年中期每月视频说产生的网络流量达到17TB。网站将会寻找更换Red5 视频服务的方案，可能会选择Oneteam媒体服务器。

压力测试 (Tsung)

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

Tsung是采用Erlang编写一个分布式测试工具。在Tsung控制机器上写tsung.xml，在这个文件中指定所有的client机器地址、每台 机器的权重、模拟的用户数量 配置完成就可以进行测试了，网站用它做HTTP的 benchmarks  测试，测试 MySQL存储引擎的处理能力，例如是否需要使用新的MySQL引擎 XtraDB，并且还需要知道XtraDB的处理能力是多大，都是通过Tsung得出的结果，因为Tsung可以输出不同的格式的报告和图表信息，如图所示：

如果你有兴趣的话，可以查看Tsung详细的用户手册：http://tsung.erlang-projects.org/user_manual.html

通过Poppen.de这次的对外技术分享，整个网站在我脑海中的架构如图所示：

总结：

• 越来越多的网站由于业务的壮大，在寻求通过消息传递的，异步式架构的方案，在poppen.de中使用的RabbitMQ是Erlang编写的消息服务器，支持Java、C/C++、.Net 、PHP 等语言。
• MySQL 的第三方引擎 XtraDB 受到越来越多人的认知，MyISAM依然有用武之地，只是老大难锁表问题一直没有很好的解决办法。
• Graphite是一款不错的系统监控软件，对与一个网站来说监控其运行状态，观测硬盘、CPU的使用率，Memcached的命中率，客户的访问动向、 来源，是一件比较重要的事情， 采用Python语言写的，个人感觉Python如果能得到更好的商业支持，将来的前景会比Java好。
• CouchDB是Apache组织又一款经典产品，作为非关键性的数据进行存储是一个绝佳的方案，例如：系统中的日志。
• Memcached 和 数据库之间会逐渐的多出一个产物，比如 MongoDB ，不会像现在这样缓存和数据库2者之间有这么大的跨度。
• 凡是接触过 Erlang 的人，都会对其产生喜好，可见Erlang的势头。
• MySQL 的 官方集群方案仍然不会被人看好，但是 MySQL 的 MMM 和 MSS 依然是经典。
• Nginx的性能强大和配置简单让他成为web服务器的新宠儿， 对一些图片的访问/读写还可以使用Nginx的本地缓存 。