Twitter是如何做到每秒处理3000张图片的？

2顶
1踩

2016-04-27 11:20 by 副主编 mengyidan1988 评论(0) 有7587人浏览

twitter

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

原文：How Twitter Handles 3,000 Images Per Second
编译：孙薇
如今，Twitter每秒可以创建并保存3000张（20GB）的图片。2015年，Twitter甚至从对媒体存储策略的优化中节省出了600万美元。

但并非一开始就是这样的，2012年Twitter还主要是基于文本的，就像《哈利波特》中的霍格沃茨魔法学校没有了那些悬挂在墙上的炫酷活动照片一样。如今已经是2016年，Twitter已进入了富媒体未来时代。在新媒体平台发展的过程中，Twitter可以支持照片预览、多张照片、gif图、Vine短片以及在线视频。

Twitter的软件开发工程师Henna Kermani在Mobile @Scale London的谈话中提及，这个媒体平台每秒能够处理3000张图片。虽然这次谈话的主要话题是讨论图片管道，但她表示其中的大多细节也适用于其他的媒体类型。

这次谈话所总结的心得中，一些最有趣的内容摘录如下：

按照可能奏效的最简单方式来执行，结果真的会让你大吃一惊：发送一条带图片的推特是一个要么全有要么全无的操作，最简单的方式就是锁定。由于无法很好地扩展，尤其是网络状况不佳的情况下，Twitter很难再增加新功能。
分离处理：将发推与发送媒体分离，通过解耦的方式来处理，Twitter便可分别优化各个途径，同时还能大幅增进操作灵活性。
移动handle（句柄），而不要移动blob（二进制大对象）：不要在系统中执行大块的数据移动，这样会消耗掉带宽，并导致接触到数据的各个服务有性能上的问题。请存储数据，并使用handle来引用。
改用分段的、可恢复的上传操作能够大幅降低媒体上传的失败率。
实验与研究： Twitter在研究中发现：将各类图片变体（缩略图、小图、大图等）的TTL（存活时间）设为20天可以让存储与计算达到最有效、最优秀的平衡。图片在20天之后的访问概率很低，删除后每天能节省下来的存储空间几乎有4TB——达到计算服务器需要数值的近乎一半，这样做之后每年能节省数百万美元。
按需操作：我们可以删除旧图片的变体，是因为它们能在瞬间完成重建，而无需预计算。根据需求来执行服务能够增加灵活性，并在任务执行的方式上更为智能，控制时也更集中化。
渐进式JPEG（Progressive JPEG）是标准图片格式的真正优胜者：不但前端和后端对其支持都很优秀，在速度较慢的网络中，这类图片的效果也很好。
在Twitter发展为富媒体未来的过程中，有许许多多好事发生，让我们来一一解读。

过去——2012年的Twitter
写入方式
用户在应用中编辑一条推文，或许再附上一张图片。

客户端将这条带图推文发送给单一整体式端点。上传时，推文中的图片和其他元数据是捆绑在一起，发送给过程中所涉及的单体服务的。

在旧式设计中，端点就是诸多问题产生的根源。

问题一：浪费大量带宽

创建一条推文与上传媒体，两者在一个操作中紧密耦合。

上传的动作是一个整体，要么全部成功，要么全部失败。无论失败的原因是什么——网络临时中断、暂时出错等等，都需要将整个过程从头来过，包括要重新上传媒体。如果在上传到95%的时候出现故障而导致失败，就必须重新再次上传。

问题二：对较大的新型媒体来说，缺乏良好的扩展

这种办法缺乏针对大型媒体，比如视频的扩展性。媒体越大，失败的可能性也越大，特别是在IT业的新兴市场，比如巴西、印度、印尼等地，由于网速慢、网络可靠性差，这个问题更加严重，确实很需要增加上传的成功率。
问题三：内部带宽的使用效率低下

终端与TFE（Twitter前端）相连，而TFE则负责用户身份验证，并将用户分配到不同图片服务器（Image Service）。

