Tumblr:150亿月浏览量背后的架构挑战(上)_最新动态_新闻资讯_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 新闻资讯 > 最新动态 > Tumblr:150亿月浏览量背后的架构挑战(上)

Tumblr:150亿月浏览量背后的架构挑战(上)

 2012/2/20 9:04:39    CSDN  我要评论(0)
  • 摘要:导读:和许多新兴的网站一样,著名的轻博客服务Tumblr在急速发展中面临了系统架构的瓶颈。每天5亿次浏览量,峰值每秒4万次请求,每天3TB新的数据存储,超过1000台服务器,这样的情况下如何保证老系统平稳运行,平稳过渡到新的系统,Tumblr正面临巨大的挑战。近日,HighScalability网站的ToddHoff采访了该公司的分布式系统工程师BlakeMatheny,撰文系统介绍了网站的架构,内容很有价值。我们也非常希望国内的公司和团队多做类似分享,贡献于社区的同时,更能提升自身的江湖地位
  • 标签:浏览 架构 Tumblr

  导读:和许多新兴的网站一样,著名的轻博客服务 Tumblr 在急速发展中面临了系统架构的瓶颈。每天 5 亿次浏览量,峰值每秒 4 万次请求,每天 3TB 新的数据存储,超过 1000 台服务器,这样的情况下如何保证老系统平稳运行,平稳过渡到新的系统,Tumblr 正面临巨大的挑战。近日,HighScalability 网站的 Todd Hoff 采访了该公司的分布式系统工程师 Blake Matheny,撰文系统介绍了网站的架构,内容很有价值。我们也非常希望国内的公司和团队多做类似分享,贡献于社区的同时,更能提升自身的江湖地位,对招聘、业务发展都好处多多。

Tumblr:150亿月浏览量背后的架构挑战(上)

Tumblr:150亿月浏览量背后的架构挑战(下)

