导读：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上抓取图片，发送通知，计算用户的排名等）。我们有几十台服务器负责从不同的服务中抓取图片的元数据，并且进行处理。这项工作连续不断、夜以继日的进行着。