Poppen.de的技术架构分享

Poppen.de是一个德国的 交友/ 聊天/ 视频 的SNS网站, 部分内容 NSFW，网站采用了很多我们熟悉的技术，像Nginx ，MySQL，CouchDB，Erlang，Memcached的，RabbitMQ(消息服务器)，采用了Graphite作为网站的系统监控，Red5作为视频服务，Tsung作为压力测试工具，选择的技术种类较多，还采用 PHP和 Erlang 2种程序语言作为不同功能的开发。

关于 Poppen.de 的资料统计数据
    *  2 000 000 用户数
    *  20.000并发用户数
    *  300.000条私人讯息/每天
    *  250.000登录/每天
功能概要
    * 用户在线搜索其他用户；
    * 站内对方写私人消息；
    * 用户上传图片和视频；
    * 用户与用户之间的在线视频聊天。
 Poppen.de整个网站的技术团队有 11个人开发人员，2个界面设计师和两个系统管理员。

H.E的口水1：
Poppen.de 是德国的成人交友/约会网站， 小朋友不要随便上哦，网站里的内容很开放，有很多怪叔叔(Gay)，呵呵。与Facebook这样巨头网站相比算是一个小型网站了，但是通过Poppen.de网站这次对外的技术信息分享，可以看出网站有个不错的技术架构，让我们可以从中得到很多值得学习与借鉴的内容。 
H.E的口水2：
NSFW这个英文缩写常常出现在Blog中，表示某个站点含有露点或者极度暴力的内容，如果你在上班的时候打开这个网站你的同事经过你身边的时候估计会让你很尴尬，呵呵。所以在我 朝廷的大局域网内是无法打开这个站点，如果一定要满足自己的好奇心，你可以动动脑筋看看有什么办法。看看我 Fang Qiang后的截图，如图所示：

查看大图请点击这里

系统架构描述：

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

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

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

* 消息服务器
整个网站采用的算是一种分布式的异步架构体系，中间采用RabbitMQ作为异步通讯服务器，通过上层28台PHP Ap Server做成的LVS集群对下层2台集群的 RabbitMQ 消息系统进行调用，这里消息系统主要用来发送运行日志，电子邮件通知，系统消息，用户图片上传，每天大约需要处理 500.000条消息，这样的架构体系可以对系统的运行性能有所改善，在Javabloger看一般有3个原因：    
     第一是加强了系统的可扩展性，
     第二是提高系统资源的使用率，
     第三是降低系统运行中瞬间的瓶颈。
比如在系统繁忙的时间里，每分钟有1000个用户进行登录,这意味着我们将有1000个并发的用户请求需要对缓存/数据库表的更新，但是现在有了消息队列的架构，我们可以运行他们每个顺序相反。如果我们需要更多的处理速度，我们可以添加更多的消费者到消息队列，还可以加入更多的机器到MQ消息群集中，不需要修改以前任何的配置或部署任何新的代码。网站表示系统将来会向异步式架构发展，将更多的业务放入RabbitMQ 系统队列中进行处理。

进一步的了解  RabbitMQ产品，详见下面的 幻灯片：

H.E的口水1：
  在2010年4月份中旬， VMware旗下的SpringSource 将RabbitMQ给收购了，不过这次收购应该是一件好事，因为SpringSource计划对RabbitMQ开发者社区提供全方位的支持，另外，SpringSource还针对此次收购发布了一个FAQ。详见： http://www.springsource.com/rabbit-technologies-acquisition-faq

H.E.的口水2:
来自2位国内/外网友的经验分享 ( Ref1) ( Ref2) ( Ref3)
1.RabbitMQ支持AMQP协议，而ZeroMQ的极为简单。
2.RabbitMQ较慢，几十个并发以内，延时为几十毫秒，但当客户端达到1000个并发的时候，速度就无法容忍了（参考）；ZeroMQ上则据称可以达到13毫米延时和高达每秒4.1兆次传递（参考, 国内需要FQ才能访问）。
3.如果队列较多的话，RabbitMQ很容易把内存耗尽，而ZeroMQ则把队列内容保存在发送端。
4.JMS仅仅是Java领域内的API规范，只能说AMQP比JMS更先进，它有自己的wire-level protocol 可编程的协议，并且RabbitMQ服务器充分利用了Erlang的分布式、高可靠性、并发等特性，而并不能一概而论的说JMS没有RabbitMQ服务器好与坏。
  
* 分布式文档数据库(CouchDB)
系统中运行CouchDB的服务器只有一台，主要是用来存日志的，因为在过去我们需要查看某台机器的日志需要登录某台机器进行tail -f 的查看，如果机器一多肯定混乱，采用CouchDB 中一些查询方法 query/group 就会让工作简化很多，而且采用分布式文档数据库存放系统日志似乎真的很合理，而且管理，使用也不算很复杂。Javabloger前端时间一个人看管了15台机器，需要查看日志的时候还真的有点不方便，所以日后会在项目中尝试一下将日志系统进行集中化处理的方案。

* 数据库服务器
采用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采用简单的文本协议和绘图功能可以方便地使用在任何操作系统上。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。网站将会寻找更换Red5 视频服务的方案，可能会选择Oneteam媒体服务器。

* 压力测试 (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这次的对外技术分享，整个网站在我脑海中的架构 如图所示，这只是我的猜想，与实际的架构有出入，请多多见谅：

查看大图请点击这里

Javabloger的总结：

1.越来越多的网站由于业务的壮大，在寻求通过消息传递的，异步式架构的方案，在poppen.de中使用的RabbitMQ是 Erlang编写的消息服务器，支持Java、C/C++、.Net 、PHP 等语言。

2.MySQL 的第三方引擎 XtraDB 受到越来越多人的认知，MyISAM依然有用武之地，只是老大难锁表问题一直没有很好的解决办法。

3.Graphite是一款不错的系统监控软件，对与一个网站来说监控其运行状态，观测硬盘、CPU的使用率，Memcached的命中率，客户的访问动向、来源，是一件比较重要的事情， 采用Python语言写的，个人感觉Python如果能得到更好的商业支持，将来的前景会比Java好。

4.CouchDB是Apache组织又一款经典产品，作为非关键性的数据进行存储是一个绝佳的方案，例如：系统中的日志。

5.Memcached 和 数据库之间会逐渐的多出一个产物，比如  MongoDB ，不会像现在这样缓存和数据库2者之间有这么大的跨度 。

6.凡是接触过 Erlang 的人，都会对其产生喜好，可见Erlang的势头。

7.MySQL 的 官方集群方案仍然不会被人看好，但是 MySQL 的 MMM 和 MSS 依然是经典。

8.Ngixn的性能强大和配置简单让他成为web服务器的新宠儿， 对一些图片的访问/读写还可以使用Ngixn的本地缓存 。