Tumblr：150亿月浏览量背后的架构挑战
|
之所以没有选择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实现的。当需要线程池的时候，就将Future传入Future池。一切都提交到Future池进行异步执行。 Scala提倡无共享状态。由于已经在Twitter生产环境中经过测试，Finagle这方面应该是没有问题的。使用Scala和Finagle中的结构需要避免可变状态，不使用长期运行的状态机。状态从数据库中拉出、使用再写回数据库。这样做的好处是，开发人员不需要操心线程和锁。 22台Redis服务器，每台的都有8-32个实例，因此线上同时使用了100多个Redis实例。 1、Redis主要用于Dashboard通知的后端存储。 2、所谓通知就是指某个用户like了某篇文章这样的事件。通知会在用户的Dashboard中显示，告诉他其他用户对其内容做了哪些操作。 3、高写入率使MySQL无法应对。 4、通知转瞬即逝，所以即使遗漏也不会有严重问题，因此Redis是这一场景的合适选择。 5、这也给了开发团队了解Redis的机会。 6、使用中完全没有发现Redis有任何问题，社区也非常棒。 7、开发了一个基于Scala Futures的Redis接口，该功能现在已经并入了Cell架构。 8、短地址生成程序使用Redis作为一级Cache，HBase作为永久存储。 9、Dashboard的二级索引是以Redis为基础开发的。 10、Redis还用作Gearman的持久存储层，使用Finagle开发的memcache代理。 11、正在缓慢地从memcache转向Redis。希望最终只用一个cache服务。性能上Redis与memcache相当。 内部的firehose(通信管道) 内部的应用需要活跃的信息流通道。这些信息包括用户创建/删除的信息，liking/unliking的提示，等等。挑战在于这些数据要实时的分布式处理。我们希望能够检测内部运行状况，应用的生态系统能够可靠的生长，同时还需要建设分布式系统的控制中心。 以前，这些信息是基于Scribe(Facebook开源的分布式日志系统。)/Hadoop的分布式系统。服务会先记录在Scribe中，并持续的长尾形式写入，然后将数据输送给应用。这种模式可以立即停止伸缩，尤其在峰值时每秒要创建数以千计的信息。不要指望人们会细水长流式的发布文件和grep。 内部的firehose就像装载着信息的大巴，各种服务和应用通过Thrift与消防管线沟通。(一个可伸缩的跨语言的服务开发框架。) LinkedIn的Kafka用于存储信息。内部人员通过HTTP链接firehose。经常面对巨大的数据冲击，采用MySQL显然不是一个好主意，分区实施越来越普遍。 firehose的模型是非常灵活的，而不像Twitter的firehose那样数据被假定是丢失的。 firehose的信息流可以及时的回放。他保留一周内的数据，可以调出这期间任何时间点的数据。 （编辑：济南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
