鱼漂 (一直漂)

　　在了解过世界最大的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产生数以千计的并发用户访问实验室的服务器。这样就可以在实验环境中与真实场景非常接近。

Usage: mk-table-sync [OPTION...] DSN [DSN...]

mk-table-sync synchronizes data efficiently between MySQL tables.

This tool changes data, so for maximum safety, you should back up your data before you use it. When synchronizing a server that is a replication slave with the --replicate or --sync-to-master methods, it always makes the changes on the replication master, never the replication slave directly. This is in general the only safe way to bring a replica back in sync with its master; changes to the replica are usually the source of the problems in the first place. However, the changes it makes on the master should be no-op changes that set the data to their current values, and actually affect only the replica. Please read the detailed documentation that follows to learn more about this.

Sync db.tbl on host1 to host2:

  mk-table-sync --execute h=host1,D=db,t=tbl h=host2

Sync all tables on host1 to host2 and host3:

  mk-table-sync --execute host1 host2 host3

Make slave1 have the same data as its replication master:

  mk-table-sync --execute --sync-to-master slave1

Resolve differences that mk-table-checksum found on all slaves of master1:

  mk-table-sync --execute --replicate test.checksum master1

Same as above but only resolve differences on slave1:

  mk-table-sync --execute --replicate test.checksum \     --sync-to-master slave1

Sync master2 in a master-master replication configuration, where master2's copy of db.tbl is known or suspected to be incorrect:

  mk-table-sync --execute --sync-to-master h=master2,D=db,t=tbl

Note that in the master-master configuration, the following will NOT do what you want, because it will make changes directly on master2, which will then flow through replication and change master1's data:

  # Don't do this in a master-master setup!   mk-table-sync --execute h=master1,D=db,t=tbl master2