推特 Answers,一天 50 亿次会话处理是如何做到的?

  • Sergio De Simone
  • 楚晗

2015 年 3 月 25 日

话题:架构语言 & 开发

Answers是 Twitter 的移动 APP 分析业务,它现在可以一天处理 50 亿次的会话。Ed Solovey 是推特的软件工程师,他描述了他们的系统是如何工作以提供“可靠、实时和可行动”的数据,这些数据是基于亿万个移动设备每秒发送的百万次的事件。

如 Solovey 所讲述,Answers 涉及的主要职责包括:

  • 接收事件 ;
  • 收集归档这些事件 ;
  • 进行离线和实时的计算 ;
  • 合并这些计算结果并产生相关性的信息

负责从设备接收事件的服务是用 Go 语言写的,并且它使用了亚马逊的弹性负载均衡器( Amazon Elastic Load Balancer)。它将每个消息负荷放入到持久化的Kafka队列中。Kafka 可以存储大量的事件,但这里的存储应仅仅被用作一种临时性的缓存,它可以保存几个小时有价值的数据。而接下来Storm会传输数据到 Amazon S3 中完成存储。

当数据存储到 S3 中后,Amazon Elastic MapReduce就会对数据进行批次性计算处理。计算的结果会存储到Cassandra数据库集群中,可以通过 API 来查询使用。

到这里,故事只讲了一半。剩下比较确切的是 Answers 可以实时性地处理数据。在这个目标中,Kafka 存储的内容被输送到 Storm,在 Storm 中这些数据会被像Bloom FiltersHyperLogLog这样的统计算法处理以提供及时性的结果, 代价是“可忽略的精确度损失”。计算结果会被 Cassandra 数据库再次保存起来。

所以处理结束后,Cassandra 既保存了批处理计算结果,也保存了实时计算的结果。查询 API 负责合并这两种计算流,并基于查询参数给出一致性的视图。当它们都可用时,批处理计算的结果更优先一些,因为它们更准确,如果批处理计算结果不可用时,就会优先使用实时性计算结果。

按 Solovey 所说,描述的这种架构在故障处理的情况下也是有效的,这要归功于连接 Answers 组件时使用了持久化的队列。这也保证了一个组件的任何中断不会影响其它的组件。所以,这种架构可以保证从故障中恢复,并且假设系统能在给定时间内恢复正常,那么就能保证数据不被丢失。

查看英文原文How Twitter Handles Five Billion Sessions a Day

架构语言 & 开发