Twitter 架构优化之路--Twitter是如何做到每秒处理3000张图片的
如今,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中,缺乏垃圾回收机制。
读取方式
用户查看推文以及相关联的图片。图片的来源是哪里?
客户端从CDN请求图片的变体,这个CDN可能需要向原点与Twitter前端请求图片,最终导致在BlobStore中直接查找特定大小、特定URL上的图片。
问题五: 不可能引入新的变体
设计上不够灵活,增加新的变体也就是不同尺寸的图片的话,需要在BlobStore中为每张图片回填新的图片大小,缺乏按需增加变体的机制。
由于缺乏灵活性,Twitter很难在客户端新增功能。
现在——2016年的Twitter
写入方式
将上传与发推解耦。
上传被设置为首要的,上传终端建立后,唯一的职责就是将原始媒体放在BlobStore中。
给上传方式增加了许多灵活性。
客户端与TFE会话,TFE与图片服务器会话,图片服务器将图片放置在BlobStore中,并向元数据存储添加数据,就是这样,没有其它相关的隐藏服务。
媒体ID(mediaId)是媒体唯一的标识符,由图片服务器返回。如果用户在客户端想要创建推文、DM或者上传个人资料照片时,系统会使用mediaID作为媒体的引用句柄,而不是直接使用媒体本身。
假设我们想要用刚刚上传的媒体来创建推文,流程如下:
客户端找到更新端点,在推文中加入mediaId;这些内容会被发送到Twitter前端;Twitter前端会将其引入合适的服务中,来执行创建。对于推文来说,使用的服务是TweetyPie,而DM和个人资料会使用其它服务;所有服务都会与图片服务器对话;图片服务器上有推文处理队列机制,可以执行类似人脸检测与儿童色情检测之类的功能;检测完成后,图片服务器与负责图片的ImageBird或者负责视频的VideoBird会话;ImageBird会生成图片变体;VideoBird会执行一些转码工作;无论如何,生成的媒体都会被放在BlobStore上。
不会直接发送媒体本身,从而节省了大量之前被浪费的带宽。
分段可恢复的上传:
用户走进地铁,没有信号;10分钟后出来,信号恢复,这时上传过程会从断开的地方自动恢复。对于用户来说整个过程是无缝的。
客户端通过上传API来初始化上传进程,后端会发给它一个mediaId,在整个上传进程中,这个mediaId都会被用作标识符。
一张图片被分为几部分,比如三个部分。通过API来append每个部分,每个append调用都会有段索引,所有append的mediaId都是相同的。上传完成后,意味着上传过程终结,媒体可供使用。
这个办法更能适应网络故障的情况,每个单独的部分都可以重试,如果网络由于某种原因而产生中断,那么暂停上传,等待网络恢复后继续该部分的上传。
简单的方法带来了巨大的收益。对大于50KB的文件,图片上传的故障率在巴西高达33%,在印度高达30%,在印尼则为19%。
读取方式
引入了名为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%的失败率,慢速连接的用户确实能获得极大改善。
Twitter 架构优化之路--Twitter是如何做到每秒处理3000张图片的的更多相关文章
- 解密 Uber 数据团队的基础数据架构优化之路
如果你用过Uber,你一定会注意到它的操作是如此的简单.你一键叫车,随后车就来找你了,最后自动完成支付,整个过程行云流水.但是,在这简单的流程背后其实是用Hadoop和Spark这样复杂的基础大数据架 ...
- 新浪微博iOS客户端架构与优化之路
新浪微博iOS客户端架构与优化之路 随着Facebook.Twitter.微博的崛起,向UGC.PGC.OGC,自媒体提供平台的内 容消费型App逐渐形成了独特的客户端架构模式.与电商和通讯工具类 ...
- 架构师之路-在Dubbo中开发REST风格的远程调用
架构师之路:从无到有搭建中小型互联网公司后台服务架构与运维架构 http://www.roncoo.com/course/view/ae1dbb70496349d3a8899b6c68f7d10b 概 ...
- 微博MySQL优化之路--dockone微信群分享
微博MySQL优化之路 数据库是所有架构中不可缺少的一环,一旦数据库出现性能问题,那对整个系统都回来带灾难性的后果.并且数据库一旦出现问题,由于数据库天生有状态(分主从)带数据(一般还不小),所以出问 ...
- 【IT名人堂】何云飞:阿里云数据库的架构演进之路
[IT名人堂]何云飞:阿里云数据库的架构演进之路 原文转载自:IT168 如果说淘宝革了零售的命,那么DT革了企业IT消费的命.在阿里巴巴看来,DT时代,企业IT消费的模式变成了“云服务+数据”, ...
- 转:微信Android客户端架构演进之路
转自: http://www.infoq.com/cn/articles/wechat-android-app-architecture 微信Android客户端架构演进之路 作者 赵原 发布于 20 ...
- 阿里巴巴 web前端性能优化进阶路
Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践.可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化 ...
- 美团点评基于MGR的CMDB高可用架构搭建之路【转】
王志朋 美团点评DBA 曾在京东金融担任DBA,目前就职于美团点评,主要负责金融业务线数据库及基础组件数据库的运维. MySQL Group Replication(以下简称MGR),于5.7.17版 ...
- QPS从0到4000请求每秒,谈达达后台架构演化之路(转载)
https://blog.csdn.net/czbing308722240/article/details/52350219 QPS从0到4000请求每秒,谈达达后台架构演化之路 达达是全国领先的 ...
随机推荐
- border三角形阴影(不规则图形阴影)和多重边框的制作
前言:这是笔者学习之后自己的理解与整理.如果有错误或者疑问的地方,请大家指正,我会持续更新! 1. border的组合写法 border:border-width border-style borde ...
- Python 破解带密码保护的Zip文件
今天发生了个有趣的事情,有个朋友发了一个带密码保护的Zip文件给我,却不给我密码,我就琢磨这怎么可以'猜'到密码呢? 经过一系列的尝试,最终使用python把这个密码给'猜'出来了.要想写出破解密码的 ...
- 虚拟机工作站创建虚拟机并安装Linux教程
前言: 今天开始学习一下Linux,之前早就想看,但是一直没时间,最近把其他知识整理完了,终于有时间来看一下Linux了. 本节只是安装虚拟机工作站,虚拟机,和Linux操作系统的过程,详细的记录了我 ...
- 系统引导修复 ---- Windows 和 Ubuntu
Windows: 1.准备windows相应镜像盘,u盘启动该系统 (以下均为windows10安装界面) 2.进入安装界面<语言,时间,键盘格式>,点击"下一步" 3 ...
- [Vijos 2024]无向图最短路径
Description 无向图最短路径问题,是图论中最经典也是最基础的问题之一.本题我们考虑一个有 $n$ 个结点的无向图 $G$.$G$ 是简单完全图,也就是说 $G$ 中没有自环,也没有重边,但任 ...
- [HNOI2012]排队
题目描述 某中学有 n 名男同学,m 名女同学和两名老师要排队参加体检.他们排成一条直线,并且任意两名女同学不能相邻,两名老师也不能相邻,那么一共有多少种排法呢?(注意:任意两个人都是不同的) 输入输 ...
- [BZOJ]4162: shlw loves matrix II
Time Limit: 30 Sec Memory Limit: 128 MB Description 给定矩阵 M,请计算 M^n,并将其中每一个元素对 1000000007 取模输出. Inpu ...
- 51 nod 1188 最大公约数之和 V2
1188 最大公约数之和 V2 题目来源: UVA 基准时间限制:2 秒 空间限制:262144 KB 分值: 160 难度:6级算法题 给出一个数N,输出小于等于N的所有数,两两之间的最大公约数 ...
- bzoj 3679: 数字之积
Description 一个数x各个数位上的数之积记为\(f(x)\) 求[L,R)中满足\(0<f(x)<=n\)的数的个数 solution 最后\(f(x)\)可以拆分成2,3,5, ...
- poj 2653 线段与线段相交
Pick-up sticks Time Limit: 3000MS Memory Limit: 65536K Total Submissions: 11884 Accepted: 4499 D ...