Pixable的架构如何支持每天2000万张图片？

 

导读：Pixable正在成为轻博客Tumblr（Tumblr：150亿月浏览量背后的架构挑战）后，另外一家火爆的社交媒体，它是一个图片分享中心。不过，Pixable可以自动把你在Facebook和Twitter的图片抓取过来，每天新增图片达2000万张，他们是如何处理、保存、分析暴增的数据的呢？Pixable CTO Alberto Lopez Toledo和工程副总Julio Viera对Pixable的系统架构进行了详细说明。

Pixable通过各种社交平台聚合你的图片，你不会错过任何一个重要的瞬间。目前，Pixable每天要处理超过2000万张新增图片：抓取、分析、分类，并和已有的超过50亿张图片比较并对其排序。如何理解这些数据是很大的挑战，这其中有两个问题比较突出：

    1、每天，采取何种方式保证高效的从Facebook、Twitter、Instagram和其他应用获得上百万张图片。

    2、如何处理、组织、索引和存储关联图片的元数据。

当然，Pixable的基础架构是不断变化的，但我们也在过去一年中学到了不少东西。因此，我们已经能够建立可扩展的基础架构，这个架构建立在我们今天的工具、语言和云服务（我们的80个服务都在AWS上运行）。本文档将简要介绍这些经验教训。

后端架构-一切皆有可能

基础设施-钟爱Amazon EC2

我们所有的服务都在使用了Amazon EC2，从CentOS Linux t1.micro到m2.2xlarge都在使用。然后我们设置好服务器，建立内部的AMI。

我们为随时部署新任务做好准备，以应对负载突然增加。所以，我们始终保持最低的性能标准。

为了应对负责波动，我们开发了自动增减容技术，该技术可以根据当前和历史负荷中一天中特定的时间点预测每种服务新增的数量。然后，我们通过开启或终止一些应用来保证系统资源供给。这样，我们就可以节省下购买那些本不需要的服务器的资金。在Amazon，做到自动增减容并不容易，这需要考虑到很多变量。

举个例子：停止一个运行了半个小时的服务是毫无意义的，因为Amazon以一个小时为单位交付。同样的，Amazon花20多分钟启动一个服务也是如此。对于突发的拥堵，我们可以智能的安排需求(智能安排启动非常迅速)，将一些需求安排在下一个小时启动。这是仅仅考虑到操作层面的研究结果，目标就是榨干投资带来的所有性能。这种思想很像《Moneyball》那部电影，我们把棒球运动员换成了虚拟化服务。

我们的网站目前运行在Apache+PHP 5.3上（过段时间我们会把部分服务器调整为nginx+php-fpm，这将成为我们的标准配置）。在Amazon弹性负载均衡基础上，我们的服务器均匀的分散在不同的地区，这样我们可以消化Amazon的宕机和价格波动。我们的静态内容存储在Amazon CloudFront上，并用Amazon Route 53用于DNS服务。的确，我们爱Amazon。

工作队列-抓取图片并分级，发送通知等等

事实上，Pixable所有的工作都是异步的（例如从不同用户的Facebook上抓取图片，发送通知，计算用户的排名等）。我们有几十台服务器负责从不同的服务中抓取图片的元数据，并且进行处理。这项工作连续不断、夜以继日的进行着。

正如预期的那样，我们有各种不同类型的工作：有些需要较高的优先级，如用户时时的通话，短消息，以及抓取当前活动用户的图片。低优先级的工作包括：抓取离线用户的图片，以及长期的数据加强延迟工作。尽管我们使用了非常强大的beanstalke作为工作队列服务，但我们依然在他之上开发了管理框架。我们称之为Auto-Pilot（自动领航员），他能够自动管理优先权，将系统资源交给高权限的工作，并停止优先权低的工作。

我们开发了非常复杂的优先权处理规则，同时考虑到系统性能和用户体验。一些指标很容易衡量，比如工作的平均等待时间，系统主从服务器之间的延迟时间等（我们从来没有延迟）。更多的是一些复杂的指标，如我们自己的PHP同步互斥的状态的分布式锁环境。我们尽可能的在性能和效率间做出公平的权衡。

抓取引擎-通过Facebook、Twitter和其他全天候的网站抓取新图片

我们内部不断的提高抓取技术，这是一种复杂的并行算法，通过互斥锁库，同步特定用户的所有进程。这种算法帮我们在Facebook上抓取图片的速度提高了至少5倍。现在，每天我们可以很容易地获取超过20万张新图片。 这是相当了不起的，事实上，任何对Facebook API的大型数据请求只能持续几秒钟。在正文后附属文件会深入探讨我们的抓取引擎。

数据存储-对图片和元数据进行索引

目前，90%的数据通过MySQL存储（在一个分布式缓存在其之上建立）在两组服务器上。第一组采用2主2从设计，存储那些规则的数据，如用户的信息、全球分类设置和其他系统参数。

第二组包含手动共享服务器，用来存储用户图片的相关信息，如图片的URL地址。这部分数据是高度非标准化的，仅在MySQL表中（NoSQL在MySQL中）我们采用了NoSQL方案，如MongoDB。所以，另外10%的数据通过MongoDB存储！我们正在部分的迁移到MongoDB，主要因为其简单且灵活，并提供分区和重写（sharding and replication）功能。

日志，剖析和分析

我们开发了高度灵活的日志和剖析框架，允许日志高粒度且细化到每行代码。每个事件日志都被按照标签分类供以后查询（例如用户X的事件，或者在模块Y调用）。重要的是，我们能动态的分析某一时间点的所有日志事件，建立整个系统的实时分析。日志和分析系统对存储系统的压力非常大（每秒钟数千次更新），所以我们将两个级别的MySQL表结合在一起（一个基于内存的快速缓存，对实时数据而言服务器就像一个有遗撒的桶），并结合一些分离的MySQL表（稍后数据将异步到表中）。这个架构每秒可处理超过1.5万条日志。我们有自己的事件跟踪系统，包括每个用户从登录到分享到个性化的点击，我们可以在以后查询分析这些复杂记录行动。

我们也依赖出色的Mixpanel服务，帮我们完成高标准的分析和报告。

前端 - 简单的可视化设备

Pixable可在各种（前端）设备上运行，如iPhone和iPad。我们也有网页版和移动网页版，他们只读取一个简单的网页，剩下的任务全部交给客户端的jQuery和Ajax完成。很快，我们所有的网站前端将运行一个单一的代码库，自动适应移动或桌面屏幕（请尝试 http://new.pixable.com ）。这样，我们可以在主要网站上使用相同的代码，包括在Android设备和Chrome浏览器的扩展。事实上，我们的Andr​​oid版App结合了移动web前端程序。Andr​​oid版App申请最小的框架控制权，并在其中显示移动web的内容。

这听起来有点苛刻，但我们所有的前端是“哑巴”。 所有繁重的任务通过我们自己的私有API连接在后台执行。 这使我们能够快速开发和部署，而无需改变已有的用户基础。 灵活的，宝贝！

API-连接我们的前端和后端

API就像胶水，使一切一起工作。用Tonic PHP开发我们自己的RESTful API，用来连接后台功能。我们还Tonic PHP基础上做了开发。这样一来，当开发新的功能或改变API的响应格式时，可保持向后兼容性。我们只配置那些支持API调用的版本。我们保留所有的老版本API，多老的移动设备不用担心兼容问题。

其实API仅仅将前端和后端进行连接，事实上并没有做任何工作。后端是Pixable的核心。(编译/包研)