转载

推特Answers，一天处理50亿次会话

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 Filters 和 HyperLogLog 这样的统计算法处理以提供及时性的结果，代价是“可忽略的精确度损失”。计算结果会被Cassandra数据库再次保存起来。

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

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

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

正文到此结束