英文原文:High Scalability

  Tumblr 每月页面浏览量超过 150 亿次,已经成为火爆的博客社区。用户也许喜欢它的简约、美丽,对用户体验的强烈关注,或是友好而忙碌的沟通方式,总之,它深得人们的喜爱。

  每月超过 30% 的增长当然不可能没有挑战,其中可靠性问题尤为艰巨。每天 5 亿次浏览量,峰值每秒 4 万次请求,每天 3TB 新的数据存储,并运行于超过 1000 台服务器上,所有这些帮助 Tumblr 实现巨大的经营规模。

  创业公司迈向成功,都要迈过危险的迅速发展期这道门槛。寻找人才,不断改造基础架构,维护旧的架构,同时要面对逐月大增的流量,而且曾经只有 4 位工程师。这意味着必须艰难地选择应该做什么,不该做什么。这就是 Tumblr 的状况。好在现在已经有 20 位工程师了,可以有精力解决问题,并开发一些有意思的解决方案。

  Tumblr 最开始是非常典型的 LAMP 应用。目前正在向分布式服务模型演进,该模型基于 Scala、HBase、Redis(著名开源K-V存储方案)、Kafka(Apache 项目,出自 LinkedIn 的分布式发布-订阅消息系统)、Finagle(由 Twitter 开源的容错、协议中立的 RPC 系统),此外还有一个有趣的基于 Cell 的架构,用来支持 Dashboard(注:Tumblr 富有特色的用户界面,类似于微博的时间轴)。

  Tumblr 目前的最大问题是如何改造为一个大规模网站。系统架构正在从 LAMP 演进为最先进的技术组合,同时团队也要从小的创业型发展为全副武装、随时待命的正规开发团队,不断创造出新的功能和基础设施。下面就是 Blake Matheny 对 Tumblr 系统架构情况的介绍。

  网站地址

  http://www.tumblr.com/

  主要数据

  • 每天 5 亿次 PV(页面访问量
  • 每月超过 150 亿 PV
  • 约 20 名工程师
  • 峰值请求每秒近 4 万次
  • 每天超过 1TB 数据进入 Hadoop 集群
  • MySQL/HBase/Redis/memcache 每天生成若干 TB 数据
  • 每月增长 30%
  • 近 1000 硬件节点用于生产环境
  • 平均每位工程师每月负责数以亿计的页面访问
  • 每天上传大约 50GB 的文章,每天跟帖更新数据大约2.7TB(注:这两个数据的比例看上去不太合理,据 Tumblr 数据科学家 Adam Laiacano 在 Twitter 上解释,前一个数据应该指的是文章的文本内容和元数据,不包括存储在 S3 上的多媒体内容)

  软件环境

  • 开发使用 OS X,生产环境使用 Linux(CentOS/Scientific)
  • Apache
  • PHP, Scala, Ruby
  • Redis, HBase, MySQL
  • Varnish, HAProxy, nginx
  • memcache, Gearman(支持多语言的任务分发应用框架), Kafka, Kestrel(Twitter 开源的分布式消息队列系统), Finagle
  • Thrift, HTTP
  • Func——一个安全、支持脚本远程控制框架和 API
  • Git, Capistrano(多服务器脚本部署工具), Puppet, Jenkins

  硬件环境

  • 500 台 Web 服务器
  • 200 台数据库服务器(47 pool,20 shard)
  • 30 台 memcache 服务器
  • 22 台 Redis 服务器
  • 15 台 Varnish 服务器
  • 25 台 HAproxy 节点
  • 8 台 nginx 服务器
  • 14 台工作队列服务器(Kestrel + Gearman)

  架构

  1. 相对其他社交网站而言,Tumblr 有其独特的使用模式:

  • 每天有超过 5 千万篇文章更新,平均每篇文章的跟帖又数以百计。用户一般只有数百个粉丝。这与其他社会化网站里少数用户有几百万粉丝非常不同,使得 Tumblr 的扩展性极具挑战性。
  • 按用户使用时间衡量,Tumblr 已经是排名第二的社会化网站。内容的吸引力很强,有很多图片和视频,文章往往不短,一般也不会太长,但允许写得很长。文章内容往往比较深入,用户会花费更长的时间来阅读。
  • 用户与其他用户建立联系后,可能会在 Dashboard 上往回翻几百页逐篇阅读,这与其他网站基本上只是部分信息流不同。
  • 用户的数量庞大,用户的平均到达范围更广,用户较频繁的发帖,这些都意味着有巨量的更新需要处理。

  2. Tumblr 目前运行在一个托管数据中心中,已在考虑地域上的分布性。

  3. Tumblr 作为一个平台,由两个组件构成:公共 Tumblelogs 和 Dashboard

  • 公共 Tumblelogs 与博客类似(此句请 Tumblr 用户校正),并非动态,易于缓存
  • Dashboard 是类似于 Twitter 的时间轴,用户由此可以看到自己关注的所有用户的实时更新。与博客的扩展性不同,缓存作用不大,因为每次请求都不同,尤其是活跃的关注者。而且需要实时而且一致,文章每天仅更新 50GB,跟帖每天更新2.7TB,所有的多媒体数据都存储在 S3 上面。
  • 大多数用户以 Tumblr 作为内容浏览工具,每天浏览超过 5 亿个页面,70% 的浏览来自 Dashboard。
  • Dashboard 的可用性已经不错,但 Tumblelog 一直不够好,因为基础设施是老的,而且很难迁移。由于人手不足,一时半会儿还顾不上。

  老的架构

  Tumblr 最开始是托管在 Rackspace 上的,每个自定义域名的博客都有一个A记录。当 2007 年 Rackspace 无法满足其发展速度不得不迁移时,大量的用户都需要同时迁移。所以他们不得不将自定义域名保留在 Rackspace,然后再使用 HAProxy 和 Varnish 路由到新的数据中心。类似这样的遗留问题很多。

  开始的架构演进是典型的 LAMP 路线:

  • 最初用 PHP 开发,几乎所有程序员都用 PHP
  • 最初是三台服务器:一台 Web,一台数据库,一台 PHP
  • 为了扩展,开始使用 memcache,然后引入前端 cache,然后在 cache 前再加 HAProxy,然后是 MySQL sharding(非常奏效)
  • 采用“在单台服务器上榨出一切”的方式。过去一年已经用C开发了两个后端服务:ID 生成程序和 Staircar(用 Redis 支持 Dashboard 通知)

  Dashboard 采用了“扩散-收集”方式。当用户访问 Dashboard 时将显示事件,来自所关注的用户的事件是通过拉然后显示的。这样支撑了 6 个月。由于数据是按时间排序的,因此 sharding 模式不太管用。 

  新的架构

  由于招人和开发速度等原因,改为JVM 为中心。目标是将一切从 PHP 应用改为服务,使应用变成请求鉴别、呈现等诸多服务之上的薄层。

  这其中,非常重要的是选用了 Scala 和 Finagle

  • 在团队内部有很多人具备 Ruby 和 PHP 经验,所以 Scala 很有吸引力。
  • Finagle 是选择 Scala 的重要因素之一。这个来自 Twitter 的库可以解决大多数分布式问题,比如分布式跟踪、服务发现、服务注册等。
  • 转到 JVM 上之后,Finagle 提供了团队所需的所有基本功能(Thrift, ZooKeeper 等),无需再开发许多网络代码,另外,团队成员认识该项目的一些开发者。
  • Foursquare 和 Twitter 都在用 Finagle,Meetup 也在用 Scala。
  • 应用接口与 Thrift 类似,性能极佳。
  • 团队本来很喜欢 Netty(Java 异步网络应用框架,2月 4 日刚刚发布3.3.1最终版),但不想用 Java,Scala 是不错的选择。
  • 选择 Finagle 是因为它很酷,还认识几个开发者。

  之所以没有选择 Node.js,是因为以 JVM 为基础更容易扩展。Node 的发展为时尚短,缺乏标准、最佳实践以及大量久经测试的代码。而用 Scala 的话,可以使用所有 Java 代码。虽然其中并没有多少可扩展的东西,也无法解决 5 毫秒响应时间、49秒 HA、4万每秒请求甚至有时每秒 40 万次请求的问题。但是,Java 的生态链要大得多,有很多资源可以利用。

  内部服务从 C/libevent 为基础正在转向 Scala/Finagle 为基础。

  开始采用新的NoSQL 存储方案,如 HBase 和 Redis。但大量数据仍然存储在大量分区的 MySQL 架构中,并没有用 HBase 代替 MySQL。HBase 主要支持短地址生产程序(数以十亿计)还有历史数据和分析,非常结实。此外,HBase 也用于高写入需求场景,比如 Dashboard 刷新时一秒上百万的写入。之所以还没有替换 HBase,是因为不能冒业务上风险,目前还是依靠人来负责更保险,先在一些小的、不那么关键的项目中应用,以获得经验。MySQL 和时间序列数据 sharding(分片)的问题在于,总有一个分片太热。另外,由于要在 slave 上插入并发,也会遇到读复制延迟问题。

  此外,还开发了一个公用服务框架

  • 花了很多时间解决分布式系统管理这个运维问题。
  • 为服务开发了一种 Rails scaffolding,内部用模板来启动服务。
  • 所有服务从运维的角度来看都是一样的,所有服务检查统计数据、监控、启动和停止的方式都一样。
  • 工具方面,构建过程围绕 SBT(一个 Scala 构建工具),使用插件和辅助程序管理常见操作,包括在 Git 里打标签,发布到代码库等等。大多数程序员都不用再操心构建系统的细节了。

  200台数据库服务器中,很多是为了提高可用性而设,使用的是常规硬件,但 MTBF(平均故障间隔时间)极低。故障时,备用充足。

  为了支持 PHP 应用有 6 个后端服务,并有一个小组专门开发后端服务。新服务的发布需要两到三周,包括 Dashboard 通知、Dashboard 二级索引、短地址生成、处理透明分片的 memcache 代理。其中在 MySQL 分片上耗时很多。虽然在纽约本地非常热,但并没有使用 MongoDB,他们认为 MySQL 的可扩展性足够了。

  Gearman用于会长期运行无需人工干预的工作。

  可用性是以达到范围(reach)衡量的。用户能够访问自定义域或者 Dashboard 吗?也会用错误率。

  历史上总是解决那些最高优先级的问题,而现在会对故障模式系统地分析和解决,目的是从用户和应用的角度来定成功指标。(后一句原文似乎不全)

  最开始 Finagle 是用于 Actor 模型的,但是后来放弃了。对于运行后无需人工干预的工作,使用任务队列。而且 Twitter 的 util 工具库中有 Future 实现,服务都是用 Future(Scala 中的无参数函数,在与函数关联的并行操作没有完成时,会阻塞调用方)实现的。当需要线程池的时候,就将 Future 传入 Future 池。一切都提交到 Future 池进行异步执行。

  Scala 提倡无共享状态。由于已经在 Twitter 生产环境中经过测试,Finagle 这方面应该是没有问题的。使用 Scala 和 Finagle 中的结构需要避免可变状态,不使用长期运行的状态机。状态从数据库中拉出、使用再写回数据库。这样做的好处是,开发人员不需要操心线程和锁。

  22台Redis服务器,每台的都有8-32个实例,因此线上同时使用了 100 多个 Redis 实例。

  • Redis 主要用于 Dashboard 通知的后端存储。
  • 所谓通知就是指某个用户 like 了某篇文章这样的事件。通知会在用户的 Dashboard 中显示,告诉他其他用户对其内容做了哪些操作。
  • 高写入率使 MySQL 无法应对。
  • 通知转瞬即逝,所以即使遗漏也不会有严重问题,因此 Redis 是这一场景的合适选择。
  • 这也给了开发团队了解 Redis 的机会。
  • 使用中完全没有发现 Redis 有任何问题,社区也非常棒。
  • 开发了一个基于 Scala Futures 的 Redis 接口,该功能现在已经并入了 Cell 架构。
  • 短地址生成程序使用 Redis 作为一级 Cache,HBase 作为永久存储。
  • Dashboard 的二级索引是以 Redis 为基础开发的。
  • Redis 还用作 Gearman 的持久存储层,使用 Finagle 开发的 memcache 代理。
  • 正在缓慢地从 memcache 转向 Redis。希望最终只用一个 cache 服务。性能上 Redis 与 memcache 相当。

  (先到这里吧,敬请期待下篇,包括如何用 Kafaka、Scribe、Thrift 实现内部活动流,Dashboard 的 Cell 架构,开发流程和经验教训等精彩内容。)

  翻译:包研,张志平,刘江;审校:刘江

发表评论
用户名: 匿名