图片服务器与图片变体生成器（Variant Generator ）会话，并生成不同大小的图片实例（比如小图、中图、大图、缩略图）。图片变体存储在BlobStore中，这是一个针对类似图片和视频等大型有效载荷而优化的key-value存储系统，存储在其中的图片是永久性的。

创建及保存推文的过程中，还涉及了许多其他服务。由于终端是单一整体式的，媒体与推文的元数据结合在一起，也会流经所有的服务。这个大型有效载荷被发送给直接负责图片的服务，这些服务并不属于媒体管道，但仍被强制执行大型有效载荷的优化。这种办法在内部带宽中效率非常低。

问题四：臃肿的存储空间

推文中的图片在数月或数年后已经不再会被调用了，但仍存于BloStore中占用空间。有时甚至在推文被删除后，图片仍存在于BlobStore中，缺乏垃圾回收机制。

读取方式
引入了名为MinaBird的CDN源服务器（Origin Server ）。

MinaBird可以与ImageBird、VideoBird对话，因此如果没有的话，可以立即生成相应大小的图片及视频格式。
MinaBird在执行客户端请求时，更为动态也更为流畅。比如因为版权问题而需要将某个内容屏蔽，使用MinaBird可以很容易地对特定某条媒体执行屏蔽及恢复的操作。
能够实时生成需求大小的图片与视频格式转码，Twitter在存储上的智能性也更高了。

按需生成要求的媒体变体意味着无需在BlobStore中存储所有的变体。这是一个巨大的胜利。

原始媒体直到删除前都存储在BlobStore中，而变体只保存20天。媒体平台团队做了很多关于最佳保存时限的研究，所有请求的图片中，大约50%只保存15天，按收益率递减结果，删除较早的图片。很旧的媒体很可能没有人会发起相应的请求，在15天后会有很长的长尾期。

如果不设定TTL（存活时间）和过期时间，每天增加的媒体存储量有6TB。懒办法就是按需生成所有媒体变体，导致媒体存储增长为1.5TB。20天TTL所使用的存储空间比懒办法多不了多少，因此不会占用太大的存储空间，但在计算上这是一个巨大的胜利。使用懒办法来计算，读取所有变体需要在每个数据中心设置150个ImageBird，而使用20天TTL的话，只需要75个ImageBird。因此20天TTL是令计算和存储达到最有效、最平衡的时间点。

由于节省存储空间和计算资源就是节省金钱，引入20天TTL之后，在2015年Twitter节省下了600万美元。

客户端优化（安卓）

在使用WebP（谷歌创建的一种图片格式）进行了6个月的实验之后，

这种图片比相应的PNG或JPEG图片要小25%。

这样一来，特别是在新兴市场，由于较小的图片对网络压力也较小，因而用户参与度也更高。

由于不支持iOS系统，并且只支持安卓4.0以上的系统，缺少平台的支持使得WebP格式花费巨大。

于是Twitter尝试了另一个选项，渐进式JPEG格式。由于通过连续扫描的形式来渲染，首次扫描可能是块状的，但在连续扫描的过程中会逐渐自我完善。

这种格式的性能更佳。

后端很容易支持。

这种格式比传统JPEG格式的编码速度慢了60%，由于一次编码，多次服务，因此这不算大问题。

渐进式JPEG图片不支持透明图片，因此保留了透明的PNG图片，除此之外其它都使用了渐进式JPEG。

客户端由Facebook的Fresco库提供支持，Fresco的优点很多。在2G网络下，效果令人印象深刻。第一次扫描PJPEG图片只用了10kb流量，因此加载时间不长，在本地管道还等待加载，什么都没显示的时候，PJPEG已经显示出了可识别的图像。

有正在进行的实现结果显示，负载细节如下：减少了9%的P50加载时间，减少了27%的P95加载时间，减少了74%的失败率，慢速连接的用户确实能获得极大改善。

分享到：